Retro Z80 project: Memory Layout and software management

[Ian.M]

The critical limitation on program size is 64K, the Z80 address space as paging aware Z80 compilers either don't exist or are vanishingly rare.

Consider a program that is explicitly coded to be paging aware, and has data structures designed to be accessed via a paging window.   Consider also that one would want a standardised method of accessing system routines, and that due to the Z80 having fixed low memory interrupt and RST vectors, it vastly favours putting system support code in the lowest page.

The resulting memory map will look like this:

0xFFFF ----------------------
          paged user data
          ----------------------
          User program, variables and stack
          ----------------------
          System entry points, ISRs etc.
0x0000 ----------------------

Its fairly obvious that the smaller the page size the less it squeezes the user program area.   It would be possible to extend downwards into the lowest page, but then each program would need its own copy of the system and ISR entry points, which is rather undesirable.  With 16K pages, you'd have up to 32K paging aware programs.  4K pages gets you up to 56K for programs. 

If the intricacies and limitations of writing code for a paged Z80 system don't entirely hold your interest, there is very little point in building one.   It would be much simpler to use an i8088 processor with native access for a 1MB address space and compiler support for it as well.  However I personally find legacy DOS era PCs rather boring but YMMV.   It may well be that a simple 32K RAM 32K ROM and memory mapped I/O Z80 board is all that you really want and need.

[grumpydoc]

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.

It is not harder to write relocatable code for the Z80 than for other platforms - you just need a separate list of the instructions to modify when a code segment is loaded.

I suspect, however, that you mean Position Independent Code (PIC) which is fairly difficult to do on a Z80 because the target range for relative jumps and index register operations is only a (signed) 8-bit offset.

The OP asked about page sizes - I would suggest that 4k is a good balance and can be achieved by mapping the top 4 bits of the address bus. Smaller and it will be too much work to bring stuff into the 64k address space, larger and you loose flexibility.

I would definitely consider writing a CP/M 3 BIOS for your system - you will then gain access to a good volume of existing software (including compilers and assemblers) and the operating system supports a simple banking scheme for extending the memory space.

If you are massively keen to just implement a system and do everything from the ground up for the experience of doing so but want >64k RAM and relatively high resolution graphics I would suggest that a Z80 system is not a good place to start - the CPU poses too many limitations which can only  really be overcome with hacks and kludges.

A system based on the Motorola 68k would make far more sense, and you get a lot more performance at a given clock speed.

[obiwanjacobi]

With 16K pages, you'd have up to 32K paging aware programs.  4K pages gets you up to 56K for programs. 

Why is it not 48k with 16k pages (and 60k with 4k pages) - assuming one bios/system/jump page (which fits into 4k for the last example)?


Ok, So what I need to figure out is how to manage all the memory-page bookkeeping for the program. I would not want to allow programs to switch the memory pages by themselves and use one of the program memory pages as jump page - I think. Indeed I see a RST bios service routine that takes care of that for the program.

I suspect, however, that you mean Position Independent Code (PIC) which is fairly difficult to do on a Z80 because the target range for relative jumps and index register operations is only a (signed) 8-bit offset.

Yes, that is what I meant, thanx for clearing that up. In fact I think the z88dk has support for relocatable code at a fairly hefty overhead of something like 3k! 

I would definitely consider writing a CP/M 3 BIOS for your system - you will then gain access to a good volume of existing software (including compilers and assemblers) and the operating system supports a simple banking scheme for extending the memory space.

Yes, that is something I am considering to start with. But I have not researched the details of that yet. It would actually be interesting to see how CP/M does the memory bank switching (in software).

Also, I have decided to start with a very basic system first - without video for now. So I don't know if and how to fit CP/M onto that yet - but my guess is that I could simply route video-out to serial-out in my custom bios (guesses may be wrong though).

[grumpydoc]

Yes, that is something I am considering to start with. But I have not researched the details of that yet. It would actually be interesting to see how CP/M does the memory bank switching (in software).

All the documentation is online, the bank switching is pretty easy but it's a while since I read through the docs. I haven't actually implemented a CP/M 3 BIOS although I did write a CP/M 2.2 BIOS and it wasn't exactly hard.

Also, I have decided to start with a very basic system first - without video for now. So I don't know if and how to fit CP/M onto that yet - but my guess is that I could simply route video-out to serial-out in my custom bios (guesses may be wrong though).

