Lets think a bit about an XMegaBox

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

Lets think a bit about an XMegaBox

Post by Jubatian » Sat Feb 06, 2016 12:51 pm

Occasionally I stroll around the web looking for parts, various console and microcomputer projects to see what people are up to. I am mostly interested in the software part, and even I have a quite elaborate design, but only as software concept (RRPGE). Anyway, Uzebox is continuously nagging me to see what would be reasonably possible with existing parts at 8 bits.

So just a proposal for something could be called as XMegaBox. So something based on an Atmel XMega.
  • CPU: XMega 16K RAM, 256K Flash. There are larger ones, I just wish to stay safe, to ensure long term availability of this part.
  • Clock: 32MHz (so no overclocking, just running at max, potentially supporting USB, probably useful for uploading games).
  • Display: 320x240 QVGA panel. They require a pixel clock of 6,4MHz, so you have 5 cycles per pixel.
  • Color output: RRGGBBI. For layout, see below, it is important.
  • SD card interface. If going for the USB upload path, not necessary, an SPI FLASH would also do!
  • Controllers: Due to the display choice, this system is ideally a handheld. So simple digital inputs do.
Display concept is the same like in Uzebox: driving the panel directly. In theory since the panel is ran at NTSC frequency (line and frame frequencies match), it may be possible to output video as well.

The main clock would come from a 6,4MHz crystal (or anything suitable to get this), which clocks the panel directly, and generates the main clock for the XMega by PLL (it can multiply by five).

A big difference to Uzebox as I realized is that the panel is clocked, it has no controller, so you get exactly 320 pixels width at 5 cycles per pixel, or 160 pixels at 10 cycles per pixel. Otherwise it is crappy nearest match (depending on where the out happens relative to the clock). An interesting feature if you can sync proper to the 6,4MHz clock is that you can freely shift around the outs: as long as they happen within the same 5 cycle block (bounded by the 6,4MHz ticks), they will update the proper pixel.

Why the RRGGBBI color output?

The idea stems from this topic here, where Alec demonstrates a possible 4 bit mode (I also realized the ld-swap-ld palettizing I used for Mode 74 was apparently invented by Janka there some 3 years ago). So I would propose wiring the 8 bit output port the following way:
  • Bit 7: to Bit6 of R/G/B on the LCD panel
  • Bit 6: to Bit7 of RED on the LCD panel
  • Bit 5: to Bit7 of GREEN on the LCD panel
  • Bit 4: to Bit7 of BLUE on the LCD panel
  • Bit 3: to Bit6 of RED on the LCD panel
  • Bit 2: to Bit6 of GREEN on the LCD panel
  • Bit 1: to Bit6 of BLUE on the LCD panel
  • Bit 0: to Bit5 of R/G/B on the LCD panel
Of course this means that in 8 bit mode, there are only 128 colors (since Bit7 should be left zero there). However you could mask out the low 4 bits of the port to produce a quite fast 4 bit color mode using a fixed EGA-like palette (the difference apart from the layout is the EGA brown, instead of which you would receive a muddy yellow: the EGA palette is not RGBI, that color is off, a different one from its full RRGGBB palette!).

The USB possibility

If instead of an SD card, the XMega realized an USB device of a mass storage class, the bootloader part could implement exposing what looks like a normal pendrive with a FAT filesystem. Then it could utilize an SPI Flash chip in any way it wants, so eliminating the fragmentation problem, while also providing a much simpler interface for games, especially which want to load or stream from the storage.

