This page is a mirror of Tepples' nesdev forum mirror (URL TBD).
Last updated on Oct-18-2019 Download

Garbled graphics on Glory of Heracles

Garbled graphics on Glory of Heracles
by on (#105853)
I'm trying to make myself a reproduction of Glory of Heracles - Labors of the Divine Hero. It works great on the Power Pak, but when I burn the image to an eeprom onto an actual UOROM cart i get garbled graphics in different places, mainly on the title screen. I double and triple checked the wiring, and specifically used a UOROM cart instead of UNROM cart so that I didnt have to rewire the mapper for the extra A17 line. But alas...

I'm using a AM28F020 chip.

Does anyone know what might be going wrong? I can provide pictures of the glitch if needed.
Re: Garbled graphics on Glory of Heracles
by on (#105854)
The chip can't be the problem since the game is running, because UxROM uses CHR-RAM and all graphics are copied to VRAM from the PRG-ROM. My guess is that there's something wrong with the CHR-RAM chip... maybe you accidentally damaged its connections while working on the other chip?
Re: Garbled graphics on Glory of Heracles
by on (#105855)
I wouldnt think so... I never touched anything on that side, and its odd, the graphics that get garbles are not the sprites (i will throw a picture on soon). I was thinking though...is there a possibility that the rom with the translation patch has changed the data around? I know that it doubled the size of the rom from 128K to 256K, so maybe it messed something up? But if that was the case, you'd think that it wouldnt work properly on the Power Pak either.
Re: Garbled graphics on Glory of Heracles
by on (#105859)
Well, maybe the picture can shed some light on this problem...
Re: Garbled graphics on Glory of Heracles
by on (#105863)
Here are the pictures (not the best, from my phone):

In one of the stores, the background is all garbled:

Image

But this part of the game looks perfect:

Image


And the title screen looks awful:

Image

So, does this shed any light on this for anyone? I'm pretty stumped.
Re: Garbled graphics on Glory of Heracles
by on (#105866)
Is there any possibility of the latch being wrong? You can boot, so clearly the OR gate works. I think the tiles for the pegasus on the title screen are in the bank from 64-79KiB, while I think the rest of the title screen is in 48-63KiB.
Re: Garbled graphics on Glory of Heracles
by on (#105877)
Whats the latch?
Re: Garbled graphics on Glory of Heracles
by on (#105879)
The 74xx161 IC on the PCB. My best guess is that maybe the game isn't successfully switching to the correct bank when it's uploading tiles to CHR-RAM.
Re: Garbled graphics on Glory of Heracles
by on (#105880)
Actually, I have a better idea. Do you know that the translation you're trying actually avoids bus conflicts correctly?
Re: Garbled graphics on Glory of Heracles
by on (#105882)
No i dont, but its the only translation that I could find for it. Got it from romhacking.net . So you think it could be a problem with the patch itself? How could I test for that?

And, if it was a problem with the patch, wouldnt it glitch out on the Powerpak as well?
Re: Garbled graphics on Glory of Heracles
by on (#105886)
I would have thought it would have glitched out on the powerpak and emulators too. Maybe the AM28F020 can source too much current for the NES to override it?

I'm unfortunately not certain what the best test for you to do next is; if this is what's wrong, the fix would be an inverter from R/W to the ROM's /OE pin (assuming /PRGSEL is connected to /CE now)
Re: Garbled graphics on Glory of Heracles
by on (#105887)
How does the Powerpak handle mappers? Im just curious as to why this game would work fine on the powerpak and not on an actual UOROM cart. Its the only UOROM cart I have, so I cannot test another one. Does anyone want to make this one and tell me if it works? :wink:
Re: Garbled graphics on Glory of Heracles
by on (#105889)
Maybe the PowerPak doesn't emulate bus conflicts.

Quote:
Does anyone want to make this one and tell me if it works? :wink:

I'd rather debug the ROM in an emulator to make sure that all mapper writes are happening to ROM locations that contain the same value that's being written... =)
Re: Garbled graphics on Glory of Heracles
by on (#105891)
Yup, that's what was wrong: the UNROM bus-conflict avoidance table exists from $C56C through $C573 and consists of 0,1,2,3,4,5,6; as appropriate for the original 128KiB game. When they expanded the game to 256KiB, they didn't expand that table to include 7 through 14. (15?)

I guess I should report this, although briefly looking I don't see how to get in contact with DvD.

I'm also uncertain why Nestopia and Nintendulator don't seem to be emulating the bus conflicts. FCEUX 2.1.5 does, however:
Attachment:
fceux-with-bus-conflicts.png
fceux-with-bus-conflicts.png [ 2.67 KiB | Viewed 5180 times ]



In any case, there are two ways for you to fix this:
1- Add any inverter (7400, 7402, 7404, whatever) from CPU R/W to ROM /OE
2- Pester DvD to fix the patch.
Re: Garbled graphics on Glory of Heracles
by on (#105894)
tokumaru wrote:
I'd rather debug the ROM in an emulator to make sure that all mapper writes are happening to ROM locations that contain the same value that's being written... =)

Just checked... yeah, that's the problem. Just in case you're not familiar with bus conflicts: mapper commands are often "masked" as writes to PRG-ROM, because since the PRG-ROM obviously can't be written to, the writes are routed to the mapper instead. However, the ROM isn't disabled (in some mappers it is, but not this one), so it thinks it's being read, so it still outputs what's stored at the specific address that was written to. If the value being written is different than the one stored in the ROM, there's a bus conflict: two different values trying to use the same address lines at the same time.

To avoid this issue, games had to make sure that mapper commands were sent to ROM locations that had the same value as the one being written, so it was common for them to have tables of consecutive values (i.e. $00, $01, $02, $03 and so on, until the largest value that could be written).

The original Herakles no Eikou was only 128KB, so it had 8 PRG-ROM banks, and a bankswitch table with values from $00 to $06 (the last bank, $07, doesn't need to be switched in because it's hardwired to $C000-$FFFF). When they expanded the ROM, they didn't update the table, so whenever the higher banks (which they probably have used only for graphics) are accessed, the bus conflicts cause invalid banks to be selected.

Maybe this should be brought to their attention. They need to either expand the bankswitch table or relocate it to a location where it can count up to $0E.

EDIT: Ninja'd. Yeah, for now your only option is to mod the cart to prevent bus conflicts. You didn't do anything wrong, it's the translation guys that messed up.
Re: Garbled graphics on Glory of Heracles
by on (#105896)
lidnariq wrote:
although briefly looking I don't see how to get in contact with DvD.

There's an email address at the bottom of their main page: dvdtranslations at yahoo dot com
Re: Garbled graphics on Glory of Heracles
by on (#105898)
Bingo!!

That did the trick. I wired in a 74HC00 I had from an old Genesis cart and the game works perfectly now :D

Thanks for all your help guys!
Re: Garbled graphics on Glory of Heracles
by on (#105951)
getafixx wrote:
Bingo!!

That did the trick. I wired in a 74HC00 I had from an old Genesis cart and the game works perfectly now :D

Thanks for all your help guys!

Could you upload a pic of the board?
Re: Garbled graphics on Glory of Heracles
by on (#105962)
Sure, here it is.

Image

74'00 pin 3 connected to PRG pin 24
74'00 pin 1 connected to Cart connector 14
74'00 pin 7 connected to GND
74'00 pin 14 connected to VCC
Re: Garbled graphics on Glory of Heracles
by on (#106554)
Thanks! :D
Re: Garbled graphics on Glory of Heracles
by on (#109310)
tokumaru wrote:
tokumaru wrote:
I'd rather debug the ROM in an emulator to make sure that all mapper writes are happening to ROM locations that contain the same value that's being written... =)

Just in case you're not familiar with bus conflicts: mapper commands are often "masked" as writes to PRG-ROM, because since the PRG-ROM obviously can't be written to, the writes are routed to the mapper instead. However, the ROM isn't disabled (in some mappers it is, but not this one), so it thinks it's being read, so it still outputs what's stored at the specific address that was written to. If the value being written is different than the one stored in the ROM, there's a bus conflict: two different values trying to use the same address lines at the same time.

To avoid this issue, games had to make sure that mapper commands were sent to ROM locations that had the same value as the one being written, so it was common for them to have tables of consecutive values (i.e. $00, $01, $02, $03 and so on, until the largest value that could be written).

The original Herakles no Eikou was only 128KB, so it had 8 PRG-ROM banks, and a bankswitch table with values from $00 to $06 (the last bank, $07, doesn't need to be switched in because it's hardwired to $C000-$FFFF). When they expanded the ROM, they didn't update the table, so whenever the higher banks (which they probably have used only for graphics) are accessed, the bus conflicts cause invalid banks to be selected.

Maybe this should be brought to their attention. They need to either expand the bankswitch table or relocate it to a location where it can count up to $0E.

Thanks for bringing this to my attention. It may take a while, as I am busy with real life right now, but I will fix it if I can. Of course, it never came up in any of our testing on any emu or flash cart or we would have dealt with with at the time. I hate releasing more than one patch for a game...

I appreciate your explanation of the issue, but I don't completely understand it.
For me to modify this, I need to understand this completely.
Could you better explain why it reads the ROM even though this is a write command? Do all legitimate writes to RAM areas also do reads?

More importantly, what I don't understand for this game is why the address being written to is $8040 not c56c thru c572... why they didn't do what I see done in other games that do this: sta $c56c,y
I don't see how the processor knows to view anything at the table at c56c just because it comes directly after the code that accesses it.

I don't have the hardware to test it on, so I'd need to work with someone who does.

Code:
;--------------------
; UNROM_8000 = Y = Block_8000 = A
;--------------------
lbl_c565: sta $94       ;
          tay           ;
          sta $8040     ; UNROM_8000 = Y = vbl_94 = A
          rts           ; Return         lbl_c56b:
;--------------------
; Table UNROM_Bank_0_6: C56C thru C572
; 7 bytes
;--------------------
_c56c:       .byte $ 0   ;
             .byte $ 1   ;
             .byte $ 2   ;
             .byte $ 3   ;
C570:        .byte $ 4   ;
             .byte $ 5   ;
             .byte $ 6   ;
Re: Garbled graphics on Glory of Heracles
by on (#109319)
DvD wrote:
I appreciate your explanation of the issue, but I don't completely understand it.
For me to modify this, I need to understand this completely.
Could you better explain why it reads the ROM even though this is a write command? Do all legitimate writes to RAM areas also do reads?

All writes to ROM for UNROM or UOROM games are simultaneously reads. The ROM doesn't know to shut up when the NES is trying to write to it, so the game sees result of the CPU and ROM fighting.
This is usually the logical AND of the two bytes. Does http://wiki.nesdev.com/w/index.php/Bus_conflict explain to your satisfaction?

Quote:
More importantly, what I don't understand for this game is why the address being written to is $8040 not c56c thru c572... why they didn't do what I see done in other games that do this: sta $c56c,y
I don't see how the processor knows to view anything at the table at c56c just because it comes directly after the code that accesses it.
I'm not certain where you found the version that writes to $8040; the version I found in GoodNES and NesCartDB are the version that uses the look-up table. (ROM CRC32 = B15653BD)

Actually checking the game, the byte at $8040 will change depending on the bank currently mapped, e.g. banks 1 and 2 could switch to any bank, banks 3,5, and 7 can only switch to bank 0, so that really shouldn't work.

Quote:
I don't have the hardware to test it on, so I'd need to work with someone who does.
I believe that the newest versions of FCEUX enforce the bus conflcits.
Re: Garbled graphics on Glory of Heracles
by on (#133437)
Since the new versions of FCEUX don't even work with the original un-translated ROM I had, I decided that I would make a new version that will work in all emulators and in the real hardware. If you start with either version of the ROM, it will convert it to the new version.

Of course, now the $c56c table is located somewhere else as it wouldn't fit there. Here's what I did.

I had a 7 byte table that would now not be used and I needed to find a place for a 15 byte table. I found two 7 byte tables back to back. The first one could be expanded 1 more byte in front as the previous 2 bytes were both RTS instructions. I put the new 15 byte table there. I moved one of the 7 byte tables to $c56c. Finally, I'm pretty sure a 7 byte piece of code that simply inverts $91.0 does not get used. $91 is a flag for the text row vs. the dakuten row. But it is simply assigned 0 or 1 so it doesn't need to be toggled.

Problem now is that I need someone to play through the whole game with the new version on the real thing and I really don't have the ability or desire to do that myself. Anyone interested in beta testing Rev B of Heracles on real NES hardware?