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.

On that note, after careful consideration of how much work it would be to have a perfectly asyncronous parallel memory that was also multiplexed to the little amount of IO ports I had available on the base Nexys2 development board, I ordered an expansion board, that is a rather fetching piece of hardware:

This (and the neat cheap breadboard they included) allows me to connect all the 40 inputs directly to the FPGA, and from there to bridge it with the built-in SRAM memory of the prototype board. Aw, if only I had remembered to bring my VHDL books with me, because I am pretty darn rusty at it.

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…

Before I put up the design, I have to say that this work wouldn’t have been possible without the valuable help of Sprite_tm of spritesmods.com. He contacted me with a lot of valuable information and more important, he removed the epoxy from the CPU in his board and made it possible to see the connection pinout. With that information and the  (somewhat incorrect) preliminary datasheet, mapping everything was a breeze:

As I was finishing, it became obvious that the NJ Pocket might not use a Read/Write signal at all, treating it as a huge block of asynchronous SRAM. I also started decoding the memory board routes to the Flash chip:

The green tracks there are individual paths that don’t connect to the main board. It’s very likely they were used while programming and might still be reusable. In particular, it might be used in some type of standard industrial Flash programming scheme, that I need to look into.

Anyway, this was a good week for this project, hope to bring more good news soon.

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|

So, this screen has a resolution of 32×32 pixels. If you wanted this sprite to appear in a specific location, let’s say pixel position (21,19) for the top bit of the sprite, then you first would divide the number by 8 (by shifting the data right 3 bits):

 tile_pos_x = pos_x >> 3;
 tile_pos_y = pos_y >> 3;

But this would just give, at best, the base location of our sprite, in this case, tile (2,1) or tile 0×6 in the previous scheme. but here’s the nice part. let’s grab those lost three bytes with a mask and call it an offset:

off_pos_x = pos_x & 0x07;
off_pos_y = pos_y & 0x07;

this gives us (5, 3) – the specific offset of the sprite. So, to accommodate this change, we shift the bitmask of the sprite the given amount of data to the right, and at the same time move it downwards the specific amount:

for (int i = off_pos_y; i < 8; i++) tile_data0x6[i] =  sprite[i - off_pos_y] >> off_pos_x;

This results in something like :

00000000
00000000
00000000
00000001
00000010
00000100
00000101
00000101

Well, now if you think about it, you just have to do the same for the next tile – in our case 0×7, except you want to move in the opposite direction:

for (int i = off_pos_y; i < 8; i++) tile_data0x7[i] =  sprite[i - off_pos_y] << (8-off_pos_x);

So, we get:

00000000
00000000
00000000
11100000
00010000
11001000
00101000
00101000

It’s now logical that the bottom tiles (0xA and 0xB) are just a variant of this concept, displaying the missing bottom. Here’s a slightly organized pseudo-code:

for (int i = off_pos_y; i < 8; i++)
{
  tile_data0x6[i] =  sprite[i - off_pos_y] >> off_pos_x;
  tile_data0x7[i] =  sprite[i - off_pos_y] << (8 - off_pos_x);
}
for (int i = 0; i < 8 - offpos_y; i++)
{
  tile_data0x6[i] =  sprite[off_pos_y + i] >> off_pos_x;
  tile_data0x7[i] =  sprite[off_pos_y + i] << (8 - off_pos_x);
}

This shapes up to this

  (0x6)    (0x7)
00000000 00000000
00000000 00000000
00000000 00000000
00000001 11100000
00000010 00010000
00000100 11001000
00000101 00101000
00000101 00101000
  (0xA)    (0xB)
00000100 11001000
00000010 00010000
00000001 11100000
00000000 00000000
00000000 00000000
00000000 00000000
00000000 00000000
00000000 00000000

What is means is that you can use 4 tiles to draw a single, 8×8 sprite anywhere on the screen. You’ll normally want to update it every frame, so the basic limit to this technique is, other than the CPU power, the amount of VRAM writes you can do to the hardware during a v-blank (updating only the altered tiles, of course). You also have to remember when several sprites take the same tile pattern, what can be solved with a simple sorting test and then ORing the final sprite results as the new tile pattern.

Now, about the whole color issue. Most consoles store the tile data in planar layers of bits. So a 2-bit sprite (meaning a 4 color sprite) would look like this:

0 - 00111100
1 - 01000010
2 - 10011001
3 - 10100101
4 - 10100101
5 - 10011001
6 - 01000010
7 - 00111100
8 - 00111100
9 - 01111110
A - 11111111
B - 11100111
C - 11100111
D - 11111111
E - 01111110
F - 00111100

This means that you’d grab line 0 and line 8 and then join them together bit-by-bit, then line 1 and 9 and so on – so in the end this is a representation of:

00 00 11 11 11 11 00 00 = 00333300
00 11 01 01 01 01 11 00 = 03111130
11 01 01 11 11 01 01 11 = 31133113
11 01 11 00 00 11 01 11 = 31300313
11 01 11 00 00 11 01 11 = 31300313
11 01 01 11 11 01 01 11 = 31133113
00 11 01 01 01 01 11 00 = 03111130
00 00 11 11 11 11 00 00 = 00333300

While this was mostly to simplify the hardware, it helps that you can still perform the same type of shifts – you just do it on a per-plane manner instead of having to take into account the bit-depth of the whole sprite.

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.

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.

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:

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: