search

mfld-fr / emu86

Intel IA16 emulator for embedded development
37 stars 6 forks source link

New layout for devices & backends #33

Closed mfld-fr closed 3 years ago

mfld-fr commented 3 years ago

This is a proposal to make the 'virtual device' / 'real backend' coupling more clear (including the console).

ghaerr commented 3 years ago

@mfld-fr: This all looks fantastic, thanks!

I can add cursor positioning, etc to sdl backend later, currently sdl is implemented for just streaming console data from ELKS headless console. If we want, ELKS direct console and support for writing and displaying character RAM directly could be added at 0xB800, etc. This would allow ELKS to run with direct console instead of requiring BIOS or Headless console.

I am in favor of committing all this, and eventually going into master branch. What else needs to be done, are the serial, stdio and sdl consoles all running? Let me know if you'd like me to test this PR after merge.

I'm not sure if you are aware, but ELKS now supports an option in the /bootopts file that allows setting serial console without kernel recompilation. This greatly speeds up testing. Are there other options that should be added to ELKS for this? Currently, Direct/BIOS/Headless console must be compiled in, but any of them can use redirected serial console (via menuconfig or /bootopts).

Another issue for discussion is that it would really nice to support stdio-based interactivity with EMU86 using your ">" prompt commands, while the SDL console is displaying the BIOS (ELKS or other) console output. I didn't get into implementing this in the POC. The command-checking should be removed from the main loop, where it can be enhanced etc as necessary, without being right in the middle of the EMU86 main loop code. It would be really nice to see instructions executing continuously (using "c" command) on stdio while emulated BIOS output is displayed on SDL console, with the ability to ^C to stop the emulation, set breakpoints, dump registers, set memory, etc. The only big issue here is exactly where the command prompt "read" comes from - we need a split version where the "console" is SDL but the command read is stdio.

Thank you!

mfld-fr commented 3 years ago

If we want, ELKS direct console and support for writing and displaying character RAM directly could be added at 0xB800, etc. This would allow ELKS to run with direct console instead of requiring BIOS or Headless console.

Yes, using the emulated memory mem_stat @ 0xB800 , etc., in emu-mem-io.c as the pixels buffer in con-sdl would be a nice thing.

I am in favor of committing all this, and eventually going into master branch. What else needs to be done, are the serial, stdio and sdl consoles all running? Let me know if you'd like me to test this PR after merge.

OK, so let me merge this PR, then I could focus on testing for the Advantech target, while you could focus on testing for the ELKS target. After this round of non-regression testing, we could merge the sdl staging branch to master.

I'm not sure if you are aware, but ELKS now supports an option in the /bootopts file that allows setting serial console without kernel recompilation. This greatly speeds up testing. Are there other options that should be added to ELKS for this? Currently, Direct/BIOS/Headless console must be compiled in, but any of them can use redirected serial console (via menuconfig or /bootopts).

The serial port virtual device mapping to any character backends (a.k.a. serial-char.c) is not yet implemented and is needed to test that ELKS serial console -> to be implemented before merging in master.

Another issue for discussion is that it would really nice to support stdio-based interactivity with EMU86 using your ">" prompt commands, while the SDL console is displaying the BIOS (ELKS or other) console output. I didn't get into implementing this in the POC. The command-checking should be removed from the main loop, where it can be enhanced etc as necessary, without being right in the middle of the EMU86 main loop code. It would be really nice to see instructions executing continuously (using "c" command) on stdio while emulated BIOS output is displayed on SDL console, with the ability to ^C to stop the emulation, set breakpoints, dump registers, set memory, etc. The only big issue here is exactly where the command prompt "read" comes from - we need a split version where the "console" is SDL but the command read is stdio.

Agree, that big main loop should be reworked, to clearly separate what is related to 1) the CPU fetch / decode / execute cycle, 2) the virtual devices animation, 3) the debugger and 4) the program event loop.