flat assembler
Message board for the users of flat assembler.
 Home   FAQ   Search   Register 
 Profile   Log in to check your private messages   Log in 
flat assembler > DOS > Fasm executable freezing in DOS

Goto page 1, 2  Next
Author
Thread Post new topic Reply to topic
gunblade



Joined: 19 Feb 2004
Posts: 209
Fasm executable freezing in DOS
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
Post 09 Aug 2005, 21:23
View user's profile Send private message Reply with quote
Tomasz Grysztar
Assembly Artist


Joined: 16 Jun 2003
Posts: 5434
Location: Kraków, Poland
Is your DOS in real mode (in such case it wouldn't use cwsdpmi services anyway)?
Post 09 Aug 2005, 21:26
View user's profile Send private message Visit poster's website Reply with quote
rugxulo



Joined: 09 Aug 2005
Posts: 1953
Location: Usono (aka, USA)
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/
Post 09 Aug 2005, 23:09
View user's profile Send private message Visit poster's website Reply with quote
gunblade



Joined: 19 Feb 2004
Posts: 209
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
Post 10 Aug 2005, 16:55
View user's profile Send private message Reply with quote
Tomasz Grysztar
Assembly Artist


Joined: 16 Jun 2003
Posts: 5434
Location: Kraków, Poland
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).
Post 10 Aug 2005, 17:00
View user's profile Send private message Visit poster's website Reply with quote
gunblade



Joined: 19 Feb 2004
Posts: 209
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 Smile).


Thanks a lot and keep up the good work,
gunblade
Post 10 Aug 2005, 17:49
View user's profile Send private message Reply with quote
vid
Verbosity in development


Joined: 05 Sep 2003
Posts: 7110
Location: Slovakia
are the EMM386 options described somewhere?
Post 10 Aug 2005, 19:28
View user's profile Send private message Visit poster's website AIM Address MSN Messenger ICQ Number Reply with quote
gunblade



Joined: 19 Feb 2004
Posts: 209
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
Post 10 Aug 2005, 20:15
View user's profile Send private message Reply with quote
Tomasz Grysztar
Assembly Artist


Joined: 16 Jun 2003
Posts: 5434
Location: Kraków, Poland
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.
Post 10 Aug 2005, 20:36
View user's profile Send private message Visit poster's website Reply with quote
gunblade



Joined: 19 Feb 2004
Posts: 209
you did it again, thanks Smile
Post 10 Aug 2005, 21:26
View user's profile Send private message Reply with quote
Tomasz Grysztar
Assembly Artist


Joined: 16 Jun 2003
Posts: 5434
Location: Kraków, Poland
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.
Post 10 Aug 2005, 22:31
View user's profile Send private message Visit poster's website Reply with quote
Tomasz Grysztar
Assembly Artist


Joined: 16 Jun 2003
Posts: 5434
Location: Kraków, Poland
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.
Post 11 Aug 2005, 00:05
View user's profile Send private message Visit poster's website Reply with quote
shoorick



Joined: 25 Feb 2005
Posts: 1416
Location: Ukraine
dos "microsoft " foxpro did not see upper memory with under dos with emm386 Smile i've been using qemm386 than.
Post 11 Aug 2005, 05:33
View user's profile Send private message Visit poster's website Reply with quote
gunblade



Joined: 19 Feb 2004
Posts: 209
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.
Post 11 Aug 2005, 16:23
View user's profile Send private message Reply with quote
THEWizardGenius



Joined: 14 Jan 2005
Posts: 382
Location: California, USA
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)!!!
Post 11 Aug 2005, 17:40
View user's profile Send private message AIM Address Reply with quote
gunblade



Joined: 19 Feb 2004
Posts: 209
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?
Post 11 Aug 2005, 18:11
View user's profile Send private message Reply with quote
Tomasz Grysztar
Assembly Artist


Joined: 16 Jun 2003
Posts: 5434
Location: Kraków, Poland
So it's the early Cyrix - I suspected so, since that explains the incompatibility.
Post 11 Aug 2005, 18:14
View user's profile Send private message Visit poster's website Reply with quote
vid
Verbosity in development


Joined: 05 Sep 2003
Posts: 7110
Location: Slovakia

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?
Post 15 Aug 2005, 10:00
View user's profile Send private message Visit poster's website AIM Address MSN Messenger ICQ Number Reply with quote
Tomasz Grysztar
Assembly Artist


Joined: 16 Jun 2003
Posts: 5434
Location: Kraków, Poland
No, by unreal mode I mean something different than just simple flat real mode - see http://board.flatassembler.net/topic.php?t=135#1442
Post 15 Aug 2005, 10:10
View user's profile Send private message Visit poster's website Reply with quote
vid
Verbosity in development


Joined: 05 Sep 2003
Posts: 7110
Location: Slovakia
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?
Post 15 Aug 2005, 11:04
View user's profile Send private message Visit poster's website AIM Address MSN Messenger ICQ Number Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  
Goto page 1, 2  Next

< Last Thread | Next Thread >

Forum Rules:
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You cannot download files in this forum


Powered by phpBB © 2001-2005 phpBB Group.

Main index   Download   Documentation   Examples   Message board
Copyright © 2004-2013, Tomasz Grysztar.