The P8X Game System

Discuss anything not related to the current Uzebox design like successors and other open source gaming hardware
Post Reply
macca
Posts: 5
Joined: Thu Jan 12, 2017 2:21 pm

The P8X Game System

Post by macca » Mon Jan 23, 2017 11:13 am

Hi,

I would like to present you the game console I'm working on, hope I'm not doing a wrong thing by posting here.

It is based on the Parallax Propeller microcontroller and uses retro-style game cartridges. It is capable of up to 320x240 pixels resolution with 64 colors, 8x8 pixels tiles, 8x8 up to 32x32 pixels sprites, full screen scrolling and stereo audio. The video output is RGB only (no composite or s-video) and there are drivers for VGA, PAL and NTSC signaling. It can be connected directly to VGA monitors and TV with SCART/RGB inputs. Audio drivers can emulate some popular audio chips like AY-3-8910, SN76489 and SID/MOS8580.
console_small.jpg
console_small.jpg (68.2 KiB) Viewed 3819 times
Games can be programmed in C/C++ using the Propeller GCC variant and a simple integrated development environment that takes care of the build process.
I have successfully ported AlterEgo and Lode Runner from the Uzebox sources (thanks to the authors for the great work).

Everything is open source and available on the web site:
https://dev.maccasoft.com/propgame

I would appreciate comments and suggestions.

Thanks,
Marco.

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

Re: The P8X Game System

Post by D3thAdd3r » Tue Jan 24, 2017 6:51 pm

A GPU, I like it. Cartridges are also very cool, perhaps there could be such thing as an SD card based multicart; then more games is practical for a player to use. I checked through the source a bit on Alter Ego and I think I get the gist of using the API...seems a bit more complex than Uzebox at the moment. The Lode Runner port has significantly less cryptic conversion it seems, is that just more portable code or you managed some Uzebox kernel equivalent?

I wasn't able to register as it didn't like any username I threw at it. It would be great to see some videos of this in action, and a kit available so one could easily build it(emulation on PC..not possible?). Very cool machine. I think you could have lots of games simply by emulation, with that beastly of specs.

macca
Posts: 5
Joined: Thu Jan 12, 2017 2:21 pm

Re: The P8X Game System

Post by macca » Tue Jan 24, 2017 8:10 pm

D3thAdd3r wrote:A GPU, I like it. Cartridges are also very cool, perhaps there could be such thing as an SD card based multicart; then more games is practical for a player to use.
And SD card is planned in the future.
D3thAdd3r wrote:I checked through the source a bit on Alter Ego and I think I get the gist of using the API...seems a bit more complex than Uzebox at the moment. The Lode Runner port has significantly less cryptic conversion it seems, is that just more portable code or you managed some Uzebox kernel equivalent?
AlterEgo was the first I ported and I have manually adapted the code, with LodeRunner I wrote some "bridge" functions equivalent to the Uzebox API and a dedicated video driver (mainly because it uses 8x12 pixels tiles while my drivers are designed for 8x8 pixels). I plan to use the same bridge functions in a future revision of AlterEgo so the code is more clear.
D3thAdd3r wrote:I wasn't able to register as it didn't like any username I threw at it. It would be great to see some videos of this in action, and a kit available so one could easily build it(emulation on PC..not possible?). Very cool machine. I think you could have lots of games simply by emulation, with that beastly of specs.
I had to implement a rather aggressive anti-spam filter to prevent automated registrations, I'll see if I can relax it a bit or whitelist your name.

A kit is almost ready, I plan to start selling it on Tindie soon. I don't have a PC emulator, emulating the processor and the original code in realtime is impossible so it should be a wrapper that emulates the function and compiles to a native program, I don't have plans to write it anytime soon.

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

Re: The P8X Game System

Post by Jubatian » Wed Jan 25, 2017 8:47 am

This is a quite powerful machine! As far as I see it uses SPI for cartridge access (one 512K ROM for each Propeller) and extra SPI RAM on the Propeller dedicated for running the game logic.
macca wrote:I don't have a PC emulator, emulating the processor and the original code in realtime is impossible
I think this is true, that is, the task of emulating even a single Propeller micro is impossible in real time. It requires cycle-perfect emulation at 80 MHz due to the hub (resource sharing between cogs), and there are 8 cogs, that's 640 million unpredictable branches per second. There is no processor in existence (maybe except in very specialized supercomputers) which could deal with that many potentially mispredicted branches. Computationally a cog at 80MHz is cheaper than an AVR at 28.6MHz, but more potentially mispredicted branches, and that would be the bottleneck.

