MicroDuo if ever (2 x ATmega1284 system)

Discuss anything not related to the current Uzebox design like successors and other open source gaming hardware
User avatar
Jubatian
Posts: 1355
Joined: Thu Oct 01, 2015 9:44 pm
Location: Hungary
Contact:

MicroDuo if ever (2 x ATmega1284 system)

Post by Jubatian » Mon May 27, 2019 4:20 pm

Just sharing something I am designing since a while. Maybe I will finally start buying stuff for actual HW work, most likely to start blowing up things first :P

Pushing 8 bit to the extreme by soldering two 1284s side by side to make a hopefully pretty awesome game console.
2x1284_7.png
MicroDuo coarse schematics
2x1284_7.png (248.14 KiB) Viewed 1335 times
The left one is the GPU, the right one is the Game Logic and Audio UC. The GPU has fixed firmware with no update capabilities, I already have the most essential parts of its code completed. It uses a very dirty trick utilizing the entire 128K of the 1284 to realize video modes "normally" impossible. So in essence this UC can be regarded as a crude "graphics card" with 16K Graphics RAM.

Why exactly 18 MHz? It seems to be a rather common crystal, and about the only one not directly derived from NTSC colorburst by which it is still possible to maintain exact NTSC timing. One scanline is exactly 1144 clocks, 8 * 11 * 13, which has a minor significance in that too that the base timer for it can be a 8 bit one with a prescaler of 8 (a 16 bit timer would still available, but realizing this I left the pin clear for the programmer).

The most common video modes would be a set of 1bpp and 2bpp modes at 288 pixels width (practically square pixels), and 4bpp mode at 192 pixels width (so for example Flight of a Dragon or Stormforce could be ported directly to this contraption).

Uzebox compatibility is sadly not possible for several reasons, one is that a full set of 8bpp tiles wouldn't fit, the other is that at this frequency and Uzebox Mode 3's resolution, it is not possible to create a tiled mode which fetches every pixel's colour directly from RAM.

The transfer mechanism I devised could be capable even to fill up the entire Graphics RAM in one VBlank, allowing to design a game not that tightly bounded to the frame rate (as if you skipped a frame, the GPU would keep displaying the previous one, you can render for multiple frames). This makes such things possible like more elaborate 3D or pseudo-3D (Outrun).

Audio is up to 31.5KHz stereo, the GPU providing the external interrupt for this.

For the pixel output, I considered using RRGGBBII, which would be a better colour space, but it would also make building the DAC more complex, and needing more precision. I rather chose to stick with the same BBGGGRRR layout like Uzebox (or the Enterprise 128).

For performance, comparison with Uzebox:
  • Uzebox, 200 lines display: ~111000 cycles VBlank
  • MicroDuo, 200 lines display: ~228000 cycles
  • Uzebox, 224 lines display: ~67000 cycles VBlank
  • MicroDuo, 224 lines display: ~256000 cycles
The two behave differently as on this 2 x 1284 system you would do the game logic while the GPU displays the frame. Then in VBlank you transfer data, the display's height here would be mostly bounded by how much you wanted to transfer (however with about 200 lines, it is likely that 16K would be possible to be transferred). For both I didn't subtract HSync interrupt as it is mostly mixer, which could even be similar anyway.

Emulation would be pretty much possible, when performance matters, the GPU could be done by native code (as it has fixed firmware), which could make it even faster than emulating Uzebox.

As it is now, mostly it needs about the same components and circuits like the Uzebox does, so I hope I wouldn't eventually send too many 1284's to the IC heavens trying to build this.

User avatar
Janka
Posts: 213
Joined: Fri Sep 21, 2012 10:46 pm
Location: inside Out

Re: MicroDuo if ever (2 x ATmega1284 system)

Post by Janka » Mon May 27, 2019 9:27 pm

