Retro Z80 project: Memory Layout and software management

[obiwanjacobi]

Z80 boots to $0000. There are several RST (Restart) instructions that call fixed routines between $0000 and $0038. There is the NMI service routine at $0066 and if you use Interrupt Mode 2 (IM2) the I register points to the upper address (A8-A15) where the interrupt vector table is located. IM1 just calls RST$38 (IM0 I will not use).

I don't get why them tying the VDDs together will be a problem. I won't need the FPGA/CPLD anymore, so it can all be 5V.

[miguelvp]

I did look it up, and the Z80 starts at address 0, the NMI forces a jump to address 0x0066, so the ROM can be on the first addresses. Usually on NMI it can fetch a value from a predefined memory address, then load that into HL and do a jump to that address, to keep it simple you can always jump to 0x0000

Hah, was just posting

Edit:
It's not a problem per se, but having the flexibility of having different voltages on the analog or digital plus 4 separate digital I/O domains would give you more flexibility, for example have a two at 5V and the other two at 3.3V and be able to level shift within the SoC, or even put a 1.8V rail if needed.

But I guess it's better they did that because otherwise the user will have to take care of having the right power rails defined.

[Bruce Abbott]

Which is fine if copies of AMSDOS can be had online and there is enough documentation to port it to new hardware.

Unlike some other contemporary machines the Amstrad's OS was properly designed and documented. The system ROMs have also been disassembled, and there is an excellent simulator for it which includes a macro assembler and debugger.

ROMs:- http://www.grimware.org/doku.php/documentations/repository

Firmware guide:- http://www.cantrell.org.uk/david/tech/cpc/cpc-firmware/

Disassembly:- http://www.retroisle.com/amstrad/cpc/Technical/firmware_cpc6128_os_rom_disassembly.asm
                       http://www.retroisle.com/amstrad/cpc/Technical/firmware_amsdos_rom_disassembly.asm

Simulator:- http://www.winape.net/

OS documentation and disassembly listings are worth taking a look at just to see how they did it...
   

[C]

OK, yes I agree you probably don't want to bit bang SCSI and if you can find an interface IC like the NCR 5380 or, even better, the Zilog one those details will be taken care of and it will be a lot simpler.

Might be worth your time to look at web for "Lobo Max-80"
It's a Z80 at high speed that is a TRS80 model III clone but way better or a CP/M3 machine.  Note that it has one rom of 512 Bytes that can boot from 5.25,8 or SCSI

SCSI-1
All pins on SCSI-1 are open collector drivers like 7406.
SCSI is bidirectional buss so you have inputs/outputs for all signals.
You could think of this as a modified parallel printer port.
Good Printer hardware would have a 8- bit status port and a 8-bit output port that is latched. Where a printer port uses a one shot that is triggered on output latch write, SCSI uses a FF ( SCSI ACK ).
This output port has two addresses so A0 can change and is latched with the data (SCSI C/D ). Using one address you have Command level due to A0 while second address changes A0 to Data level. Very simple 9-bit output.
When a device on SCSI bus reads the data the FF connected to SCSI ACK is reset.
You have 2x 244, 2x 273, 74 & 7406's

The nice thing here is the easy add of the C/D signal so that you can have two types of data & the hardware handshake.

I thought SCSI-2 was mostly about the move to wider busses which probably isn't all that useful for a Z80 system.

Sorry SCSI-2 is on two hardware versions "Fast SCSI" is 8 bits @ 10 MBs, "Fast Wide SCSI"  is 16 @ 10 MBs"
Note that there is many ways to go from 8 to 16 &  16 to 8 and be fast.

Did TurboDOS have subdirectories? - That was the biggest thing I disliked about CP/M

There is some bits stored as the high bit of filenames. The directory actually contains subsets. See CP/M3 & TurboDos for this.
With large hard drives, fairly common to have a utility to select different areas.
The utility program is mounting an area of hard drive as a drive letter like you changing floppy's..

OK, yes using SCSI to talk to a Raspberry Pi front end would certainly be doable and flexible.

But as far as I am concerned I have absolutely no interest in hooking a Z80 to an RPi and having the latter just act as an I/O processor for the Z80. This is totally a personal view, of course and everyone is different but were I to built a Z80 system I would want it to be able to stand on its own feet.