Anyway, interesting stuff. I see that the Propeller has a video generator, but as far as I understand, it is quite limited (especially in colors). How do you generate video on this (based on the screenshots & description, I guess it is entirely done in code, I think requiring the precise sync of several cogs to get them sharing turns in producing pixels).

macca
Posts: 5
Joined: Thu Jan 12, 2017 2:21 pm

Re: The P8X Game System

Post by macca » Wed Jan 25, 2017 11:26 am

Jubatian wrote:This is a quite powerful machine! As far as I see it uses SPI for cartridge access (one 512K ROM for each Propeller) and extra SPI RAM on the Propeller dedicated for running the game logic.
Yes but the cartridge eeprom uses I2C, the SPI ram can be used to hold data that can't fit on the Propeller's RAM (which is limited to 32k). The game l'Abbaye des Morts uses the SPI ram to hold the room maps because the layout changes when the player touch a switch or pick up an item.
Jubatian wrote:I think this is true, that is, the task of emulating even a single Propeller micro is impossible in real time. It requires cycle-perfect emulation at 80 MHz due to the hub (resource sharing between cogs), and there are 8 cogs, that's 640 million unpredictable branches per second. There is no processor in existence (maybe except in very specialized supercomputers) which could deal with that many potentially mispredicted branches. Computationally a cog at 80MHz is cheaper than an AVR at 28.6MHz, but more potentially mispredicted branches, and that would be the bottleneck.
Right, I've ported an emulator written in .NET to C++ and it is still very slow.
Jubatian wrote:Anyway, interesting stuff. I see that the Propeller has a video generator, but as far as I understand, it is quite limited (especially in colors). How do you generate video on this (based on the screenshots & description, I guess it is entirely done in code, I think requiring the precise sync of several cogs to get them sharing turns in producing pixels).
Yes the video generation is entirely done in code, the Propeller's video generator is basically an 8-bit parallel streamer, the meaning of the bits are up to the application, in this case I have used the standard VGA layout with 2-bits for each color plus h/v-sync signals for a total of 64 colors. There are drivers that can use the full 8-bits for color generation plus two extra bits for the signals, but I choose the standard setup to make it easy to have a reference for custom drivers.

The video drivers can generate signals compatible with VGA at 640x480, PAL at 320x240 and NTSC at 320x224, it is up to the application to choose what output driver to use. There is also an experimental driver setup that auto-adapt the output based on the user hardware choice (I have two jumpers on the board to select VGA, PAL or NTSC preferred output). The video signal is generated by a single COG, the graphics rendering uses 5 COGS synchronized by the video signal generator, each COG renders one scanline that is fed to the video generation COG for output.

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

Re: The P8X Game System

Post by Jubatian » Mon Jan 30, 2017 1:25 pm

Huh. The VGA 640x480 mode uses approx 25MHz pixel clock. I take this that your 5 cogs share turns in producing pixels, each running at 80MHz (approx. 20MHz instruction rate). So every cog generates a pixel once in 4 instructions (16 clocks) while the five cogs run in sync. Nice, although it must be very messy if you wanted to produce 8 pixels wide tiles (it seems quite difficult to get a functional graphics mode here by conventional Uzebox principles, I guess you use some line buffer or line double buffer principle to realize stuff). For PAL / NTSC (or double scanned 320x240 VGA) it should be capable to realize awesome graphics.

macca
Posts: 5
Joined: Thu Jan 12, 2017 2:21 pm

Re: The P8X Game System

Post by macca » Tue Jan 31, 2017 10:20 am

The Propeller chip has instructions to deal with the video generator/stream that leave the cog free to do other things while the pixels are output, but yes the timings are very tight in VGA mode.

Yes the architecture uses a single scanline buffer that is filled by the renderers. The Cog dedicated to generate the video signals reads one scanline in its own memory then signals through a common variable the next scanline number it expects, the Cog assigned to generate that scanline fills the buffer and continue with the next scanline. The 5 rendering Cogs generates 5 consecutive scanlines in parallel.

Post Reply

Who is online

Users browsing this forum: No registered users and 2 guests