mfld-fr / emu86 Goto Github PK

Opened this issue to track one remaining option in #32.

Many projects use a shared emu86 executable for testing, and expect a project-specific configuration (especially the 'target' parameter), but have no way to check if the current executable was built with the right configuration.

So add a command-line option to report the configuration used to build the emu86 executable.

This is a very good test case for the graphical console 😉

A:\>alleycat
Please turn on the color display.
error: INT 10h AH=00h: unsupported mode 4h
error: execute operation
2B0F:5C93  CD 10              INT     10h

From #14 : replace assertions by returning error to help user for debugging.

Hello @mfld-fr,

I thought you might be interested in this statement from the IBM PC AT Technical Reference manual, compatibility section (2nd bullet point):

It seems to say that the 80286 CPU in the PC/AT does not perform a trace (TF flag) interrupt on the INT instruction, but that the processor used in the IBM PC/XT does interrupt on the INT instruction when the TF flag is set.

Currently, EMU86 does not trace through INT, as it resets TF flag on execution, correct? I present this for informational and discussion purposes only.

Thank you!

First ELKS port to 8018X revealed that a better timing accuracy is needed to predict the target responsiveness. As the main loop frequency is already measured, the idea is to compute ratios for timer frequency and CPU IPS, and adapt the emulator IPS to match the emulator timer frequency.

Example for the R8810:
Tfreq = 5 MHz, Efreq = 3 MHz -> Rf = 0.6
Tips = 1.3 M -> Eips = 0,78 M -> Ri = 0.26
The emulator should execute 26 instructions per 100 iterations.

@cocus : what would be the OR566 frequencies ?

Hello @mfld-fr,

I was successful in a quick first pass at enhancing the disassembler to convert address values to symbol names, including private static symbols in the ELKS kernel. For instance, here's a trace of ELKS ROM kernel returning from a timer interrupt. You can see the scheduler timer list being checked and then the PIC EOI and register restore, with symbols from C and ASM. This greatly enhances the ability to see what is going on:

I haven't added the far text segment or data segment symbol lookup yet. There might be some issues determining when a data reference should be converted to a data symbol or not. The current implementation is a hack that uses a conversion of an ia16-elf-nm namelist of the ELF system file (before elf2elks conversion) to C and compiles it in, which isn't really what we want. I was thinking of a -M mapfile option or something like that, along with the -f system image. We will need a way to specify the near vs far code segment, which I haven't thought of how to handle yet.

Is this something you are interested in? I've produced this with a 20-line hack, but it needs work and my hands are a bit full over at ELKS right now. You probably have your own ideas about how this should be implemented.

Thank you!

Because printing is not coupled to decoding.

I tried for the first time the 'console' mode on commit 1e25716, and I got the following error on Gentoo Linux:

mfld@home /mnt/data/home/mfld/advantech/mon86/target $ ../../emu86/emu86 -w 0x80000 -f ../../img/ADVTECH1.BIN -w 0xf8100 -f mon86.bin -c 0xf8100
info: load address 80000h
info: load file ../../img/ADVTECH1.BIN
info: file size=80000h
success: file loaded
info: load address F8100h
info: load file mon86.bin
info: file size=B2Ch
success: file loaded
info: code breakpoint address F8100h
warning: writing byte into ROM @ f0692h
warning: cannot read from console:: Resource temporarily unavailable
error: execute operation
0060:472A  CD 16              int     $0x16
>q

The same run works fine in 'pty' mode.

R8810 is an Intel 80188 clone by RDC.

Missing code path: functions char_normal & char_raw are not connected to the debugging loop when the emulated serial port uses the stdio back-end. Have to do the same asconsole_normal & console_raw, but as serial_normal & serial_raw.

Workaround is to use the pty back-end with SERIAL=pty, and to use pcat for serial input / output (as on the real target).

After commit of #50, I refreshed repo which had a couple other changes to it during time PR was being constructed.

Upon refresh, same ELKS image which works on #50 fails to boot with the following startup and error:

$ emu86 -I ../elks-gh/image/fd1440.bin 
info: disk image ../elks-gh/image/fd1440.bin (DCHS 0/80/2/18)
error: execute operation
AX 0800  BX 0004  CX 4F12  DX 0080  FL 0001
SI 0000  DI 0000  IP BBB4  SP 213E  BP 0000
DS 0000  ES 0000  CS 02C0  SS 1233

CF 1  PF 0  AF 0  ZF 0  SF 0  TF 0  IF 0  DF 0  OF 0

02C0:BBB4  CD 13              int     $0x13
>

Image attached:
fd1440.bin.zip

Any ideas? I don't yet know if this has to do with 8-bit ADD fix or an INT 13h modification. I thought I'd ask before digging into it.

From #9 : in continous traced execution, output an additional trace when a HW interrupt occurs (actually the fake timer interrupt for now).

The addition of -Werror in Makefile prohibits macOS (running with off_t = long long) from compiling. Here is compilation with -Werror removed:

