Lets think a bit about an XMegaBox
Posted: 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.
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:
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).
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.
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
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).