Hey,
Just got some old laptop (60mhz, *drool*), and stuck dos on it, since it has no cd drive, nor any ethernet ports its hard and quite useless to put linux on it. Everything's worked fine, except for fasm. For some reason, the fasm executable just freezes when i run it, it prints out the "flat assembler version 1.63.5" (i've tried the stable too, did the same thing), and after that it just freezes.. ive tried debugging it, but i could only find a 16-bit debugger, therefore it crashes after fasm goes into 32-bit mode.

Any idea why this is happening, or how to fix it? (oh, im using cwsdpmi V0.90+, and all other 32-bit applications seem to work fine, including info-zip, rar, and nasm).

Thanks,
gunblade

Is your DOS in real mode (in such case it wouldn't use cwsdpmi services anyway)?

As far as debuggers go, two good free symbolic ones are 386SWAT and GRDB:

http://www.sudleyplace.com
http://members.tripod.com/~ladsoft/grdb.htm

These are also available (among others) at:
http://www.sac.sk (under /UTILPROG/)


Anyways, what brand of DOS are you running? What version? Have you tried a clean boot (no CONFIG.SYS or AUTOEXEC.BAT)? Try some older versions of FASM from the SourceForge page, and see if that helps:

http://fasm.sourceforge.net/archive/

Thanks for the quick response, i'm using DOS 6.22.
Therefore it should be running in real mode.
And to test it, i removed the cws*.exe's temporarely, and the program did run the same as before, freezing after showing the version.
using GRDB (which is a very nice debugger btw, thanks), it shows not enough memory. Trying to work round that somehow (got 4MB mem in total)

Old version (1.50) didnt work either.. ill try version 1.00 i guess and see if that works.

Thanks,
Gunblade

Perhaps you've got a kind of processor that is unable to execute the unreal mode correctly - the solution may be to force fasm to use DPMI instead, you can either modify the MODES.INC (put "jmp dpmi" just after the "real32:" label), or turn the system into V86 mode (for example by installing EMM386.EXE with RAM parameter).

Hoozah!
That worked perfectly, now just uses dpmi instead of the real32.
I'll have to look into why its not working properly, although the cpu isnt even Intel, so that could be causing some of the problems. (laptop is IBM Thinkpad 340CSE if your interested ).


Thanks a lot and keep up the good work,
gunblade

are the EMM386 options described somewhere?

heh, the problems never end.. now the problem seems to be: "Invalid Opcode at eip=2c"
trying to debug it seems to freeze the system.

do i have to make the jmp a jmp short? or what could be the problem?

thanks,
gunblade

Sorry, my mistake - put "jmp dpmi" just before "smsw ax", after the [program_base] and [buffer_address] get correctly initialized.

vid: the "help" command in DOS 6.22 has it.

you did it again, thanks

I'm very interested what processor do you have - because this is the first time I got report that the unreal mode is not working on some. Though it was already known that the most of available emulators, like Bochs, are not able to run unreal mode fasm, since visibly they don't have those tricks implemented - fasm changes the base of real mode IDT and the real mode code descriptor to 32-bit, this is highly "non-standard". It was working however on all processor on which I tested it - but I had access to Intel and AMD processors only. Perhaps you've got something different. Maybe I should add some additional processor identification to the MODES.INC so it won't try to enter unreal mode on unknown processors.

Please check out the updated 1.64 for DOS package - I have added checking for the 32-bit real mode, and it processor seems to not support it, it uses the DPMI if available, or exits with error message. It is now able to signalize nicely an error under Bochs (so that's right, Bochs is not able to emulate 32-bit real mode), and I hope it will be OK also on your hardware.

dos "microsoft " foxpro did not see upper memory with under dos with emm386 i've been using qemm386 than.

Well, i'd love to find out the cpu type, but might have to end up opening the laptop to see what it is. Shockingly enough, the cpuid instruction freezes the machine..
The new 1.64 version does work as you said, so im just using that now.

Might rumage through the bios and see what i can find.

It might be a 386 if CPUID doesn't work. Either that or a non-Intel CPU that's supposed to be compatible with that 486 (or better) but isn't.

I looked it up. This site: http://www.ertyu.org/~steven_nikkel/thinkpadspecs.html
says that IBM 340 and 340CSE have a 486 SLC2 50/60, either 4 or 12 MB RAM, up to 360 MB HDD, and an internal FDD... man, your computer is ANCIENT (like mine)!!!

hehe, yup, 50/60Mhz, 4MB ram, 200MB HD, FDD drive

i dont use it as my main comp, i have a ibm thinkpad t22 for that.. on which i run linux, nicely.

so the cpu is an SLC?

So it's the early Cyrix - I suspected so, since that explains the incompatibility.

Quote:

So it's the early Cyrix - I suspected so, since that explains the incompatibility

Why? They didn't have unreal mode or what? Even HIMEM.SYS requires unreal mode, no? How can it run?

No, by unreal mode I mean something different than just simple flat real mode - see http://board.flatassembler.net/topic.php?t=135#1442

i know but if processor does support flat real mode (eg. it doesn't reset limits to 64k etc.), then it also supports everything unreal mode needs, no?