cc -g -Wall -DSDL=1 -DELKS   -c -o emu-main.o emu-main.c
emu-main.c:54:37: warning: format specifies type 'unsigned long' but the argument has type
      'off_t' (aka 'long long') [-Wformat]
                printf ("info: file size=%lXh\n", size);
                                         ~~~      ^~~~
                                         %llX
1 warning generated.
cc -g -Wall -DSDL=1 -DELKS   -c -o op-print-intel.o op-print-intel.c
cc -g -Wall -DSDL=1 -DELKS   -c -o emu-con.o emu-con.c
cc -g -Wall -DSDL=1 -DELKS   -c -o con-sdl.o con-sdl.c
cc -g -Wall -DSDL=1 -DELKS   -c -o rom8x16.o rom8x16.c
cc -g -Wall -DSDL=1 -DELKS   -c -o serial-none.o serial-none.c
cc -g -Wall -DSDL=1 -DELKS   -c -o rom-elks.o rom-elks.c
rom-elks.c:155:58: warning: format specifies type 'unsigned short' but the argument has
      type 'byte_t' (aka 'unsigned char') [-Wformat]
                        printf ("\nerror: INT 10h AH=%hXh not implemented\n", ah);
                                                     ~~~                      ^~
                                                     %hhX
rom-elks.c:350:59: warning: format specifies type 'unsigned short' but the argument has
      type 'byte_t' (aka 'unsigned char') [-Wformat]
  ...printf("INT 13h AH=%hxh: invalid DCHS %d/%d/%d/%d\n", ah, d, c, h, s);
                        ~~~                                ^~
                        %hhx
rom-elks.c:356:69: warning: format specifies type 'unsigned short' but the argument has
      type 'byte_t' (aka 'unsigned char') [-Wformat]
  ...printf("INT 13h AH=%hxh: multi-track I/O operation rejected\n", ah);
                        ~~~                                          ^~
                        %hhx
rom-elks.c:387:58: warning: format specifies type 'unsigned short' but the argument has
      type 'byte_t' (aka 'unsigned char') [-Wformat]
                        printf ("\nerror: INT 13h AH=%hXh not implemented\n", ah);
                                                     ~~~                      ^~
                                                     %hhX
rom-elks.c:488:58: warning: format specifies type 'unsigned short' but the argument has
      type 'byte_t' (aka 'unsigned char') [-Wformat]
                        printf ("\nerror: INT 16h AH=%hXh not implemented\n", ah);
                                                     ~~~                      ^~
                                                     %hhX
rom-elks.c:504:59: warning: format specifies type 'unsigned short' but the argument has
      type 'byte_t' (aka 'unsigned char') [-Wformat]
                        printf ("\nerror: INT 17h: AH=%hXh not implemented\n", ah);
                                                      ~~~                      ^~
                                                      %hhX
rom-elks.c:545:59: warning: format specifies type 'unsigned short' but the argument has
      type 'byte_t' (aka 'unsigned char') [-Wformat]
                        printf ("\nerror: INT 1Ah: AH=%hXh not implemented\n", ah);
                                                      ~~~                      ^~
                                                      %hhX
7 warnings generated.

These errors are likely in rom-pcxtat.c as well.

Suggest either removing -Werror or fixing printf format specifications to be portable.

Staging branch is https://github.com/mfld-fr/emu86/tree/sdl.

After #14 merge, as the INT8 will no more be called on each HLT instruction, implement a dummy timer to keep the ELKS timeouts working, otherwise it would block in the BIOS console driver.

Compilation of EMU86 fails when SERIAL=pty set in config.mk:

Gregs-MacBook-Pro2:emu86 greg$ make
cc -g -Wall -Werror   -c -o list.o list.c
cc -g -Wall -Werror   -c -o op-common.o op-common.c
cc -g -Wall -Werror   -c -o op-id-name.o op-id-name.c
cc -g -Wall -Werror   -c -o op-class.o op-class.c
cc -g -Wall -Werror   -c -o emu-mem-io.o emu-mem-io.c
cc -g -Wall -Werror   -c -o emu-proc.o emu-proc.c
cc -g -Wall -Werror   -c -o op-exec.o op-exec.c
cc -g -Wall -Werror   -c -o emu-int.o emu-int.c
cc -g -Wall -Werror   -c -o emu-main.o emu-main.c
cc -g -Wall -Werror   -c -o op-print-intel.o op-print-intel.c
cc -g -Wall -Werror   -c -o emu-con.o emu-con.c
cc -g -Wall -Werror   -c -o con-char.o con-char.c
cc -g -Wall -Werror   -c -o char-stdio.o char-stdio.c
cc -g -Wall -Werror   -c -o serial-char.o serial-char.c
cc -g -Wall -Werror   -c -o char-pty.o char-pty.c
char-pty.c:101:3: error: implicit declaration of function 'cfmakeraw' is invalid in C99
      [-Werror,-Wimplicit-function-declaration]
                cfmakeraw (&tios);
                ^
