RetroBrew Computers Forum
Discussion forum for the RetroBrew Computers community.

Home » RBC Forums » General Discussion » ECB VGA framebuffer?
ECB VGA framebuffer? [message #6818] Wed, 20 November 2019 06:11 Go to next message
jpstmuk is currently offline  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 #6819 is a reply to message #6818] Thu, 21 November 2019 05:34 Go to previous messageGo to next message
jpstmuk is currently offline  jpstmuk
Messages: 5
Registered: October 2015
Junior Member
I just saw the pigfx project on Github: https://github.com/fbergama/pigfx

It's somewhat similar idea to the propio, vga3, etc. it seems to currently be setup to connect a serial interface to a Pi (zero) and turn it into a text terminal with HDMI output.

I wonder if it would be feasible to change from the simple serial interface to i2c, spi or even a frankenstein command/data bus for graphics data over multiple gpio ports. It would need either the bare metal kernel on the other side changing to remap the incoming requests to something like libsdl/liballegro graphics primitives which would in turn render using the Arm Videocore GPU and output on HDMI, or use one of the real-time Linux kernel patches applying so that it would boot to a single running 'gpu process'.

I suspect using gpio as a parallel bus would be faster for data transfer, but my guess is that there is probably an ecb card already designed with an i2c or spi interface that could be leveraged and most of the time would be spent loading assets into vram initially anyway, rather than sending 'rotate', 'draw line' type commands.
Re: ECB VGA framebuffer? [message #6820 is a reply to message #6818] Thu, 21 November 2019 08:33 Go to previous messageGo to next message
Andrew B is currently offline  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 #6821 is a reply to message #6820] Thu, 21 November 2019 08:43 Go to previous messageGo to next message
jpstmuk is currently offline  jpstmuk
Messages: 5
Registered: October 2015
Junior Member
Interesting; I've been seeing references to the Prop2 in my searches - it seems to have been stuck in development for some time, but it does appear to be coming out on the other side now.

In the meantime, I've just asked Will for one of his ECB-USB-FIFO boards and I'll see what kind of progress I can make coaxing a Mark IV to speak SDL-style commands over the USB link. Should be fun!
Re: ECB VGA framebuffer? [message #6823 is a reply to message #6821] Thu, 21 November 2019 23:05 Go to previous messageGo to next message
Andrew B is currently offline  Andrew B
Messages: 467
Registered: October 2015
Location: Near Redmond, WA
Senior Member
Administrator
Propeller 2 is real now - Parallax has approved the latest Rev B for production, they plan to order 10,000 chips in the first batch, will be in in about 6 months or so - see https://forums.parallax.com/discussion/170809/p2x8c4m64p-app roved-for-production

There are a few (49 of of this post) official Eval boards with Rev B engineering sample chips left on the web store - https://www.parallax.com/product/64000-es

Also 4-packs of Engineering Sample chips - https://www.parallax.com/product/p2x8c4m64p-es-4

[Updated on: Thu, 21 November 2019 23:06]

Report message to a moderator

Re: ECB VGA framebuffer? [message #6839 is a reply to message #6823] Mon, 25 November 2019 01:16 Go to previous messageGo to next message
jpstmuk is currently offline  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(Wink 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?
Re: ECB VGA framebuffer? [message #6860 is a reply to message #6839] Fri, 06 December 2019 11:39 Go to previous messageGo to next message
etchedpixels is currently offline  etchedpixels
Messages: 333
Registered: October 2015
Senior Member
The challenge with serial is overruns. I've got a bunch of various 'smart' serial to LCD drivers, some of which can talk back about buttons etc and none of them are totally reliable because they don't have full flow control and proper serial behaviour. So whilst they are allegedly 'serial' they are actually only usable properly with I2C.

Z88DK has a general CP/M library implementation and uses a slightly tweaked SDCC. It generates Z80 code so isn't portable to all CP/M. For most of it have you considered just writing an API description and a python script to output the bindings for it ?

I'd much rather have a 'real' period VGA card. I've been looking into the NEC 7220 / Intel 82720 / Zilog Z7220A but still haven't figured out enough of it to turn it into a VGA card. It can do it - indeed there were early VGA cards using it, and in theory it can do 1024x768 VGA mono.

Re: ECB VGA framebuffer? [message #6861 is a reply to message #6860] Fri, 06 December 2019 12:43 Go to previous messageGo to next message
jcoffman is currently offline  jcoffman
Messages: 332
Registered: October 2015
Senior Member
etchedpixels wrote on Fri, 06 December 2019 11:39


I'd much rather have a 'real' period VGA card. I've been looking into the NEC 7220 / Intel 82720 / Zilog Z7220A but still haven't figured out enough of it to turn it into a VGA card. It can do it - indeed there were early VGA cards using it, and in theory it can do 1024x768 VGA mono.


There is an obsolete N*VEM PBWiki board using the NEC 7220: "ECB uPD7220 GDC" indexed here:

https://retrobrewcomputers.org/n8vem-pbwiki-archive/0/358453 34/48860720/index.htm

There are several screen photos from those of us who tested the v1 and later v2 board. Look for the .JPG's.

The graphics could be driven to 800x600, 16 programmable colors. However, we never figured out BITBLT for this controller. A/N display might be possible using chip hardware, although with little interest in the card, the project was dropped.

Finding working UPD7220 chips was a problem. I sourced five; three of which were DOA.

--John
Re: ECB VGA framebuffer? [message #6976 is a reply to message #6861] Fri, 31 January 2020 21:38 Go to previous message
Andrew B is currently offline  Andrew B
Messages: 467
Registered: October 2015
Location: Near Redmond, WA
Senior Member
Administrator
I bought an entire tube of 7220's from Quest Components at one point and then never built a board to use them.

They are untested but if anyone is interested I'd be happy to sell a couple off to a good home for a reasonable price.

Or maybe there is some kind of a simple 'aliveness' test I could figure out on a breadboard to test them.

I just moved my office into a larger room in the house so I'm hoping to get my retro stuff that has been in storage the last year or so unpacked!
Previous Topic: Hello
Next Topic: Mini 8080 SBC?


Current Time: Thu Mar 28 21:56:35 PDT 2024

Total time taken to generate the page: 0.00927 seconds