Retro Z80 project: Memory Layout and software management

[bson]

However you wouldn't design any Z80 system with a pixel mapped graphical display which needed block moves for scrolling - at the very least you would design the graphics so that a start address for the frame buffer can be specified, scrolling then just becomes a question of updating the start address.

This is certainly true.  A Z80 isn't viable for VGA graphics operations, except for very very limited use cases.

One possible design to put e.g. 512k VRAM in its address space is to put aside a 4k region that can be mapped as separate read/write windows onto the VRAM. Map the 12-bit window using a pair of 8-bit registers, one for reads and one for writes, to form 20-bit VRAM read/write addresses and it can fit 1MB.

If you only have 512k VRAM then put a 512k EEPROM in the upper half and use it to implement overlays by copying code into the remaining 60k of address space.  Z80 era CP/M compilers will know how to emit overlays, although it imposes a tree code structure.  At reset the EEPROM can be used in lieu of main memory for startup, which copies a boot image into main memory and unmaps the EEPROM.

That's a ridiculous amount of work and logic though, only to create something that's pathetically slow yet neither useful or authentic...

[Ian.M]

As I said: its *VERY* attractive to use something like a $5 Raspberry PI Zero, to provide graphics, bulk storage and even the keyboard interface.  If you don't want to go the full FPGA route, the basics would just be a dual port RAM and an interrupt line in each direction for handshaking.   Even with 'vanilla' non-programmable glue logic, that's easily achievable.

[westfw]

its *VERY* attractive to use something like a $5 Raspberry PI Zero, to provide graphics

Yes, this is what happens when I think about designing some sort of "historical" system.  "x is pain to do in logic.  I know!  I could use a modern microcontroller to do X!  Wait - now that I have a modern microcontroller, why was I trying to design a YYY based system, again?"  In addition to providing an easy solution for graphics/storage/keyboard, an RPi0 can probably emulate most legacy z80 systems in faster than real time...

