PIC and Z80 combo ( too late)

[22swg]

Back in the 1980's I had loads of fun with some Z80 systems / dev boards, the main problem for the DIY builder was getting the start up sw into the memory map, to cut this long story...  I have on my desk a PIC18F   z80 programmer design ( built and working) . the concept allows direct loading / examining of Z80 memory via a PC , (up to 64k CMOS usually battery backed ) programs can be saved / loaded from 32k EEprom or PC byte / file entry , PIC requires connection to the z80 bus (16). operation is via a FTDI serial , Given the age of Z80 (currently using 10Mhz Cmos version ) Perhaps I am wasting my time, I dont have a Z80 application in mind , Just explored the concept.. Opinions please ...   

[danadak]

I think the approach is generally applicable. Using PUC to program Z80
program storage relatively straightforward. The programming algorithms
are usually pretty simple, even when you incorporate error checking. Even
the HV interface usually simple.


Regards, Dana.

[spudboy488]

Intrigued by some of the other "retro Z80" talk on this board, I am doing the same thing for the fun of it. My design will start out simple enough with the Z80 and 64K RAM with an expansion port for I/O. I will use a PIC to load the RAM with whatever code I come up with. I'm still in the initial stages so nothing is built yet but it should be a fun system to play with. I guess the difference between what you are doing and what I plan is that you are programming EPROMs where I am just loading up RAM.

On a side note: What are you using to develop Z80 code with?

[obiwanjacobi]

Nice!

I have a similar setup going on. I used a PSoC5 (dev kit) as 'System Controller'. It has a connection to the PC that runs a terminal program and the System Controller implements a bunch of commands that can be issued from the PC. Stuff like fill-memory <value>, write-memory <file> and read-memory. The System Controller also provides the clock for the Z80 and has commands to slow it down to a crawl for debugging purposes.

The Z80 has 4 banks of 64k (x 8 bits) and a Memory Management Unit (MMU) to map 4kB blocks anywhere into the active Z80 address space. The System Controller also has commands to manipulate the MMU directly.

There is also an Altera Max II (EPM240) CPLD that does all of the decoding for the system (enabling memory banks, control signals for the MMU etc).

I have a blog that I try to keep up to date with what I am doing...

[22swg]

Thanks for replies, The current test bed , is a minimum Z80 with 32k battery backed up SRAM and clock... sorry to confuse but  the EEPROM 24LC256 is used by PIC18F45K22 to hold data ( could be expanded to SD card ) the pic and EE is off the Z80 board , just connects when needed to Z80 data bus + 8 others + 5V ,  at the moment developing memory change / dump / read , routines .

obiwan..... That is some impressive work there , think i will be visiting quite a bit if I continue with the Z80 fun... 

[obiwanjacobi]

Thanx! Been at it for some time now. Been taking small steps, test often, fail early.

[22swg]

part 2 of n .... Way back someone gave me a NASCOM , think my programmers sw is looking a bit familiar ... 

[rfeecs]

Something similar, but 8085 instead of Z80?:

http://mini-altair.tripod.com/

[22swg]

rfeecs  .. like the progression shown on your link , a lot of work no doubt, At the moment I am just interested in the PIC side of the project, my C is not up to much , so its as much about that as anything, I seem to remember I had an Z80 assembler program that ran on a 286 (dos) . 8085 was used a lot in early retail machines , also found one in my Elka E19 Organ... (rip)....

[Howardlong]

I did something very similar about 25 years ago, but with a few LS TTL latches hooked up to a PC parallel port, with some homebrew software to take a hex file generated from a cross compiler and bit bang the parallel port.

The Z80 design used flash shadow RAM from Simtek, now part of Cypress. These are called nvSRAM nowadays. On boot they automatically load the flash into RAM. At shutdown, you can elect to write the entire RAM contents into flash either in hardware or with a software access sequence.

The nvSRAM ISTR I could program in circuit using the BUSRQ/BUSAK CPU pins, and a DIP header debug spring clip on top of the CPU. Possible just a reset puts the busses into tristate, without needing BUSRQ/AK, I can't remember that detail, it was a long time ago.

[westfw]

I've been thinking that a modern microcontroller can replace a lot of parts in assorted "historical" microcomputer designs.
The "front panel" is obvious, and by extension bootloading from various media, but also possibly RAM and EPROM replacement (especially for asynchronous bus designs), even the clock.  (oh imagine the debugging you can do single-stepping a clock on a multi-cycle cpu!)

But then I think that if I have a modern microcontroller, why should I bother with the "historical" processor at all?  :-(

[Rasz]

the concept allows direct loading / examining of Z80 memory via a PC

nowadays this is mostly done in real time using emulation without lifting soldering iron
c64
atari st

[Bruce Abbott]

But then I think that if I have a modern microcontroller, why should I bother with the "historical" processor at all?  :-(

A good point. I guess it depends on what your reasons are for using the "historical" processor . If it's just so you can call it 'retro' like those 'valve' amps with LEDs instead of heaters, then it doesn't matter if the CPU is doing nothing at all.

My reasons for using a Z80 are:-

1. Because I like the simplicity of programming in 8 bits, particularly Z80 machine code which is fun to write.

2. To reproduce the look and feel of real 80's hardware, using the original chips wherever possible.

3. To do things that were impractical back then due to the expense and lack of knowledge, eg. add a hard drive, Ethernet or USB.

4. See if an 8 bit system can be made to do things that were considered impossible 'back in the day', eg. play full motion video.

5. Make a sophisticated  8 bit computer like a C64 or Amstrad CPC with custom chips for video and sound etc., using GALs, CPLDs or MCUs that were not available to hobbyists.

also possibly RAM and EPROM replacement

EPROMS were a pain because they were slow to program and took ages to erase, and static RAM was expensive so we struggled with DRAM controllers and slow memory. Nowadays large parallel EEPROMs and fast static RAMs are cheap. A bootloader is also useful for developing system software (I built an EPROM emulator to do the same job, but it worked off a parallel printer port which modern PC's don't have).
   
But I draw the line at having a 'coprocessor' which actually does most of the work. I want the Z80 talking to an SD Card or high speed serial port for transfering files etc., and not end up writing piles of code for some modern chip (if I wanted to do that then I would just use the 'coprocessor' for everything and not bother with the Z80).
     

[amyk]

4. See if an 8 bit system can be made to do things that were considered impossible 'back in the day', eg. play full motion video.

https://en.wikipedia.org/wiki/S1_MP3_player

http://www.bunniestudios.com/blog/?p=139

But I draw the line at having a 'coprocessor' which actually does most of the work. I want the Z80 talking to an SD Card or high speed serial port for transfering files etc., and not end up writing piles of code for some modern chip (if I wanted to do that then I would just use the 'coprocessor' for everything and not bother with the Z80).

A lot of the "anonymous" Chinese SD card MP3 players are based on an 8-bit core (usually 8051), so it's perfectly possible.... with enough clockspeed. The only real disadvantage of 8-bit is the limited address space, but if you're just streaming bits off a storage device, decoding them, and sending them into a DAC or screen, there's very little memory required.

And an SD card itself may contain an embedded 8051 controller...  https://www.bunniestudios.com/blog/?p=3554