If you can do all and can have a total of 8 counting the Z80 then you have a lot of choices. One is use very little or use less over time. You could let the Z80 pick what.
In place of USB to serial where you add a serial port to Z80 at fixed speed, you could have a processor doing this function and no serial port on Z80. This processor could then give you a lot more. How about a Debug terminal and printer port. Could act like a Flash drive making a file move easy.

What about a quick and easer interface to "SD cards"? Newer controllers make this easer and cheap.
 

That said I would probably set p a Z80 emulator running CP/M to do development work for the target.

There is a Z80 emulator running TurboDos.

@obiwanjacobi
This may help you some.

A processor like the 68K which is 16-bit wants two parallel banks of 8 bits so that it can write a byte or two bytes.
To match up with a Z80, The Z80 would be using A0 to select a bank.
If you think of what then happens to memory, the Z80 would be switching banks as the instructions are read. A 16-bit operation would use one bank then the other.
If you are wanting to have dual port memory, you just opened a 50% window.

Said a different way your two 64kx8 chips would have memory A0 connected to Z80 A1 and so on for remaining address lines. Z80 A0 would become part of memory CE. The 68k would use the 16 data in parallel and to be compatible with this, The Z80 would need an additional transceiver. Staying 8-bit wide the transceiver would not be needed.

This can be used many places. Going wide with cache is a help in increasing memory speed.

[grumpydoc]

Might be worth your time to look at web for "Lobo Max-80"
It's a Z80 at high speed that is a TRS80 model III clone but way better or a CP/M3 machine.  Note that it has one rom of 512 Bytes that can boot from 5.25,8 or SCSI

Some of my earliest programming was on a TRS-80. Sadly I never developed much love for the machine.

SCSI-1
[.....]

If we'd been having this conversation 25 or 30 years ago I would have agreed that adding a SCSI interface was the right thing to do. I started to try to design one for my Nascom but never finished it.

Today, I think we will have to agree to differ on this point.

Did TurboDOS have subdirectories? - That was the biggest thing I disliked about CP/M

There is some bits stored as the high bit of filenames. The directory actually contains subsets. See CP/M3 & TurboDos for this.
With large hard drives, fairly common to have a utility to select different areas.
The utility program is mounting an area of hard drive as a drive letter like you changing floppy's..

I never used CP/M3 - it came just a bit after I'd moved on from Z80 systems but looking at the CP/M3 documentation it looks as though it is no different from CP/M 2.2 - just one directory per disk.

I think it would be worth listing the alternatives.

OK, yes using SCSI to talk to a Raspberry Pi front end would certainly be doable and flexible.

But as far as I am concerned I have absolutely no interest in hooking a Z80 to an RPi and having the latter just act as an I/O processor for the Z80. This is totally a personal view, of course and everyone is different but were I to built a Z80 system I would want it to be able to stand on its own feet.

If you can do all and can have a total of 8 counting the Z80 then you have a lot of choices. One is use very little or use less over time. You could let the Z80 pick what.
In place of USB to serial where you add a serial port to Z80 at fixed speed, you could have a processor doing this function and no serial port on Z80. This processor could then give you a lot more. How about a Debug terminal and printer port. Could act like a Flash drive making a file move easy.

What about a quick and easer interface to "SD cards"? Newer controllers make this easer and cheap.

As has been observed this would have to be a "for fun" project and everyone's idea of how to do it will be different - and mostly equally valid.
 
If I were to implement a Z80 system today, just to play with one, I would want it to be fully stand alone. Using an FPGA for serial I/O or even video would be fine but using a vastly faster general purpose SBC as a front end just would not feel right - however useful it might be. It so happens that I would not have a clue about using an FPGA so I would go down the discreet logic route.

I would, almost certainly look at one of the more modern Z80 lines such as the 64180, Z180 or ez80 though, together with modern high density SRAMS It should not be that difficult to build a system which would run rings around anything that could have been built in the 1980's without loosing the "genuine Z80" feel.

[BloodyCactus]

well talking scsi + z80...

Zilog was a second source for the very famous NCR 5380 scsi chip. Zilog ones come in PLCC or DIP! Its a full SCSI controller in a chip. It does afaik 3mbs? can still get these chips all over ebay etc. a very very popular chip. lots of documentation around for them.

