SD Keiji Blader Repro Issues

A place that you can discuss reproduction of classic titles or "licensed-for-reproduction" homebrew for personal use.

Moderators: B00daW, Moderators

Forum rules
1. NO BLATANT PIRACY. This includes reproducing homebrew less than 10 years old, with the exception of free software.
2. No advertising your reproductions, with the exception of free software.
3. Be nice. See RFC 1855 if you aren't sure what this means.
lidnariq
Posts: 9379
Joined: Sun Apr 13, 2008 11:12 am
Location: Seattle

Re: SD Keiji Blader Repro Issues

Post by lidnariq » Thu Jan 23, 2020 12:45 pm

Actually, thinking on this some more, if you're having problems before you get to the 128KB line, this has got to be some kind of software problem, not a hardware problem. You shouldn't see any symptoms of not supporting a larger ROM before then...

lidnariq
Posts: 9379
Joined: Sun Apr 13, 2008 11:12 am
Location: Seattle

Re: SD Keiji Blader Repro Issues

Post by lidnariq » Thu Jan 23, 2020 3:09 pm

Sanni's dumper also refuses to try to dump any amount other than 128KB PRG from a X1-017 cart:

Code: Select all

// Supported Mapper Array (iNES Mapper #s)
// Format = {mapper,prglo,prghi,chrlo,chrhi,ramlo,ramhi}
static const byte PROGMEM mapsize [] = {
[...]
  82, 3, 3, 5, 6, 0, 1, // taito x1-017                                       [prgram r/w]
[...]
int PRG[] = {16, 32, 64, 128, 256, 512};
[...]
      prghi = pgm_read_byte(mapsize + index + 2);

Ice Man
Posts: 530
Joined: Fri Jul 04, 2014 2:34 pm

Re: SD Keiji Blader Repro Issues

Post by Ice Man » Fri Jan 24, 2020 2:10 am

I modified the script to dump 256K as well. That shouldn't be the issue. Even if it was 128K only, it's still wrong.
If only I knew a way to calculate which address line is wrong. I checked all connections and there isn't anything weird going on with the PRG pinout at all.

I'll check more later.

Ice Man
Posts: 530
Joined: Fri Jul 04, 2014 2:34 pm

Re: SD Keiji Blader Repro Issues

Post by Ice Man » Fri Jan 24, 2020 5:24 am

Stumble upon this: https://www.emu-land.net/forum/index.php?topic=79662.0

And according to what they say, PRG A13-A15 are swapped:
A13-> A15
A16-> A13
A15-> A14
A14-> A16

This gives me new data to dump but banks are still messed up.


EDIT: SUCCESS! For 128K so far.
This is the Taito PRG ROM Pinout for 128K (28 Pins):

Code: Select all

                  ---_---
       PRG A14 - |01   28| - +5V
       PRG A12 - |02   27| - PRG A15
       PRG A7  - |03   26| - PRG A16
       PRG A6  - |04   25| - PRG A8
       PRG A5  - |05   24| - PRG A9
       PRG A4  - |06   23| - PRG A11
       PRG A3  - |07   22| - PRG A13
       PRG A2  - |08   21| - PRG A10
       PRG A1  - |09   20| - PRG /CE
       PRG A0  - |10   19| - PRG D7
       PRG D0  - |11   18| - PRG D6
       PRG D1  - |12   17| - PRG D5
       PRG D2  - |13   16| - PRG D4
       GND     - |14   15| - PRG D3
                  -------
EDIT2: There's no PRG A17 at all. Tested ALL NC pins and they're either low or high giving me either the lower 128K or the upper 128K. Dumping the complete 256K is not possible with the X1-017 at all without extra logic to get PRG A17 assuming that's possible somehow.

FrankWDoom
Posts: 223
Joined: Mon Jan 23, 2012 11:27 pm

Re: SD Keiji Blader Repro Issues

Post by FrankWDoom » Fri Jan 24, 2020 11:10 am

How did you determine the correct pinout for the mask rom? Is the mapper documentation wrong?

Ice Man
Posts: 530
Joined: Fri Jul 04, 2014 2:34 pm

Re: SD Keiji Blader Repro Issues

Post by Ice Man » Fri Jan 24, 2020 11:23 am

Mapper documentation is correct. That's why I was able to properly dump it using an EPROM.
It just doesn't follow any JEDEC or Nintendo format but Taito's own apparantly.

See topic at Emu-Land.

lidnariq
Posts: 9379
Joined: Sun Apr 13, 2008 11:12 am
Location: Seattle

Re: SD Keiji Blader Repro Issues

Post by lidnariq » Fri Jan 24, 2020 12:14 pm

Ugh.

Well, I put the assertion that the X1-017 supported 256KB in the wiki, so I apologize. I don't know why I did - I think I assumed that if PRG A17 was present in the X1-005 it would be present in the X1-017 also.

Can you test if the X1-017's PRG banking registers are readable? Since they don't overlap with anything else. If they are readable, I wonder if the upper bits are even implemented, or if register readback looks like [..PP PP..] where . = open bus or always 0

Ice Man
Posts: 530
Joined: Fri Jul 04, 2014 2:34 pm

Re: SD Keiji Blader Repro Issues

Post by Ice Man » Fri Jan 24, 2020 12:20 pm

How would I test that with the cartreader? I don't have any logic analyzer or oscilloscopes, sadly.

lidnariq
Posts: 9379
Joined: Sun Apr 13, 2008 11:12 am
Location: Seattle

Re: SD Keiji Blader Repro Issues

Post by lidnariq » Fri Jan 24, 2020 12:37 pm

Well, Arduino, so you could hijack the existing API...?

Code: Select all

void readRAM() {
  CreateRAMFileInSD();
  for (int reg = 0x7EF0; reg < 0x7F00; reg++) {
    for (int val = 0; val < 256; val++) {
      write_prg_byte(reg,val);
      write_prg_byte(0x7D00,0); // try to drive data bus low
      sdBuffer[val*2] = read_prg_byte(reg);
      write_prg_byte(0x7D00,255); // try to drive data bus high
      sdBuffer[val*2+1] = read_prg_byte(reg);
    }
  }
  sdFile.write(sdBuffer, 512);
}
(edit: add open bus detection, maybe?)


Unrelatedly, have you updated the pinout you shared at the beginning of the thread to compensate for the pin shuffling on the OEM cart?
Last edited by lidnariq on Fri Jan 24, 2020 1:04 pm, edited 2 times in total.

Ice Man
Posts: 530
Joined: Fri Jul 04, 2014 2:34 pm

Re: SD Keiji Blader Repro Issues

Post by Ice Man » Fri Jan 24, 2020 12:47 pm

Yea, I updated it right after. Feel free to put it on the Wiki if you like.

And okay, i'll try it tomorrow and report back.

EDIT: Modified the RAM script and added yours. The dump is 1KB and all zeroes.

lidnariq
Posts: 9379
Joined: Sun Apr 13, 2008 11:12 am
Location: Seattle

Re: SD Keiji Blader Repro Issues

Post by lidnariq » Fri Jan 24, 2020 1:33 pm

All zeroes is disappointing, but not surprising, but I don't see how it could be only 1KB? It really should be 16*512 = 8192 bytes.

Ice Man
Posts: 530
Joined: Fri Jul 04, 2014 2:34 pm

Re: SD Keiji Blader Repro Issues

Post by Ice Man » Fri Jan 24, 2020 1:42 pm

Even increased the file size but still all zeroes.
Hope that helps somehow.

But regarding the missing PRG A17 line. Wouldn't it be possible to somehow control that with a Demux (73'139 for example) e.g.
1G = /ROMSEL
1A = PRG A15
1B = PRG A16
1Y0 = PRG A17
Last edited by Ice Man on Fri Jan 24, 2020 1:46 pm, edited 1 time in total.

