Use a signal as a means to stop execution and drop into debug console

[cocus]

I usually find that my code misbehaves or it's stuck doing something and I have no clue about that. Since I run it under vscode and gdb, I can pause it and modify _flag_prompt and set it to 1. However, this is really cumbersome. I think it might be useful if we can handle a signal, like SIGSTP to drop into the debug prompt.

[ghaerr]

Hello @cocus,

We do, SIGINT works as you require. That's how the ^C processing works to regain control when running trace in continuous mode.

Thank you!

[mfld-fr]

@cocus : are you using the PTY backend for the serial port or the STDIO one ?

[cocus]

I'm using the stdio. I tried yesterday when I rebased my changes on top of master, and ctrl+c did kill the app, but I will investigate a little bit further tonight if I did something wrong on that test.

[mfld-fr]

@cocus : could you please provide your config.mk so that I could try to reproduce your problem ?

[mfld-fr]

@cocus : in my latest commit 4189d0d, I generalized the SIGINT (Control-C in EMU86 console) to all the configurations, and I checked that it effectively breaks the continuous code execution and starts the debugger using the STDIO backend.

@ghaerr : you can now interrupt ELKS running in the SDL console the same way (but not in the SDL window, of course, in the EMU86 console).

[ghaerr]

you can now interrupt ELKS running in the SDL console the same way (but not in the SDL window, of course, in the EMU86 console).

Fantastic, this is just what I was looking for! For some reason, I was thinking we'd need multiple consoles for this. You can ignore my previous comments about multi-console requirements.

Things now function very nicely on macOS :)

[ghaerr]

@mfld-fr : Try running emu86 -i ..., using SDL it's very cool: one can now single step through the entire boot process, watching INT 19h and full startup. Eventually (using 'c' command) the SDL console appears and the ELKS boot process can be seen, along with full disassembly on the stdio console.

There really isn't any small 8086 emulator out there that works like this. I can imagine, with a few additions to the debug console, along with symbol name mapping from a map file (which I plan to implement), a new level of being able to debug ELKS and other kernels.

@cocus: We should be able to get a better handle on why MSDOS/FreeDOS isn't booting using this mechanism :)

[cocus]

@ghaerr I've spotted an issue on the disk init functions on the elks sources (where the default disk gets assigned id 01 instead of the more logical 00). However, I've tried to boot DOS from it, and it doesn't even get near the point where it displays "Starting MSDOS..." as I can get with my bios. Seems like there's an issue when reading disk sectors. I'll have to dig deeper. In any case, tonight I'll try again the ^C and see if it breaks out, hopefully it does and it didn't work for me because I had a mess with my sources.

@mfld-fr I've tried with the default config file prior to modifying it to run my own target, but it didn't work in that configuration. I might've forgotten to clean the build, or at least, that's my best theory. As a side note, is there an IRC or Discord to chat about this project? I wouldn't want to add an issue for any small thing I might encounter

[mfld-fr]

Sorry, we did not setup any IRC channel, but there is no problem to open issue for small things like this one, that pushed us to revisit and improve the current code :sunglasses:

Maybe you could push your branch even dirty in your fork, so that we could have a look to your WIP, and see if we could help ?

[ghaerr]

Hello @cocus,

I've spotted an issue on the disk init functions on the elks sources (where the default disk gets assigned id 01 instead of the more logical 00).

Are you talking about in disk init in EMU86 or ELKS? I don't quite understand what disk ID assignment you are talking about.

However, I've tried to boot DOS from it, and it doesn't even get near the point where it displays "Starting MSDOS..." as I can get with my bios.

I was thinking that you could start emu86 with "-i" option then run using "c" to display the disassembly. Its a bit tedious, but the terminal scrollback buffer could then be used to inspect what is happening in excruciating detail.

There are also some "-v7" etc options that turn on logging for various INT processing, which shows when certain INT instructions occur and other external-device related things, including IN and OUT instruction ports. Using -v options will spit out more high-level information, instead of looking at instruction traces. It's been a while since I tried this and I'll take a look and see whether anything can be added to help you on that.

Seems like there's an issue when reading disk sectors.

To remove issues relating to CHS numbering, etc., try booting from a floppy image. EMU86 emulates disk services using INT 13h. I'm thinking some info (-vXX) options could also be added there to show more exactly what is occurring.

Thanks!

[cocus]

@mfld-fr : I will upload my workspace to a branch today, and I'll let you know.

@ghaerr : No, I mean the rom-elks.c file. Have a look at https://github.com/mfld-fr/emu86/blob/cc283d0c70d6bde84242bacf51e3824c48816688/rom-elks.c#L185, that condition runs 5 times on my machine, but it should run 4 times. If I change that loop to use indices, then it loops 4 times (as expected). The side effect is that when you load an image, the first one ends up in the "second disk" (i.e. d = 1). This can be evidenced by the line https://github.com/mfld-fr/emu86/blob/cc283d0c70d6bde84242bacf51e3824c48816688/rom-elks.c#L242. Even tho this is not that important, I figured out it's not right either. And as a side note, I'm using the original 1.4M disk images, not an hdd image. CHS is setup properly for this disk image. -v 2 at least shows you some info about the disk reads.

I've been using the emulator with -i and going line by line. But I ran out of time trying to understand why DOS doesn't work with the "elks" target. I'll investigate further today. My day time work takes a lot of my time sadly.

[ghaerr]

that condition runs 5 times on my machine, but it should run 4 times.

Hello @cocus - this is a continuation of the same off-by-one bug with side effects that was reported by @mfld-fr in #31 and fixed in #38.

I'll submit a PR with the two other cases fixed.

Thanks for noticing and reporting this!

[ghaerr]

-v 2 at least shows you some info about the disk reads.

Try -v 3, that will add drive and CHS info for each attempted sector read on INT 13h calls, and run in "g" (go) rather than "c" continuous trace mode. Let me know where you'd like to see additional informational output.

[cocus]

@mfld-fr : https://github.com/cocus/emu86/tree/cocus/orckitt-566-emu86 Here's my local mods that I've carried in order to support (somewhat) this board. Note that the "SD" card emulation is something I've added since I've hacked an SD card into the 80C188 pins directly (that technology wasn't available back then LOL).

@ghaerr : I've figured out why I couldn't interrupt the app and it got killed when I hit ^C. It turns out it's because of vscode's terminal, which seems to kill the app if you press these keys. I've tried on a normal system console, and indeed, I got the expected behavior.

[mfld-fr]

@cocus : just a question after looking at your fork. What is exactly your CPU / MCU model ? You told in #30 that you are dealing with a 80C188 (no UART, DMA in PCB), while I can see in your fork that you included the 80C186EB header (2 UARTs, no DMA in PCB).

[cocus]

It's an 80C188EB. Yes, I had that H file since I started tinkering with it a long ago. I don't even know where I got it from, but it had all the PCB elements I needed (for now). I usually double check if they are on the same position as the datasheet expects. There might be a 80c188eb.h somewhere, but this one still fits my needs. This 80C188EB has 2 UARTs, and I should check if there's a DMA available (I don't think so, that might only be available on the -XL variants).

[mfld-fr]

OK, got it, thanks. According to the 80C188EB datasheet, I think you have no DMA, as DMA silicon in 80C188 looks to have been moved out to make room for UARTs. Anyway, UART is more usefull for hacking than DMA :smile:

[mfld-fr]

I think that after generalizing SIGINT for 'debug break', and fixing the BIOS disk array by the way, we are done with the initial question.