[C]

With a NCR 5380 or some other scsi controller,
What do you gain and what do you lose or has greater cost?

A write sector to a scsi device is two blocks of data with the C/D signal changing between the two blocks. The C block(command block) is different sizes and is often in different area of memory from where the D block(data to write) is located.
Not hard to do in software but if DMA is used is two DMA transfers with something to change C/D state between the two.
So from the very simple hardware where processor does it all, you start adding the controller init code and then even more code to remote control the controller.

For what I am trying to say, you do not have to match SCSI, just a lot of it's capabilities.
9- bit data or hardware way of separating 8-bit data into at least two categories.
Send bidirectionally with speed control to prevent overruns.
Multi-host, While this sounds complicated, it can make things a lot easer and faster. 
The SCSI controller chip can make some parts a lot slower. It was built with delays for long cable connections.
Think of all the ways that this can be done easily with low software overhead. Async 8-bit serial has been used to send/receive Ethernet or IP packets, but has a very high software overhead to do it. Sync serial with it's bit stuffing makes this easy.
Todays fancy async serial controllers make sending 9-bit data hard and has limits. With some of the initial serial controller chips this could be easy.
It's the idea, scsi  just contains the parts needed for a parallel buss.     

[BloodyCactus]

well, I never brought scsi up to begin with, but if someone is going to start messing with scsi and try to implement it, I was just pointing out you can get nice friendly pinout (plcc/dip) chips that handle the scsi interface. and hey, even zilog got on the 5380 bandwagon. personally, I wouldnt try and bitbang scsi, like I would not try and bitbang gpib. interface chips exist to help simplify using the protocols.

[C]

BITBANG
Shows one difference of a micro controller and a microprocessor. With a microprocessor you have two nice signals that happen when a port is read/written that can be used.
With a micro controller you have to bitbang a parallel printer port.
With a microprocessor and good hardware you just write to parallel printer port, hardware does the strobe.
scsi & gpib were built to work with simple 8 bit microprocessors and be cheap in hardware.

[timofonic]

