Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - bewilderbeest

Pages: [1]
1
2000-present / Re: 36pcase analysis - VT369 with serial flash
« on: November 29, 2025, 07:18:22 PM »
Also, attached is what I've got so far for a combined ROM, which a probably-bad header.

2
2000-present / Re: 36pcase analysis - VT369 with serial flash
« on: November 29, 2025, 07:16:52 PM »
Thanks! I tried it, but no luck, with either 426 or 427. It looks like the flash ROM ends up infinite looping after reading a value from 0x41e7 which isn't what it expected.

It also looks like it's directly mapping the SPI flash and booting it without going through the internal ROM. I guess that on the real device, on power up the internal ROM at 0x1000-0x1fff is mirrored at 0xf000-0xffff so the internal ROM's reset vectors get used. I'm not sure if this is significant, given that the whole purpose of the internal ROM is to set up the SPI flash and make it look like it's memory mapped, but it's worth noting.

Regarding the EEPROM: the menu code reads values out of the EEPROM and then programs them into PPUCTRL and PPUMASK. I have a suspicion it might not work properly without the correct EEPROM values being present. Also, AFAICT has device address 0x10, which isn't a valid I2C EEPROM address, so there's more to figure out there. The mysterious I2C serial ROM protection chip is at 0x30. Does this sound like it's a 426 or a 427 with some unemulated hardware, or if it's a whole new mapper?

You're the author of NintendulatorNRS, right? There's a lot of information about the VT369 in there --- is there any reference I can consult?

Looking at the source code I did spot an oddity: it treats the GPIO registers as 8-byte structures, but there's a lot of code in flash ROM which only makes sense if they're really 4 bytes wide. e.g. the code for turning the LCD screen on and off works by changing 0x4144 and 0x4146.

3
2000-present / Re: 36pcase analysis - VT369 with serial flash
« on: November 29, 2025, 08:21:37 AM »
Oh, I should add: the big flash ROM contains the following text:

"Cube Technology CompanyWrite By Anthony" (sic)

Hi, Anthony!

4
2000-present / Re: 36pcase analysis - VT369 with serial flash
« on: November 29, 2025, 08:19:29 AM »
Ah, yeah, I missed an update... I think this is a 427, with _two_ I2C devices; one for a protection ROM and one for the EEPROM. Except the EEPROM command set looks all wrong, so maybe it's not a standard EEPROM? I dumped the contents by just calling the existing routines in the protection ROM. The I/O port used for both is 4150. There's no CPU encryption.