CP/M just needs single character input/output routines to be implemented - this can easily be via a UART

[obiwanjacobi]

I always have trouble with "here are all the source files" documentation 

[grumpydoc]

I always have trouble with "here are all the source files" documentation 

I would suggest that you look at the information on the web regarding CP/M, your comment suggests that you haven't.

The BIOS is well defined and documented. You were planning on writing your own - it is hardly a more difficult task to write to an existing spec.

There is detailed documentation for what you need to implement here http://www.cpm.z80.de/manuals/cpm3-sys.pdf

Various binaries and source code can be downloaded here http://www.cpm.z80.de/

[C]

A USART as an interface to the world is simple but immediately adds a bunch of problems.

First is the speed problem. What speed, to slow and Z80 waits to output, to fast and you have over run on input. To fix this the best choice is a hardware handshake using the extra hardware lines of USART.

Now you have an 8-bit data stream where all 8-bits are used and want to add control information like this character is red, flashing or is current input location on screen. You now have to funnel more data through the same 8-bit data stream. Simple just went out the window and added a lot of software overhead.

CP/M uses a printer port, You now need a second USART or need to funnel even more data streams through that one 8-bit port.

On top of this CP/M wants some mass storage. Many more 8-bit streams that are based on blocks of 8-bit data. And you have even more control data to select what.

To keep it simple, you need an interface that can separate what is control information and what is 8-bit data and does hardware handshake on a byte level to prevent input overrun while allowing max speed for output.

You can then use the control information to specify what the 8-bit stream of data is. To save software time, it would be nice to not have to pack two or more blocks control data into a single byte. Would also be nice to not have fixed size control or data blocks. 

It's not hard to find this has been done in the past and is still done in the present.

If you are looking at this page then you are looking at an example. The problem is this example caters to human reading adding a lot of overhead for a processor.

In the past for serial links was Synchronous block framing links using HDLC & SDLC. These used hardware bit stuffing to allow known start & end of a block. By knowing the start of a block you can have a simple to decode control vs data.

For very simple parallel interface you have the SCSI interface. This can be very simple for a Z80. If you use two output ports, you can use A0 to specify the control vs data on output. Hardware handshake is a simple FF that is set when these ports are written to. 
For input you could have two ports, One to read status and if the byte is control or data and a data input port that resets the FF on port read.

By using a control block of data, both ends of the link become simpler for software and allow the one link to be what would take many hardware interfaces.

To add to what grumpydoc suggests I would add looking at the IMS Z80 TurboDOS 14 Implementers Guide.pdf
http://maben.homeip.net/static/S100/IMS/software/IMS%20Z80%20TurboDOS%2014%20Implementers%20Guide.pdf

The advantage of TuboDos is that a single Z80 can be whole system like CP/M3 but have option of having one or more systems to assist the Z80.

Looking at the character based I/O shows that a simple software standard can be used to work with many I/O devices.

C
 

[legacy]

how to attach a narrow (8bit)/Single Ended SCSI interface to an MPU ?

[obiwanjacobi]

I will look into CP/M after I have the basic hardware up and running. I did glance at the CP/M documentation but could not find my way in there very easily. Thanks for pointing out the documents gentlemen, that will certainly help.

I will start with a UART for basic IO but that will not mean I will stop there. Already have been peeping into building an IDE interface, which doesn't look so difficult. SCSI may be easier - I don't know- but I do know I have no drives for that. I think I still have a couple of old IDE drives that perhaps I could use.

Anyway, first things first.

[Ian.M]

CompactFlash cards (not CF+) have an interface that's electrically compatible with PATA IDE.  If I was building a retro system, I would rather trust solid state storage than old spinning rust!

[station240]

CompactFlash cards (not CF+) have an interface that's electrically compatible with PATA IDE.  If I was building a retro system, I would rather trust solid state storage than old spinning rust!

Yes +1 to this
Easy to get CF to IDE adapters off ebay for a few dollars. Even cheaper than just buying the CF socket on it's own.

You could also later consider adding an IDE CD/DVD rom drive to the system, so you can have an entire Filesystem image on a CD. the ISO 9660 should be easy enough to understand.

[C]

In place of trying to adapt something newer to the old Z80 and having a mess. Would be much easer and faster to just use a SCSI like interface to connect to something new that you can control.

