MS-DEBUG style program for ELKS

[cpiker]

I'm new to assembly development and have found the classic MS-DOS DEBUG program to be quite instructive. Do you know if a similar program has been compiled for ELKS? I noticed the elkscmd/debug directory in the source tree but didn't see anything in there that looked to an interactive interpreter which could examine memory, set registers etc.

I'm not concerned with gdb level of debugging, just looking to poke around memory, run a few instructions, and in general see what's going on.

Thanks for any pointers,

[ghaerr]

Hello @cpiker,

Thanks for your interest in ELKS. We don't have a DEBUG-like program for interactively poking around memory and assembling instructions, but that would be nice to have. I've looked at the DOS DEBUG source and unfortunately it's written in MASM (Microsoft ASM) itself and thus not an easy port to ELKS. If we could find something like DEBUG written in C, that would be a good start.

We do have a number of tools that are still very useful for looking around memory and disassembling it: disasm and hd. Examples of their use disassembling the start of the ELKS kernel at FFFF:0010 and looking at low memory for example:

# disasm 
Usage: disasm [-k][-a][-s symfile] [[seg:off[#size] | filename | -]
# # disasm ffff:10
Disassembly of 0010:
ffff:0010  89 1e f8 22       movw    %bx,(22f8)
ffff:0014  89 3e fa 22       movw    %di,(22fa)
ffff:0018  89 36 fc 22       movw    %si,(22fc)
ffff:001c  01 d6             add     %dx,%si
ffff:001e  89 36 fe 22       movw    %si,(22fe)
ffff:0022  8b 3e fc 22       movw    (22fc),%di
ffff:0026  89 d1             mov     %dx,%cx
ffff:0028  31 c0             xor     %ax,%ax
ffff:002a  d1 e9             shr     $1,%cx
ffff:002c  fc                cld
ffff:002d  f3                repz 
ffff:002e  ab                stosw   
# hd 0:0#256
000000: 50 44 07 0b 53 ff 00 f0  56 44 07 0b 53 ff 00 f0  PD..S...VD..S...
000010: 53 ff 00 f0 54 ff 00 f0  53 ff 00 f0 53 ff 00 f0  S...T...S...S...
000020: ea 43 07 0b f0 43 07 0b  93 d5 00 f0 93 d5 00 f0  .C...C..........
000030: 02 44 07 0b 93 d5 00 f0  57 ef 00 f0 93 d5 00 f0  .D......W.......
000040: 37 55 00 c0 4d f8 00 f0  41 f8 00 f0 fe e3 00 f0  7U..M...A.......
000050: 39 e7 00 f0 59 f8 00 f0  2e e8 00 f0 d2 ef 00 f0  9...Y...........
000060: b8 d5 00 f0 f2 e6 00 f0  6e fe 00 f0 53 ff 00 f0  ........n...S...
000070: 53 ff 00 f0 53 ff 00 f0  a8 4a 07 0b b8 92 00 c0  S...S....J......
000080: 53 ff 00 f0 53 ff 00 f0  53 ff 00 f0 53 ff 00 f0  S...S...S...S...
*
# 

There is also the -S option to produce ASM output from the ia16-elf-gcc C compiler, and various other emulators that can show instruction-by-instruction display while emulating. But that's not really the same as an interactive DEBUG.

Thank you!

[cpiker]

Mostly I'm looking to probe ports and see what I get in order to add support for various old machines I have around. Nice to do interactively if I can. I suppose it's not hard to make a thin wrapper on inb(), outb(), you've provided all the tools to do so easily.

On a side note, in what way is a MASM dialect program incompatible with ELKS? Is it just that it doesn't fit well with the existing toolchain or are there much deeper problems because output objects can't be coerced into a.out executable?

Could the project JWasm be of some assistance?

[ghaerr]

There a couple of issues: first, we don't have a MASM-compatible assembler running on ELKS. There's way too many 8086 assembler-source variants, so any program would need to be handed edited, and DEBUG is large. The other issues are that, yes, we don't have a linker that directly links .OBJ files to a.out format, although I've written various utilities that can translate formats. But these have their own issues, especially when it comes down to UNIX/Linux's requirements for handling "common" bss data. So that becomes a toolchain issue.

That said, it can all be done, just takes work. I don't think it a great idea to port large assembly programs to ELKS, it would be much nicer to start portably in C. But you're very welcome to start porting assembler if you like, I'll help you with issues. IIRC I looked at JWasm, but it's oriented around 32-bit Windows or DOS-extenders. They apparently have a 16-bit version for DOS, but that's got to be very carefully checked, since one could spend lots of time porting it, only to find it can't assemble large programs like DEBUG in 16-bits anyways. We have the 8086-toolchain project, which has yet another source variant AS86 assembler and linker that runs on both PC desktop and ELKS itself. That project also ports NASM for ELKS but after spending too much time getting that working, we found that it took 3+ minutes to assemble programs that other assemblers could finish in seconds. We had to throw it out, as it is terribly designed with regards to speed. So there's lots of things to think about.

We've tried to solve the "large program" problem by allowing big C programs to be ported to ELKS using OpenWatcom's large model, and ELKS can then load the resulting OS/2 16-bit NE binary. That works because the OWC toolchain already completely handles all the problems with multiple code and data segments, and also has an assembler and linker that work alongside the compiler. (And yes, the OWC assembler is yet another ASM input source format, not compatible with MASM, NASM, GCC, etc.)

[smj-cc]

Mostly I'm looking to probe ports and see what I get in order to add support for various old machines I have around. Nice to do interactively if I can.

There are 'bare-metal' implementations of "FORTH" for various older hardware. FORTH is trivial to implement compared to a full disk operating system, so there are quite a few of them. They should be able to do what you want interactively.
I wrote a couple myself decades ago for both Z80 and 8051.

[cpiker]

Wow, I haven't thought about Z80's in a while!

Are there any fourth implementations that will load and run on ELKS? Looking in elkscmd I didn't see anything, but I presume that's not the full extent of ELKS software. Say I had a raw Fourth bin (not a.out) how would ELKS even load that into memory? Is it simply a matter of prepending the right a.out header to the file? Even though ELKS expects a separate Code Segment and Data Segment, is it able to handle programs where CS == DS?

Fourth does look fascinating, and if it's as easy as everyone says I could probably get it running, but I'm trying not to lose sight of the goal, hardware support for Leading Edge Model D computers with Xircom E-Net adapters.

[cpiker]

Thanks for the long thoughful answers :-) I'm learning a bit of ELKS history.

So consulting the public MS-DOS archive it turns out that debug.com's size on disk is about ~11K and the sources are around 6K lines (with comments and spaces). In the source code I spotted a little over 20 INT 21h calls, which isn't that many, but debug also bakes in the assumption that programs have a PDB and that I/O is handled using file control blocks.

All in all that's a bit more then I want to deal with porting. Better to start with a new program using the current tool-chain that would let me examine memory and perform interactive port I/O, I don't actually need a debugger, just a small real-mode hardware exploration tool.

[tyama501]

FYI

ELKS basic can do inpb, outb.
I sometimes use it for debug.

https://github.com/ghaerr/elks/blob/master/elkscmd/basic/README.md

[cpiker]

Thanks! That looks like it would be sufficient. I can't view individual registers, but that's more of a debugging task