DOS ain't dead

DOS386

01.03.2008, 03:10

@ DOS386

Debug 1.13 : bugs and suggestions

Bug: doesn't decode UD2 instruction ($0F,$0B)

Suggestion (seems not present in this form, at least in 1.12): edit memory: display existing byte, and allow to replace it with a new one, or keep if no new value entered

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***

Japheth

Germany (South),
01.03.2008, 06:15

@ DOS386

Debug 1.13 : bugs and suggestions

Post reply

> Bug: doesn't decode UD2 instruction ($0F,$0B)

That's not a bug, that's a missing feature. It also doesn't decode MMX, SSE, ...

> Suggestion (seems not present in this form, at least in 1.12): edit
> memory: display existing byte, and allow to replace it with a new one, or
> keep if no new value entered

I don't understand what you want, but before I consider to do anything please resolve my little FASM riddle first:

http://www.bttr-software.de/forum/forum_entry.php?id=3378

(without using "dirty hacks")

---
MS-DOS forever!

rCX Maryland, USA, 27.06.2008, 20:29 @ Japheth	Thanks Post reply
	Thanks Japheth, I'm glad this is still being developed. It was really helpful in writing my game.

rCX

Maryland, USA,
27.07.2008, 22:54
(edited by rCX, 28.07.2008, 00:47)

@ Japheth

Bug?

Post reply

In FD DEBUG, when 'g' is used the segments are changed and have to be manually reset to run a program again. This does not happen in MS DEBUG.

----------------
In MS DEBUG; DS,ES,SS,CS are unchanged after using 'g':
C:\>debug test.com -r AX=0000 BX=0000 CX=0008 DX=0000 SP=FFFE BP=0000 SI=0000 DI=0000 DS=147E ES=147E SS=147E CS=147E IP=0100 NV UP EI PL NZ NA PO NC 147E:0100 B402 MOV AH,02 -g A Program terminated normally -r AX=0000 BX=0000 CX=0008 DX=0000 SP=FFFE BP=0000 SI=0000 DI=0000 DS=147E ES=147E SS=147E CS=147E IP=0100 NV UP EI PL NZ NA PO NC 147E:0100 B402 MOV AH,02 -g A Program terminated normally -

----------------
In FD DEBUG; DS,ES,SS,CS are all changed after using 'g':
C:\>debug test.com -r AX=0000 BX=0000 CX=0008 DX=0000 SP=FFFE BP=0000 SI=0000 DI=0000 DS=1463 ES=1463 SS=1463 CS=1463 IP=0100 NV UP EI NG NZ NA PO NC 1463:0100 B402 MOV AH,02 -g A Program terminated normally (0000) -r AX=0000 BX=0000 CX=0000 DX=0000 SP=FFFE BP=0000 SI=0000 DI=0000 DS=13E4 ES=13E4 SS=13E4 CS=13E4 IP=0100 NV UP EI PL ZR NA PE NC 13E4:0100 C3 RET -g Program terminated normally (0000) -

----------------
The program I used prints 'A'
mov ah,2 mov dl,41h int 21h int 20h

Is this a bug or was it intentional? Thanks :-D

ecm

Düsseldorf, Germany,
28.07.2008, 02:22

@ rCX

Bug?

Post reply

> In FD DEBUG, when 'g' is used the segments are changed and have to be
> manually reset to run a program again.

No; resetting them would indeed crash the computer, or at least use DOS memory no longer occupied by this program. FD DEBUG seems to unload debugee after it terminated and then create the dummy PSP like if no debugee is loaded at all.

The different segment results in that a loaded program will get it's own environment block opposed to the DEBUG dummy PSP that shares DEBUG's environment block; most likely the environment block of the loaded program will be just there where the dummy PSP itself will be created.

---
l

Japheth

Germany (South),
28.07.2008, 08:01

@ rCX

Bug?

Post reply

> Is this a bug or was it intentional? Thanks :-D

it's intentionally. Just reload your program with 'l' if you'd like to see the old values of the segment registers.

---
MS-DOS forever!

Rugxulo

Usono,
02.03.2008, 00:16

@ DOS386

Debug 1.13 : bugs and suggestions

Post reply

> Suggestion (seems not present in this form, at least in 1.12): edit
> memory: display existing byte, and allow to replace it with a new one, or
> keep if no new value entered

debug MYFILE.COM
e 100

"Space" will skip/ignore the byte and go to the next one.
"54" will put "54" in place of current byte.
"Enter" will go back to the "-" prompt.

Is this what you meant?

P.S. Japheth, no idea, just PM or e-mail Tomasz directly.

Japheth

Germany (South),
02.03.2008, 15:46

@ Rugxulo

Debug 1.13 : bugs and suggestions

Post reply

> P.S. Japheth, no idea, just PM or e-mail Tomasz directly.

I'd prefer you, the FASM adorers, to solve it. It's you who permanently speak about how fast, great and superior FASM is ... :-D

---
MS-DOS forever!

Japheth

Germany (South),
04.03.2008, 11:42

@ Japheth

Debug 1.13 : bugs and suggestions

Post reply

