Game console prototype "GameTank"

[Agumander]

barrym95838 wrote:

That's a very handsome kit! Nicely done.

Thanks! Hopefully it works and I didn't accidentally create some kind of weird antenna with that donut-shaped top board.

GARTHWILSON wrote:

Wow! How many layers did you need in the board in the second picture to get it all routed?

Indeed, I wondered at first if I'd have to go up to six layers but it ended up working out in just four. The autorouter seemed to have an easier time with the bottom board than the top board, strangely enough. Maybe it was because of the irregular shape.

[Agumander]

Got the boards in on Friday and spent the weekend soldering this baby over a few sessions.

Originally I anticipated spending the week in "integration hell", but ultimately I only had to add one bodge wire after realizing that I gave a certain net the name !RE2 "Read Enable 2" on one sheet and !OE2 "Output Enable 2" on another sheet. As a result the CPU had been able to write to Graphics RAM but not *read* it; which is necessary for the Inflate algorithm as well as programs simply using it as extra general-purpose memory.

For now I'm powering it with my bench supply through two wires soldered on at the back. I've designed and ordered a board that can solder on in place of these wires, based on an LM2575 switching regulator and its reference schematic in the datasheet.

After that the next step is to design and print a suitable case. The "tank" theme will work into that but I'm still deciding how subtle.
The board stack already looks kind of cool, so the enclosure will have to be cool enough to compete if it's going to cover that view.

It's a bit of a rush to hold this thing. With almost a hundred ICs it has a certain heft that feels about right for something that took me three years to make.

[Dr Jefyll]

Agumander wrote:

It's a bit of a rush to hold this thing.

Understood! Congrats on your success.

-- Jeff

[Agumander]

Hoping to make it more exciting soon! I decided to do one more major change to the feature set, which is expanding the Graphic RAM from 32Kb to 512Kb. This corresponds to increasing the size of loaded sprite/tile sheets from 2x the screen resolution to 32x the screen resolution. This allows, for instance, more types of animated enemy character in a single level. Or for a smaller number of characters to have a greater number of animation frames, like in an arcade-style fighting game.

Of course, as a result of recent changes I'll also need to update my emulator and all the software I've already written. But I'm looking forward to posting a video demo soon that shows off the new capabilities.

[Sheep64]

Agumander on Wed 9 Jun 2021 wrote:

I haven't actually tested out the tweak that would bring the blitter speed back up to 7MHz, but instead included it on the new board with a trio of solder jumpers that would either enact the 7MHz fix or simply route the 3.5MHz version that would still be sufficient for games.

It may horribly complicate clock but I wonder if your blitter works with three phases rather than four? This would provide 1/3 speed increase while retaining current reliability.

[Agumander]

Sheep64 wrote:

It may horribly complicate clock but I wonder if your blitter works with three phases rather than four? This would provide 1/3 speed increase while retaining current reliability.

I did try sketching out a few different timing ideas. The phases of the blitter are already treated as four separate offset clocks so I could potentially clock them with a shift register and clock that shift register at the highest number that still works.

More recently I've been questioning my decision to bank the *entirety* of general purpose RAM. As in, the only RAM which isn't shared with the audio processor or video card.
I realized today that when the video card is in DMA mode though, all but the lowest 8 bytes of its address range aren't particularly useful. Part of it could be used as a window into the higher parts of the SRAM which currently only has 8K at a time banked in at the bottom of my address space.

On the other hand I don't expect to need that much memory to stay fixed between banks. The biggest hassle from the banking so far has been interrupt handling, where an interrupt comes in and I don't know what bank I'm on because the register is write-only. It's also not that much of a problem to store a couple of bytes in the SRAM shared with the audio processor as its programs necessarily have to be short to achieve a decent sample rate.

At this point I think if I'm going to order boards and solder up another prototype I'd rather just fix the bodges and have two working prototypes with this quirk than end up with a single working prototype without.

[Sheep64]