(I overlooked a bit the clock requirement of USB, but this use case allows to shut off the LCD panel, and use the internal oscillator of the ATMega as described in the Atmel docs unless there is any other way to get both. It might be impossible to use USB and run a game the same time also for the reason that interrupts can't happen within the video frame render)

Some XMega differences

The XMega has a DMA peripheral which may be useful for some tasks (and may make the job of producing a proper emulator harder if used...). For the graphic part, it notably has differences in load & store timings, likely the most striking being that it can store at 1 cycle / instruction. This makes it more reasonable to implement line buffered modes (such as Mode 2). Being slightly faster than Uzebox doesn't pay off since graphic either has to be done at 5cy / pixel to get full resolution (likely causing rather using the fast 4 bit per pixel possibility outlined above), or you have 10cy / pixel for a 2:1 aspect ratio 160x240 mode.

Being slightly faster may pay off somewhat in VBlank, which is much shorter when doing full height (you still have 262 lines with the QVGA panels, and you need to produce 240 lines to fill the screen instead of 224 with Uzebox).

User avatar
D3thAdd3r
Posts: 2422
Joined: Wed Apr 29, 2009 10:00 am
Location: Minneapolis, United States

Re: Lets think a bit about an XMegaBox

Post by D3thAdd3r » Sat Feb 06, 2016 4:55 pm

16K of ram would go a long way to make bigger games: imagine loading tilesets and sprites, which cost no flash, into ram..for nearly everything. I think the concept expands out much further than it did with older consoles, with mass storage, to where it is essentially unlimited 1 page at a time. It doesn't allow full 8 bit 256 tile and sprite sets to be decoupled from flash entirely, though at 256K flash that is likely unnecessary, would limit the video modes.

If XMegaBox(great name BTW) were to come, a critical necessity would be a lot of kernel developed to make programming time effective to see the bigger games actually happen. Briefly I tried developing for RetroWiz, a neat little idea in it's own right, but it's Achilles Heel: it is not time effective to make a small game there and not enough features are done. Games like Super Mario Bros. 1 are no longer impressive at 16+256 specs. Now 1 guy really needs to make Super Mario World :shock: It's that engineering thing that the cup is neither half full, nor half empty, rather it is twice as large as it needs to be. If coding was made effective enough, 1 determined guy might actually make SMW and it would be incredible.

The whole 16K+256K spec point I really like. My theory on something like the 1284 was that we would be badly hindered by the available cycles. There still isn't enough with 1 cycle stores to make a "mode 2 like" that could compete with mode 74 for example, and would probably shift the mode 3 like method even further to the forefront? That is an interesting discussion actually, I might be wrong about that part. Still with more ram and flash I think the CPU effectively needs to be closer to 64mhz honestly, except!, DMA...that thing could do some serious damage I bet!

I wont hijack so briefly some thoughts. Eliminate the AD725 and use a Cortex M4 to emulate it(colorburts possible with that clock and DMA?) and hopefully the existing video modes. Basically the kernel and games stay the same at the C level on a '644, but underneath it is now simply building display lists for the M4 to implement. Same with the sound, now you can have more PCM to be around SNES quality. The games automatically have way more free ram and cycles with the same chip count and approximately the same price.

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

Re: Lets think a bit about an XMegaBox

Post by Jubatian » Sat Feb 06, 2016 8:52 pm

Though decisions, indeed! I actually put the most though in the video generation part, to have it working with a real 8 bit in a sane and useful manner.

I had seen several proposals for VGA here, all more or less overclocking even the XMega. I think the VGA is just too demanding for byte-banging video (with a 8 bit staying within specs). NTSC progressive scan is on the edge of "reasonably possible". But composite is becoming obsolete and it is hard to interface proper without dedicated chips (I rather think about the receiving end, which is not even present for example for EUzebox). So I decided to drop it, and rely on the apparently widely available QVGA landscape panels which are designed to go with NTSC line and frame frequency (and thus may enable the console to still produce video output).

That also ended up setting the hard limit of 5 cycles per pixel, which requires the XMega to tick at 32MHz. Pleasant, although 5 cycles per (square) pixel is steep, and here you have no option to go just a little bit wider.

That's what the color layout is for! By placing RGBI on the top half nybble, I enable replicating Mode 74 (with fixed palette) with the following instruction sequence (after disabling the low 4 bits of the output):

Code: Select all

    lpm   r0,      Z+
    nop
    out   PIXOUT,  r0
    swap  r0
    nop
    nop
    nop
    out   PIXOUT,  r0
I emphasized the "nop"s to show how much slack there is in this 16 color mode. So staying with these colors, you can go quite far with video mode designs, and of course you still have the option for 256 colors or video modes with true palette if you can manage it (or go for the 160 pixels wide option at 10cy / pixel). The tiled concept should remain, it is actually a very decent concept, not substantially slower than using a real framebuffer for rendering sprites (for both the bulk is the same: one copy to either prepare or recover the area behind the sprite, and one sprite blit). The decency is in how it is capable to conserve RAM, and how fast it is for tiled concepts (faster and easier to use than a framebuffer). You can have 2 byte / tile in VRAM on a 16K RAM XMega which also eliminates the 256 tile limit.

The 16K RAM should be quite enough to be a bit lazy at coding and still get passable results, and of course could turn the console into a wicked powerhouse in the hands of someone willing to push the limits. If you can cram those games out from just 4K...

I had read about the AVGA / RetroWiz project, the latter for VGA even wants to run the ATMega328 at 32MHz. At this for the 168 pixels width there are 5 cycles / pixel (the intro video says 4 cycles, but that would mean running at ~25MHz while the site says 32), as far as I see using the same concept like I outlined above (although I wonder how it got the brown color for the Commander Keen demo, that's especially that color which is off of RGBI on the EGA, and doesn't even seem to be present on the intro video where the palette is briefly shown with muddy yellow as expected). So not pressing VGA, staying with NTSC gives you 10 cycles for the same in which about anything is possible...

Using an ARM makes me somewhat uneasy, feeling it rather like a kludgework than a sleek 8 bits console. If I had that, I would rather go for some completely imaginary system, like my RRPGE concept (16 bits). So anyway, the decision about video is along the lines of these.

The DMA I think won't likely help much in the video generation unless you went for framebuffer. Although it could be interesting for linebuffering (if you can get it to output at the proper rate), that is, opening some insane possibilities for Mode 2 style stuff. However I believe it would be a fragile thing (it might be somewhat unreliable where the actual DMA bus accesses occur across different or later XMegas, stalling CPU issued 'ld' instructions, which could end up becoming a ticking bomb for code relying on such. You also can't do transparent blits with it, so it isn't that useful either for accelerating sprite blits.

For audio I had seen complaints here and there for the lack of stereo. It can be added, and for mono output if you need that, it isn't slower (you can output the same mixing result to both channels). Of course otherwise it likely remains similar to Uzebox's since the environment isn't substantially different (although if it is possible to go with the USB device path, and so use something less "hostile" than an SD card with a FAT filesystem for the actual game storage, that may open possibilities).

User avatar
uze6666
Site Admin
Posts: 4449
Joined: Tue Aug 12, 2008 9:13 pm
Location: Montreal, Canada
Contact:

Re: Lets think a bit about an XMegaBox

Post by uze6666 » Sun Feb 07, 2016 3:50 am

Ahhh the Xmega...keeps coming now and then. :) There's plenty of stuff and discussions about xmega consoles on the board. Checkout: http://uzebox.org/forums/viewtopic.php? ... ilit=xmega for the first discussion. Mast3rbug came with an actual implementation (using VGA) and relates it's adventures: http://uzebox.org/forums/viewtopic.php?f=10&t=1781 and http://uzebox.org/forums/viewtopic.php? ... ilit=xmega.

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