lidnariq
Posts: 9379
Joined: Sun Apr 13, 2008 11:12 am
Location: Seattle

Re: SD Keiji Blader Repro Issues

Post by lidnariq » Fri Jan 24, 2020 1:45 pm

... I forgot to add the lines from the end of the original Arduino code :oops:

Code: Select all

      sdFile.flush();
      sdFile.close();
  set_address(0);
  PHI2_HI;
  ROMSEL_HI;
}

Ice Man
Posts: 530
Joined: Fri Jul 04, 2014 2:34 pm

Re: SD Keiji Blader Repro Issues

Post by Ice Man » Fri Jan 24, 2020 1:49 pm

That wasn't missing since I just modified the mapper 82 readRAM(); part from:

Code: Select all

        case 82: // 5K
          write_prg_byte(0x7EF7, 0xCA); // PRG RAM ENABLE 0 ($6000-$67FF)
          write_prg_byte(0x7EF8, 0x69); // PRG RAM ENABLE 1 ($6800-$6FFF)
          write_prg_byte(0x7EF9, 0x84); // PRG RAM ENABLE 2 ($7000-$73FF)
          for (word address = 0x0; address < 0x1400; address += 512) { // PRG RAM 5K ($6000-$73FF)
            dumpMMC5RAM(base, address);
          }
          write_prg_byte(0x7EF7, 0xFF); // PRG RAM DISABLE 0 ($6000-$67FF)
          write_prg_byte(0x7EF8, 0xFF); // PRG RAM DISABLE 1 ($6800-$6FFF)
          write_prg_byte(0x7EF9, 0xFF); // PRG RAM DISABLE 2 ($7000-$73FF)
          break;
