Index
> DOS > problem with unREAL mode fasmGoto page 1, 2, 3, 4, 5 Next |
| Author |
|
|
edfed 09 Jan 2008, 12:50
fasmd doesn't work on pure dos.
cause of dpmi so, a simple fasmd.exe supported on pure dos is a good thing. unreal, dmpi, big real, all these modes are problems instead to be solutions. running fasmd on pure real mode, yes we want. |
|||
09 Jan 2008, 12:50 |
|
|
LocoDelAssembly 09 Jan 2008, 14:20
Couldn't it worked aroung by adding a couple of int3 on the first offsets and install a int3 handler that workarounds the problem or it is just simply imposible to have EIP[31:16] <> 0 on real/unreal mode?
|
|||
|
09 Jan 2008, 14:20 |
|
|
vid 09 Jan 2008, 14:56
edfed: do you actually USE fasmd in pure dos, or do you just want it?
 |
|||
|
09 Jan 2008, 14:56 |
|
|
Vov4ik 09 Jan 2008, 15:03
Why you can't use more, than one code segments? Just FAR JMP or FAR CALL to code in the other sehgment(s).
|
|||
|
09 Jan 2008, 15:03 |
|
|
Tomasz Grysztar 09 Jan 2008, 15:08
LocoDelAssembly wrote: Couldn't it worked aroung by adding a couple of int3 on the first offsets and install a int3 handler that workarounds the problem or it is just simply imposible to have EIP[31:16] <> 0 on real/unreal mode? The problem is with interrupts, which store only IP (not EIP) on stack. If I disabled interrupts for the time of assembly, there would be no problem like that. I considered this kind of solution, too - but I need to call DOS functions sometimes and this is a problem. The only module that doesn't use DOS calls at all is the parser - I may then move parser to the end of code segment and disable interrupts for the time of parsing. A bit ugly, but may work for some time... Vov4ik wrote: Why you can't use more, than one code segments? Just FAR JMP or FAR CALL to code in the other sehgment(s). As I said, this would require changes in the files that are currently common between the architectures - and I don't want such sulution. It would be possible to make some macros to keep the core files common, but I still don't like it. |
|||
|
09 Jan 2008, 15:08 |
|
|
Japheth 09 Jan 2008, 16:32
Hi,
my suggestion: throw away the unreal thing and restrict to DPMI. You can easily integrate hdpmi in the FASM binary, see: http://board.flatassembler.net/topic.php?t=7593 so FASM will remain a stand-alone binary running in DOS (and as a goody, it will also run in v86-mode). |
|||
|
09 Jan 2008, 16:32 |
|
|
Tomasz Grysztar 09 Jan 2008, 16:41
Japheth wrote: Hi, I wouldn't like to integrate any 3rd party code. fasm was initially (in pre-public versions) integrated with my own extender (HDOS), but later I dumped it. I prefer to leave fasm using whatever DPMI is available, so you can choose the one that works best for you (and in Windows subsystem you got the best one available there). |
|||
|
09 Jan 2008, 16:41 |
|
|
Japheth 09 Jan 2008, 16:47
Tomasz Grysztar wrote:
Ok. However, this is no real argument, since the startup code can always decide whether to use the currently running DPMI host or - if it is possible at all - to run under the one supplied with the binary. |
|||
|
09 Jan 2008, 16:47 |
|
|
edfed 09 Jan 2008, 19:31
i was stupefied by the existance of fasmd...
and really disapointed when i tryed it on dos, doesn't work, all my hopes to use fasmd on a dos compatible hand made system is in the garbages... so yes, i use fasmd on dos. but dos with windows... all i want, is to use fasmd on a pure dos floppy disk... guess why! only cause dos starts instantlly, a fatal bug is corrected faster when using a dos platform, restart is less than 5 seconds...and then, fasmd become the OS, cause it's directlly launched... |
|||
|
09 Jan 2008, 19:31 |
|
|
Tomasz Grysztar 09 Jan 2008, 21:21
edfed: you need a DPMI service to be installed on your DOS. Try either HDPMI from the FreeDOS distributions, or the CWSDPMI.
|
|||
|
09 Jan 2008, 21:21 |
|
|
DOS386 09 Jan 2008, 21:21
.
Tomasz wrote: Quote: it still limits the code that can be run from one segment to 64 KB. But the EXE is 73 KiB already and you have a "32-bit" unreal mode ? Anyway, my suggestions: - Throw away the unreal mode and integrate HDPMI32 or - Integrate HDOS, but make sure that it also works if an external DPMI host (HDPMI32) is present. Existing FASM without IDE for DOS does NOT work if a DPMI host exists and in real mode  Several people including me complained about this but there was no clear answer so far  Also it reportedly doesn't work on Cyrix
edfed wrote: > fasmd doesn't work on pure dos. > cause of dpmi NOT true 
> running fasmd on pure real mode, yes we want. NONSENCE - in future please try to reduce the quantity of your posts and increase the quality of them instead
LocoDelAssembly wrote: Quote: Couldn't it worked aroung by adding a couple of int3 on the first offsets and install a int3 handler that workarounds the problem or it is just simply imposible to have EIP[31:16] <> 0 on real/unreal mode? Horrible hack, DPMI is better
vid wrote: > edfed: do you actually USE fasmd in pure dos, or do you just want it? I DO USE it in DOS
edfed wrote: Quote: i was stupefied by the existance of fasmd... and really disapointed when i tryed it on dos, doesn't work, all my hopes to use fasmd on a dos compatible hand made system is in the garbages... Why didn't you ask here ? instead of posting all your stupid Drunk Stuff ?
Quote: so yes, i use fasmd on dos. but dos with windows... Seems you have no idea what DOS is  Last edited by DOS386 on 09 Jan 2008, 21:43; edited 3 times in total |
|||
|
09 Jan 2008, 21:21 |
|
|
Tomasz Grysztar 09 Jan 2008, 21:25
DOS386 wrote: Tomasz wrote: I said it in the text you quoted - all my data and tables are moved to places after the code. The code itself is still smaller than 64 KB. DOS386 wrote: Anyway, my suggestions: I'm OK with throwing away the unreal, but I won't provide DPMI host with fasm. I just feel it's not the way it should be. I would make it work just like FASMD does now. |
|||
|
09 Jan 2008, 21:25 |
|
|
DOS386 09 Jan 2008, 21:35
.
Quote: I said it in the text you quoted - all my data and tables are moved to places after the code. The code itself is still smaller than 64 KB. OK, I didn't analyze it in deep - default operand size in CS is 32-bit, but CS limit still 16-bit ? Quote: OK with throwing away the unreal, but I won't provide DPMI host with fasm. I just feel it's not the way it should be. I would make it work just like FASMD does now. It's OK for me ... having a DPMI compatible HDOS included would be better of course - smaller than HDPMI32's 33 KiB maybe ?
Any plans with HDOS ? In other tread you pointed me to it, but no "final" answer at the end. _________________ Bug Nr.: 12345 Title: Hello World program compiles to 100 KB !!! Status: Closed: NOT a Bug |
|||
|
09 Jan 2008, 21:35 |
|
|
edfed 09 Jan 2008, 21:38
give me some support for dmpi on msdos 6.22 and i'll shut up.
Quote:
yes and i don't want to know more about this middle age OS. |
|||
|
09 Jan 2008, 21:38 |
|
|
Tomasz Grysztar 09 Jan 2008, 21:44
edfed wrote: give me some support for dmpi on msdos 6.22 and i'll shut up. http://clio.rice.edu/cwsdpmi/csdpmi5b.zip Load it with the "cwsdpmi -p" command. |
|||
|
09 Jan 2008, 21:44 |
|
|
DOS386 09 Jan 2008, 21:44
> give me some support for dmpi on msdos 6.22 and i'll shut up.
Download HXRT.ZIP, extract HDPMI32.EXE and shut up
HDPMI32 -r > yes and i don't want to know more about this middle age OS. Your problem is that you don't know what you want at all  |
|||
|
09 Jan 2008, 21:44 |
|
|
DOS386 09 Jan 2008, 21:53
Tomasz wrote:
Quote: I prefer to leave fasm using whatever DPMI is available, so you can choose the one that works best for you I see NO problem here. Just don't use the included one if an external is available (bypassing existing is bad, DOS/32A 9.xx does this way). Quote: and in Windows subsystem you got the best one available there. Not for me  |
|||
|
09 Jan 2008, 21:53 |
|
|
edfed 09 Jan 2008, 21:59
thank you
|
|||
|
09 Jan 2008, 21:59 |
|
|
edfed 09 Jan 2008, 23:25
now, it works very well, i have fasmd 10 seconds after boot from a floppy.
thank you all, exept dos386 for his sarcasms...  |
|||
|
09 Jan 2008, 23:25 |
|
| Goto page 1, 2, 3, 4, 5 Next < Last Thread | Next Thread > |
Forum Rules:
|