> I'd prefer you, the FASM adorers, to solve it. It's you who permanently
> speak about how fast, great and superior FASM is ... :-D

Tomasz has solved it for you finally: http://board.flatassembler.net/topic.php?t=8338

the correct FASM version is:

macro defext name { extrn name match realname,name \{ public __imp_\# realname __imp_\# realname dd name \} }

---
MS-DOS forever!

Rugxulo

Usono,
04.03.2008, 15:19

@ Japheth

FASM macro for Japheth

Post reply

> I'd prefer you, the FASM adorers, to solve it. It's you who
> permanently speak about how fast, great and superior FASM is ...

If I ate roast beef 11 times in my life, would you say I was permanently eating roast beef? ;-)

But seriously, FASM is great, but the whole preprocessor/assembler difference and the ultra-powerful macros can be a bit mind-boggling. :confused:

IMO, the guy (Tomasz) really is a genius (officially, a mathematician).

> Tomasz has solved it for you finally:
> http://board.flatassembler.net/topic.php?t=8338

So what program was this intended for anyways? (Just curious.)

Japheth

Germany (South),
04.03.2008, 16:00

@ Rugxulo

FASM macro for Japheth

Post reply

> But seriously, FASM is great, ...

I know. FASM is great, DGPJJ is great, ... I'm used to buy everything what's advertised because I'm such a smart guy ...

> but the whole preprocessor/assembler difference and the ultra-powerful macros
> can be a bit mind-boggling.

IIRC I already asked, but cannot remember your response: did you ever write a non-trivial FASM program? Because, IMO, someone who did that should be familiar with the "match" directive.

> So what program was this intended for anyways? (Just curious.)

It's a small tool which creates tiny modules for IMPHLP.LIB (contained in hxdev) by launching an assembler "several" (currently 1500) times. I knew that FASM would be the best tool for that because it includes the very minimum into the COFF output. The imphlp.lib in hxdev v2.14 was created with NASM, size is about 600kb. With FASM, the size will shrink to about 480 kB.

---
MS-DOS forever!

Rugxulo

Usono,
04.03.2008, 17:59

@ Japheth

FASM macro for Japheth

Post reply

> I know. FASM is great, DGPJJ is great, ... I'm used to buy everything
> what's advertised because I'm such a smart guy ...

You don't have to buy 'em, they're free. ;-) I understand that you prefer MSVC over DJGPP, but it's a much larger download, not open source, but I guess has better optimizations? (And Intel is reportedly even better, but AFAIK, only their Linux version is free for non-commercial use.)

I didn't say FASM was perfect, but it has a lot going for it. You of course are free to use whatever you want. It is not my intention to bombard you with "adverts". :-|

> IIRC I already asked, but cannot remember your response: did you ever
> write a non-trivial FASM program?

Does my tiny attrib clone count? LFN dir? If not (and probably not, oh well), then not really. I mostly write tiny utils for my own use, nothing fancy or ground-breaking, sorry to offend or disappoint you. :-|

> Because, IMO, someone who did that
> should be familiar with the "match" directive.

I'm only superficially aware of it since I've never majorly needed it. The simple "match =1, DEBUG { include 'only8086.inc' }" in the manual is the most I've ever used.

> It's a small tool which creates tiny modules for IMPHLP.LIB (contained in
> hxdev) by launching an assembler "several" (currently 1500) times.

Yikes! Certainly doing that will be much much faster in FASM. (Even YASM is a fair bit faster than NASM.)

Japheth

Germany (South),
04.03.2008, 20:37
(edited by Japheth, 04.03.2008, 20:47)

@ Rugxulo

FASM macro for Japheth

Post reply

> Does my tiny attrib clone count? LFN dir? If not (and probably not, oh
> well), then not really. I mostly write tiny utils for my own use, nothing
> fancy or ground-breaking, sorry to offend or disappoint you. :-|

I want to understand why you obviously love this thing. DOS386 loves it because it fully supports DOS, you might love it because you don't really know it yet ... :-D

> Yikes! Certainly doing that will be much much faster in FASM. (Even YASM is a
> fair bit faster than NASM.)