to:

Code: Select all

case 82: // 5K
  for (int reg = 0x7EF0; reg < 0x7F00; reg++) {
    for (int val = 0; val < 256; val++) {
      write_prg_byte(reg,val);
      write_prg_byte(0x7D00,0); // try to drive data bus low
      sdBuffer[val*2] = read_prg_byte(reg);
      write_prg_byte(0x7D00,255); // try to drive data bus high
      sdBuffer[val*2+1] = read_prg_byte(reg);
    }
  }
  sdFile.write(sdBuffer, 512);
          break;

lidnariq
Posts: 9379
Joined: Sun Apr 13, 2008 11:12 am
Location: Seattle

Re: SD Keiji Blader Repro Issues

Post by lidnariq » Fri Jan 24, 2020 2:08 pm

Yeah, you could rebuild the extra bits using some external hardware. Something to decode the right memory region, something to hold the data, something to multiplex the result.

Since the registers are at $7EF[ABC], one might decode the registers at $7EF[8-F] via
0111 1110 1111 1xxx
need to not collide with RAM or PPU
0110 xxxx xxxx xxxx ($6000-$6FFF)
0111 00xx xxxx xxxx ($7000-$73FF)
0000 0xxx xxxx xxxx ($0000-$07FF)
0010 0000 0000 0xxx ($2000-$2007)
Must either decode R/W or /ROMSEL to avoid colliding with PRG ROM
this is pretty easy if you have some 74'133s on hand (/ROMSEL, M2, A14...A9, A6..A3), but it looks like they're discontinued for mass manufacture now. I think it should just barely fit in a 74'138 ? M2, A12, A11, A3 high & R/W low shouldn't collide with anything relevant.
Latch writes in a 74'259 - this addressable latch is still being made. Remultiplex the output with a 74'153.

I'll draw a schematic and add it in here soon. Edit: done.
oversize-m82.png
oversize-m82.png (3.18 KiB) Viewed 2638 times
Alternatively, this would be a fine thing to solve using a PAL or GreenPak.

Post Reply