flat assembler
Message board for the users of flat assembler.
Index
> DOS > problem with unREAL mode fasm Goto page Previous 1, 2, 3, 4, 5 |
Author |
|
rugxulo 24 Feb 2009, 07:13
DOS386 wrote:
I disagree, searching for CWSDPMI or HDPMI32 would be a good idea, IMHO (or even CWSDPR0 if you really want to avoid swapping). You could always make this configurable via environment variable like EMX and RSX do: "set EMX=c:\dos\rsx.exe" will force RSX (DPMI) instead of EMX (VCPI). So "set DPMI=MWDPMI" (or whatever) could override the default search. Then again, I guess nobody will die with the current setup. But I don't think it's a bad idea to try loading one (as all DJGPP apps do, and nobody complained, but it's configurable too). |
|||
24 Feb 2009, 07:13 |
|
DOS386 24 Feb 2009, 08:05
rugxulo wrote: searching for CWSDPMI or HDPMI32 would be a good idea In reversed order at worst Quote: You could always make this configurable via environment variable like EMX and RSX do: "set EMX=c:\dos\rsx.exe" will force RSX (DPMI) instead of EMX (VCPI). So "set DPMI=MWDPMI" (or whatever) could override the default search. EMX + RSX dead stuff again ... I prefer a clear "No DPMI host" message from silent searches sensitive to 1'000'000 undocumented enviral variables with unpredictable results and all the CWSDPMI.SWP, buggy CWSDPMI versions and related mess _________________ Bug Nr.: 12345 Title: Hello World program compiles to 100 KB !!! Status: Closed: NOT a Bug |
|||
24 Feb 2009, 08:05 |
|
pfranz 01 May 2009, 08:11
I'd like to have the last DOS fasm version which runs in unreal mode. Which one is it? Can someone provide it? Thank you
|
|||
01 May 2009, 08:11 |
|
rugxulo 02 May 2009, 10:03
Either wait for 1.68 or use something like 1.67.23 (or maybe .37, I forget).
|
|||
02 May 2009, 10:03 |
|
Czerno 02 Jun 2009, 09:06
This thread is old but I'm a newcomer so please let me resurrect it.
What is the problem anyway ? There may be a misunderstanding here, but are you (Thomasz) saying that you are blocked from expanding the code segment over 64 k in "huge" real mode (CS.D=1) ? That doesn't need to be so. True, the processor doesn't auto-save the high part of EIP on interrupts, but the "user level" code itself can save that to a convenient system-accessible place whenever it changes and be restored by the 2-stage interrupt return code. A 'convenient' place to store high EIP often means the CR3 (but I think you are using it for another purpose) or CR2 but could be to a fixed place in low memory, too. You organise the user code inside of 64 k byte large sections (pseudo-segments, so to say) such that each section has a relatively small number of entry from the other section(s). Whenever jumping ('near' jumping of course) between different sections, adjust the saved high EIP. Pray tell, guys, does this make sense for FASM ? |
|||
02 Jun 2009, 09:06 |
|
Tomasz Grysztar 02 Jun 2009, 11:28
There are even simpler solution that do not require using huge EIP at all. The only problem is that fasm's source are written in an OS-independent way which makes any tricks a bit harder to do.
Still, I already designed a good method to deal with this in future, when needed (for now fasm's code still fits into the 64k). So this thread is really obsolete now. |
|||
02 Jun 2009, 11:28 |
|
Czerno 02 Jun 2009, 16:14
Tomasz Grysztar wrote: There are even simpler solution that do not require using huge EIP at all. The only problem is that fasm's source are written in an OS-independent way which makes any tricks a bit harder to do. Sure! Quote: I already designed a good method to deal with this in future, when needed (for now fasm's code still fits into the 64k). Thank you, keep the good work done ! and please keep us updated. Quote: So this thread is really obsolete now. I hoped we could talk about VMware (in)compatibility with exotic real modes, since there is no good way to report bugs to them unless you have a support contract. Should i open a new thread, or is it off topic on the here board ? Regards -- Czerno |
|||
02 Jun 2009, 16:14 |
|
DOS386 04 Jun 2009, 14:11
> Either wait for 1.68 or use something like 1.67.23
Get 1.67.29 > I hoped we could talk about VMware (in)compatibility with exotic real modes Better run DOS natively Tomasz wrote: > Still, I already designed a good method to deal with this in future, > when needed (for now fasm's code still fits into the 64k). So it will be in 1.68 ? Please look into the IDE BUG also > So this thread is really obsolete now. NOT yet. |
|||
04 Jun 2009, 14:11 |
|
Tomasz Grysztar 04 Jun 2009, 14:37
DOS386 wrote: So it will be in 1.68 ? There is no need for it to be applied to 1.68, because right now the code still fits under the limit. |
|||
04 Jun 2009, 14:37 |
|
Czerno 06 Jun 2009, 07:58
Folks ! Are there any X86 virtualisation systems that cope with FASM huge real mode properly ? Care to test, anyone ?
VMware fails, Virtual PC fails as well (tested VPC 5.1. I have little hope newer MS VPC might fare better). Bochs (emulator, not a VM; slow!) does well ! Please report test results under other VMs that can boot a DOS (Virtual BOX/Parallels/QEMU...) Testing is easy : boot a VM to DOS from a real or virtual floppy containing a copy of FASM - real mode DOS, no expanded memory manager - From the DOS command line : a) launch FASM (no parameters) : it should print its help message. b) (optional) check if it can FAsSeMble a short "hello world" sample. What gives ? |
|||
06 Jun 2009, 07:58 |
|
Mac2004 06 Jun 2009, 08:21
Czerno: How about Virtualbox? I haven't tested it by myself, though...
Regards, Mac2004 |
|||
06 Jun 2009, 08:21 |
|
DOS386 06 Jun 2009, 10:11
> VMware fails, Virtual PC fails as well
Good. > Bochs (emulator, not a VM; slow!) does well ! Good. > a) launch FASM (no parameters) : it should print its help message. > b) (optional) check if it can FAsSeMble a short "hello world" sample. Don't forget c): self-compiling the commandline version and the IDE from the IDE _________________ Bug Nr.: 12345 Title: Hello World program compiles to 100 KB !!! Status: Closed: NOT a Bug |
|||
06 Jun 2009, 10:11 |
|
Czerno 06 Jun 2009, 14:17
DOS386 wrote: > VMware fails, Virtual PC fails as well You're being facetious, obviously. Yet there are evident security implications in the VM managers loosing control here : NO good, in my book. -- Czerno |
|||
06 Jun 2009, 14:17 |
|
Czerno 08 Jun 2009, 11:24
Though I'm not a regular VBox user, just set up a tiny DOS box for the experiment :
AMD Sempron 2400 / PCLinuxOS /VBOX 2.1.2 (no hardware virtualisation) / DOS 7.1 / FASM 1.67.29 Fantastic ! VirtualBOX executes FASM huge real mode code without a hickup ! Now come on guys, go test this in the other virtual systems ! XEN anybody ? Also, can someone repeat my tests but with hardware virtualisation on (VT and the like) ? I don't have the adequate processors... Cheers |
|||
08 Jun 2009, 11:24 |
|
Mac2004 12 Jun 2009, 03:48
Czerno wrote: Fantastic ! VirtualBOX executes FASM huge real mode code without a hickup ! Excellent! Regards Mac2004 |
|||
12 Jun 2009, 03:48 |
|
Goto page Previous 1, 2, 3, 4, 5 < Last Thread | Next Thread > |
Forum Rules:
|
Copyright © 1999-2024, Tomasz Grysztar. Also on GitHub, YouTube.
Website powered by rwasa.