that one interface connected to something like a raspberry pi would let you have all the I/O you would want.

Going a step further SCSI is multi-host, so you could have a second Z80 & raspberry pi connected. Up to 8 hosts on SCSI-1

In the keep it simple, look at how much I/O you can get by connecting to something in the line of STM32.  The Z80 could then access many serial ports with a simple program on STM32. Do I need to say that one or more serial ports could be over USB to a PC.

An SD card could be the Z80's hard drive.
Would be simple to have the Z80 working with many drives that on other computer is just a file. This keep the operating system on Z80 working.

One simple interface on Z80 that can have simple Z80 software driver and open up the world for I/O.
By having control of both sides of the link, you have control to make it work.

The hardware does not have to match SCSI just need the same ideas in place.. Where SCSI-1 has a bidirectional open collector buss you could adapt the idea to what would be simple at both ends. The advantage of open collector is that many drivers can try to talk and not have a logic fight.
 
Need to keep in mind that what works with current hardware may not work with a slow Z80. You can break software and hardware by being to slow or too fast.

Many I/O devices have a min speed. For floppy drives, you work at this speed or have to add something that gives you a window that will work.

Think of what you may have seen in past. That scanner that stopped and backed up a bit if you did not read the data at speed. How many CD's have been pitched by not meeting the min write speed.

Think of how much software will be needed to just control some of the new devices. If the Z80 is talking with something new that can talk to these devices the software needed just became a lot easer.

Get from the old to something new that is better able to handle the problems while at same time keeping the hardware simple.

[Bruce Abbott]

I will look into CP/M after I have the basic hardware up and running. I did glance at the CP/M documentation but could find my way in there very easily.

CP/M is a horrible operating system. I wouldn't consider it unless there was some specific CP/M application that I wanted to run.

CP/M creates (almost) 64k of RAM address space by loading essential BIOS functions into low and high RAM and then switching the boot ROM out. Everything else - including most DOS commands - is loaded from disk into the TPA (Transient Program Area) starting at location $0100. This creates a lot of disk activity and makes it difficult to have more than one program in memory at once. The BIOS itself can switch in ROMs or extra RAM as required, but this is normally hidden from user programs. 

I will start with a UART for basic IO

Good idea. Even if you upgrade the display and keyboard hardware it will still be useful for debugging etc.

have been peeping into building an IDE interface, which doesn't look so difficult.

IDE is very easy if you don't need DOS compatibility. You can use a simple 8 bit interface, which ignores every second byte and so wastes half the drive capacity - but who cares when you still have Gigabytes available? 

SCSI may be easier

IDE is basically SCSI but with a more friendly bus interface.

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.

The way I did it was to create a set of small subroutines or macros that replaced certain CPU instructions such as LD A,(HL) and LDIR. The only problem with this approach is that the code may be much slower, therefore having an efficient page switching system is very important. It should be able to:-

1. Switch pages in and out with as few instructions as possible. Paging hardware should be arranged so that a single OUT(port) instruction will select the desired page read/write combination. Page select bits can be lined up with the upper address bits, so the high 8 bit register of a 16 bit pair can be sent directly to the port. These bits could map expanded memory into a 'window' while keeping the OS ROM etc. active.  Another paging register could put the mapper into different modes, or select 'special' page combinations that might be useful. 

2. Allow reading from one page combination and writing another without any switching. This can effectively double the base memory addressing range with almost no overhead.

3. Keep track of which pages are currently selected so it doesn't have to switch them unnecessarily, again using as few instructions as possible. The alternate register set can be used to do this. 

Or what all of those restriction are in the first place.

As Ian.M said, the major limitation is the Z80's 64k addressing limit. Any program that wants to address a greater range needs extra code to handle the higher address bits. However in most applications 64k is enough, the problem being how to maximize usable RAM inside that 64k. The OS ROM, system variables, and memory mapped peripherals (eg. video RAM) all eat into that space. The paging system needs to switch all of these out of the way when desired, but still have them available when necessary.   
 

[C]

how to attach a narrow (8bit)/Single Ended SCSI interface to an MPU ?

Look at the interface to SCSI that is in the LOBO MAX-80. Not a lot of chips needed.