While I certainly appreciate the effort, it's mainly the existing games and the emulator which did it for me in 2011. Also, putting a decent game into only 60K ROM and 4K RAM requires a lot of thought and that's a whole lot of the gratification programming for the Uzebox offers. It's missing if the machine gets better. It's simple enough to build a game for a console based on more powerful chips … or simply create another browser game or an app for smartphones. Let's have the lesser engineers do that. (Not that I don't do it, but for other audiences. :mrgreen: )

Having a dedicated graphics processor also drops simplicity and versatility and hinders tinkering and I think that's what was keep people going on the last years. See the variety of new video modes, and we didn't even have a raster kernel yet which allowed to switch video modes per line. Certainly something I would love to develop (or help developing).

User avatar
Jubatian
Posts: 1355
Joined: Thu Oct 01, 2015 9:44 pm
Location: Hungary
Contact:

Re: MicroDuo if ever (2 x ATmega1284 system)

Post by Jubatian » Mon May 27, 2019 9:54 pm

Good points actually!

It is partially rather a struggle from my part as since long I have some quite elaborate roleplaying and adventure game ideas in mind which I would like to realize (and also some pixel comic idea similar to The Pocalypse which would be interesting to do in a manner that it actually ran on something, but that needs the RAM). With Uzebox, the SPI RAM comes somewhat near, but it is just something, well, sort of just meh. A bit clunky, no matter how much effort I put at it to get clean interfaces out of it. Then occasionally I also dust off my 6510 asm skills, the C64 looking just more generous for more artwork intensive games if one can master the VIC's graphics modes: the 64K is RAM, allowing to load things from the floppy.

Emulation for this one is definitely doable, and if I get to actual HW, I would do it, what actually holds me back is real HW, and the lack of skill / any equipment at the moment (after switching countries, still not quite sure if I would even live here, say, a year later). Otherwise I would estimate it to be just a matter of a few weeks to get it working based on CUzeBox.

Some of the video modes I designed have quite a variety of possible mix-ups, Flight of a Dragon with Mode 74 uses part 4bpp with 8 pixels wide tiles, part 1bpp with 6 pixels wide tiles. The SPI RAM variant allows for adding high-resolution tile rows (384 pixels wide), this is also an option for Mode 72. The Mode 40/41/42 group have options to use bitmapped graphics in chosen tile rows, likewise Mode 90 as well, which I designed for Yllawwally, he even planned to use it for encounters (a screenshot here), but it didn't made it into the released game.

The problem with arbitrary mixing is the limited RAM, that some combinations just don't make sense, and that combining is actually a very complex techique, all sub-modes meant to be combineable need to have precisely aligned scanline timing. So I think it only makes sense if one designed a mode which includes reasonable use-cases. And then it also needs consideration on ROM usage.

User avatar
Janka
Posts: 213
Joined: Fri Sep 21, 2012 10:46 pm
Location: inside Out

Re: MicroDuo if ever (2 x ATmega1284 system)

Post by Janka » Tue May 28, 2019 12:07 am

The screen list which determines which render method to use for a certain line is only trip points, and the address of the function to set for the following lines. That's three bytes per trip point and we had maybe 10 trip points per screen. Not much. If RAM was really tight, one could simply not render one tile line of the screen (all one colour) and get the needed 30 bytes.

Actually, this could save RAM and cycles for split-screen games and also makes it possible to have 30 or more RAM tiles both in the upper and the lower half of the screen.

In addition, that 16x4 tile mode I favour for platformers has to be mixed with an 8x8 tile mode for the stats. A raster kernel could do that.

But I see now, we should continue this discussion as another topic.

olin
Posts: 8
Joined: Sun May 12, 2019 3:16 pm

Re: MicroDuo if ever (2 x ATmega1284 system)

Post by olin » Tue May 28, 2019 11:30 pm

