Bug reports?

Official support forum for the Exodus Emulation Platform

Moderator: Nemesis

Firebrandx
Newbie
Posts: 7
Joined: Fri May 03, 2013 7:54 pm

Post by Firebrandx » Sat May 04, 2013 4:20 am

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.

mickagame
Very interested
Posts: 256
Joined: Sat Jun 07, 2008 7:37 am

Post by mickagame » Sat May 04, 2013 2:37 pm

Olympic Gold (Barcelona 92).
I think there is a bug with control when playing archery.
If anyone can confirm ...

superandroidtron
Newbie
Posts: 2
Joined: Sat Jun 01, 2013 11:17 pm

Post by superandroidtron » Thu Jun 27, 2013 2:37 am

Day Trip Tech demo
Freezes on gray screen upon startup

tryphon
Very interested
Posts: 316
Joined: Sat Aug 17, 2013 9:38 pm
Location: France

Post by tryphon » Sat Sep 14, 2013 9:08 am

Ibn Active disassembly settings, if you give a Start address greater than the End, Exodus crashes.

tryphon
Very interested
Posts: 316
Joined: Sat Aug 17, 2013 9:38 pm
Location: France

Post by tryphon » Mon Sep 23, 2013 4:53 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 ?
Last edited by tryphon on Wed Oct 09, 2013 7:39 pm, edited 1 time in total.

tryphon
Very interested
Posts: 316
Joined: Sat Aug 17, 2013 9:38 pm
Location: France

Post by tryphon » Wed Oct 09, 2013 7:34 pm

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.

tryphon
Very interested
Posts: 316
Joined: Sat Aug 17, 2013 9:38 pm
Location: France

Post by tryphon » Sat Oct 12, 2013 4:08 pm

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.

ehaliewicz
Very interested
Posts: 50
Joined: Tue Dec 24, 2013 1:00 am

Post by ehaliewicz » Wed May 21, 2014 4:41 am

I found a bug while working on some code.

Image

Basically, the line

Code: Select all

movea.l #$00FF0D1E, A6
isn't updating the A6 register.

Nemesis
Very interested
Posts: 791
Joined: Wed Nov 07, 2007 1:09 am
Location: Sydney, Australia

Post by Nemesis » Mon May 26, 2014 10:45 pm

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.

ehaliewicz
Very interested
Posts: 50
Joined: Tue Dec 24, 2013 1:00 am

Post by ehaliewicz » Tue May 27, 2014 12:29 am

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 :oops: ), but you are probably right in this case. At the very least, restarting the emulator tends to fix it :wink: .

Miles Prower
Newbie
Posts: 3
Joined: Thu Jun 26, 2014 7:23 am

Post by Miles Prower » Fri Jun 27, 2014 10:01 am

I found a game that doesn't boot called 'Fatal Rewind"

plamazy
Newbie
Posts: 6
Joined: Mon Jul 08, 2013 12:04 pm

Post by plamazy » Thu Jul 03, 2014 8:40 pm

ehaliewicz wrote:I found a bug while working on some code.

Basically, the line

Code: Select all

movea.l #$00FF0D1E, A6
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.

Eugene.S
Newbie
Posts: 2
Joined: Sat May 04, 2013 10:20 pm

Post by Eugene.S » Mon Aug 25, 2014 7:18 pm

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

Kabuto
Interested
Posts: 27
Joined: Sun Aug 25, 2013 6:56 pm

Post by Kabuto » Sun Dec 07, 2014 2:08 pm

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.

Nemesis
Very interested
Posts: 791
Joined: Wed Nov 07, 2007 1:09 am
Location: Sydney, Australia

Post by Nemesis » Sun Dec 07, 2014 10:14 pm

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.

Post Reply