If you look back at SCSI-1, it is a simple buss.
Does not take a lot of software to get working at a low level.
You are building up a block of data to tell the device on other end what to do, the control data block.
Each chunk sent over the buss has a control block and a optional data block. The hardware keeps the two distinct by having a 9-th signal. There is no need to mess with 8-bit data to keep control data separate from data data.  By using A0 to generate this 9-th signal, output can be very fast. If you think of the quick tests a Z80 can do to 8-bit data, you can make the input simple. Read a status byte, One instruction gives you 0, Negative or positive. So you can easily test if the high bit is 1,0 or all are 0. A shift instruction and test instruction gets you another bit.
By arranging the bus signals in the status port, you can make it easy and fast.

It can actually take more software to work with that nice fancy SCSI controller. The fancy SCSI controller then puts a lot of limits on what can be done for some gains.
The same is true for working with the IEE488 bus direct or with a controller.

The big problem comes with all the software layers that have been stacked on top of the simple. If you do not have control of both ends then you have to match up to the standard of that device. Do you really need all the layers to function at the Z80 or could the middle man computer do these?

If you have control of both ends then you can create new command blocks to do a function. In place of creating the fancy escape sequences for terminal control that only work with one specific terminal, you could have a simple command block that has the data needed. The middle man computer could then do this work.

You can have a network of 8 computers on SCSI-1 based on that hardware.

The important things that SCSI does is
1. hardware separation of two types of data, With simple hardware this is almost free.
2. This hardware separation lets you know starting point of each by this change.
3. Hardware handshake a byte level.
4. The buss lets more then one host exist. 

If you look back A Z80 most times did not directly control a hard drive. It used the SCSI buss to talk to a (z80)controller the then worked the hard drive.

Hard to find on web these days, there was a lot of different types of equipment connected to buses like SCSI, not just storage like hard drives.

[C]

 Bruce Abbott
Older versions of CP/M were trying to do the best you can on the limited hardware of the time.
You need to think of what the swap is doing. It's a trade of make the operating system larger all the time so that user programs had to be smaller or swap out parts of operating system so that user programs have more space.
Still done to this day in operating systems.
The reloads from disk where cured on many systems that had the hardware to do so. A ram disk does wonders here while keeping ease to change.

If you have the RAM then CP/M3 can keep this in memory.

Would guess that you never saw a large TurboDos system running. Some of the hardware for these were built to be cheap. It did not take much of a hardware change to get very fast. You just have to plan ahead when building the hardware. Each user had at lease a Z80. The better systems had a lot of ram connected to each Z80. Put a bunch of Z80's in a box, and connect the boxes. Easy to expand to a large number of anything in system.

One thing to think about is the need of large memory for data. In the past when you needed more memory then you would have you used a disk drive. If you are trying to use the old Z80 programs the easy thing to do is just use a ram disk or a regular disk drive that has system cache buffer. While the program thinks it's reading a disk, what is actually happening is a memory swap.
Some programs of the time did their own overlays using a disk. 

[grumpydoc]

CP/M is a horrible operating system. I wouldn't consider it unless there was some specific CP/M application that I wanted to run.

Well, umm yes, but.....

If the intent is to build a Z80 based system then what are the options?

TurboDOS has been mentioned which looks interesting but I'm not sure how much work getting a system running would be.

CP/M3 is well documented and there are fairly extensive archives of CP/M software - especially things like assemblers, compilers and emulators - which will all make the task of getting a system bootstrapped easier.

After that? Well, roll your own but to do anything useful you need to do the OS and tools and applications yourself which seems like a lot of work.

Also, crud compared to what? 8-bit operating systems are all a bit crufty if you ask me.

While I can see the point of building a Z80 system from scratch in 2015 - in fact I'm pondering it myself just because I have a lot of Z80 bits in the parts drawer - I can't really see the point of writing a Z80 based operating system.

SCSI has been mentioned - I'm not sure that this is such a good idea either. SCSI-1 was supposed to run at 5MB/s which no Z80 is going to be able to do if you are bit banging an interface. It was an asynchronous interface so might run slower (never tried) but if you are doing programmed I/O on a Z80 with handshake then expect not much more than 20kB/s but the real reason is that there isn't exactly a lot of suitable hardware still kicking around.