I like the idea of dedicated 'GPU'. What about adding a dedicated video SRAM that would work as RAMDAC? The tiles would be loaded to Video SRAM (rather than the GPU RAM itself) and the GPU would render pixels by sending 'read' addresses to the VSRAM, which would output the values on the 8bit data out pins connected to resistor arrays. Maybe you could even use ATmega644 as the GPU. Just a thought...

User avatar
Jubatian
Posts: 1355
Joined: Thu Oct 01, 2015 9:44 pm
Location: Hungary
Contact:

Re: MicroDuo if ever (2 x ATmega1284 system)

Post by Jubatian » Wed May 29, 2019 10:14 pm

olin wrote:
Tue May 28, 2019 11:30 pm
I like the idea of dedicated 'GPU'. What about adding a dedicated video SRAM that would work as RAMDAC? The tiles would be loaded to Video SRAM (rather than the GPU RAM itself) and the GPU would render pixels by sending 'read' addresses to the VSRAM, which would output the values on the 8bit data out pins connected to resistor arrays. Maybe you could even use ATmega644 as the GPU. Just a thought...
I actually considered this, too, but it ends up using one more chip (the SRAM), and it is quite complicated to get these three properly interacting. I rather wanted to keep it simple. The 16K RAM the GPU has actually fits well with the typical capabilities of graphics solutions sitting in old 8 bit microcomputers, and it is sufficient for the purpose.

Actually the GPU would be capable to do 4bpp framebuffer at 288 pixels width, which would benefit from more RAM, but then the problem of transferring it to the GPU would be the bottleneck. The design hugely pushes the 1284 to the limits in terms of coding trickery. The useful modes are 4bpp at 192 pixels width (1.5:1 pixel aspect ratio), where it can use a tiled mode (256 or ~400 tiles) to fill the screen, 2bpp and 1bpp modes at 288 pixels width with color attributes, and a simple 1bpp mode at 384 pixels width (which mixed with the 192 pixels wide mode would somewhat resemble to mixing High-Res and Multicolour on the C64).

One of the key points in this design was to avoid overclocking anything, so in that regard the ATmega644, which runs rather reliably at 28.6MHz, is not that useful (the ATmega1284s can not run at this frequency at all). For home building, it is the same DIP-40 chip, so no gains sticking with the 644 :)

The other key point is that this system still has a nice set of limitations, but not excessive, ordinary good design aimed at considerate use of the resources would do well on it. So likely it could do well with C for more artwork / story intensive games (adventure, roleplaying), portable code, easier to get it running on other homebrew systems (ARM), while this 2 x 1284 one could have true emulation (so stuff developed for it could potentially get onto the web or into MAME, LibRetro, and similar emulation packages).

CunningFellow
Posts: 1174
Joined: Mon Feb 11, 2013 8:08 am
Location: Brisbane, Australia

Re: MicroDuo if ever (2 x ATmega1284 system)

Post by CunningFellow » Wed May 29, 2019 10:37 pm

Generally I think

PIC SUCKS AVR RULES

But a PIC might be a better choice for your GPU side. The whole idea of the PIC architecture was to be a peripheral for other CPU that did not have proper I/O.

Their ISA is very suited to bit twiddling.

A 28 pin DIP 8 bit PIC with 128K flash and 8K RAM is 1/2 the price of a an ATMEGA1284.

If you don't mind going up to the non 8bit PICs then there are options in the dsPIC range that have 24K of RAM and also have DMA to get data in and out of the peripherals.

User avatar
Jubatian
Posts: 1355
Joined: Thu Oct 01, 2015 9:44 pm
Location: Hungary
Contact:

Re: MicroDuo if ever (2 x ATmega1284 system)

Post by Jubatian » Wed May 29, 2019 10:51 pm

CunningFellow wrote:
Wed May 29, 2019 10:37 pm
Generally I think

PIC SUCKS AVR RULES
Well, today they are both Microchip, so at this point the old battle became a bit moot :lol: Could even be a fun thing just for the heck of it!

