36pcase analysis - VT369 with serial flash

[bewilderbeest]

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

[bewilderbeest]

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

[NewRisingSun]

This is the first time you mentioned an EEPROM

Mapper 426 already emulates a serial ROM that responds to command 0x30. Used by:

• Cheertone Gaming Tech CT-885 (one version, serial ROM dumped)
• CULAGEiMi Handheld Game for Kids&Adults Built-in 270 Retro Video Games (serial ROM not dumped)
• Red5 Mini Arcade Machine 240-in-1 (72842) (serial ROM dumped)

I have attached the two ones with the dumped serial ROMs for your convenience. CT-885 also has CPU opcode encryption.

[bewilderbeest]

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?

[bewilderbeest]

Oh, I should add: the big flash ROM contains the following text:

"Cube Technology CompanyWrite By Anthony" (sic)

Hi, Anthony!

[NewRisingSun]

iNES header, Flash ROM, internal mask ROM, serial ROM. Set the NES 2.0 "# of Misc. ROMs" to 2. The internal mask ROM contains code for the sound CPU; if it is not used, there is no reason to include it. Only NintendulatorNRS (website unlicensed.games->Lost in Bygone Gamingsupports mapper 426, in case you want a modification target. EEPROM content is not included in the .NES file but is treated like a battery-backed .SAV file.

Also, what is the exact name of the product? The AliExpress link does not work for me.

[bewilderbeest]

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.

[bewilderbeest]

Also, attached is what I've got so far for a combined ROM, which a probably-bad header.