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



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.

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.

Understood! Congrats on your success.

-- Jeff

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html

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.

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.

_________________
Modules | Processors | Boards | Boxes | Beep, Beep! I'm a sheep!

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.

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.



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.

_________________
Modules | Processors | Boards | Boxes | Beep, Beep! I'm a sheep!

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