Parallel (8bit) Interface for Z80, etc?

[MarkJelic]

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?

[chregu82]

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.

[MarkJelic]

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.

[fbergama]

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.

[MarkJelic]

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. :)

[MarkJelic]

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

[chregu82]

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.

[MarkJelic]

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.

[chregu82]

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.

[MarkJelic]

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.

[chregu82]

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.

[MarkJelic]

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.

[chregu82]

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?

[MarkJelic]

Well, some games, like Castle Wolfenstein, are indeed drawn pixel by pixel (called bitmap mode) and this was pretty common.

[MarkJelic]

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/

[chregu82]

I just found the github repository of this project. There are lots of similarities with pigfx.
https://github.com/robdobsn/PiBusRaider/