pigfx
pigfx copied to clipboard
fbergama
Parallel (8bit) Interface for Z80, etc?
Just found out about this project. Nice work. I believe it currently uses a serial interface to talk to the mcu... But could it be adapted to work using a 8bit parallel interface?
It probably can be done and it's already on my list of things to do in the future. But there's nothing done yet, not even a concept.
OK, do you mind if I throw out some ideas to you? First up, a background: The Pi Zero along with PiGFX would be attached to a Z80 based computer, be it the TEC-1 SBC (search in Wiki to get to FB group) or an RC2014 back-plane computer. There is currently already a expansion board for the RC2014 that uses the existing serial interface of PiGFX but of course it is limited because of speed. So the ideal would be to have a parallel interface along with a number of control lines and address lines. With this sort of setup, the CPU could do fast, sequential block dumps.
Now, I'm not familiar with the capabilities of a Pi at all, so the following could be out of the ballpark so please excuse my ignorance on the subject... But I'll give you what would work for us.
I guess the first question is whether there are enough connectors (pins) on the Pi to allow for 8 data lines, 11-13 address lines and a few control lines? If so, then you could realistically access the memory of the Pi completely randomly. But I'm going to assume it can't do than many pins, so, here is an alternative. I'm thinking it would need 8 data lines, and 3 control lines: _CS, R/W, CTRL
- The CS is an obvious pin: if this is not enabled (low = enabled) then the data/address pins are Hi-z state.
- The combination of the Read (low) and Write (high). Generally, Read means data will be extracted from the Pi, Write means data will be going into the Pi.
- The CTRL pin depending on its state tells the Pi if the data on the Data pins are indeed data (only) or if they are “control codes”. When the CTRL pin is High, it also takes into account the R/W line. If it is in Write mode, then the data on the Data lines are taken as an instruction to the Pi. A control code of “00h” on the data lines would mean RESET to reset the Pi, and you could have any other control codes doing something direct like screen blanking, or maybe even “bank switching” the memory access described below, depending on how much RAM you have spare. Basically you have 8 bits to play with in terms of setting various coes, including maybe the MSB of an address?
However, if the CTRL is High and the R/W pin is in Read mode, this tells the Pi that the data lines makes up an address pointer that it stores for use with your sequential read and write routines. You might have to take in two sequential codes to set a long enough address, depending on graphics mode.
Then, if the CTRL line is low, it works as the sequential read/write memory depending on the state of the R/W pin.
In effect, for the micro (let’s says it’s a Z80) to write a screen full of data would need to: Output to a decoded CS port along with a couple address lines, a single byte of data. Those address lines include going to both the R/W line and the CTRL line, so it would be different “ports” you’d be writing to to get control or data sent to the Pi. After that single control code set by the z80, all future writes to a slightly different port address would sequentially write all the required data. This could also (at a later upgrade) be sprite data to a particular bank of ram in the Pi or positional data for the sprites, etc. Starting with a simple 80x40 (or maybe a few modes) of B&W text to start with would be great. Then follow up with colored (foreground and background) text (with basic graphical characters) and then just keep going. :)
Keep in mind that for a Z80 running as low as a single MHz might want to use this, and so the transfer interface you want to be as fast as possible. Set an address and start dumping!
These are all shooting from the hip. I'm about to order an RC2014 system along with that Pi interface so I'll see what it can do with the serial interface and then be able to comment better on this upgrade.
PS. I just realised the description of the control lines basically matches what your typical 16x2 or 20x4 LCD module uses... And why not? Everyone knows how to talk to one of those from just about any 8-bit computer... So, maybe a starting point would be the controls as per those modules, but just make it act as if it is a 80x40 character LCD :)
Then, start adding different characters and fonts (different resolutions?) and then color information as well. For text colours, allow a byte for the character and then a byte (or two?) for the colour data. Then, in the control codes, allow sequential data dumping to be able to set the jump value over the colour byte(s). I believe the Vera video chip for the Commander X16 project does it that way.
When I started developing PiGFX I also considered that. However, Pi IO lines work at 3v3 and are absolutely not 5v tolerant. So, a level shifter is required to be used with TEC-1 SBC or RC2014.
Apart from that, I think it is possible to implement it.
Yes, I'm aware of that and have already ordered some 74LVC245(8-bit Logic Level Shifter) in anticipation of playing with a Pi Zero. :)
Here is a good article on how the LCD modules work in terms of their 3 control lines:
https://embedjournal.com/interfacing-lcd-module-basics/
And so I would align the control lines I described above to follow established protocols, like this:
RS | Register Select; 0: Instruction Register 1: Data Register RW | Read Write Select pin 0: Write mode; 1: Read mode; EN | A Enable Pin To enable the LCD Module
In my opinion a interface based on this lcd interface would probably be a good choice. At the moment we have 13 GPIO available at the small header and 22 on the 40 pin header. So this is not a problem. I would like to keep the protocol the same as on the serial line, although this is not as fast as possible. The Pi would have to use interrupts for read and write events. This could cause timing problems with usb and ps/2. But it's worthtrying. I also have no idea about the speed at which this would work reliably.
In my opinion a interface based on this lcd interface would probably be a good choice. Thanks for the support.
At the moment we have 13 GPIO available at the small header and 22 on the 40 pin header. So this is not a problem.
Wow, we have THAT many pins available to play with?! We really could go the full monty and be direct memory addressable! (Not saying we should... just that we could. :)
I would like to keep the protocol the same as on the serial line, although this is not as fast as possible.
Not having any experience just yet, I can't comment. That said... We should always try to be as fast as possible. :)
The Pi would have to use interrupts for read and write events.
Couldn't it be polling the three control lines, rather than using interrupts that could affect other operations? Mind you, if interrupts don't affect the other function like USB (which is a MUST) then sure, maybe for the Enable pin, at least.
It's not the intention of PiGFX to access memory directly. It's a terminal emulator with commands to draw complex things on the screen. This is much faster. You only send ascii chars to draw text and a few chard to draw complex graphics. It would not work to poll the control lines as it's unpredictable how long one poll cycle is. So you would probably miss data, read or write too late.
It's a terminal emulator
Honestly, I would prefer to think of it as an "8-bit Computing Video Card". Terminal emulators are really never very clever. How magical was a VT100 terminal? Answer: Like, NOT! Instead, we could make this a universal retro-compatible "video card" that becomes as ubiquitous and easy to use as those LCD modules!
You only send ascii chars to draw text and a few chard to draw complex graphics.
Well, I guess that could be called Mode 0 - Terminal But I'm thinking, with the graphics capabilities I've seen a Pi be able to do, we could aim a lot higher. Bitmaps. Sprites. Collision detection...
It would not work to poll the control lines as it's unpredictable how long one poll cycle is.
Yeah, fair enough... But we really only need one line to be interrupt-driven - the Enable line. The others are set before the enable line is triggered.
You are right. It's only the enable line which needs to trigger the interrupt. I also woukd like to build more advanced graphic features, but also for the serial protocol. There could be different commands for parallel / serial though. Or even a configurable interface behaviour.
a configurable interface behaviour. Yes I think a config.txt file should identify if you will be using it in serial mode or parallel mode. advanced graphic features, but also for the serial protocol. That's the problem with the serial protocol; you can't have anything like sprites or bitmap graphics that move or change too much as updating it is too slow.
We already have the ability to read a configfile. I don't think that serial is too slow for advanced graphics. Once a sprite is loaded you only would have to send a command for placing and moving this object. Would you like to draw pixel by pixel?
Well, some games, like Castle Wolfenstein, are indeed drawn pixel by pixel (called bitmap mode) and this was pretty common.
BTW, it has been brought to my attention that there seems to be a video card/interface that uses a Pi Zero already on the market for the RC2014 system. Not sure how open the development of that board is or what the creator is like in terms of sharing his ideas, but maybe it might be worth contacting him to see how he did it? It's a bit pricey for me right now, but I may end up getting one, to at least try it out.
https://www.tindie.com/products/robdobson/play-retro-games-rc2014-graphics-kit/
I just found the github repository of this project. There are lots of similarities with pigfx. https://github.com/robdobsn/PiBusRaider/
I think I'll get one of these units and see how well and easy it is to use.
(hello, I have been following this thread since the weekend, but had not had chance to comment until now)
Those "graphics cards" are great. They work like a lot of the old school, classic, video output devices. They're memory mapped.
This specific one, when in ZX mode, is pretending to be a non-small portion of the Sinclair ULA. That was a device that 'suspended' the CPU to use the system memory to synthise the display. The RC2014 versions can also use "bus monitoring" to copy the memory into Pi RAM per every write, so not needing to suspend the main bus to access GPU RAM.
We've got an external one, no longer maintained, for a real spectrum that does the same as part of the Spectrum Next project - you can see the source for the Pi side right here: https://gitlab.com/thesmog358/tbblue/-/tree/master/rpi/archive/tkpi/PI_OS
They work, wonderfully, but they have a limited response time of the Fast Interrupt Handler on the Pi, and the maximum speed of the bus - since the Pi can't latch the values written to the GPIO alone, so needs to service the IRQ before the bus changes.
I'm here, right now, mostly to chip in to the question "how well and easy it is", but also be nosey, and be a cheerleader, as "parallel access" has always been an itch for this project I wanted to scratch for me personally, and watching someone else do it is awesome, and saves me one more thing off my wishlist of toys to break ;-)
I see the 8-bit bus text file in the docs directory.
There are lots of similarities with pigfx.
meh, not really, he has hardware accurate bus timings, ie. can push the bus speed upto 50Mhz +. The control interface is a REST API on HTTP running off of the WIFI module (not the RPi), and its written in C++. Its bare metal is based on Circle, with a lot of other stuff in there too.
Yes it can do some of the things PiGFX can do (it has a simple terminal, and a mono vector graphics terminal), but so much more as well (see his "What can you do with BusRaider - Part 1" on his site, there is video too). I'll be using them in combination, not as an either/or solution.
I like the fact PiGFX is (essentially) COMs only, which will work on 99.99 percent of current, future, and original hardware, with only some software need to "program the graphics". (actually I cant think of a system it would not work on).
I come from a different perspective, I have always wanted a native Linux (or Linux for RPi) 256-32bit color console (not just a terminal as xterm is). I have already looked at Kernel sources, have a patch, but it mean "hacking" the termcap files. I also use FBterm (256 color console with background transparency), but it has quirks (like not being Xterm compatible). I want PiGFX as my console terminal at boot.
I see some potential for PiGFX to also provide full VT52, VT102, & ANSI terminals (probably the most common used across most platforms, especially "retro"/8bit platforms). I already looked at the VT300 and Tektronix 4010 before I saw the #39 (Sixel graphics) issue.
The way I see it, the more (full) terminals you add, the more features PiGFX can use/have. ie. VT102 has a total of 6 fontset options (UK/US switched, so 5 actually), line drawing characters, and scroll areas (text windows). VT300 have Sixel bitmap graphics, and REGIS vector graphics. Tektronix 4010 has a native resolution of 4096x4096 vector graphics. There are already a couple of DEC sequences to set specific modes, so hijacking it to set any (major terminal) should be fine. DEC also have an (no longer used) terminal query that could be used to output some details about current (PiGFX) settings and terminal mode.
In my opinion, the current set of features in not "manipulatable" enough and relies too much on being able to remove the sd-card to add/store graphics and change default config settings. That requires better filesystem access (ie. more PiGFX specific terminal sequences). A built in screen and bitmap designer would probably go a long way to helping that (like a re-purposed GFX2 app), once the mouse is supported (has anyone tested a PS/2 mouse yet?). The fact that you can't use a USB and PS/2 keyboard at the same time is also problematic.
The problem with a project like PiGFX is that unless the (main) developer has a need for it, things wont get added. And adding partial support for some terminals will cause more problems in the long term, at least for people who know what they are looking for, or know what type of terminal their system needs.
I hope to get some hardware in the coming weeks to allow me to fill these gaps, and provide some full featured terminals, that will add more (useful) functionality to PiGFX, while porting it to a terminal program for Raspberry Pi OS at the same time.
If people are interested in more bus/interface solutions, there is also the RPi TUBE & RPi specific adapters developed by the Amstrad community (based on the BBC Model B community work). I hope to look at the current 8bit bus a bit too, but I believe PiGFX should not be dependant on it in any way, just COMs dependant. What could be (hijacked?) from the BusRaider project, is the highspeed COMs interface (in the megahrtz range), even if its a daughter project.
If you are wondering where I am going with this (besides specific console for linux/RPi) I see Civilization 1 type game powered by 4Mhz Z80 with minimum of (say) 64Kb (and yes with sound, eg. like the AtariST version), with assets in a subfolder on the sd-card, including tiles (not just sprites). This requires the mouse, and/or keyboard alternate (AtariST uses ALT-arrows).
FWIW, about the only RPi I dont have atm, are the Zero's, and I will have at least 2 for the projects mention here, so I can test on a wide range of hardware, including armv6.
Cheers
Paul
