Optionalize the target support

[mfld-fr]

Today EMU86 is used in two cases : testing MON86 / SYS86 before flashing it into the real target, and testing ELKS on an emulated PC platform. So build two versions of EMU86 : emu86-pc for PC platform, and emu86-sbc for Advantech SNMP-1000 SBC, each one with it specific INT, MEM and IO support.

[ghaerr]

Hello @mfld-fr,

This would be a useful addition.

I am in the process of implementing a "headless" console option in ELKS, where ELKS is built on top of just two BIOS calls for console I/O, instead of using the full ELKS BIOS Console, which has problems because of emulated cursor management, etc.

The other headless configuration would be a true "serial console", where console I/O uses a serial port. This option is different that the current CONFIG_CONSOLE_SERIAL, which just directs kernel output to the serial port.

For EMU86, ELKS could be verified running on a much smaller set of BIOS routines, something much closer to bare metal. With optionable EMU86 target support, that development process could made easier and quicker.

It could make sense to use #ifdefs/#ifndefs in emu-int.c, rather than completely separate source files per target. This would allow an "all" version that had everything, for porting new code, while the target could be changed during development and adaptation of the OS as well to the real hardware.

[mfld-fr]

@ghaerr : Sounds good ! About the target selection, I just pushed my working branch to show you my latest changes to implement a more low-level emulation at device level, rather than BIOS level, for you to figure out why I am currently wondering about the way to cleany unify the code for all targets : https://github.com/mfld-fr/emu86/tree/sys86

[ghaerr]

why I am currently wondering about the way to cleany unify the code for all targets

You have a lot going on, I will have to think more about it too.

A couple thoughts on your working branch (these are just general thoughts for a possibly organization):

• We definitely want to keep the possibility of having int10h and int16h BIOS emulations, for the "PC" (or possibly subset "ELKS") build. I just implemented CONFIG_CONSOLE_HEADLESS in ELKS that allows "console" I/O over just three BIOS calls, INT 16h AH=1 (read kbd), INT 16h AH=0 (get kbd status), and INT 10h AH=0x0E (write teletype); this reduces the BIOS footprint substantially for the ELKS ROMFS/EMU86 version. Combined with CONFIG_CONSOLE_SERIAL, this should allow running ELKS on advtech over serial only with just stubbed or no BIOS calls. (This could be checked by turning off various emulated INTs using a config file or Makefile defines?).
• Possibly use -DADVTECH=1 or -DELKS=1 in Makefile to include/exclude BIOS or other features between targets for the short term time being, before splitting files.
• Suggest possibly splitting emu-int.c in to emu-bios.c for BIOS emulation, (and/or e.g. hw-8259.c for hardware device emulation) outside of 8086 CPU.
• Suggest possibly renaming older serial_send/serial_recv etc to console_send/console_recv etc to eliminate confusion between that and the new actual serial port emulation, which also use "serial" in function names. Since PTY driver is now of little use, remove it from emu-serial.c.
• Rename emu-serial.c to hw-8250.c.
• Possibly split emu-mem-io.c into emu-mem.c and hw-io-advtech.c.
• Not sure if you're removing memset of 0xFF in main RAM: this was useful for finding some earlier bugs that ended up executing FF's.

[mfld-fr]

Finally, keeping the same executable name, but with options in Makefile to select the emulated target : 'elks' for standard PC, and 'advtech' for SNMP-1000 SBC. Done in #14 (first commit).