Building a simple 8-bit IDE interface makes much more sense so that would get my vote. It's pretty easy, there are lots of notes and schematics on the web and you can hook up to a CF card. In fact it might even be possible to use an IDE->SATA interface and talk to a completely modern drive. Crazy but it might just work; a CF card maks a lot more sense though.

Serial I/O - use the Z80 SIO or a 16550, Centronics - use a Z80 PIO

USB might also be doable using something like the FT245R which opens up quite a few possibilities.

[Ian.M]

That's another reason to use CompactFlash - it has an 8 bit mode.

Thert is no point whatsoever in implementing SCSI 1 as compatible hardware is now vanishingly rare.   OTOH  a GPIB interface would be truly worthy if you have even a small collectrion of test equipment with it.

I still think the best host interface would be a reasonably large dual port RAM to a linux SBC, with a FPGA to manage full Z80 bus access so you don't have to burn any ROMs to bootstrap the Z80 side and to allow you to implement a full transparent monitor/debugger.   That would vastly ease cross-development.

[C]

grumpydoc:
Think your missing the keep it simple while at the same time very expandable.

SCSI has been mentioned - I'm not sure that this is such a good idea either. SCSI-1 was supposed to run at 5MB/s which no Z80 is going to be able to do if you are bit banging an interface. It was an asynchronous interface so might run slower (never tried) but if you are doing programmed I/O on a Z80 with handshake then expect not much more than 20kB/s but the real reason is that there isn't exactly a lot of suitable hardware still kicking around.

The next step pass SCSI-1 is SCSI-2 which has a max of 10MB/s while still the same, just better bus drivers. Both will slow down with out loss of data. If you want to push to a faster speed then the Z80 can do then you need to use DMA.
With proper designed hardware the Z80 can go a lot faster then 20kbs.
My old Lobo at 5.3 meg clock can use 8" DD floppys with out DMA. If my math is correct that is  62.5k bytes a second.

The SCSI interface is faster due to not having the critical time requirement in software.
A good SCSI interface you are not bit banging.

If you control everything connected to the bus, nothing prevents you from defining different control blocks on the bus. 

Just so you know, most CP/M software will still function when using TurboDos as a operating system. TurboDos does add some system functions that programs can use along side of the CP/M system functions. Because this system was built with the idea that each user has a Z80 and all I/O can be local or via a network is the big advantage. Most used the S-100 bus to link the local Z80 users to other processors, but this can be over many types of buses. You are just sending chunks of data over a bus.
One thing that TurboDos adds due to this remote I/O is many different I/O streams. These can be remapped. So while CP/M is limited on I/O ports like the console & Printer, TurboDos allows easy access to a large number.
Now why do you need to recreate the operating system? One Z80 is like your PC while the others look like a mapped network drive, printer, com port. It is a powerful system. By using CP/M or TurboDos drive interface you could have a system drive that exists as a file on something new.
To expand this you could add the capability of block based I/O. This would allow reading and writing files not stored on a CP/M format block device.

All you are really doing is putting TurboDos network data on SCSI hardware bus.
By using one byte in front of this data you can switch formats of data.
1 = TurboDos network data
2 = multi-disk logical block data
3 = Multi-stream Byte I/O
4 = debug byte I/O

Want something new, simple software change on both ends.
 
So just to be very clear
Use the SCSI-1 hardware layer to connect from one or more Z80s to NEW Processor and connect more NEW Hardware to this NEW Processor if needed.
If the NEW Processor is a Raspberry Pi then the SCSI hardware connection would let you tab everything the Raspberry Pi has just by adding some software.



 

[Bruce Abbott]

things like assemblers, compilers

It doesn't make sense to develop software on the target machine if you don't have to. A modern PC can cross-compile much better and faster than a typical CP/M Z80 system could, and you can download code into the target machine in a few seconds. Even burning code into an EEPROM is quicker.

After that? Well, roll your own but to do anything useful you need to do the OS and tools and applications yourself which seems like a lot of work.

You don't have to write an OS from scratch - just grab an existing one and modify it. Developing low level drivers is the hardest part whether you use CP/M or some other OS. The problem with CP/M is you are forced to do everything  the way it wants.

Also, crud compared to what? 8-bit operating systems are all a bit crufty if you ask me.

