I have Linux (ubuntu 22.04.4 LTS), I tried to compile it and in the end I was able to do it, although it gave me some warnings, when trying to use it with commands like --version, or -d the program tells me segmentation fault
For safety concerns "%s" should be added. However no compiler errors/warnings about gtk_message_dialog_new() are emitted with gcc 11.1.0 and gtk-2 2.24.33-2 ("-2" from Arch Linux) on my machineTM Is this a gcc bug? Here is a truncated build log showing only the useful parts. -Wformat -Werror=format-security
For safety concerns "%s" should be added. However no compiler errors/warnings about gtk_message_dialog_new() are emitted with gcc 11.1.0 and gtk-2 2.24.33-2 ("-2" from Arch Linux) on my machineTM Is this a gcc bug? Here is a truncated build log showing only the useful parts. -Wformat -Werror=format-security
$ git apply fmt.patch
git apply fmt.patch
For safety concerns "%s" should be added. However no compiler errors/warnings about gtk_message_dialog_new() are emitted with gcc 11.1.0 and gtk-2 2.24.33-2 ("-2" from Arch Linux) on my machineTM. Is this a gcc bug? Here is a truncated build log showing only the useful parts.
compilation error for missing string literal or format arguments
Here is what happens w/o the patch.
Fix GCC 10 build failure
change gtk2 font size with gtk-chtheme
More on this: I also think all of the "negative summands" flag setting sections in correctOvCaFlagafterAddSubExtended() are incorrect. From reading this (accepted answer), the "addition" section flags are all being set correctly, but the subtraction (negative "b") flags are not: +-+ should probably not be setting OF +-- should probably be setting CF --+ should probably not be setting CF --- should probably not be setting OF That was just a cursory glance, and also assuming that the table in the the...
More on this: I also think all of the "negative summands" flag setting sections in correctOvCaFlagafterAddSubExtended() are incorrect. From reading this (accepted answer), the "addition" section flags are all being set correctly, but the subtraction (negative "b") flags are not: should probably not be setting OF should probably be setting CF should probably not be setting CF should probably not be setting OF That was just a cursory glance, and also assuming that the table in the the accepted answer...
Incorrect interpretation of sign extended immediate
cmake: - fixed compilation of plugins
buildsys: - added cmake buildsystem for linux - WIP
i8086pic/i8086sic: - implement CloseDevice function (fixed unknown symbols in log file)
i8086sic/i8086vga: - fixed missing symbol addString (only visible during runtime)
Link error in i8086gui on Gentoo
properly fixed in master - thx
i8086gui: - added missing linkage to clibs
Typos in makefile causing build errors
fixed in master - thx
Fix possible stack array overflow in i8086devices.c
Fix typos preventing build.
Typos in makefile causing build errors
GUI stack array overflow (off-by-one error)
fixed in master - thx.
Fix stack array overflow in GUI.
GUI stack array overflow (off-by-one error)
Link error in i8086gui on Gentoo
Typos in makefile causing build errors
GUI stack array overflow (off-by-one error)
Fixed a couple minor memory leaks.
Amends 53d5c2 -- Fixes return-with-immediate order of operations (#3).
Allow specifying breakpoints and memory addresses (and code display) beyond
Updates to fix memory leaks, and allow i8086text to use addresses up to 0xFFFFF
Those changes look fine. But i did a cosmetic commit yesterday which fixed all the indentation (2 spaces no tabs) and line endings (removed windows line endings and let git handle conversion). This resulted in this merge request to not cleanly apply. I have cherry-picked your three commits from your fork and fixed the indentation conflicts and pushed the result to our master. Also you should consider doing merge requests from dedicated branches on your side instead of doing those from your master...
Updates to fix memory leaks, and allow i8086text to use addresses up to 0xFFFFF
[cosmetic] - removed commented code
[cosmetic] - removed windows line endings - reindent the code (2 spaces - no tabs)
STOS does not grab correct register
fixed in git master
Thx - this is a simple C&P error - good spotting :)
Patch to fix #5 -- STOS incorrectly fetches AX into DI
REP does not correctly locate string command
Patch to fix #5 -- STOS incorrectly fetches AX into DI
Sorry, it looks like this was already fixed at some point. I had pulled the 0.9.2 tarball that was available from the front page, which (at least at the time) still had the bug that appears to have been patched back in 2004 (or prior).
well i really hate that ticket system if source forge - this very ticket appeas in "Patches" which suggests that you posted a patch aswell - but i can't see any patch. Are you able to do pull requests with your suggested changes (the easy ones at least) - it would make code discussions much easier ...
My fork was as of 305f9e, so not the "latest". I'm seeing now that there have been a significant number of commits since that time. There are also a significant number of bugs in i8086text.c, most of which pertain to reading/using/displaying addresses as uint16 rather than uint32. I'll upload those as a separate ticket, but it's going to be difficult to separate out the other changes I've been making as well (such as passing a core pointer to all routines, to allow multiple emulators to run in the...
I didn't have visibility into the history (since Git was only established with the latest version). By "at one point", I was referring to whatever change commented out the "direg=" and "accreg=" lines, and introduced the lines immediately after them. It's possible the commented-out lines were never part of a release.
which versions of the emu do you compare when talking about introduced regressions here?
did you test this with latest master code instead of the released binaries?
STOS does not grab correct register
REP does not correctly locate string command
[docs] - updated reference manual with searchable version - thx to Dr.Brown
this fix makes rep handle 2 byte stringops right! for V0.9.2
Nope this is simply bullshit. Patch is wrong. REP works fine as is.
missing opcode
fixed dec mem16 in git master c0f634b97884fbb4988e90263dfd757cfb24e5d1 - thx @hardi
[wrapper] - fixed duplicated opcode 255 (push, inc mem16, dec mem16, uncond jmp) by also allowing param 1 which is a sign for dec on 16 bit memory address - thx to hardi for the heads up - fixes #1
[asm] - added test for dec on 16bit memory address - part of #1
[Singletons] - we are in C land here - any proper C-Compiler/Linker will fail due to duplicated symbols (so does Xcode). Fixed by declaring our singletons as extern and define them in the related c file only
[cosmetic] - fixed missing end comment tag
SAHF bug
fixed in git master 1e87f30f649a94b5b68e93bc84fcce9c92009891
[asm] - test for SAHF - part of #4
[datatrans] - fixed SAHF by only transfering bits 0, 2, 4, 6 and 7 from AH to the flags register as documented by intel in 1979 - fixes #4
LAHF bug
fixed in git master 273cb2fd5d4fcf370978d5a65867d1a89e27dd9d
[Makefile.in] - properly remove vga and sic device when usegtk is configured to 0 - fixes compilation on osx (where make is a bit more restrictive)
[datatrans] - fixed LAHF - only transfer bits 0, 2, 4, 6 and 7 into AH - leaving 1,3 and 5 untouched - fixes #3
[emufuncs] - added missing include and fixed wrong call to new extended function - part of #5
Ok - looked into it again. In the intel reference from 1978 (the pdf i added to the docs folder in git) - says: [..] The content of bits 5 3 and 1 is undefined [..] Thats what we basically implemented here by simply copying the whole 8 bits of the flags register to AH (overwriting bits 5 3 and 1 in AH with whatever is in the flags register at that time). The second source of truth [tm] i've found is this one: http://www.electronics.dit.ie/staff/tscarff/8086_instruction_set/8086_instruction_set.html#LAHF...
[asm] - added missing asm examples
[devices] - add some missing source files for devices
[i8086text] - in addition to key "n" also allow "f7" to step to next instruction to match what the README says ...
core dumped if i8086test -r rom.bin
You used it in a wrong way. you need to do make install which will copy over the emu.cfg to your prefix/i8086emu dir You need to alter this file to enable the loading of the rom file Then you start with an assembled file as parameter only the given assembled program will be loaded at the configured program start address (default 0x100 or overwritten by -o option) The -r option you used contains of 2 parameters - an address and the rom file which should be loaded to address - once again - you used...
DEC instruction bug
fixed in masetr eb42009899d2abbc38257a6ba6759afb413a8121
[Error] - fixed possible bad access on invalid file pointer
[arithmetic] - fixed DEC and INC which is not supposed to alter the carry flag as of intel documentation - fixes bug #5
[emufuncs] - added correctOvCaFlagafterAddSubExtended with extra paramter for requesting unaltered CF flag - part of bug #5
[make] - fix of usegtk=0 - configure option (from patch tracker)
[docs] - added intel documentation for i8086 cpu
'opcode not implemented error'
'opcode not implemented error'
you've forgotten to assamble the fire.asm file with "nasm" before feeding it to the emu. The emu needs binary code not the ascii asm code.
new limker needs -fPIC in the CFLAGS
removed old CVSROOT
- fixed RETFS opcode wrong order of operations - fixes #3 - thx to ereisch for the fix
- fixed compilation on some newer gcc (4.9.2) - linking shared object needs -fPIC on the objects
added rom.bin and core.dmp
some more code updates from the tarball
Updated with all the files from the 0.9.2 release bundle
RETF-with-immediate returns to incorrect address
thx - i have converted this very outdated project to git and pushed your patch for this issue.
- fixed RETFS opcode wrong order of operations - fixes #3 - thx to ereisch for the fix
initial checkin