1 error generated.
make: *** [char-pty.o] Error 1

I was trying to debug latest reported problem between EMU86 and ELKS ghaerr/elks#932 (comment) with 8018X target.

Since 8018x target uses serial port as ELKS console, EMU86 has to be configured differently. I tried a couple configurations to no avail, then found this one.

Since 8018X version of ELKS uses serial port as console, and EMU86 has no other function of CONSOLE= in this case, IMO there ought to be an easy way for EMU86 to be use stdio for console/serial, without having to resort to special setup of pcat or pty. In other words, SERIAL=stdio should work when CONSOLE=stdio. Since that doesn't compile, I tried redirecting the serial port.

I don't think it should be a problem for both CONSOLE to be stdio and SERIAL=stdio in the 8018x case, since there is no other ELKS "console" output, and EMU86 won't read from stdio unless in ">" command mode.

I would get more into this but IMO it seems that this area of design of EMU86 is quickly becoming too complicated for user, and I now don't fully understand it.

Thank you!

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.

Hi, I've hacked this project enough to support my weird board that I'm trying to use (80C188, 128k RAM, 512k FLASH, serial port, and I've added an SD card) so I don't have to remove the flash, burn it, and place it back on the board to test my code. Of course I'm not emulating all of the aspects of the 80C188, but close enough.
I've reached a point where my custom bios is able to provide enough system services to interact with the user, read disk, etc.
Now I've tried to boot my own code, and it works perfectly. After that, I've tried to run DOS (MS-DOS 3.30, MS-DOS 6.22, FreeDOS) all of them from a 1.4MB floppy (emulated), but there's always an issue and it crashes. I'm not sure why tho, debugging it doesn't yield anything obvious. Both the MS DOS 3.30 and 6.22 usually crash after the DOS has been set up so it's providing the int21h, and I can see that it overwrites the entire BDA with gibberish.
Maybe you have some experiences running DOS on the emulator, or maybe one of my changes did break something, or even my BIOS is faulty or it's providing something that the DOS doesn't like.

Thanks!

POP CS is forbidden for 80186, allowed for 8086.

See #8 comments

The size of the operand is explicit for string operations with 'BYTE' or 'WORD' qualifiers, but only given though an hint based on the number of digits when displaying an immediate value. Improve the display to be more explicit, in both Intel and AT&T syntax.

Hello @mfld-fr,

Over at ELKS I was reading a discussion where you were helping debug a floppy disk problem several years ago, and you mentioned you were using EMU86 to step through BIOS int 13h (disk I/O service). Did you write int 13h emulation code for EMU86 and/or do you still have it?

I have been thinking of adding BIOS int 13h emulation code to EMU86, that would allow a "standard" ELKS Image file to be mapped into EMU86, booted, and run. The Image file would be passed as an EMU86 parameter and the first block read into memory at 0:7C00. EMU86 could then be used to emulate the PC version of ELKS starting from the boot code!

Is this something you are interested in having added to EMU86?

Thank you!

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.

Hello @mfld-fr,

While adding code for cursor positioning for ELKS BIOS console, as first step for #39, some very strange timing-related behavior has been found. I am pretty sure this is relating to the changes made in converting from the dummy IRQ 8 ELKS hack to more fully emulating the 8259 PIC.

I don't completely understand the new PIC emulation code, and have spent hours debugging this, when finally a direct hint was found: the ELKS kernel is executing printk("Unexpected interrupt: %u\n", i); in elks/arch/i86/kernel/irq.c for IRQ 0 (timer interrupt), but only under certain startup and loop timing scenarios. This improper "unexpected interrupt" seems to be occurring continuously and the bug manifests itself as the SDL and Emscripten ports never displaying an initial console on startup (all black or grey). This seems to be because he SDL subsystem is thrashed with incoming data and never gets time to update the SDL buffer.

A PR is forthcoming which will enable duplicating the problem - the PR implements the remaining BIOS console functions, but the very strange thing is that the bug only shows up when BIOS console (not Headless console) is set on ELKS. further, the problem disappears when the TIMER_MAX value is upped from 1500 to 20000 in timer-elks.c.

Development can only continue by setting all TIMER_MAX values to 20000, and as a result, the SDL and Emscripten ports are very, very slow. Ultimately, using a instruction timer loop rather than real-time may be a continuing problem for EMU86 in this area. The reason(s) why are involved, but related to the fact that ELKS Headless and BIOS consoles require kernel polling, set by a kernel timer callback, in order to read the keyboard, and this entire process, along with the timer 0 interrupt frequency, is essentially used by the SDL/Emscripten ports to pump the graphics subsystem event loop. We can discuss more on this later.

Can you check to see whether the new PIC code checks to see whether it checks the 8259 specific mask bit before generating an interrupt? This could help to solve this issue.

Thank you!

Linux terminal is in bad shape after interrupting EMU86 with control-C and then exiting. Used default configuration with mixed debug and console in EMU86 stdio.