The Red5 ROM you dumped has a very similar protection ROM, I think (I'm not well up on the NES format), but it's not identical.

(a) what's the best emulator to try and hack support for this thing into, and (b) to emulate this I need the big serial flash, the internal mask ROM, the serial protection ROM, and the EEPROM. How do I get all of those into a NES file?

5
2000-present / Re: 36pcase analysis - VT369 with serial flash
« on: November 29, 2025, 07:49:14 AM »
...and here's the EEPROM contents (or at least the first 256 bytes of it). It's almost completely blank, with about six values used for setting stuff like PPUCTRL during the menu screen.

6
2000-present / 36pcase analysis - VT369 with serial flash
« on: November 27, 2025, 05:53:27 PM »
(continued from 'How to get dumped roms into a useful format?' on the parent forum)

I've got this 36-in-1 phone case thing from AliExpress; one of these. https://de.aliexpress.com/item/1005001809126228.html?spm=a2g0o.order_list.order_list_main.11.46921802nqg8j7&gatewayAdapt=glo2deu

It's built around a blob and an SPI flash chip (the latter running at 90 (!) MHz). I've dumped the flash chip, did some hacking, confirmed it's a VT-369 derivative, and then found that there's partial MAME support for it. I then figured out how to dump the internal 4kB ROM, and it turns out to be the generic internal ROM from the MAME VT-369, which is nice. I was then clued in that this device also has some kind of serial ROM device on the blob which gets loaded at 0x0e00, and I dumped that too. And that's where stuff gets weird.

It looks like this thing is a bitbanged SPI/I2C device with at least two commands. When given the command 0x30, it responds with the 256 bytes of data which is loaded at 0x0e00 (attached). When given the command 0x10, it then receives a single payload byte and responds with another byte. This is used by the device to get various parameters which are used in setup, like determining which set of NMI routines to use, etc. The payload byte determines the parameter. I've identified a bunch.

One possibility is that it's two devices on an I2C bus, and device 0x30 is a 256-byte serial ROM, and device 0x30 is... something else, but neither look valid for a serial ROM device address. But the commands don't look right for SPI flash either.

Before I start running more stuff on my increasingly fragile test rig, has anyone tackled this device (or similar) who knows anything about it?

Thanks!

(Attaching the 256 bytes I've read so far.)

7
Famicom/NES / Re: How to get dumped roms into a useful format?
« on: November 26, 2025, 05:26:50 PM »
Thanks very much --- I found the code which reads the serial ROM. It looks wretched. I'm going to figure out how to dump that, too.

The good news is that I've managed to dump the internal 4kB ROM (via blinking the screen in morse code!). It has a SHA1 hash of 39d674d965818922aad5993e9499170d3ebc43bf, which is the same internal ROM as is used in a bunch of other device, so that's at least confirmation that I did it right.

Attached, simply because I can.

8
Famicom/NES / Re: How to get dumped roms into a useful format?
« on: November 19, 2025, 07:35:45 PM »
I got some more information.

Turns out that the dump's SHA1 itself matches the one in MAME as the 36pcase device, which is currently non-functioning.

Yes, it's a VT369, but there's a bunch of extra registers all through 0x41xx. I can't tell whether these simply aren't in https://www.nesdev.org/wiki/VT02%2B_Registers or whether it's a VT369 derivative. I've identified the LCD backlight switch, for example, on 0x4144 and 0x4146. The MAME source does describe some of these extra registers but not all of them. Is there any good source for VT369 documentation? The MAME source describes way more registers than any of the wikis.

If it's a VT369 then it'll be starting up from the internal mask ROM, which makes sense from what I'm seeing sniffing the SPI. I'm going to try and dump this; I've no idea if it's different to any of the other dumps around. Maybe that'll make MAME emulation work. I'm hoping there isn't an internal I2C device in the blob; looks like some VT369s have this.

Also, I broke the screen. Dammit.


9
Famicom/NES / Re: How to get dumped roms into a useful format?
« on: November 17, 2025, 02:21:44 PM »
Sure --- attached (without the header).

The PRG ROM it uses at startup is at 0x7c000-0x7ffff, and it's clearly accessing the VTxx extended registers for stuff like memory map configuration, so I'm relatively sure it's a VT369. There's also a chunk of code at 0x76000 which looks like it's loaded/mapped at 0x6000. But it may be more complex than that. Sniffing the SPI flash bus shows a startup sequence which looks like it's initialising the SPI flash in software, which means there might be a mask ROM inside the blob in addition to the SPI flash. This means there could be an extremely non-standard handoff between the internal ROM and the SPI flash; there's certainly no code at 0x00000-0x03fff.


10
Famicom/NES / How to get dumped roms into a useful format?
« on: November 16, 2025, 04:10:30 PM »
I'm pulling apart a 36-in-1 phone case thing which plays NES games. I've dumped the ROM and have got as far as figuring out that it's some late VTxx device, possibly a VT369, with the ROM on SPI flash connected via a 90MHz (!) SPI bridge. This makes it quite interesting because it's relatively easy to reprogram.

I gather that emulators like Nintendulator stand a chance of playing this, depending on the details of the implementation, but I've found that Nintendulator insists on there being a valid .nes header on the top of the image. What's the right header to put on something like this?

Thanks!

Pages: [1]