(So I have yet to get around to building a legacy system :-( )

(There's also the "Wouldn't it be fun to enter a program on front panel switches, like in the old days?  Sure it would!   No, wait.  I actually did that once.  It was NOT fun... :-( )

[Ian.M]

That is why building a retro computer should only be contemplated if you are interested in the hardware implementation.   A Linux SBC is a cheap crutch to get your retro system working sooner and more easily than you would otherwise.  If you make it modular with a backplane, you can move towards an entirely retro system step by step, though %DEITY% only knows where you are going to find a Shugart Technology ST-506 in good working order!

[grumpydoc]

though %DEITY% only knows where you are going to find a Shugart Technology ST-506 in good working order!

http://www.ebay.co.uk/itm/NEC-D5124-ST506-MFM-HARD-DRIVE-10MB-fd1c15-/400990411216?hash=item5d5ce419d0:m:mNRM6eNxFmS6hvkiqfmaWPg

You just knew, really, didn't you, that it would be ebay

[Ian.M]

Uh Oh!  Unfortunately the NEC D5124 was first shipped in  1983.  That's a bit of a downer if you are shooting for the heyday of S100 bus Z80 systems just before the launch of the IBM PC in 1981.   

However, on the up side, NEC still have a support page for it!  O0
https://support.necam.com/legacy/harddrives/d5124.cfm

[C]

Why not just put a SCSI-1 interface on it and use it for all IO.
Can be very fast and yet you do not have to worry about loosing data.
You have command / data separation
Terminals, printers and more have been connected over SCSI
Has been used as a small network between computers.

Can be very simple in logic

[miguelvp]

Well, I did buy some of those chips bson mentioned, not for a Z80 and I do get they'll be a bit of a pain to get them working on my PSoC chip.

But for the price they are pretty good, you can use the same address space to get 8 bits with two of them, one upper nibble the other one lower nibble. Put two and you got a double buffer, that is handy even if the memory is already double ported.

Well, just took a glance at the datasheet before I bought them, still they might bite me to get 8 of those chips.

[Bruce Abbott]

V9958

what do you think about realizing a PCB ?

V9958 has 1.78mm pin spacing so it will definitely need a PCB. My intention is to make a daughter board with DRAMs etc., and a connector with enough pins to interface to the CPU board. I am thinking stackable boards with a single row of 0.1 inch pitch pins on each side, or a double row connector on one end, or... so many choices!

I have had enough of manually wiring boards (just spent several hours trying to track down a bug in my code, only to find that I had wired the UART reset signal to the wrong pin!). From now on I will design all my circuits with Eagle CAD and have the boards made by OSH Park. Turn-around time from OSH Park is 2-3 weeks, but I have so many other projects to work on that the wait isn't an issue.

[legacy]

V9958 has 1.78mm pin spacing so it will definitely need a PCB

of course, even if adapters to 2.54 are available: I to not like them at all and I prefer a PCB with 4-6 DRAM installed!

My intention is to make a daughter board with DRAMs etc., and a connector with enough pins to interface to the CPU board. I am thinking stackable boards with a single row of 0.1 inch pitch pins on each side, or a double row connector on one end, or... so many choices!

I'd like to conclude my two VDUs, the first is VHDL, the second is V9958. Just them!
The target is a 68000 board I have already built, even if it needs a lot of improvements.


Currently I am busy the the TAP, which is a mixage of VHDL + hardware staff + firmware stuff + C code
I hope to conclude a mile stone by the end of this yeas & probably I will not respect the deadline 

I have had enough of manually wiring boards

good!

[westfw]

Dual port (parallel/serial) memory chips, cheap: http://www.ebay.com/itm/8-TC524258BZ-80-DUAL-PORT-VIDEO-RAM-256Kx4-512x4-150-30ns-5V-ZIP-28-DRAM-VRAM-/271632014082?hash=item3f3e879b02
I don't quite understand how they're supposed to work; it looks like the address pins are shared.  (IIRC, the "serial" access loads up an address normally, and then gets consecutive addresses piped out the serial port at each (separate) clock for "a while."  But wow, there are a lot of different cycle types in that datasheet!  I don't think I ever quite figured out all the possibilities in between "software refresh" and "use a DRAM controller built by someone else.  (I didn't have to!))

[legacy]

@Bruce Abbott
I have created an Eagle cad library, the V9958 is burned in!

I just guess about the CRT signals as this chip need something able to follow H & V synchronism, which are not VGA compliant
and it sounds like jam as I do not have such equipment.

[legacy]

DRAM controller built by someone else.  (I didn't have to!))

ummm, fpga + dram (~ papilo/pro ?) sounds like keep getting better in VDU project
( mine is coming for xmas )

[Bruce Abbott]

this chip need something able to follow H & V synchronism, which are not VGA compliant
and it sounds like jam as I do not have such equipment.

Yes, it is a problem with most of these retro video chips. You need a scan doubler or upscaler. My solution is the Gonbes GBS-8200 upscaler, which sells for less than US$20 on eBay. Like most upscalers it has artifacting issues with non-interlaced video. I made a little circuit for it that bypasses the normal controls and loads configuration data directly into the upscaler chip.

     

[legacy]

excellent!

and you have remembered me when I opened this topic a while ago

[obiwanjacobi]

This excerpt made me think, you do have access to the memory half of the time if you don't use DRAM...

Now what could I do with that... 

[Ian.M]

IIRC You only get one refresh per M1 instruction fetch cycle.  That means that if you need the maximum memory bandwidth consistently, the Z80 must only execute 4 T state instructions for the length of the transfer.

[grumpydoc]

IIRC You only get one refresh per M1 instruction fetch cycle.  That means that if you need the maximum memory bandwidth consistently, the Z80 must only execute 4 T state instructions for the length of the transfer.

You are correct but the scheme presented does not requite that only 4 t-state instructions are executed.

The video controller used uses a double 80 character row buffer, the data in each row is used repeatedly to drive the character generator - so the data only needs to be refreshed every n scanlines where n is the height  of the character cell.

Assuming an 8x8 cell this means 80 bytes every 512us - the longest Z80 instruction (on a quick recheck) is 23 t-states (RES (lY+d)*)  so 6us on a 4MHz Z80 - 6x80 is 480us so just enough time** even in the worst case.

* But IIRC you get two M1 cycles with the index reg operations.

** However *some* time will be needed to set up the registers for the transfer

It's a bit of a hack, means you can't use mode 2 interrupts because you need to use the I register to form A₈-A₁₅ during refresh cycles and each character row will have to start on a 128 byte boundary because the R counter is only 7 bits and odd things will happen if it overflows during the transfer.

[stmdude]

I've skimmed the pages of this topic, but I couldn't see _what type_ of graphics you're planning to display, as the "optimal" solutions vary quite a bit.

If you want to be able to do completely bitmapped graphics (think home-computer), you're sort of on the right way with mapping video-memory into the systems address space.

However, if you're looking to display text or old-school 2D game graphics, you're just getting yourself into unneccessary trouble by doing this. By old-school 2D game graphics, I'm talking about stuff you saw on the NES or Genesis/MegaDrive.
The way they approached it was to have a very early version of a discrete graphics card, with its own memory, that you uploaded data to (through MMIO or regular IO), and then told it to basically "put graphics A at position 0,3" by use of a tile-map.
The concept of tiles is explained in the following video:


Andy Brown did something similar as well, using an FPGA to be the discreete graphics card, and an STM32 as the main CPU. He has a very good writeup here:
http://andybrown.me.uk/2014/06/01/ase/

Oh, and the tile-map concept works very well for (monospaced) text as well.

[rrinker]

 C got here first with the TRS-80 stuff (I had a 4p). That ROM file made for some interesting hacks - also the 4p could be booted over the serial port. I don't think the video memory was bank switched out, but I just tossed my set of technical reference manuals. There was also a "hi res" graphics board, but it wasn't full VGA, I think it was 640x240. That had its own video memory and display chip. That's the one option I never had, instead I had the Dotplot program which allowed you to make hi res graphs of math functions by individually addressing the print solenoids in a dot matrix printer. Quite clever.
 Having that full 64k available made it possible to run all sorts of operating systems. Being able to run CP/M and the version I had's capability to read and write any disk format the drive was physically capable of helped save a lot of time in my intro Comp Sci class in college, which involved 8080 assembly, it it proved the conduit to get my first terminal emulator onto my first MS-DOS machine.
 Very interested to see how this turns out. Another interesting bit (but I do not have the link on my iPad) is a fellow who built a Z80 system in an Altoids tin.

        --Randy

[miguelvp]

Actually with the project I'm working on and posting in here:
https://www.eevblog.com/forum/projects/no-bitbanging-necessary-or-how-to-drive-a-vga-monitor-on-a-psoc-5lp-programmabl/

The prototyping board has plenty of GPIOs left to read a dual ported frame buffer to act as a display card. Or even use some serial protocol including USB.

I'm expanding from the CGA proof of concept I did a while back:
https://www.eevblog.com/forum/projects/make-use-of-an-old-cga-monitor/msg697201/#msg697201

That proof of concept can drive an old CGA monitor with just 7 pins since they are TTL level so no external DAC required:



But before I moved to CGA I was working with a VGA monitor:


The sprites came from finding an image on the internet, organizing it and writing a program to produce the file format I needed to fill in the PSoC 2KB EEPROM.

So on the ongoing project I'm just planning to do a CGA palette but if the frame buffer is enough it can do 3 bits per color (512 total) using that cheap VGA module.



Or even drive this 8 bit per color DAC, but unfortunately the PSoC module can only reach 80MHz with a very precise external OXCO, but with a good XTAL  it probably can achieve video modes  that require 75MH pixel clock, the good color DAC can reacy 330MHz but not the Cypress board.

https://www.eevblog.com/forum/microcontrollers/ov5640-hack/msg446190/#msg446190

This is the board:

But it used 31 pins plus ground, not sure how many were absolutely necessary

FPGA connectivity shown here, never tries that module on the prototyping board (yet)



Edit: BTW my dual port video ram arrived, all 8 64Kx4bits or 512KB worth.



And yeah, I edited this just to show off the book behind the chips

What can I say I started with the ZX81 but the Spectrum is my turning point. Wrote an assembler and emulator for PC, even an assembly program to read the tapes on the old IBMs that had Cassette Din ports on the back.

Oh and the z80 emulator could debug too.

[obiwanjacobi]

Hehehe, I had that book too 

For now I have parked the video memory problem in my design. The reason I brought it up was because I thought that perhaps there were design choices for banked memory and video memory that interfered. And there are and they do but in the spirit of "small steps, Elly" (Contact) I decided to get a basic Z80 system running first. Progress so far is that I have a running Z80 NOP-test circuit and have started to put down the schematic and thinking about the system in a little more detail.

The discussions here did make me more aware of potential pitfalls and alternate solutions. During researching the video options I ran into the series. A very small but very powerful (so it seems) graphics generator chip that may be an option.

However, I still am not entirely sure on how to partition the memory banks (4k/8k/16k/32k??) and how to let the software deal with that. Also in light of a future file system, how are files loaded that are bigger than the memory page? How do you manage that etc. That is still a big question for me.

[Ian.M]

Unless one of your primary interests is recreating legacy graphics systems, I believe most of the non-hosted graphics options to be a very large amount of work for not that much gain.  The FTDI EVE 2 is just offloading the graphics to a custom processor - conceptually not much different to using a host computer or a nintelligent serial terminal.   However its QSPI interface isn't well suited to the Z80 bus without quite a bit of glue logic.

One of the suggestions I made - to use a fast '486 era cache RAM for page translation would be capable of multiple page translation tables that could be switched with a single OUT instruction.  That combined with a 4K page size and separate read and write mapping gives you the most flexibility.    How to deal with it in software - well if you are running the system 'raw' with no OS, you simply page in program or data memory as required.  Done right, execution can continue from the instruction after the paging OUT in the new page, or you can have a paging routine you call (probably via a RST) that reads the page, and address to call from inline data bytes after the RST, does the paging, calls the routine in the new page and on return, reverts to the previous page, fixes up the stack to skip the inline data and returns to the main program.   If you are going to run CP/M+ or MP/M, then you need to write a BIOS for it to provide compatible paging routines.

Perhaps you could expand on the subject of your concerns regarding the filesystem?
I don't see any great issues with writing a routine to read N sectors from bulk storage and transfer them to contiguous locations in physical memory.   

[legacy]

you can look @ gameduino2, i comes with an LCD and it uses a custom GPU, with a serial interface!

[obiwanjacobi]

I think Gameduino also uses an FTDI EVE chip...

I get how to switch the memory page, both in hardware and software. I get how to read a file - that is not the issue. What I don't get is how big to make the pages and what the pro's and con's are for the size and how to manage a program that is bigger than the memory page size. I cannot see a way to make that work elegantly without imposing a whole lot of restrictions on the program itself. Or what all of those restriction are in the first place.

I think this also has to do with the fact that it is very hard (almost impossible) to write relocatable code for the Z80 unless its a very small program..? So there have to be fixed start addresses for the programs (which is fine) but I would like them to be page agnostic.

[Progress - a bit off topic]
The tools (that are any good) I have found so far ar the Z88 Development Kit (z88dk) which provides an Z80 Assembler, a C compiler and a Linker and supports a lot of old Z80 machines (I don't need). But it is pretty easy to re-target. Also found the Small Devices C Compiler (SDCC) which can also be dropped into z88dk.

I decided to use KiCad instead of Eagle because I could not get Eagle to work with a project that is not in its own project folder (which is a totally flawed concept to begin with). But that means I am on a bit of a learning curve for KiCad. Luckily I have found a nice channel with lots of tutorial video's.