I have an Amstrad CPC6128. For several years this was my main computer, which I used for cross development on other Z80 based machines. It came with CP/M 3 as an option. The only thing I ever used CP/M for was formatting and copying discs (which was painful if you only had one disc drive, because you had to swap discs several times). Other disc utilities that ran under AMSDOS were more powerful and user friendly, plus you could quickly hack together your own stuff in BASIC. Many ROM-based utilities were produced that provided instant access without having to boot a system disc and then load the application from another disc.

My idea of a good OS is one that boots instantly and is fully functional 'out of the box'. Modern systems have gone backwards in this regard. My PC gets left on for hours because turning it off and on again takes too long. I don't turn my phone off because it takes forever to boot, and I keep 3G turned off because it tries to download updates all the time.
       

I can't really see the point of writing a Z80 based operating system.

The whole concept of a Z80-based system is pretty pointless today - except for fun. I agree that writing writing a whole OS from scratch isn't most people's idea of fun. Luckily there is a fair bit of code out there that can be used as a framework.

My goal is to build a Z80-based 'home computer' style system (like Amstrad, Spectrum, Sega etc.) which does things that weren't practical 30 years ago because it was too expensive and/or time consuming. I don't want to just throw in modern hardware that does all the grunt work, leaving the Z80 as a hood ornament. I do want the Z80 to be in control and working as efficiently as possible, because I love writing optimized Z80 code!
 

[Bruce Abbott]

USB might also be doable using something like the FT245R which opens up quite a few possibilities.

Many peripherals that have been designed to work with modern MCU boards (Arduino etc.) can be interfaced to the Z80, and don't require a lot of CPU power to operate. I am using a CH376 USB controller on my Aquarius, getting 110k Bytes/sec read speed over the 8 bit parallel interface.   

[obiwanjacobi]

We're going pretty much off topic here but I will describe what my thoughts are at this time for the system, in order to direct and scope the discussion a bit.

The idea is to build a modular system on a central bus. I want to be able to add stuff later. I have a Z80 CPU and for now 4x64k RAM - I will start with using only one of those. I have no ROM. Instead I am planning to use an MCU to provide a UART connection to a PC that can download programs directly into RAM. The MCU I am planning to use initially is an Atmel atmega128. It has a ton of IO and an external address / data bus, which means it can act as a smart DMA. The MCU will also provide the initial set of IO peripherals (SPI, UART, I2C, Timers/Counters etc). All the glue logic that is required for memory bank switching, MCU/DMA access, interrupt logic, Debug support etc will be in a CPLD - the Altera MaxII - for now. This is a non-volatile device with around 100 IO pins. It will generate the clock (50MHz?) and divide that down dynamically for the CPU (and MCU?) - meaning I can slow the system down for debugging etc as it runs (I hope that works). Having a programmable logic device gives me all the opportunity to experiment and evolve. Provided that the basic connections are correctly (thinking of having a PCB made).

That is it, that is all that I have for now. I am currently working out the way the MCU will be interacting with the system, most importantly: how new programs are loaded into RAM. The CPLD is a black box for now. I describe what I need it to do but will flesh out the VHDL for that later - have to learn that too.

I hope this gives you guys some idea where I am heading with this project. The goal is not to make period-correct hardware, or not to reinvent the wheel etc. This is a journey full of learning new things and I love to think about stuff like this - that is the goal. Reinventing the wheel gives you great insight in how that works and why - and it will be your wheel. That being said, I also do like to have a project that will eventually work and that is why I try to work in little/small increments. So discussing SCSI or IDE at this point (for me) is pointless other that seeing if I have the correct signals on my bus to be able to extend that later.

But I do appreciate this discussion very much. It has made me see (some) things in a different way. Thank you all for that.

[miguelvp]

I do see one problem using the MAXII, it can provide 3.3V logic while the Z80 and Memory are probably at TTL levels of 5.0V.

On the 4x64k RAM you can use two of those daisy chained and sharing the same memory addresses with one of the chips offering the high nibble (D7-D4) and the other doing the lower nibble (D3-D0) that way you have the full 8x64K.

Using a single chip for the full 8 bit data bus (D7-D0) will mean you have to have them electrically wired together having D7-D4 sharing the same bus as D3-D0. That can of course be done because its all in the timing. And that provides the benefit of having a full 8x32K, leaving your the upper 8x32K address space to be populated at a later time with multiple banks selected via a demultiplexer controlling the chip select of those higher memory banks.
Edit: Actually it will be more complicated to share the 4 bit bus for both higher and lower nibble, you'll need the CPLD to decode that so that the Z80 sees all 8 bits at once. So the CPLD could act as an ALU and manage all the Address and Data lines from the Z80.

