mfld-fr / emu86 Goto Github PK
View Code? Open in Web Editor NEWIntel IA16 emulator for embedded development
Intel IA16 emulator for embedded development
POP CS is forbidden for 80186, allowed for 8086.
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
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.
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.
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.
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.
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.
R8810 is an Intel 80188 clone by RDC.
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.
From #9 : in continous traced execution, output an additional trace when a HW interrupt occurs (actually the fake timer interrupt for now).
Because printing is not coupled to decoding.
From #14 : replace assertions by returning error to help user for debugging.
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.
Opened this issue to track one remaining option in #32.
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!
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 ?
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.
Staging branch is https://github.com/mfld-fr/emu86/tree/sdl.
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!
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!
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!
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!
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).
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.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.