Thank you so much for this!
This was going to be my next question.
I just tried jumping the pins and removing the same chips as the photos and it wont boot, which makes me believe there is something modified in the ROM.
- Thread starter 98pacecar
- Start date
I just tried jumping the pins and removing the same chips as the photos and it wont boot, which makes me believe there is something modified in the ROM.
Brentradio
Champion
So will the multi kit remedy all of this?
My ESPGaluda board showed up tonight, same boards as EVAWINGZERO (killing blade), here is a link to the the 27c322 U9 rom. I have not had time to compare it to what is currently out there, but im sure you guys can clue us all in. Also in case it wasn't answered this graphics board revision is No 0213
ESPGaluda_u9 *Link removed, confirmed that dump matches MAME espgaluda_u8.bin*
Last edited:
Thanks for posting, I just compared it against MAME and it's a perfect match for the espgaluda_u8.bin in in espgalbl
so now I'm confused because I've run that ROM with the 2 jumper wires shown in EVAWINGZEROs pic and pulled all the same chips and got no boot.
that means that either
A. there is another modification to the PCB that we haven't noticed yet
or
B. the PALs are not original and that's what makes it work.
PASTBLASTER
Grand Master
Thanks neofrank, my EPRom writer is across town.
Do you guys want better / more pictures of any specific parts of the board?
Do you guys want better / more pictures of any specific parts of the board?
if the PAL is original then there has to be a cut trace or another jumper wire somewhere that we're missing. look over the PAL chip on the left side, the empty PAL socket below the EPROM and the traces in that corner of the PCB on both sides... Maybe even pull the PAL just to make sure there aren't any pins intentionally folded in.
Yes, as I said I pulled all the same chips so U2, U8 and U22 were all pulled when I tested.
@neofrank does your PAL have the label in-tact... if so I'm curious what it reads. Also do you have empty sockets on U3, U5 and U6, or no sockets at all? There seems to be a few variations of of the ROM layout on these PCBS so I'm wondering if that plays a role.
PAL labels are in tact, and look original. DH U1 and DH U7. Here are the images from my boardset, I can work on pulling/dumping pals, but it'll probably be this weekend before I can devote much time to it. Also these we're just quick cell photos prior to dumping, I can get more detailed ones or trace out connections with my meter if needed.
Attachments
OK here is something interesting...
I have 3 Killing Blade Carts
2 of them are on "0179" PCBs like in your picture and have the program ROM split across U3, U4, U5 and U6 with U9 un-populated
1 of them is on "0179-02" which has the program ROM on U9 and U3, U4, U5 and U6 un-populated.
I've been trying to work this conversion on 0179-02 since it makes sense that we're trying to burn a single 27c322 EPROM and that PCB was setup for that.
However both yours and EVAWINGZERO's carts had sockets in U3, U4, U5 and U6 which makes me think these carts were originally the version that had the Program ROM split across those ICs
my U1 PAL is labeled "DH U1X" so perhaps it's different than the "DH U1" PAL. I'm out of time for tonight but unless someone else gets further with this I'll try checking one of my other Killing Blade carts tomorrow and see if I can make this conversion work on one of those.
xodaraP
Legendary
@twistedsymphony
On the PAL socket where the jumper wires are, near pin 20 in both photos is a via that looks like it might have had the trace cut
The photos are not detailed enough to say for sure but it does seem coincidental that it looks the same in both photos
What do you think?
On the PAL socket where the jumper wires are, near pin 20 in both photos is a via that looks like it might have had the trace cut
The photos are not detailed enough to say for sure but it does seem coincidental that it looks the same in both photos
What do you think?
the other photo shows it better but for whatever reason doesn't upload properly on my phone after being cropped
GOOD EYE!
@EVAWINGZERO or @neofrank if you can get a clear close up shot of the PCB area with the 2 jumper wires, that would help confirm!
oneleaf86
Grand Master
OK turns out I just can't read. I had both jumpers wired underneath the socket
. When I woke up today with a fresh mind, I quickly realized where I went wrong. The board now works as it should! Thanks TS 
Attachments
This is interesting, as on my 257-1 board they seemed to be routed to the ASIC. I'll have to double-check.
It would explain why you can run the game with the ASIC removed, but makes me wonder how the ASIC can decrypt the ROM without creating bus collisions on the data lines.
GVpp, A20 and A19 go to the PAL on my board as well, though to different pins. GVpp is used as an /OE pin during normal operation.
11, 12 and 31 should go to Ground. 12 and 31 are ground lines, 11 is an /E line which goes to the /CS lines on all ROM footprints (including T-ROM) and to pin 9 on J2 on my board. I have the feeling that this was to support a multi-slot feature that was dropped. Connecting it to ground enables the ROM permanently, like on the graphics board.
I've got the same thing on mine. Only the connections on J1 seem to trace to the CPU.
So to get the game to boot it needs to be unencrypted, patched to not offload any functionality to the ASIC, and mapped to the correct boot address. I assume they are already patched to work in different donor boards, and the PAL modification does the address mapping.
I almost wonder if the ASIC is wired like an additional EPROM on the same buss with the main board switching to the PROGRAM ROM and reading, which in-turn reads into the ASIC, then it can switch to the ASIC and read what has just been decrypted.
Well
If we look at ddp doj
There is code at 13b7b8. My handiwork crashes in the 200000+ range. In mame the hacked amb version runs around 23b7b8 after the init_kovsh action.
That's 0x100000. Isn't that mapped by those adres lines?
Looking at the original ddp doj pcb running in name, I see the core run around 0x13xxxx but it makes side trips to the code at 0x23xxxx a lot.
Maybe the asic makes code appear at 0x200000+ for this game?
Look at the copies in ram with debugger.
Theres a version at 0x100000 and 0x200000 and both have vector tables and everything at the start. Why?
If we look at ddp doj
There is code at 13b7b8. My handiwork crashes in the 200000+ range. In mame the hacked amb version runs around 23b7b8 after the init_kovsh action.
That's 0x100000. Isn't that mapped by those adres lines?
Looking at the original ddp doj pcb running in name, I see the core run around 0x13xxxx but it makes side trips to the code at 0x23xxxx a lot.
Maybe the asic makes code appear at 0x200000+ for this game?
Look at the copies in ram with debugger.
Theres a version at 0x100000 and 0x200000 and both have vector tables and everything at the start. Why?
