Kazzo USB rom dumper / dev cart programmer

Discuss hardware-related topics, such as development cartridges, CopyNES, PowerPak, EPROMs, or whatever.

Moderator: Moderators

lidnariq
Posts: 11429
Joined: Sun Apr 13, 2008 11:12 am

Re: Kazzo USB rom dumper / dev cart programmer

Post by lidnariq »

The Mask ROM looks perfectly normal (other than being the standard JEDEC 28-pin 128 KiB ROM). I mean, I can tell the following from the picture:

Left '161: can't tell much, other than that its outputs probably connect to the left '157
Left '157: set up to emit either (output of right '157) or (value in left '161)
Right '157: set up to emit either (value of CPU address bus) or (lower three bits of right '161)
Right '161: definitely latches CPU A0-A3 when so instructed by the PAL

PAL:

Code: Select all

1: ?A10?
2: /ROMSEL
3: A14
4: A13
5: A12
6: ?A11?
7: ?R/W?
8: ?PPU A11?
9: ?PPU A10?
10: Gnd

20: +5V
19: Latch1
18: Mux1
17: Latch2
16: ?Mux2?
15: PRGROM /OE
14: M2
13: ?PRGRAM /CE?
12: ?CIRAM A10?
11: Latch2Q3
kazblox
Posts: 35
Joined: Thu Feb 23, 2017 2:27 pm

Re: Kazzo USB rom dumper / dev cart programmer

Post by kazblox »

Oops! I have missed that the mapper splits the address map into scrawny bits and splits the primary 4K bank space at 0xC800 into a 1K region at 6C00-6FFF and a 3K region at C000-CBFF whenever the cart does a read... So I modified the script to read those areas.

I'll get back to this thread once the guy runs the newer version of the script to see if anything has changed.

EDIT: Crap, uh, I just realized that anago can't read from the middle of the address space (i.e. 6000-7FFF returns with "address range must be" error). Is this a software or hardware limitation for the Kazzo?

EDIT: nevermind, cpu_ramrw exists
User avatar
krzysiobal
Posts: 1036
Joined: Sun Jun 12, 2011 12:06 pm
Location: Poland
Contact:

Re: Kazzo USB rom dumper / dev cart programmer

Post by krzysiobal »

Some kind of anticipation for tracks under chips and restored schematics.
Image Image
lidnariq
Posts: 11429
Joined: Sun Apr 13, 2008 11:12 am

Re: Kazzo USB rom dumper / dev cart programmer

Post by lidnariq »

Hm, I made a bunch of different guesses about connectivity, especially under the right '157and left '161...
Attachments
ks-7030+tracery.jpg
kazblox
Posts: 35
Joined: Thu Feb 23, 2017 2:27 pm

Re: Kazzo USB rom dumper / dev cart programmer

Post by kazblox »

Right.... I'm close to giving up on trying to dump this with a Kazzo. Even with the correct cpu_ram fields, cpu_ramrw, in what I'm assuming should be write mode (writing the WRAM back to a file), just gives a "RAM image error" when trying to dump the 1K chunks at 6C00.

I guess I'll have to get the guy to send off the mask ROM to get dumped then...
lidnariq
Posts: 11429
Joined: Sun Apr 13, 2008 11:12 am

Re: Kazzo USB rom dumper / dev cart programmer

Post by lidnariq »

Care to share your current kazzo script?
kazblox
Posts: 35
Joined: Thu Feb 23, 2017 2:27 pm

Re: Kazzo USB rom dumper / dev cart programmer

Post by kazblox »

https://pastebin.com/WQSUqHNi

My plan was to dump the .NES file, take the extra 3K banks cpu_read dumps and combine them with the 1K banks cpu_ram_access dumps. (the 1K goes first, then the 3K second) But I don't know how to work the Kazzo well, and of course I only have indirect access to it, so it just currently errors out for us when trying to dump from the workram tab.

And then, I still have other problems, not knowing what causes the banks to change only once regardless of whatever I write to 0x9000 afterwards...
lidnariq
Posts: 11429
Joined: Sun Apr 13, 2008 11:12 am

Re: Kazzo USB rom dumper / dev cart programmer

Post by lidnariq »

Hm. Having now done by best to trace the board, this is wrong:
cpu_write(d, 0x9000, i);

Your register writes should always look like
cpu_write(d, 0xN000+i, 0xFF); because the latches latch the address bus, not the data bus.

If I understand correctly, even though PRG ROM is readable directly from $8000 through $B7FF, you have to use reg0 to read out the bits that are hidden under the RAM ports at $B800-$D7FF.

So I think you want something like

Code: Select all