Edit: just to note that as I recall, I/O share D7-D0 so if for example you use a port to select the upper memory bank, you have to make sure that is not enabled on regular memory read writes, so it can get a bit tricky  but not impossible.
CS (chip select) pin usually is negative logic. So you have to make sure only one subsystem sharing the data bus has the CS low and that the timings are correct for accessing or writing the data. All that could be done within the CPLD.

For programming the device, you can halt the Z80 or hold it on reset (not sure on the pin details without looking it up) load the memory while the Z80 is not active with the program. And restart the Z80 via it's pins.

The Z80 will start or you can provide the reset irq and fetch the boot address. Both boot paths should take you to the same start path, well not necessarily but just to keep it simple.

I do think the PSoC 5LP prototype kit will serve you for your CPLD and MCU needs including the UART connectivity to the PC in one module. Plus give you expansion for other systems including the VGA controller.

And it can do 5V and support more than one voltage rail acting also as a level shifter if needed. Although I don't know of the top of my head if those other voltage levels are exposed in the prototyping kit, otherwise you might need to spin your own DIP compatible board.

[obiwanjacobi]

Sorry, I have 4 chips of 64kx8-bits (UM61512AK). That is why I said I would start out using only one of them...

From what I can read the Max II is pretty easy with its 5V tolerance...

The Z80 will tri-state its bus on reset and busreq. I was planning on using busreq as a generic way gaining access. I also want to have some debug features that may want to peek and poke into the memory where I could reuse that.

Yes, that PSoC is beginning sound good - although what I have now is very cheap. Also have no experience with PSoC. The idea of the FPGA was born out of having a video output that it would generate. Perhaps time to rethink some of this...

(BTW: Have my first 'hello world' CPLD/VHDL program running, an 8-bit counter.)

[grumpydoc]

grumpydoc:
Think your missing the keep it simple while at the same time very expandable.

I'm trying not to

A good SCSI interface you are not bit banging.

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.

But there is still not all that much stuff around to actually talk to.

The next step pass SCSI-1 is SCSI-2 which has a max of 10MB/s while still the same, just better bus drivers. Both will slow down with out loss of data. If you want to push to a faster speed then the Z80 can do then you need to use DMA.

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

With proper designed hardware the Z80 can go a lot faster then 20kbs.
My old Lobo at 5.3 meg clock can use 8" DD floppys with out DMA. If my math is correct that is  62.5k bytes a second.

I did say "if you are doing the handshake in software".

If you can use INIR a Z80 can transfer one byte every 21t-states or about 190kB/s for the 4MHz part

But if you have anything where you are doing handshake in software it is going to drop quickly - if you need to poll a "byte ready" flag as with most floppy controllers then I make the loop about 60 t-states minimum which is 67kBytes/sec for the 4MHz part.

However for the 2.5MHz part it is 41kB/s, and 33kB/s for a Z80 clocked at 2MHz  - I remember trying to hook a 2MHz Z80 to an 8" floppy and found it impossible. Don't forget that your 5.3MHz part is a "fast" Z80.

If you need to toggle more handshake lines during transfer it will slow down even more.

Just so you know, most CP/M software will still function when using TurboDos as a operating system

Yes, I saw that which increases the appeal, I admit.

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

So just to be very clear
Use the SCSI-1 hardware layer to connect from one or more Z80s to NEW Processor and connect more NEW Hardware to this NEW Processor if needed.
If the NEW Processor is a Raspberry Pi then the SCSI hardware connection would let you tab everything the Raspberry Pi has just by adding some software.

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.

things like assemblers, compilers

It doesn't make sense to develop software on the target machine if you don't have to. A modern PC can cross-compile much better and faster than a typical CP/M Z80 system could, and you can download code into the target machine in a few seconds. Even burning code into an EEPROM is quicker.

See above, mostly - it would be nice if the system could sustain itself.

Given that the sort of programs that one might write on a Z80 system are going to be minuscule by the standards of modern PCs the speed-up might not be all that large.

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