I did extensive coding on PIC18s, I dunno the situation today, but then there weren't free C compiler options for them. Not that such a GPU would have too much C code, the PIC instruction set isn't quite C friendly anyway. I also had a share of PIC24s, fixing up some huge piece of software gone terribly south in design (also needing digging down into ASM to figure out what the hell is going on due to the poor coding disciplines at C level, undefined behaviours...).

I don't think the price of the 40 leg centipede is much of a factor in these hobbyist game consoles :) I think for the OSS compiler (GCC) and that I really really don't want to build an emulator for the PIC as well, I would stick with the AVR (normally I plan to run the GPU with native code, but would like to have the option of full emulation for assisting development, or simply just GPU hacking).

28 pins is really not enough anyway, it would halve transfer rate from Logic CPU to GPU (8 bits instead of 16 bits in one synchronized transfer), which would be a major hit for the versatility of the design.

User avatar
Jubatian
Posts: 1355
Joined: Thu Oct 01, 2015 9:44 pm
Location: Hungary
Contact:

Re: MicroDuo if ever (2 x ATmega1284 system)

Post by Jubatian » Sun Jun 23, 2019 9:30 am

Just a bit of progress report.

No HW yet, I am still not quite there, but I hope I will eventually get all the stuff needed for it. At least in a month I will get a lot of things which I had remaining in Hungary, along them a few things which are useful for actual HW building.

However there are two important developments on the code:
  • Video MCU is capable to actually have a bootloader, without any unsafe kludge. So it will have it. Still I plan for mostly fixed firmware on that, but I think 48K ROM will be just available on it for loading it with data (the game file format would then contain capability to include such data), and of course it also opens for the occasional game doing something out-of-ordinary with video (at the cost of requiring turning on true V-MCU emulation in emulators).
  • Video modes capable to use the RAM of both MCUs to generate display. Enables for example displaying 16 colour 288x216 full-screen images, which is impossible even with SPI RAM on the Uzebox. A scanline can be taken either from V-MCU or L-MCU, so properly allocating these, there may be lots of L-CPU time remaining to do something sensible (although potentially no much RAM).
It may be odd, but yes, it is possible to have high-resolution 4bpp at 18MHz with the AVR, if you are serving it scanline by scanline from RAM, and have 128K of program memory. That's how 16 colour 288x216 is possible (3 cycles / pixel). I was aware of this since a while (along with the other tricky code this thing has), but had no much utility without having 32K RAM to go with it.

It looks like this will become quite an 8 bit beast!

Anyway, at the moment I am also working on something for the Uzebox which will be certainly exclusive for the Uzebox if I manage to pull it off (as the weird Mode 72 based video it has is only possible at Uzebox's clock frequency), and something pretty much unseen before! :)

EDIT: Almost forgot a third. I also sketched up earlier a fairly OK Mode 3 implementation for this, not wholly compatible as the V-MCU's 16K RAM is not sufficient for that, but something which might be just OK for quickly porting some Uzebox games.

rv6502
Posts: 23
Joined: Mon Feb 11, 2019 4:27 am

Re: MicroDuo if ever (2 x ATmega1284 system)

Post by rv6502 » Tue Jun 25, 2019 1:48 am

Jubatian wrote:
Wed May 29, 2019 10:51 pm
28 pins is really not enough anyway, it would halve transfer rate from Logic CPU to GPU (8 bits instead of 16 bits in one synchronized transfer), which would be a major hit for the versatility of the design.
Can you really pump 16bits transfers on a 1284 tho?

The extra bits can certainly be useful for other things such as sending interrupts or command/data protocol control flags but if it's synchronized burst transfers then only 8 wires are needed (or 8 resistors to be safe)

Code: Select all

ld r19, z+           
out PORT, r19        (nops)
ld r19, z+           in r19, PORT
out PORT, r19        st z+, r19

Post Reply

Who is online

Users browsing this forum: No registered users and 1 guest