If you manage to do the hardware (In sure you'll finally manage it!), please consider a port of FUZIX. It's a resurrect of a 8 bit by l long time Linux kernel hacker Alan Cox.

 I it's an UNIX-like OS, but 16bit and MCUs are taken in consideration too. There's MSP430 port too.

[grumpydoc]

If you manage to do the hardware (In sure you'll finally manage it!), please consider a port of FUZIX. It's a resurrect of a 8 bit by l long time Linux kernel hacker Alan Cox.

 I it's an UNIX-like OS, but 16bit and MCUs are taken in consideration too. There's MSP430 port too.

Thanks for that link - looks really interesting. I was aware of UZI and even have the source code stashed somewhere but it's a long way from a set of source code to a working system.

[obiwanjacobi]

Beh, I just discovered my Altera Max II (244) is way too small for what I want to do (not in pin count though). Almost completely filled it with the Memory Management Registers (RAM) alone (> 70%).   

[Ian.M]

That's why you should use a '486 era cache ram for the page address translation.  Then all the CPLD has to do is provide the glue logic that lets the Z80 read and write the page translation tables via a couple of addresses in its I/O space. 

[legacy]

the PCB goes complex

I suggest to have a look at Arty board

[obiwanjacobi]

External (to the cpld) cache memory would require for normal operation (assuming 4k pages):

CPU                   MEM       Sys: Mapped Addresses
A12-A15 =>  |            |
MEMREQ =>  | D0-D7 |  => MA12-MA19
RD/WR    =>  |            |

To configure the contents of the cache (assuming same content for RD and WR and starting IO address $00):

CPU                 MEM          System
A0-A3   =>   |             |
IOREQ  =>   |  D0-D7 |  => D0-D7
RD/WR  =>  |              |

(Decoding to Cache-CE not drawn)

That would sort of boils down to that I need to isolate the entire memory chip. That would eat up a considerable number of pins on the CPLD. Is this what you had in mind or am I missing something here?

[C]

First
  switching signals takes time. be good not to have delays like this for normal use.

Look at Instruction

OUT (C), r

C -> A0-A7
B -> A8-A15
r  -> D0-D7

One transiver to connect Z80 D0-D7 to memory chip  D0-D7 durring update
One latch for High address of memory chip
Z80 A15 down to map size direct to memory chip low address


C

[Bruce Abbott]

External (to the cpld) cache memory would require for normal operation (assuming 4k pages):

Sorry if this a dumb question but what exactly are you trying to do, and why do you need 'cache' memory?

[grumpydoc]

External (to the cpld) cache memory would require for normal operation (assuming 4k pages):

Sorry if this a dumb question but what exactly are you trying to do, and why do you need 'cache' memory?

The aim is to extend the Z80 address bus by 4 or 8 bits (to 20 or 24 bits).

To do this you need a fast RAM - I have previously used a pair of 74F189's which are handy as they have separate data in and data out lines which makes connecting it up slightly easier.

But any fast (10ns or so) RAM will do and 256k x 8 10ns SRAMs are readily found as the L2 cache on an i486 or early pentium motherboard.

[Ian.M]

I described the support logic for I/O mapped reading/writing a W24257A 32Kx8 SRAM used for page address translation in some detail back in post #34.  My conclusion was: one 8 bit latch for translation table selection, and one bidirectional tristate buffer to get the data bus to the W24257A data pins during I/O operations to it, + a chunk of glue logic that shouldn't take too many extra CPLD pins *IF* you are already monitoring the whole Z80 bus to implement a fully featured debugger.  If not, you may want to do some I/O address decoding outside of the FPGA.

[obiwanjacobi]

Ah right, I thought it was mentioned but couldn't find the post.

So the IO address for configuring/switching will also be above the 4k address. That would require the use of that one OUT (bc) instruction, but that would work.

I have looked into what cache memory to choose (I could not find the type you mentioned) and obviously need 74F series to keep overhead to minimum (what is the difference between all the octal bus latches with tri-state outputs!?  ).

[Ian.M]

You need to make sure the cache ram you use does *NOT* latch its address bus - i.e. it will operate with /CS and /RD held low, and update its data bus to reflect any address changes.   I suggested the W24257A because it supports this unusual access mode.

You need to check the datasheet of your chosen chip to confirm it does also.

If you add logic to remap the address lines to support easier block loads, use analog switches for minimal propagation delay when in address translation mode.   The 8 bit page table latch and the bidirectional tristate buffer for the databus are not in the direct path for translated address propagation delay, so 74HC logic should be fine.

[timofonic]

External (to the cpld) cache memory would require for normal operation (assuming 4k pages):

Sorry if this a dumb question but what exactly are you trying to do, and why do you need 'cache' memory?

The aim is to extend the Z80 address bus by 4 or 8 bits (to 20 or 24 bits).

To do this you need a fast RAM - I have previously used a pair of 74F189's which are handy as they have separate data in and data out lines which makes connecting it up slightly easier.

But any fast (10ns or so) RAM will do and 256k x 8 10ns SRAMs are readily found as the L2 cache on an i486 or early pentium motherboard.

Are there a list of them? I have a bunch of old broken motherboards and computers getting dust somewhere, maybe there are enough of that to share.

[C]

Found this data sheet for
GLT725608-15J3
http://pdf.datasheetcatalog.com/datasheet_pdf/g-link-technology/GLT725608-12FB_to_GLT725608-20TS.pdf

On page 5 look at READ CYCLE 1  (1,2,4)

NOTES:
1. WE is High for READ Cycle.
2. Device is continuously selected  CE ? VIL.
3. Address valid prior to or coincident with CE  transition low and/or transition high.
4. OE ?  VIL.

A new data output = new address input delayed by Taa time.  Taa = 15ns max
with WE = high, CE & OE = low
This should be what lan.M is talking about

C

[Ian.M]

Yes. that's the access mode you need

Cache RAM in the late 386 to early Pentium era was frequently socketed - 0.3" pitch PDIP - 28 or 32 pin for the cache itself in multiples of 4 and often a 28 pin cache tag RAM.   If your scrap motherboard has socketed chips near the CPU that match this description, put the part numbers into google to see what they are.   Beware of soldered in fake cache on some PC Chips motherboards (almost always accompanied by a soldered in BIOS and other signs of cheap&nastyness).

[timofonic]

15n and 20n? I'm too tired and lazy now, I'll look later and check all my old trash too