After that? Well, roll your own but to do anything useful you need to do the OS and tools and applications yourself which seems like a lot of work.

You don't have to write an OS from scratch - just grab an existing one and modify it. Developing low level drivers is the hardest part whether you use CP/M or some other OS. The problem with CP/M is you are forced to do everything  the way it wants.

Which is going to be true of any already extant OS.

Also, crud compared to what? 8-bit operating systems are all a bit crufty if you ask me.

I have an Amstrad CPC6128. For several years this was my main computer, which I used for cross development on other Z80 based machines. It came with CP/M 3 as an option. The only thing I ever used CP/M for was formatting and copying discs (which was painful if you only had one disc drive, because you had to swap discs several times). Other disc utilities that ran under AMSDOS were more powerful and user friendly, plus you could quickly hack together your own stuff in BASIC. Many ROM-based utilities were produced that provided instant access without having to boot a system disc and then load the application from another disc.

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

I'm not so much suggesting CP/M3 because I think it is a good OS (it was functional) but because of the resources still in existence.

My idea of a good OS is one that boots instantly and is fully functional 'out of the box'. Modern systems have gone backwards in this regard. My PC gets left on for hours because turning it off and on again takes too long. I don't turn my phone off because it takes forever to boot, and I keep 3G turned off because it tries to download updates all the time.

Amen to that one.
       

I can't really see the point of writing a Z80 based operating system.

The whole concept of a Z80-based system is pretty pointless today - except for fun. I agree that writing writing a whole OS from scratch isn't most people's idea of fun. Luckily there is a fair bit of code out there that can be used as a framework.

My goal is to build a Z80-based 'home computer' style system (like Amstrad, Spectrum, Sega etc.) which does things that weren't practical 30 years ago because it was too expensive and/or time consuming. I don't want to just throw in modern hardware that does all the grunt work, leaving the Z80 as a hood ornament. I do want the Z80 to be in control and working as efficiently as possible, because I love writing optimized Z80 code!
 

Sounds like we actually agree on that one as well.

[miguelvp]

Sorry, I have 4 chips of 64kx8-bits (UM61512AK). That is why I said I would start out using only one of them...

Not a problem I thought you were trying to use a 4 bit chip, but I see that's not the case.

From what I can read the Max II is pretty easy with its 5V tolerance...

Yes it should be tolerant but to drive 5.0V CMOS devices they require a pull up resistor. But I didn't read it fully.

Yes, that PSoC is beginning sound good - although what I have now is very cheap. Also have no experience with PSoC. The idea of the FPGA was born out of having a video output that it would generate. Perhaps time to rethink some of this...

Bad news on the Prototyping kit. Seems they tied up VDDD (digital) and VDDA (analog) together to a common VDD.
Also all four VDDIOs are combined to a single VDDIO, meaning you can't really do level shifting between the 4 I/O domains as it's wired up. But I think you can still level shift between VDD and VDDIO, so you can use VDD at 5V and VDDIO at 3.3V if you need peripherals at that level.

Of course you can always spin your own board, or maybe the freesoc2 (substantially more expensive) has all the power rails separate but I doubt it. I'm on my tablet at away from home so it's hard to look at more details.

As for the software is really easy to use, and you don't even need to write verilog to use their already vast number of premade components. Pretty much you just need to drag them into the canvas and connect them with wires. Those components are also accessible to the Cortex M3 for any software control needs like interfacing blocks via USB to hook it up to your external computer.

It also has 64KB SDRAM that you could use as the z80 memory, or at least to a portion of it, plus a 2KB EEPROM that could hold the z80 boot. I will have to look at more details because it's been a while since I used the z80 to see where the initial boot vector is at in the memory space and where the z80 starts executing on power up. I think it was on the upper memory but in any event it should be easy to map it.

Of course it's not unlimited as in the number of pins available but I think it should be more than enough.
They also have graphical modules to drive LCDs directly (up to  480x320) that interfaces with a graphical library (of course this will take some of the SDRAM)
http://www.cypress.com/documentation/component-datasheets/graphic-lcd-controller-graphiclcdctrl

Balancing things around I still think it will be very flexible and still allow growth for SCCI or other needs, within the pins limits, so optimizing the use might take some doing.

(BTW: Have my first 'hello world' CPLD/VHDL program running, an 8-bit counter.)

Congrats!
[/quote]