Best Debugger/Dissembler/Assembler for 8/16-bit DOS Environment

[MikeS]

All too clunky, but thanks.

I have to ask: what's clunky about it? You save it on your development machine, hit the key to switch the keyboard to the other machine, and run the program. Just exactly what more do you want? Am I missing something?

Some people really are hard to please... ;-)

 

[Trixter]

I have to ask: what's clunky about it? You save it on your development machine, hit the key to switch the keyboard to the other machine, and run the program. Just exactly what more do you want? Am I missing something?

You're missing the fact that my other machine uses an XT 5-pin DIN keyboard with XT signaling. KVMs only work with AT signaling. And the 8088 doesn't have VGA either

The holy grail of what I need is a way to mount a directory in two places at once (ie. mount a samba share as a drive letter in DOS on an 8088 without it taking up 300+ KB of RAM). So far, no dice.

Mike Brutman tossed around the idea of writing a custom client/server that used only his TCP library and a packet driver, but I have no idea if he was actually pursuing that.

 

[Chuck(G)]

Hmmm, I use an AT-XT converter between the KVM and the XT. Both have VGA output. The XT uses a Tsenglabs 16-bit VGA card that also happens to function in 8-bit mode.

You know, there are lots of microcontroller setups with ethernet or WiFi nowdays--most are faster than an XT. It might be fairly easy to rig one up as a virtual disk drive to an XT. Or something with USB, perhaps.

Just thinking aloud.

 

[Great Hierophant]

For small projects where I just want to throw 10 to 50 instructions into a file and GO, I use the a86 assembler. Hard to beat "a86 file.asm" to produce a .com file in about 2 seconds.

If you have a 386 or higher, SoftICE is definitely the way to go, especially if you're trying to reverse-engineer or crack something. DOSBOX's debugger is indeed very cool too, and can get around "anti-debugger" tricks because the trick can't observe it is running in a virtual machine, but it is more useful for observing than useful debugging IMO.

Gotcha. What if you are trying to crack a disk protection check that croaks on a fast-speed machine like a 386 or you need to test it on a 8088 or 286? What tools to use then?

 

[Mike Chambers]

Hmmm, I use an AT-XT converter between the KVM and the XT. Both have VGA output. The XT uses a Tsenglabs 16-bit VGA card that also happens to function in 8-bit mode.

You know, there are lots of microcontroller setups with ethernet or WiFi nowdays--most are faster than an XT. It might be fairly easy to rig one up as a virtual disk drive to an XT. Or something with USB, perhaps.

Just thinking aloud.

I was thinking about attempting something like that with my Netduino. Something that be connected straight into an MFM or RLL controller, but it's probably way too complicated and I'd be limited by the number of GPIO pins. The reason I'd use a Netduino instead of an Arduino is that they have MicroSD card slots that could hold a disk image. The plus model even has an ethernet port, so one could use a remote image.

 

[Trixter]

For the curious, I've settled on firing up two DOSBOX windows, each with different configs, to do my development. One session runs at full speed with all the bells and whistles, and that's where I edit and compile. Another session is set to roughly the speed of an XT and allows me to do quick rough checks of my code. When I am confident enough to test on the real thing, I just copy it to an FTP server, then move to the real hardware and download it using mTCP's ftp client, then test.

This is not optimal, but it is very quick and convenient as both sessions share exactly the same filesystem. I compile in the "fast machine" and then immediately move to the "slow machine", run the DOSBOX internal command RESCAN to update the filesystem cache, then run my code. If I hang either "machine", I just close the window and start it back up again.

The only major drawback is that DOSBOX does not properly emulate the CTRL-BREAK sequence, nor are there any plans to do so. I tried an alternate build that claims to have a CTRL-BREAK patch, but it doesn't work on my system. I'm working around it by having my IDE save all open project files before running the compiled code, so I don't lose any work if something hangs, just time.

(Thanks to this setup, I've resumed development of my benchmark. I have chucked my grand plans to make it a full CUI-compliant Turbo Vision program, and will just be coding a very simple interface from scratch instead -- get it out there first, then worry later about learning an entire event-driven framework if it interests me.)