It is currently Sat Dec 16, 2017 9:59 am

All times are UTC - 7 hours





Post new topic Reply to topic  [ 571 posts ]  Go to page Previous  1 ... 29, 30, 31, 32, 33, 34, 35 ... 39  Next
Author Message
PostPosted: Sat Apr 22, 2017 8:38 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 6534
Location: Seattle
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


Top
 Profile  
 
PostPosted: Sat Apr 22, 2017 11:12 pm 
Offline

Joined: Thu Feb 23, 2017 2:27 pm
Posts: 34
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


Top
 Profile  
 
PostPosted: Sun Apr 23, 2017 9:28 am 
Offline

Joined: Sun Jun 12, 2011 12:06 pm
Posts: 262
Location: Poland
Some kind of anticipation for tracks under chips and restored schematics.
Image Image


Top
 Profile  
 
PostPosted: Sun Apr 23, 2017 12:01 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 6534
Location: Seattle
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 1008 times ]
Top
 Profile  
 
PostPosted: Sun Apr 23, 2017 2:18 pm 
Offline

Joined: Thu Feb 23, 2017 2:27 pm
Posts: 34
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...


Top
 Profile  
 
PostPosted: Sun Apr 23, 2017 2:37 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 6534
Location: Seattle
Care to share your current kazzo script?


Top
 Profile  
 
PostPosted: Sun Apr 23, 2017 2:51 pm 
Offline

Joined: Thu Feb 23, 2017 2:27 pm
Posts: 34
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...


Top
 Profile  
 
PostPosted: Sun Apr 23, 2017 3:24 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 6534
Location: Seattle
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.


Top
 Profile  
 
PostPosted: Sun Apr 23, 2017 3:52 pm 
Offline

Joined: Thu Feb 23, 2017 2:27 pm
Posts: 34
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?


Top
 Profile  
 
PostPosted: Sun Apr 23, 2017 4:04 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 6534
Location: Seattle
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?


Top
 Profile  
 
PostPosted: Sun Apr 23, 2017 4:08 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19348
Location: NE Indiana, USA (NTSC)
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!


Top
 Profile  
 
PostPosted: Sun Apr 23, 2017 4:24 pm 
Offline

Joined: Thu Feb 23, 2017 2:27 pm
Posts: 34
Pretty much nothing other than the "RAM image error" I described above.

Time to dig deep into the unagi source code!

Image


Top
 Profile  
 
PostPosted: Sun Apr 23, 2017 5:17 pm 
Offline

Joined: Thu Feb 23, 2017 2:27 pm
Posts: 34
...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.


Top
 Profile  
 
PostPosted: Sun Apr 23, 2017 5:47 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 6534
Location: Seattle
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...


Top
 Profile  
 
PostPosted: Sun Apr 23, 2017 6:06 pm 
Offline

Joined: Thu Feb 23, 2017 2:27 pm
Posts: 34
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.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 571 posts ]  Go to page Previous  1 ... 29, 30, 31, 32, 33, 34, 35 ... 39  Next

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 8 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group