Page 3 of 4
Posted: Sat May 04, 2013 4:20 am
by Firebrandx
panzeroceania wrote:Firebrandx, what games have you tried? and where did you get the roms?
do you have checksums?
I believe they are Goodgen or whatever it's called. Anyway, no matter what game I load, I can hear sound and see the palette and memory banks reacting, but the image window remains completely white.
Posted: Sat May 04, 2013 2:37 pm
by mickagame
Olympic Gold (Barcelona 92).
I think there is a bug with control when playing archery.
If anyone can confirm ...
Posted: Thu Jun 27, 2013 2:37 am
by superandroidtron
Day Trip Tech demo
Freezes on gray screen upon startup
Posted: Sat Sep 14, 2013 9:08 am
by tryphon
Ibn Active disassembly settings, if you give a Start address greater than the End, Exodus crashes.
Posted: Mon Sep 23, 2013 4:53 pm
by tryphon
I don't know if it's a bug, but playing Phantasy Star 3 and keeping loading the same save state again and again, I don't always have the same result when the game starts.
I didn't try to reproduce it with another emulator.
EDIT : I've noticed it happens more often if I pause the emulator (through processor control), then load a save state, then re-run the emulator.
It's clearly related to Exodus, and not to the game.
Just a conjecture : maybe some operations lock part of the RAM, and loading save state doesn't unlock it ?
Posted: Wed Oct 09, 2013 7:34 pm
by tryphon
I put my hand on a game that won't start with Exodus : Psy-O-Blade.
Here's what the event.log says :
21:27:33.863 4 - Error System Failed to load module from file C:\Users\Tryphon\Downloads\Exodus_1.0.0\Modules\AutoGenerated\MegaDriveROMLoader\psyoblade.bin.xml!
21:27:33.712 4 - Error System Errors occurred while loading module from file C:\Users\Tryphon\Downloads\Exodus_1.0.0\Modules\AutoGenerated\MegaDriveROMLoader\psyoblade.bin.xml.
21:27:33.273 4 - Error System BusInterface.MapDevice failed for SRAM on bus BusInterface!
21:27:32.791 4 - Error System BusInterface.MapDevice failed for SRAM on bus BusInterface!
21:26:41.762 1 - Information System Loaded module from file C:\Users\Tryphon\Downloads\Exodus_1.0.0\Modules\Sega Mega Drive.xml.
21:26:30.783 1 - Information System Successfully registered device Z80.
21:26:30.718 1 - Information System Successfully registered device YM2612.
21:26:30.653 1 - Information System Successfully registered device SN76489.
21:26:30.565 1 - Information System Successfully registered device TimedBufferIntDevice.
21:26:30.563 1 - Information System Successfully registered device SharedRAM.
21:26:30.561 1 - Information System Successfully registered device RAM.
21:26:30.559 1 - Information System Successfully registered device ROM.
21:26:30.528 1 - Information System Successfully registered extension MegaDriveROMLoader.
21:26:30.441 1 - Information System Successfully registered device MDBusArbiter.
21:26:30.440 1 - Information System Successfully registered device MDControl6.
21:26:30.440 1 - Information System Successfully registered device MDControl3.
21:26:30.439 1 - Information System Successfully registered device A10000.
21:26:30.384 1 - Information System Successfully registered device M68000.
21:26:30.277 1 - Information System Successfully registered device S315-5313.
I've tried with 2 different ROM dumps.
Posted: Sat Oct 12, 2013 4:08 pm
by tryphon
Another game that won't start, but for another reason : Ninja Burai Densetsu.
The emulator starts, but the code seem traped in a loop, before the appearance of SEGA logo, as if the geographical protection was active (but I tried with Nemesis in all 4 modes).
The ROM plays well with Gens.
Posted: Wed May 21, 2014 4:41 am
by ehaliewicz
I found a bug while working on some code.
Basically, the line
isn't updating the A6 register.
Posted: Mon May 26, 2014 10:45 pm
by Nemesis
That animation is very useful, thanks for recording that. From looking at what you're doing, I think it's actually just a user interface update issue, I think the register is in fact being set correctly.
On those debug windows, when you put the cursor into one of the text boxes, updates are frozen on that text box until it loses focus. Updates need to be frozen, otherwise you couldn't actually type a new value while the data was being actively changed. When the edit control loses input focus, the debug window compares the current text in the edit control with the text that was originally in the control when it obtained input focus, and if it's changed, it updates the register with the new value. It appears what's most likely happening is that the register window isn't correctly recognizing that focus has been lost, so the text in the window isn't being updated. I'll try and reproduce this problem on my end, and see if I can prevent it occurring.
What I would suggest to confirm the cause of this issue, and to work around it, is to try doing the same steps you were doing, but before clicking on another window after putting input focus on a register text box, click on the background of the register window. That should clear the input focus from any text boxes, and should allow the register window to update all fields with the new values when the processor state changes.
Posted: Tue May 27, 2014 12:29 am
by ehaliewicz
Nemesis wrote:That animation is very useful, thanks for recording that. From looking at what you're doing, I think it's actually just a user interface update issue, I think the register is in fact being set correctly.
On those debug windows, when you put the cursor into one of the text boxes, updates are frozen on that text box until it loses focus. Updates need to be frozen, otherwise you couldn't actually type a new value while the data was being actively changed. When the edit control loses input focus, the debug window compares the current text in the edit control with the text that was originally in the control when it obtained input focus, and if it's changed, it updates the register with the new value. It appears what's most likely happening is that the register window isn't correctly recognizing that focus has been lost, so the text in the window isn't being updated. I'll try and reproduce this problem on my end, and see if I can prevent it occurring.
What I would suggest to confirm the cause of this issue, and to work around it, is to try doing the same steps you were doing, but before clicking on another window after putting input focus on a register text box, click on the background of the register window. That should clear the input focus from any text boxes, and should allow the register window to update all fields with the new values when the processor state changes.
Thanks a bunch. This has happened a few times since and I hadn't figured out a consistent way to trigger it or fix it. I'm not sure it's always caused by focusing on the input field for the register (I didn't actually know you could change it
), but you are probably right in this case. At the very least, restarting the emulator tends to fix it
.
Posted: Fri Jun 27, 2014 10:01 am
by Miles Prower
I found a game that doesn't boot called 'Fatal Rewind"
Posted: Thu Jul 03, 2014 8:40 pm
by plamazy
ehaliewicz wrote:I found a bug while working on some code.
Basically, the line
isn't updating the A6 register.
That looks the same as what I posted about before:
MOVEA.L $C(A6), A1
did not update A1 correctly. As I noted, the value in A1 didn't update, even after moving to another part of the code. It is easy to repro because it happens every time.
Posted: Mon Aug 25, 2014 7:18 pm
by Eugene.S
Castlevania - Bloodlines (U) [!].gen
bug:
1) Load Rom and go to the options menu in game
2) Try to listen different BGMs (from 00 to 30)
and press B (to stop playback) and C (to start playback) buttons
Sound disappears suddenly when you are listen BGMs in option menu,
and you'll need to reset system by pressing F4
Posted: Sun Dec 07, 2014 2:08 pm
by Kabuto
Exodus seems to be about the only emulator that denies 68k -> z80 bus accesses while the z80 bus isn't fully acquired yet - pretty nice for debugging. But there's an implementation bug. In my case I'm just using z80 instructions with 4T maximum, so theoretically the 68k just needs a pause of 11 cycles between requesting and accessing the z80 bus - and hardware tests show that that's actually the case and things work just fine with 12 cycles inbetween. This code snippet works fine on Exodus and real MD:
Code: Select all
move.w #$100, $A11100 ; Request z80 bus
swap d6 ; as much delay as a NOP
move.l d7, (a4)+ ; write to the z80 bus (2*word writes on purpose, just need the upper half byte of each word to be transferred)
move.w d6, (a1) ; Release Z80 bus (writes 0 to $A11100)
Though this snippet here works fine on a real MD but glitches heavily in Exodus:
Code: Select all
move.w #$100, (a1) ; Request z80 bus (writes to $A11100)
swap d6 ; as much delay as a NOP
move.l d7, (a4)+ ; write to the z80 bus (2*word writes on purpose, just need the upper half byte of each word to be transferred)
move.w d6, (a1) ; Release Z80 bus (writes 0 to $A11100)
I'd expect the write to always happen last no matter what the instruction is, and thus on hardware there's no difference between these 2 snippets - they both have a delay of 12 cycles between z80 bus request and z80 bus write. But Exodus gets something wrong here.
Posted: Sun Dec 07, 2014 10:14 pm
by Nemesis
You're right, there is a timing issue there right now. The problem is that the M68000 and Z80 cores in Exodus don't currently support yielding the bus partway through an opcode, meaning it can take longer to acquire the bus in Exodus than it would on the real hardware currently. There are two reasons for this limitation, one being the way the emulation cores were originally written when I hadn't considered this issue, and the second one being a lack of accurate timing information on when bus access occurs within an opcode for both the M68000 and Z80 processors.
This is the biggest accuracy issue with the emulator right now, and it's also the main cause of a lot of games not running currently. Other emulators actually use incorrect timing for VDP events in order to make things work, IE, especially around the assertion of the VDP "F" status flag. Correct emulation of the timing for these games requires correct timing emulation of each bus access.
I'm working towards solving the design problems for the next release of Exodus, so that yielding the bus partway through an opcode will be possible. All that will be required then is to perform thorough and complete hardware tests to determine the timing and order of each bus access within each opcode. The recently designed UMDK hardware will make this much easier fortunately, due to its bus trace feature.