nesdev.com
http://forums.nesdev.com/

Kazzo USB rom dumper / dev cart programmer
http://forums.nesdev.com/viewtopic.php?f=9&t=7912
Page 32 of 36

Author:  lidnariq [ Sat Apr 22, 2017 8:38 pm ]
Post subject:  Re: Kazzo USB rom dumper / dev cart programmer

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]
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

Author:  kazblox [ Sat Apr 22, 2017 11:12 pm ]
Post subject:  Re: Kazzo USB rom dumper / dev cart programmer

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

Author:  krzysiobal [ Sun Apr 23, 2017 9:28 am ]
Post subject:  Re: Kazzo USB rom dumper / dev cart programmer

Some kind of anticipation for tracks under chips and restored schematics.
Image Image

Author:  lidnariq [ Sun Apr 23, 2017 12:01 pm ]
Post subject:  Re: Kazzo USB rom dumper / dev cart programmer

Hm, I made a bunch of different guesses about connectivity, especially under the right '157and left '161...

Attachments:
ks-7030+tracery.jpg
ks-7030+tracery.jpg [ 1.19 MiB | Viewed 793 times ]

Author:  kazblox [ Sun Apr 23, 2017 2:18 pm ]
Post subject:  Re: Kazzo USB rom dumper / dev cart programmer

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...

Author:  lidnariq [ Sun Apr 23, 2017 2:37 pm ]
Post subject:  Re: Kazzo USB rom dumper / dev cart programmer

Care to share your current kazzo script?

Author:  kazblox [ Sun Apr 23, 2017 2:51 pm ]
Post subject:  Re: Kazzo USB rom dumper / dev cart programmer

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...

Author:  lidnariq [ Sun Apr 23, 2017 3:24 pm ]
Post subject:  Re: Kazzo USB rom dumper / dev cart programmer

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:
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.

Author:  kazblox [ Sun Apr 23, 2017 3:52 pm ]
Post subject:  Re: Kazzo USB rom dumper / dev cart programmer

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?

Author:  lidnariq [ Sun Apr 23, 2017 4:04 pm ]
Post subject:  Re: Kazzo USB rom dumper / dev cart programmer

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?

Author:  tepples [ Sun Apr 23, 2017 4:08 pm ]
Post subject:  Re: Kazzo USB rom dumper / dev cart programmer

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!

Author:  kazblox [ Sun Apr 23, 2017 4:24 pm ]
Post subject:  Re: Kazzo USB rom dumper / dev cart programmer

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

Time to dig deep into the unagi source code!

Image

Author:  kazblox [ Sun Apr 23, 2017 5:17 pm ]
Post subject:  Re: Kazzo USB rom dumper / dev cart programmer

...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:
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.

Author:  lidnariq [ Sun Apr 23, 2017 5:47 pm ]
Post subject:  Re: Kazzo USB rom dumper / dev cart programmer

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...

Author:  kazblox [ Sun Apr 23, 2017 6:06 pm ]
Post subject:  Re: Kazzo USB rom dumper / dev cart programmer

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.

Page 32 of 36 All times are UTC - 7 hours
Powered by phpBB® Forum Software © phpBB Group
http://www.phpbb.com/