for (local i = 0; i < 8; i += 1) {
  cpu_write(d, 0x8000+i, 0xFF);
  cpu_read(d, 0x7000, 0x1000);
}
for (local i = 0; i < 16; i += 1) {
  cpu_write(d, 0x9000+i, 0xFF);
  cpu_read(d, 0xC000, 0xC00);
  cpu_read(d, 0x6C00, 0x400);
}
RAM is not battery-backed so you shouldn't need to read it...

I fear that FCEUmm's source shuffles the 1KiB slices around, so even this won't be a match, even if it's closer to what's on the physical ROM.
kazblox
Posts: 35
Joined: Thu Feb 23, 2017 2:27 pm

Re: Kazzo USB rom dumper / dev cart programmer

Post by kazblox »

That should work. Problem is, when I tried the method of directly reading 0x6000-7FFF earlier, according to the guy I'm dumping this cart for, anago always errors out with "address range must be 0x008000 to 0x010000". Does he happen to have an older version of anago?
lidnariq
Posts: 11429
Joined: Sun Apr 13, 2008 11:12 am

Re: Kazzo USB rom dumper / dev cart programmer

Post by lidnariq »

Oh, huh.

That constraint is in script_dump.c, so it can't just be trivially fixed by changing some of the other scripting. Does anyone know how to rebuild anago without that constraint?

So that's why you were attempting to dump the other bits as though they were RAM.... (duh). Did anything go wrong, other than the bankswitching not happening at all?
tepples
Posts: 22705
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: Kazzo USB rom dumper / dev cart programmer

Post by tepples »

Does that mean if someone were to make an NROM-368 cart, with a circuit to decode $4800-$FFFF, anago wouldn't be able to dump it? OMG DRM!
kazblox
Posts: 35
Joined: Thu Feb 23, 2017 2:27 pm

Re: Kazzo USB rom dumper / dev cart programmer

Post by kazblox »

Pretty much nothing other than the "RAM image error" I described above.

Time to dig deep into the unagi source code!

Image
kazblox
Posts: 35
Joined: Thu Feb 23, 2017 2:27 pm

Re: Kazzo USB rom dumper / dev cart programmer

Post by kazblox »

...and I've already hit a error relating to API compatibility that I can't solve, despite using the correct version of libusb-win32.

Code: Select all

In file included from ../reader_kazzo.c:8:0:
../usb_device.h:29:23: error: unknown type name ‘usb_dev_handle’
 int usbGetStringAscii(usb_dev_handle *dev, int index, char *buf, int buflen);
                       ^~~~~~~~~~~~~~
../usb_device.h:40:19: error: unknown type name ‘usb_dev_handle’
 int usbOpenDevice(usb_dev_handle **device, int vendorID, char *vendorNamePattern, int productID, char *productNamePattern, char *serialNamePattern, FILE *printMatchingDevicesFp, FILE *warningsFp);
                   ^~~~~~~~~~~~~~
../reader_kazzo.c:11:8: error: unknown type name ‘usb_dev_handle’
 static usb_dev_handle *device_open(void)
        ^~~~~~~~~~~~~~
../reader_kazzo.c: In function ‘device_open’:
../reader_kazzo.c:13:2: error: unknown type name ‘usb_dev_handle’
  usb_dev_handle *handle = NULL;
  ^~~~~~~~~~~~~~
../reader_kazzo.c: At top level:
../reader_kazzo.c:30:8: error: unknown type name ‘usb_dev_handle’
 static usb_dev_handle *handle = NULL;
        ^~~~~~~~~~~~~~
../reader_kazzo.c:48:25: error: unknown type name ‘usb_dev_handle’
 static void device_read(usb_dev_handle *handle, enum request r, enum index index, long address, long length, uint8_t *data)
                         ^~~~~~~~~~~~~~
../reader_kazzo.c:89:26: error: unknown type name ‘usb_dev_handle’
 static void device_write(usb_dev_handle *handle, enum request w, enum index index, long address, long length, const uint8_t *data)
                          ^~~~~~~~~~~~~~
make[1]: *** [<builtin>: reader_kazzo.o] Error 1
If anyone else has experienced this error or knows how to build a Win32 build for anago with GCC 6.3, be my guest.
lidnariq
Posts: 11429
Joined: Sun Apr 13, 2008 11:12 am

Re: Kazzo USB rom dumper / dev cart programmer

Post by lidnariq »

That looks like you don't have the libusb build headers installed? Or at least that it didn't include them and/or couldn't find them. usb_dev_handle is definitely in mine...
kazblox
Posts: 35
Joined: Thu Feb 23, 2017 2:27 pm

Re: Kazzo USB rom dumper / dev cart programmer

Post by kazblox »

Ok, renaming the lusb0_usb.h header to usb.h solved it... But that's only a minor issue.

I now have to recompile libusb since the precompiled binary is incompatible for my mingw32 environment... and now that it's requiring "conio.h", which my mingw64 environment only has, and Visual Studio crap, it's making me go crazy.
Post Reply