Well, as seen in a previous post I damaged the main board pretty seriously while removing the ROM daughterboard, but still had hopes it could be salvaged. In the process of making everything work, sadly, it became obvious that I would be unable to solder connectors to some of the lower address lines and data lines, and hence I still cannot emulate RAM access on the device (it can still be repaired, I think, but i don’t have a conductive ink pen with me to rebuilt the lost tracks). It will take me some weeks to get a replacement, and in the meantime I’m building a dumper for the FlashROM, that you can see up there all wired up.
Here is the small, but significant, first step into programming the VT168. Using a standard build of the cc65 C compiler and a draft configuration file, I successfully mapped the memory and structure of the VT168 hardware. With that and the available register documentation, I had a sample running in a few days. However, there is one glaring flaw in the main datasheet – it does not explain how to select color modes for the background layers. After a bit of head scratching, here is how it’s configured:
The BK1_Color and BK2_Color bits can be found in the 0×2013 and 0×2017 registers, respectively. One interesting feature of this SoC is that, while only 64Kb addressing space is available to the main CPU, with higher portions of the 8Mb memory visible by a mappable 32Kb segment starting at 0×8000, the graphical unit fetches data from that memory space using automatic segment mapping. This makes graphical access very clean. There are a bunch of very clever things in this SoC, actually, and I hope to be able to show them off – that is, if they’re actually not horribly broken in the real hardware.
I finally got around to figure out the pinout of the little Flash ROM board in the NJ Pocket. For that I had to remove it to check the bottom pins… and well, let’s say things didn’t went very well:
Despite my best efforts to safely remove it, the board is glued before the soldering. This complicated the job of removing the solder cleanly, and it led to a last ditch effort that resulted in way more damage than was needed. Luckily there are plenty of test pads and I haven’t damaged any additional hardware other than a slightly scratched ground track. As such, It might still be possible to connect some test hardware to the CPU – I already have a simple VHDL module ready for this and will get around to writing some code soon.
Earlier today, I was talking about the Sega Mega Drive and how it sometimes used software sprites (but mostly its predecessor, the Sega Master System). This made me think of the technique for a while and how I haven’t seen it detailed in any length for a while. It was not that common, but still useful to make games that would defeat the sprite-limit in the hardware, or if the system had no sprite hardware at all in a given graphical mode.
First, let’s define a sprite. It’s going to be a simple one, a 8×8 bullet. Let’s make it that it only has 2 colors, meaning it only needs 1-bit per pixel (we’ll get to why this example is important later):
I took a quick break to map the pinout of the VT1682 CPU unto a library for my favorite schematic editor. I use an old version of bSch i translated into English a couple of years ago. It runs fine, even on Windows 7, but the tools that convert the text files to the binary format used by the program are 16-bit apps, and hence unable to run on x64. Luckily they had no qualms about running under DosBox. There is also a short FlashROM symbol I rendered from the Application Note.
Update: I found I was lacking the original measurements of the small board that holds Flash memory i mentioned in the last post, so I retook the measures and took the chance to build a small diagram. The pin order of the diagram mimics, somewhat, the expected physical position on the board, so this is a visual aid as well.
To add to my previous post, I ran my oscilloscope over the pins on the small board. It exposes 44 pins, and one would expect to see 16 data pins, and the full 21 addressing space. So a quick look revealed 23 pins with a waveform like this:
That seem to be address and control data from the CPU. Additionally 16 pins had a much sharper response, and are likely the data pins.
Of the remaining 5 pins, one seemed to carry Vcc, three were grounded, and one had a negative-trigger behaviour:
And is likely the /OE pin. So far so good. One of the test pads also carries a control signal, but until I remove the board it will impossible to determine which one. At any rate, it seems the basic signals required to dump the ROM are available, so that will be one of the first tasks. Once I’ll post about unsoldering and figure the pinout, I’ll detail my dumping hardware.
To start this blog, I want to focus on a piece of hardware that has caught a bit of interest recently. It is the NJ-250A “NJ Pocket”, a very cheap (under $20) console that can be obtained from several internet retailers:The machine itself is manufactured by Shenzen Nanjing technologies. While a longer, more detailed post on them will be in order later on, SN is known to be a manufacturer of NES/Famicom pirate and original carts. However, this machine does not carry any NES games. In fact it rather carries 60 “original” games, and by that I mean games that despite using stolen art and audio, are original games and have the very bad gameplay to prove it.
Never the less, it’s very obvious that the games look nothing like a NES. Something very different was inside.
The very fine folks at PGC Forums, led me to the right path – the hardware inside is based on the V.R. Technology’s VT1682 solution, a completely original SoC, that while inspired by the NES hardware, has none of the custom parts. Even more interesting, VRT themselves offers detailed datasheets (PDF) , programming guides (PDF) and even a compiler/emulator for the hardware. The specifications are also interesting:
Main CPU : 5.3Mhz 6502-based hardware. VRT claim to fame is the OneBus system, that replaces the NES CPU dual data bus paradigm for a single, software mappable bus that accesses up to 32Mbytes in data.
Sound CPU : 21Mhz 6502 with additional DAC outputs. Losing the 2A03-style sound chip is sad, but replacing it with a fast CPU pays off in flexibility. There is potential for synth or module/tracking audio, as well as using it as a co-processor.
Graphics PU : A fully redesigned video chip with little similarity to the NES. Up to 240 16-color sprites per frame (16 by line), and two background layers with support for bitmap and high-color.
Memory : 8Kb PRAM with 4Kb shared between sound and main cpu. 4Kb VRAM supporting tiles and sprite data.
All the other bits and pieces that one expects from a microcontroller – LCD controllers, UART, etc:
Interest piked, I went ahead and decided to tear down the device. It’s a pretty simple and uneventful job, with the same screws for every single part and 4 plastic tabs holding the case and boards. Beneath the LCD (a very bright but slightly low res screen), all one could find is the familiar epoxy blurb of the CPU and some shoddy patch soldering:
Notice the test pads and jumpers. Hoping some of these lead to the serial port, but it’s too soon to say. However, turning the board around we get some good news:
The flash chip isn’t coy to its origins, and reveals itself as a 256Mbit, 16-bit data bus Intel StrataFlash. With a nice, compreensive datasheet around, it seems the task of reading and writing to it isn’t impossible. In addition, the small board where it rests seems to have pads that could have been used for the original flashing process. The other two IC’s are also easily identified:
Atmel AT24C02N – a 2048 bit serial memory
TDA2822M, a classic if cheap audio amp
While the purpose of the later is obvious, the former confounds me. Best I can imagine is that it’s meant to hold some sort of save data. Next post will detail what I found out about the machine pinouts and my plans to dump the data.
The machine itself is manufactured by Shenzen Nanjing technologies. While a longer, more detailed post on them will be in order later on, SN is known to be a manufacturer of NES/Famicom pirate and original carts. However, this machine does not carry any NES games. In fact it rather carries 60 “original” games, and by that I mean games that despite using stolen art and audio, are original games and have the very bad gameplay to prove it.