Re: Lets think a bit about an XMegaBox

Post by Jubatian » Sun Feb 07, 2016 9:43 am

Huh, I didn't see you also tried the XMega before! I read Mast3rbug's project (the "powerkill console") recently, and I remember the other topic as well (Ahh, Cheetahmen, worst game ever? :P Tried to play that thing on a NES emulator).

For the ARM path, I don't think we should "hijack" someone else's "thread", there is already a decent one out in the wild: the Bitbox console. Really, we should contribute to that if going for the 32 bit path. I ran a few though experiments over that system, thinking about how neat would be 360x360 over the VGA 720x400, 70Hz standard (DOS text mode's timing). The nice thing in this at 256 colors that you could port the game you make to DOS, since with "unconventional" standard VGA programming (ModeX) you can have that resolution (as 360x400), the 360 pixels height used is half of 720p, and 360x360, 8bits is just below a 128Kbytes barrier. It also has 1,5:1 pixel aspect ratio like 7 cycles / pixel on Uzebox.

With the XMega the more critical would be the approach to the kernel, of course built over your work. With 16Kbytes you have some possibilities not feasible for Uzebox. An interesting concept for sound follows.

Uzebox, the VSync mixer. The nice part in the VSync mixer is that since it can process each channel in one go, it takes less overall cycles (no channel set-up & writeback housekeeping) than an inline mixer (or could do more in the same amount of cycles than that). But it steals away the VBlank, and a lot of memory. Now what if the latter was a no problem? Was it possible to get around the VBlank problem?

It should actually be possible! First, lets consider what if we ran the HSync generation by PWM in the display section. It should be possible (if HSync was placed on a pin capable for PWM), and it eliminates the necessity of coding the toggling of that pin. This alone doesn't seem to be a huge win. But lets add that how its possible to create a quite fast sync to timer (I demonstrated it a few days before). Now what if at the end of a line we exited from interrupt, and re-entered for the next line? (Where it suddenly becomes important that HSync is toggled by PWM)

Oh right. The stack. Loads of pushes and pops. But wait. The XMega is a cycle faster at pushes. A little bit of win. But lets go further. That video code seriously needs all the registers it can have. And wasting bazillions of cycles just for pushing and popping is ridiculous. But what if... What if the "iret" didn't return to main, rather to a specialized code using only a smaller subset of registers? Pretty much doable! (Just push a return address, and do the "iret", and once the segment using the specialized main is done, within the interrupt, discard the return address on the top of the stack, and use the normal exit path to return to the real main).

So lets code a VSync mixer which in the reality runs in HSync! Sure it needs 2x262 bytes of RAM, but on the XMega we would have that! The result:
  • A potentially more powerful mixer, a great thing alone (If just 100 cycles were available each HBlank, you would have 24000 cycles for it in 240 lines, a pretty decent deal).
  • It is running in HBlank, so there is no mixing in VBlank!
  • Since it is actually a VBlank mixer by concept, you don't need HSync mixing, so you even have those cycles spared in VBlank!
Sadly this concept has no much use with Uzebox. Not because it may be impossible to PWM the HSync (the concept might work even without that, but less time for the mixer), but the memory use which is not affordable with 4K (You can only use this concept with RAM tiled video modes where there is time for an inline mixer, but those modes need RAM for the RAM tiles. Mode 2 style concepts could have the RAM, but they need all the HBlank time to do sprites. Of course may be useful with a no-sprites mode, but those modes aren't that useful for most games - except things like Megatris and maybe some rougelikes).

Just brainstorming. I am not at home, so can't code Mode 74, and neither have anything much better to do right now, which shows :lol:

User avatar
makapuf
Posts: 13
Joined: Sun Jun 24, 2012 11:55 pm

Re: Lets think a bit about an XMegaBox

Post by makapuf » Tue Feb 09, 2016 4:49 pm

Hi, I'm makapuf (maker of the Bitbox) Thanks for the notification !

Just as a co incidence, we've just released a few month ago the bitbox micro which apart from halving every spec of the bitbox (incl speed, memory, nb of components, size and cost :) ) , uses a RRRGGBBL VGA out DAC (shared bit between G and B). Why ? because it's quite simpler than rgbi hardware wise, allows 8 levels of true grey for instance. - but I don't want to hijack this thread either !

Here 's an analysis of the palette : http://neil.franklin.ch/Info_Texts/DAC_ ... lours.html

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

Re: Lets think a bit about an XMegaBox

Post by Jubatian » Fri Feb 12, 2016 7:45 am

Huh! Nice :)

For the palette I proposed the inclusion of an RGBI nybble since the Uzebox or even the XMega has too little RAM to have a true framebuffer, so has to build up a tiled surface real-time. This is quite costly for the possible speed. When using 4 bits only, that gives enough slack to perform it adequately well, so higher resolutions are possible while retaining flexible graphics capabilities. Otherwise the RRRGGBBL solution you went for is a very nice deal! (It just doesn't have a good 4 bit subset, but on the BitBox nobody would want to render with a hardware-fixed 4bpp palette anyway).

I checked the BitBox Micro's specs, just one curiosity. Why the decision for mono sound? From the outside, stereo doesn't seem like it would imply too many extra components, and for people going for mono sound it doesn't demand more CPU power (just output the same value to both). Or maybe there is some kernel / DMA channel specific there? (I would think that to fill the DMA operated linebuffer, you would need an interrupt at line frequency which could be utilized for the direct output of the audio as well)

Is there a forum by the way? Later I might buy one or two for experimenting with some game ideas.

User avatar
uze6666
Site Admin
Posts: 4449
Joined: Tue Aug 12, 2008 9:13 pm
Location: Montreal, Canada
Contact:

Re: Lets think a bit about an XMegaBox

Post by uze6666 » Sat Feb 13, 2016 5:19 am

For what it's worth, I kinda always regretted for the Uzebox, not thinking of the RRGGBBII model like LucidScience used for its VGA generator. It seems one of the most balanced and nice fixed color palette you can get from 8 bit.

User avatar
makapuf
Posts: 13
Joined: Sun Jun 24, 2012 11:55 pm

Re: Lets think a bit about an XMegaBox

Post by makapuf » Mon Feb 15, 2016 10:09 am

I checked the BitBox Micro's specs, just one curiosity. Why the decision for mono sound?
Well, mono sound is twice simpler than stereo to generate, and we wanted the micro to be as simple as possible. I personally don't find stereo that much better for simple systems, and the bitbox is not superceded as the bigger console with uSD, expansion, 15bit color, stereo snd and all.
Or maybe there is some kernel / DMA channel specific there? (I would think that to fill the DMA operated linebuffer, you would need an interrupt at line frequency which could be utilized for the direct output of the audio as well)
In order to be independent from video modes/clockig, the DAC driven by DMA has an independent timer from Hsync, so, no issue.
Is there a forum by the way? Later I might buy one or two for experimenting with some game ideas.
Well it's a mailing list (google group). Maybe I should really create a forum, but for now, you're welcome to join in and ask questions !

Post Reply

Who is online

Users browsing this forum: No registered users and 1 guest