invalid opcodes with your alpha version
LowLevelMahn opened this issue · comments
tested your alpha from: https://www.reddit.com/r/EmuDev/comments/hku1vb/x86_sharing_very_early_build_of_new_80186_pc/
"crashes" for me someway
bios boot goes well but then just a blank window
different error with a freshly git version/build x64 debug
using latest SDL2 dev and latest VS2019
VS2019 x64 debug
x86 build debug crashes even further
so its 12.07.2020/8:48 and you just pushed changes :) need to test again
still crashes very very early with x86?
and x64 debug give
Ah, I see the problem with your original post. Use "-hd0 hd0.img" instead of -hd1. Maybe a bit confusing, but it's zero-based. It was loading the disk up as the second hard drive. So there was no bootloader code loaded, but the CPU just starts executing at 07C0:0000 anyway.
For the machine initialization failure in your latest post, did you make sure you copy the roms folder into the start-up path of the debug run? (Or modify the start-up path to be wherever your "roms" folder currently is) ... It's acting like it can't find the BIOS.
The crash you get in the git version in OPL3_getSample is more interesting. That's something I haven't seen, I've tested on a number of machines though they've all been Windows 10. Maybe I need to spin up a Win 7 VM and see if I can reproduce.
Thank you for reporting issues!
-
my x86 version crashed too early because of the wrong "x64" SDL2 dll version - FIXED
-
"-hd0" fixed the overall startup problems
your pre_alpha is running fine (BIOS, DOS,...)
but the latest git-versions is still crashing
x86 and x64 get both the stack-corruption error in OPL3_getSample
if your able to run under Linux - try using the super briliant with gcc or clang builtin
AddressSanitizer(https://stackoverflow.com/questions/37970758/how-to-use-addresssanitizer-with-gcc9)
much much better than valgrind or dr.memory - maybe its an undefined behavior that just don't happend on your system
you just need to add some configs to your sh script thats it
does not crash for both if i disable OPL3 in Code
or
if using Dr.Memory on XTulator.exe which slows down the startup dramaticaly to less than 10-20% of the normal speed
could be an evil timing/thread access problem - AdressSanitizer should show, also very nice is ThreadSanitizer which shows races
I think I found the problem with the OPL3 crash, and I suspect it'll work for you with the latest master commit.
nope :(
the stack corruption moved a little
just use ASAN(and TSAN) under linux - every error that gets reported is a real error, sometimes hard to see that reported stuff are real errors - due to programmers confidence in code quality :)
and i don't think that my main development machine/or used software is the problem here: dosbox and all other emulators im trying, also SDL1/2 using stuff never gets me a stack corruption not with mingw, vs2017 or vs2019 - i would do the ASAN test myself but i've currently got no linux at hand - still waiting for Microsoft to get ASAN for Visual Studio out of beta
I fixed it! I was able to reproduce it in debug mode. Nuked OPL wanted two bytes to play with when generating the sample, even though I told it I only want one. Some resampling logic it's doing. So whatever was in the address after my variable in the stack was getting overwritten. The joy of pointers.
works!
-the heap manager/code generation is extended with more testing in debug mode - best for finding memory problems - release mode will just produce undefined behavior
-ASAN would have told you the source of the problem on first try
I didn't want to set up a linux VM for this right now, and the MSVC ASAN didn't tell me anything. Glad it's working, thanks for pointing it out.
i though you were on linux :)
MSVC ASAN is still in very beta state :(