I've been thinking about video timings and I hoped that prompting you after a period of reflection (allowing two months for Tetris addiction) might be productive. You switched from two phases to four phases because one of the original phases was marginal. Rather than rotating a shift register, I considered one 74x161 (configured to count 14, 15, zero at 28MHz) and one 74x138 to obtain three strobes. However, I have no idea if three phases mesh with your design. I presume no.

Agumander on Thu 2 Jun 2022 wrote:

The biggest hassle from the banking so far has been interrupt handling, where an interrupt comes in and I don't know what bank I'm on because the register is write-only.

Atari's solution to write-only registers is to first write the value to a well know location. If an interrupt occurs and it modifies the same register then the interrupt is able to restore the write-only register - possibly before the main routine modifies register.

If you're banking RAM, it might be useful to reserve one memory location within every bank. Populating the bank number is quite easy: STX bank_latch // STX zp_bank_number // DEX // BNE. The reserved memory location can be used to quickly determine bank number within an interrupt. After an interrupt handler pushes registers, it can read bank number from RAM and then switch to bank zero (or similar) with the original bank number held in the register of your choice. At the end of interrupt, bank number can be restored and then registers can be restored from stack. Useful stack values may be split across two banks but nothing is ambiguous and it all works.

For microcontrollers and games, where the application is larger than the data, it is more important to bank ROM. Interrupts can be written such that RAM bank and ROM bank is always preserved.

[Agumander]

It's been a good long while since I posted an update but this project is very much still alive!

The earlier mentioned increase to Graphics RAM has been super useful. I can fill it with tons of animation frames while loading a level and render characters that have several distinct animations.
Reserving a location in every RAM bank as per Sheep64's suggestion has also worked well, making it easier to check the current bank. I'm using the extra memory for a generously-sized draw queue that triggers on the blitter's completion IRQ, which will help make sure the blitter doesn't sit idle for too long.

The emulator has been improved a bit, audio is now more accurate as I figured out how to synchronize the CPU thread and the audio thread with a device lock.

I revamped the website for the project and started inviting people to try developing for the system. A friend at my local hackerspace has agreed to be a guinea pig for a tutorial starting from zero game programming experience.

Also I recorded a new video of the most recent prototype running the most recent software since the video Hackaday embedded in their article is from 2020 and shows a much buggier GameTank.
https://www.youtube.com/watch?v=FyrKu8JzlZ4

[Agumander]

Things have been very busy in GameTank world. I had booths at two gaming conventions and a hacker conference last month and I sold 17 "developer bundles" consisting of the main console unit, a controller, a blank cartridge, and the cartridge flasher. Next month I'll be giving a talk at JawnCon0x2 and the next week showing the system at Portland Retro Gaming Expo.

Today I'm pleased to share that I'm partnering with Crowd Supply to try getting enough of these made to reach the next tier of bulk parts pricing.
Yesterday evening the pre-campaign page went public: https://www.crowdsupply.com/clydeware/gametank

Up until this year I'd been using PCBWay to make around a dozen boardsets at a time and finish assembly in my basement as orders come in- or frantically all at once the week before a convention.
This was already starting to hit the limit of how quickly I could put these together and properly test them while doing quality work. Then of course the tariffs made it impractical to keep using PCBWay at scale.

I'm waiting on a quote from a contract manufacturer in Croatia, the import fee on which would only be 15%. Crowd Supply projects also get a discount from this particular manufacturer. Being a subsidiary of Mouser also helps C.S. negotiate parts deals. My hope is to add a zero to my batch size ie. at least 100* consoles. Once I get the manufacturing quote I'll know better what kind of numbers are feasible. Biggest hurdle will probably be sourcing and verifying those pesky IDT7007s.


(* or a nice round computery number like 128)

[BigEd]

Thanks for the update. Good to see you climbing the curve.

[Martin_H]

This is a neat project and your ability to maintain momentum for this long a time is impressive.

Most of the project makes sense, but NTSC video generation always seems like magic to me. I understand how the colorburst signal is used as a reference for the chrominance signal. But transforming a frame buffer into that signal is mystifying. Back in the day the Atari 800, C64, and ColecoVision all had custom IC's to do it, and I always assumed those IC's were crafted by elves.

In contrast generating VGA with a microcontroller or even discrete logic is straightforward. You index the RAM and use a resistor DAC to transform a byte to a VGA pixel. The V sync and H sync signals aren't complicated either.

[barnacle]

NTSC colour generation (sorry, 'color' ) isn't difficult in concept. That is, it's bloody clever and was invented by a lot of very clever people, and still isn't as good as e.g. PAL coding, but it's not really difficult... allegedly.

The video signal consists of syncs (from 0v to 0.3v) and the monochrome signal (from 0.3v to 0.7v), and effectively two colour signals which are phase encoded at 3.58MHz. Those two signals are Y (luminance) -R (red) and Y - B. So when the decoder sorts out the signal, it is missing the green signal, but that's easy to recreate: it's Y minus 0.3 red, minus 0.11blue. Suddenly you have red green and blue to drive the tube guns.

There is a colour burst which occurs a microsecond or so after the line sync (pardon me if I don't know the NTSC spec; I was a PAL broadcast engineer) and lasts a couple of microseconds. On NTSC, this is at a constant phase and provides a constant reference for the Y-R and Y-B signals.

So if you have a convenient 3.58MHz signal, you can generate a clock for that and use that as the burst. The phase of the colour signal itself says what colour should be displayed; the amplitude says how bright it should be. You can generate that signal by phase delaying the clock... say, eight steps into the 3.58MHz gives eight colours. I have a vague memory that a certain Mr Jobs did some very clever circuitry to do that; I think (from forty years after I last looked in one) that the BBC Micro did something essentially similar for PAL (though that involves changing the burst phase on alternate lines, along with the phase of the signal...

That probably hasn't helped you at all... sorry.

Neil

edit: I forgot: the colour signal is a maximum of 0.3v p-p and is added to the Y luminance signal. So your peak voltage is around 1.2 to 1.3v.

edit 2: corrected 'chrominance' to 'luminance' above. My brain was out to lunch.

[Agumander]

I'm probably going to end up dedicating a significant portion of my 55 minute JawnCon talk to (an attempt at) demystifying color video.
My phase delay comes from clocking a shift register at 8x the color frequency - about 28.6363MHz - and feeding the data pin with the color carrier.
The rest is just counting out the timing for when the burst should happen, and muxing between the phases.

Color video seemed magical to me when I started. Actually it still does. But that's what got me so interested in figuring it out.

[barnacle]

It's all great fun

One point which is perhaps not generally appreciated is that the chrominance bandwidth in both PAL and NTSC is significantly lower than the luminance bandwidth: around 400kHz vs over 5MHz. This is part of the broadcast spec and is designed to minimise the overall bandwidth of the transmission system (and therefore reduce costs for both transmitters and receivers).

The practical effect is that while an RGB system can have every pixel a different colour across a line, the PAL or NTSC encoding will smear those colours across perhaps the width of a character. It's the best that could be arranged in the 1950s, but in modern terms it's sadly disappointing.

Neil

[gfoot]

barnacle wrote:

One point which is perhaps not generally appreciated is that the chrominance bandwidth in both PAL and NTSC is significantly lower than the luminance bandwidth: around 400kHz vs over 5MHz. This is part of the broadcast spec and is designed to minimise the overall bandwidth of the transmission system (and therefore reduce costs for both transmitters and receivers).

This is something I've heard before but not really understood - does it mean that the 400kHz bandwidth is an inherent limitation of encoding data in the phase of colour carrier wave of that frequency? Or does it mean that the bandwidth of the input signal is limited by deliberate filtering before it gets encoded in the carrier wave, to make the overall signal easier to transmit later on?