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.panzeroceania wrote:Firebrandx, what games have you tried? and where did you get the roms?
do you have checksums?
Bug reports?
Moderator: Nemesis
-
- Newbie
- Posts: 7
- Joined: Fri May 03, 2013 7:54 pm
-
- Newbie
- Posts: 2
- Joined: Sat Jun 01, 2013 11:17 pm
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 ?
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 ?
Last edited by tryphon on Wed Oct 09, 2013 7:39 pm, edited 1 time in total.
I put my hand on a game that won't start with Exodus : Psy-O-Blade.
Here's what the event.log says :
Here's what the event.log says :
I've tried with 2 different ROM dumps.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.
-
- Very interested
- Posts: 50
- Joined: Tue Dec 24, 2013 1:00 am
I found a bug while working on some code.

Basically, the line
isn't updating the A6 register.

Basically, the line
Code: Select all
movea.l #$00FF0D1E, A6
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.
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.
-
- Very interested
- Posts: 50
- Joined: Tue Dec 24, 2013 1:00 am
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 itNemesis 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.


-
- Newbie
- Posts: 3
- Joined: Thu Jun 26, 2014 7:23 am
That looks the same as what I posted about before:ehaliewicz wrote:I found a bug while working on some code.
Basically, the lineisn't updating the A6 register.Code: Select all
movea.l #$00FF0D1E, A6
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.
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
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
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:
Though this snippet here works fine on a real MD but glitches heavily in Exodus:
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.
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)
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)
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.
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.