Actually FASM is slightly slower than NASM to finish this task because it displays its "logo" 1500 times (that's why a -q option might be useful for FASM). If I redirect the displays to a file, it needs about 50% of NASM's time.

---
MS-DOS forever!

Rugxulo

Usono,
05.03.2008, 01:18

@ Japheth

FASM macro for Japheth

Post reply

> I want to understand why you obviously love this thing. DOS386 loves it
> because it fully supports DOS, you might love it because you don't really
> know it yet ... :-D

Open source, assembles itself (no need for a compiler to rebuild).
Fast.
Multi OS.
Multiple output formats from any version (including making .EXE w/o linker).
Nice simple IDE w/ FASM built-in for DOS w/ syntax highlighting.
Nice docs and excellent forum (IMO) with lots of examples.

I'm not saying I hate NASM or most (any?) other assemblers. But FASM is indeed pretty powerful.

> Actually FASM is slightly slower than NASM to finish this task because it
> displays its "logo" 1500 times (that's why a -q option might be useful for
> FASM). If I redirect the displays to a file, it needs about 50% of NASM's
> time.

Yeah, but if you can just redirect to NUL, why add -q just to do the same? (I mean, it's fine I guess, but the whole "no cmdline options" thingy seems to be disappearing pretty quickly ...). For now, just do that or reassemble without that part.

Japheth

Germany (South),
05.03.2008, 11:10

@ Rugxulo

FASM macro for Japheth

Post reply

> Open source, assembles itself (no need for a compiler to rebuild).
> Fast.

[more ads snipped]

> Yeah, but if you can just redirect to NUL, why add -q just to do the same?

It's not "the same", it just appears to be the same.

> (I mean, it's fine I guess, but the whole "no cmdline options" thingy seems
> to be disappearing pretty quickly ...)

Yes, because it was nonsense from the very beginning and this was absolutely clear to all who are able to use their brains. It was bought just by the adorers...

---
MS-DOS forever!

Rugxulo

Usono,
05.03.2008, 14:24

@ Japheth

FASM macro for Japheth

Post reply

> [more ads snipped]

Well, you did say "I want to know ...". :-P

> > Yeah, but if you can just redirect to NUL, why add -q just to do the
> same?
>
> It's not "the same", it just appears to be the same.

Maybe -q would be faster for your needs (1500 times in a row!)?

> > the whole "no cmdline options" thingy seems to be disappearing
> > pretty quickly ...)
>
> Yes, because it was nonsense from the very beginning ... It was bought
> just by the adorers...

Well, the inherent idea was that there wouldn't be a billion cmdline options needed to output a specific output format. It was supposed to (and did) simplify everything and prevent errors.

<sarcasm>
Now that you've found your true love, NASM, I expect you to write 100% of everything in it.
</sarcasm>

There's room for more than one, obviously. And they don't have to all behave the same way (ahem, Octasm). :-D

Japheth

Germany (South),
15.01.2009, 06:43

@ Rugxulo

Debug 1.13 : bugs and suggestions

Post reply

> "Space" will skip/ignore the byte and go to the next one.
> "54" will put "54" in place of current byte.
> "Enter" will go back to the "-" prompt.

and '-' will go back one byte.

---
MS-DOS forever!

Japheth

Germany (South),
30.07.2008, 11:20

@ DOS386

Another DEBUG clone

Post reply

Here's another DEBUG clone, which also understands 386 instructions:

http://www.modest-proposals.com/Furball.htm

It's based on the v0.95 source of Paul Voita's Debug.com, but syntax changed to Masm (can be assembled with Jwasm, needs -Zm switch).

---
MS-DOS forever!

ecm

Düsseldorf, Germany,
30.07.2008, 21:46

@ Japheth

Another DEBUG clone

Post reply

> It's based on the v0.95 source of Paul Voita's Debug.com, but syntax
> changed to Masm (can be assembled with Jwasm, needs -Zm switch).

Do you plan to develop for this and drop our good NASM DEBUG from now? :-P

---
l

Japheth

Germany (South),
31.07.2008, 13:29

@ ecm

Another DEBUG clone

Post reply

> > It's based on the v0.95 source of Paul Voita's Debug.com, but syntax
> > changed to Masm (can be assembled with Jwasm, needs -Zm switch).
>
> Do you plan to develop for this and drop our good NASM DEBUG from now? :-P

No. But I will try it and see if some useful feature can be stolen...

---
MS-DOS forever!

ecm

Düsseldorf, Germany,
31.07.2008, 16:21

@ Japheth

Another DEBUG clone

Post reply

> No. But I will try it and see if some useful feature can be stolen...

Good idea, indeed ;-)

---
l

Japheth

Germany (South),
13.01.2009, 10:48

@ DOS386

FD Debug 1.14

Post reply

There's a new version available:

http://www.japheth.de/debxxf.html

readme: http://www.japheth.de/Debug/readme.txt

good news: some bug-fixes + a better H cmd
bad news: won't assemble with Nasm/Yasm anymore, needs Masm/JWasm. Fortunately there is NOMYSO ...

---
MS-DOS forever!

rCX Maryland, USA, 14.01.2009, 04:31 @ Japheth	FD Debug 1.14 Post reply
	> There's a new version available: > > http://www.japheth.de/debxxf.html > > readme: http://www.japheth.de/Debug/readme.txt > Thanks for the update!

Debug 1.13 (Announce)

Debug 1.13 : bugs and suggestions

Debug 1.13 : bugs and suggestions

Thanks

Bug?

Bug?

Bug?

Debug 1.13 : bugs and suggestions

Debug 1.13 : bugs and suggestions

Debug 1.13 : bugs and suggestions

FASM macro for Japheth

FASM macro for Japheth

FASM macro for Japheth

FASM macro for Japheth

FASM macro for Japheth

FASM macro for Japheth

FASM macro for Japheth

Debug 1.13 : bugs and suggestions

Another DEBUG clone

Another DEBUG clone

Another DEBUG clone

Another DEBUG clone

FD Debug 1.14

FD Debug 1.14