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:
Color Mode BKx_Color ---------- --- 16 colors 0 0 16 colors? 0 1 64 colors 1 0 256 colors 1 1
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.
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.
Click on to see the results of my efforts…
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):
00111100 01000010 10011001 10100101 10100101 10011001 01000010 00111100
Let’s define a tiled screen made of several 8×8 tiles. For clarity sake, let’s just make a 4×4 one and name them using hexadecimal letters:
0 1 2 3 0 |0x0|0x1|0x2|0x3| 1 |0x4|0x5|0x6|0x7| 2 |0x8|0x9|0xA|0xB| 3 |0xC|0xD|0xE|0xF|
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:
- 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.