ECB VGA framebuffer? [message #6818] |
Wed, 20 November 2019 06:11 |
jpstmuk
Messages: 5 Registered: October 2015
|
Junior Member |
|
|
We've got quite a few options for display output for the various ECB connected hosts (propio, vga3, scg, vdu, etc) with various levels of text and/or graphic output, but I was wondering if anyone had ever attempted a full VGA style framebuffer card?
It would be fairly ambitious, but in terms of outright drawing speeds and performance, since most of the tasks would be vram-to-vram (assets loaded into off-screen memory and then blitted around the place - assuming the use of something akin to a later MS-DOS VGA chip like an S3 or Cirrus Logic), in theory the speed of a 6502 or z80 host on the ecb wouldn't matter too much.
|
|
|
|
Re: ECB VGA framebuffer? [message #6820 is a reply to message #6818] |
Thu, 21 November 2019 08:33 |
|
Andrew B
Messages: 467 Registered: October 2015 Location: Near Redmond, WA
|
Senior Member Administrator |
|
|
The new Propeller 2 chip runs at 180 MHz+ and has the ability to output composite video, VGA, component HD, and DVI video all in one chip. Engineering samples of what should be the final silicone are out now.
If I were going to do a framebuffer based card I'd use that, because it will be readily available for the future, and with the right planning you could support everything from old school TVs, to HDTVs, to VGA, and DVI on one card.
There are already experiments going on with the 'HyperRam' low pin count xSPI RAM modules to add to the available RAM for a framebuffer.
|
|
|
|
|
Re: ECB VGA framebuffer? [message #6839 is a reply to message #6823] |
Mon, 25 November 2019 01:16 |
jpstmuk
Messages: 5 Registered: October 2015
|
Junior Member |
|
|
Well I've started on the Linux side of things and have the bare bones of a serial datastream to libSDL decoder working.
Code is GPL licensed and lives here: https://github.com/megatron-uk/PyPiGFX
The idea here is that you can synthesise a text stream (e.e <0000()>), send it over a serial link, and the decoder on the other side with translate it into (in this case) SDL_init( and run it. Although the project is intended to use a Pi (Zero - since it will easily fit inside a SBC-sized enclosure), it should actually (eventually) run on any host that has a SDL implementation and Python; I'm using my main Linux desktop with a Nvidia GTX 1080 now... so slight overkill!
So far I'm just working with a loopback FIFO, sending commands by hand, but once I've got a dev environment setup on the Mark IV, I should be able to start getting the client to do this itself.
I'm not aiming for binary/object level compatability with libSDL, but instead syntax level. So if you write a piece of code on Windows/Mac/Linux and use SDL_BlitSurface(srcbitmap, srcboundingbox, dstbitmap, dstboundingbox) you should be able to write it exactly the same in CP/M and compile it with SDCC, have it synthesised down to a text datastream, sent over the (serial|usb|piece-of-string) link, decoded at the other end and have your bitmap copied around the screen just as it would if you had written it locally.
Since the client is almost always going to be memory bound, I've made the decision to not try to transfer SDL objects back, instead object reference id's, which the client can use in place of an actual bitmap, piece of screen memory, queue or timer instance. The client instead passes references to those objects and the server looks them up from a list objects created in previous calls. I may have to write a couple of extra methods to return descriptions of several objects (bitmap depths and sizes, bounding box coordinates, etc), but they are ones that should be easily mappable to simple structs.
On that note, is there an SDCC primer guide/standard library reference anywhere to help me get started on the client side of the implementation?
|
|
|
|
|
|