-
Yes, if you can grab the bus, you can do it that way, but a much simpler approach is for the Z80 to run from RAM, bootstrapped by the ATmega328. You need some way of getting code into RAM - but that's just a matter of disconnecting (or inhibiting) /RD to the memory, releasing /Reset + a hardware circuit to assert /WAIT every /MREQ + /RD from the Z80, and signal the ATmega328 so it can stuff a byte on the bus then release /WAIT.
It would send opcodes and data bytes to configure the MMU, and load DE with the desired address to copy to in RAM then stream LDI instructions to copy the desired code into RAM - probably a simple monitor program. For each LDI the write to (DE) taking effect but the read from (HL) actually being supplied by the ATmega328, without reference to HL on the address bus, so one payload byte is transferred for every two opcode bytes. Finally it stuffs a jump instruction and re-enables /RD from memory and disables the /WAIT circuit.
At that point the Z80 is running the monitor, and a PC application can use it to bootload the system with *ANYTHING* from a simple IntelHEX download + FLASH write utility, up to a full CP/M Plus system running from RAMdisk. The PC application can be just about any off-the-shelf terminal program that supports paced sending of text files. -
Your flash rom has a software protect feature to prevent accidental writes.
You should be able to just connect your existing /WR that goes to RAM to your Rom chip with no problems.
You would gain the most power by having the Z80 able to write the Flash Rom.
Now as you are working on CP/M3 BIOS keep in mind a few things.
In addition to the CP/M3 config that will build your CP/M3 system, some systems also have/had a special program that could change some data fields in the working BIOS.
For example, you might boot from one CP/M drive and after running some code or CP/M programs, change the CP/M drive map.
Keep in mind that CP/M has a program that can write to boot/system area.
IF you add the proper drive tables you could have RAM or ROM disks.
You could use CP/M format to put directory structure in place. Then just copy files to new drive.
The only special thing you will need to do after getting capability to FLASH Rom write is a special program to put the power up boot in the highest 16k area. Make your CP/M ROM Drive 16k smaller then top of ROM.
With some good code even CP/M2 can use a RAM or ROM drive.
With CP/M3 capability to run a program on CP/M2 and change to CP/M3 you have a great test environment.
Build a NON-Banked version of CP/M3
Use this to build two more CP/M3 versions
CP/M3 with ROM and/or RAM disk drives.
Banked CP/M3
Banked CP/M3 with ROM and/or RAM disk drives.
For future keep in mind that a CP/M disk drive could be a file or array of blocks on PC or something.
You will gain more by having Z80 write to Flash Rom then Atmega328 writing to Flash Rom
lan.M's post is for
NO CFcard drive in system that is working.
NO Rom in system that is working.
-
Yeah, I like the idea of having some sort of storage media like Compact Flash (or SD card via an SPI interface) rather than using the 328 to completely bootstrap the Z80 with no ROM. Would be great if I could just flick a switch, put the SBC into 'ROM programming'-mode, and stream a new monitor HEX file from the terminal or via the 328 and its USB connection.
All I'd need to do is hold the Z80 in reset, or tri-state its address/data buses with a ~BUSREQ and let the 328 do the rest. The only problem with that system is that currently, the 328 is only connected to the Z80 system via a serial interface to the SIO. I'd need a bigger micro-controller if I want it to be able to take over the address and data buses... -
Not really. Just add a 74HC595 hooked up to the ATmega328 SPI pins. Its output is tristateable so it can go direct to the data bus, then you only need a few more I/O pins for the bus stuffing logic. By stuffing Z80 commands (+ data) you avoid the need to interface to the address bus + can get the CPU internal state if you add a 74HC165 to read the data bus. You can even use it to implement a hardware debugger though it will need two bytes of stack in RAM - add hardware to decode a M1 cycle at address 0x0066 to detect a NMI has occurred, then your ATmega328 takes over and stuffs instructions, the first being PUSH AF with the memory disabled to read out the Accumulator and flags from the bus, then you can push the other register pairs and start shuffling stuff internally to get a full readout. Once you've got the CPU state without affecting RAM (other than the address stacked on NMI entry) you can stuff instructions to manipulate memory or I/O, and disable the stuffer for just the right number of /MREQ or /IORQ cycles for the instruction just stuffed to access the memory or peripherals. To resume normal execution, you stuff POP instructions + the previous register contents to restore the CPU state then stuff a RETN. and disable the stuffer. To implement single stepping is easy - the next /M1 after debugger exit must trigger a NMI. To implement breakpoints is harder - the easiest option for RAM only breakpoints is to put DI + JP 0x0066 at one of the RST vectors, then that RST instruction can be used as a software breakpoint.
-
Ouch.. that sounds waaay beyond my feeble digital electronics and assembly comprehension and skills...
Okay, well maybe I should just focus on getting CP/M 3 up and running for the moment. I'm getting sidetracked by interesting ideas that are ballooning into quite complex concepts (at least to my inexperienced mind!)
-
Why not do the easy thing?
You have CP/M running.
There are many programs that allowed one CP/M computer to talk to another computer and transfer files
file transfer protocols
Kermit
XMODEM,YMODEM, ZMODEM
Some of these are built in to a PC terminal program
TeraTerm is one of many for PC side
-
It should be easy enough to understand. Think about it some more and consider what it would take to feed the Z80 a known sequence of opcodes and data bytes in place of what would normally come from the external memories. If you want to use a smaller ATmega, it needs a couple of shift registers so it can do the Z80 data bus interface via SPI, to save pins, it doesn't hook up to the address bus but does need several control signals and some of them have to be intercepted - do that with analog switches to minimise the propagation delay when the hardware bootstrap/debugger is not in control - and some glue logic to handle some control signals that are too fast for the Atmega to handle in code.
If you want a full debugger, it has to know when the CPU is about to start a new instruction so it can jump in and take over. Its a PITA intercepting NMI by decoding a M1 fetch from 0x0066 as that's 16 address lines, 12 low and 4 high that have to be decoded, but that's the cost you have to pay because you don't have access to an ICE bondout version of the Z80 CPU if you want to do it in hardware. The alternative is for the ATmega to assert /Wait, sniff the data bus for the byte on it then release /Wait till the next /M1 cycle (needs some logic to do that autonomously), while it runs the stream of /M1 bytes received through a state machine that recognises ALL the z80 multi-byte opcode prefixes. When it reaches a M1 fetch that hasn't been modified by a prefix, it can take over from the memory and substitute its own data on the bus to take control of the CPU. -
Is it too late to chuck this in the mix?
(I only stumbled across this forum yesterday)
Wow - that's certainly an impressive spec for 3 chips and some glue logic! Might have to give that one a try at some point in the future when I get hold of some larger memory chips! Also an interesting web site with some fascinating information on it.
-
Why not do the easy thing?
You have CP/M running.
There are many programs that allowed one CP/M computer to talk to another computer and transfer files
file transfer protocols
Kermit
XMODEM,YMODEM, ZMODEM
Some of these are built in to a PC terminal program
TeraTerm is one of many for PC side
I'd like to keep the SBC as simple and standalone as possible - I eventually plan to add a keyboard interface and CRT driver so it is complete standlone, so I won't be connecting it to a PC except for debugging/software updates, perhaps.
EDIT:
Actually C, I think I follow you - you mean transfer the data into CP/M in the same way I currently do with files from my PC (as a pasted data stream). Once in CP/M, I can just write a program to do exactly what I've outlined below in my response to Ian.M's post and write the data to the ROM with just a simple hardware change to allow me to set the ROM for write access...?It should be easy enough to understand. Think about it some more and consider what it would take to feed the Z80 a known sequence of opcodes and data bytes in place of what would normally come from the external memories. If you want to use a smaller ATmega, it needs a couple of shift registers so it can do the Z80 data bus interface via SPI, to save pins, it doesn't hook up to the address bus but does need several control signals and some of them have to be intercepted - do that with analog switches to minimise the propagation delay when the hardware bootstrap/debugger is not in control - and some glue logic to handle some control signals that are too fast for the Atmega to handle in code.
I understand the principle of injecting op codes and data onto the data bus to make the Z80 do the heavy lifting and store the ROM hex file in RAM before writing (or flashing it) to the ROM, but in practice it just seems like a huge task. So I'd be looking to intercept a 'POP DE' op code from the Z80, for example, and injecting (e.g.) the first 2 bytes of the new ROM hex file onto the data bus, so the Z80 thinks it's getting DE off the stack but is actually getting two bytes of data from the micro-controller.
The program running on the Z80 would then take the contents of the DE registers and LD it to a RAM address in HL. INC HL, rinse and repeat until the ROM hex file is fully transferred from the micro-controller to RAM. Then the program running on the Z80 could just write the data to ROM with an IO select via a flip flop to pull the ROM's ~WR line low and LDIR it across, resetting the flip flop (and making the ROM read-only again) when its done?
The issue is that for such a simple concept, it requires a detailed knowledge of the Z80 architecture in terms of control signals and timings - one I don't believe I have at the moment, not to mention hijacking the data bus. I'll admit to finding the idea highly elegant but somewhat scary and fraught with problems. -
My explanation of how you can make the ATmega bootstrap the Z80 is really not that tricky, and doesn't need a deep knowledge of the bus timings - or at least no more so than you need to build a Z80 system that's more complex than a minimal one in the first place. The idea of a zero CPU resources hardware debugger is however a lot more complex so I quite understand your reluctance to start down that road at thios stage. Its something you could retrofit later by adding a daughterboard carrying the hardware bootstrap/debugger between the Z80 and its socket. Adding mounting holes to permit such a daughterboard to be secured with PCB standoffs would future-proof your design.
However if you aten't going to have a hardware bootstrap of any sort, then you are up s--t creek if the boot block in the FLASH chip gets corrupted. If you want to avoid having to pull the FLASH chip to put in your programmer, I strongly recommend writing a monitor ROM that can cold-boot the machine, and can also receive data in IntelHEX format and store it to RAM. Burn it to EPROM and provide a socket for it on your memory board. You'll also need a SPDT switch to select between routing the ROM chip select to the FLASH or the EPROM, while the non-selected one is held inactive by a pullup on its /CS pin.
Then if you brick the FLASH bootblock, you can switch to the monitor ROM, restart anduse it to load an IntelHEX downloader + FLASH writer utility into RAM and run it, then flip the switch back to select the FLASH before sending it the FLASH image to be programmed. -
My explanation of how you can make the ATmega bootstrap the Z80 is really not that tricky, and doesn't need a deep knowledge of the bus timings - or at least no more so than you need to build a Z80 system that's more complex than a minimal one in the first place. The idea of a zero CPU resources hardware debugger is however a lot more complex so I quite understand your reluctance to start down that road at thios stage. Its something you could retrofit later by adding a daughterboard carrying the hardware bootstrap/debugger between the Z80 and its socket. Adding mounting holes to permit such a daughterboard to be secured with PCB standoffs would future-proof your design.
Yeah, I see the wisdom in adding daughterboard mounting holes to the motherboard - you never know what you might want to add in future to the processor socket.However if you aten't going to have a hardware bootstrap of any sort, then you are up s--t creek if the boot block in the FLASH chip gets corrupted.
Ah - hadn't thought of that... the random nasty power-outages mid-way through writing the new boot block etc.If you want to avoid having to pull the FLASH chip to put in your programmer, I strongly recommend writing a monitor ROM that can cold-boot the machine, and can also receive data in IntelHEX format and store it to RAM. Burn it to EPROM and provide a socket for it on your memory board. You'll also need a SPDT switch to select between routing the ROM chip select to the FLASH or the EPROM, while the non-selected one is held inactive by a pullup on its /CS pin.
Then if you brick the FLASH bootblock, you can switch to the monitor ROM, restart anduse it to load an IntelHEX downloader + FLASH writer utility into RAM and run it, then flip the switch back to select the FLASH before sending it the FLASH image to be programmed.
Yeah it's an added expense, but a necessary one I suppose if I'm going to go the route of being able to program the FLASH in-circuit. Stupid question time - could the FLASH still be written to (to fix the previous corrupt boot block) if its ~CS pin is held high, I wonder? I suppose it wouldn't be a problem if it couldn't be - I could just copy the necessary program to RAM from the backup ROM and switch it out again, making the FLASH ROM active and then updating it with the new boot code.. -
If you think ahead some things get easer.
You have a MMU that can access a large area of memory.
You could have a dip switch between the Flash Rom's WR pin and system, a hardware write protect.
By using a 138 to decode which chip, you could have many flash roms in the system. You can then change which is used for power-up boot by changing which connection of 138 is used for CS.
This is keeping it simple.
-
nockieboy
Think for a bit of starting over or someone else starting to make a copy of what you have.
Trying to use Grant's design has caused you all kinds of problems.
Some comes from using small often costly memory.
As you know now, the cost of new 512k byte memory is cheap.
It is not that hard to connect an address line high or low on a breadboard.
You can use a DIP switch to do this and be able to change it just by changing the switch.
So Grant's design using a larger Rom could have had many things in the rom at a change of a switch.
You could have played with many different rom based z80 systems with just a switch settings change.
One switch setting could be CP/M with ROM & RAM disks.
The needed CP/M programs could have been put on ROM when the rom was created.
Grant went to some work to make a crippled system that is hard to upgrade
When basic system was running, a 273 could have been added to reduce the need to change dip switch settings.
A 374 could have been added to read a dip switch.
This can add many different modes for system software. One of my systems uses a dip switch to select what drive to boot for system. This system could boot from 8, 5 1/4 | 3.5 disk drives as well as SCSI and network, a nice important switch.
Your MMU then becomes a simple upgrade.
When you added MMU to system, you would just remove some connections from dip switch or 273 and connect to MMU outputs.
In addition to the 273 above changing address lines of Memory chips, it or a second 273 could give you a status output on LED's. Makes testing a lot easer.
Now think of what the above is
A working CP/M system with RAM & ROM disks;
A CP/M program that can send or receive HEX files via console would let you transfer data to/from PC.
Data could be to/from ROM or CP/M files.
A terminal program on PC that knows a file transfer protocol could then be used to transfer files, removing need to convert to HEX on PC.
The un used console port can then be used.
With a working CP/M system, there exists many programs to cure problems.
A. It was not uncommon to use console port to send/receive programs or data files.
B. It was not uncommon to use a second port to connect to a different system and send/receive programs or data files.
So to summarize
With a working computer, it is easer to get a second computer running.
It can be easy to get a second copy of a computer running with just a little planning ahead.
ONE is a bad number.
For Z80 having a switch or jumper change to have a second choice for power-up book makes things easer. It is not hard to have two flash roms in the system and keep one write protected with hardware.
Simple would be flash rom's WR pulled high with a resistor & dip switch to connect system WR for each flash rom chip
With Z80 able to read/write Flash Rom it is not hard to have an image stored on PC.
Keep in mind that some things are just easer to have Z80 do the job then the PC.
You are working on CP/M BIOS. One small function is write sector or block. You will be reading/writing blocks of ram. Small change to have a Ram disk. An it's a second small change to have a ROM disk.
You can have CP/M use part of chip and have your bios capable of writing any area of chip.
When you can read/write blocks of a rom/ram you can then use CP/M format command to create a working disk.
With good foundation steps it becomes easer to expand.
-
You are working on CP/M BIOS. One small function is write sector or block. You will be reading/writing blocks of ram. Small change to have a Ram disk. An it's a second small change to have a ROM disk.
You can have CP/M use part of chip and have your bios capable of writing any area of chip.
When you can read/write blocks of a rom/ram you can then use CP/M format command to create a working disk.
With good foundation steps it becomes easer to expand.
That's the one thing I haven't had any time to look at yet. At the moment, I have absolutely *no* idea whatsoever how CP/M handles reading/writing to disk. I'm going to have a go at writing some routines to handle programming sectors of the FLASH ROM first as a step towards getting In-Circuit Programming of the ROM up and running.
Once that's working and I've got CP/M 3 up and running, I can start looking at getting it working with RAM/ROM disks. The CP/M 3 setup is stalling at the moment as I'm having difficulty working out exactly what I need to do with the CP/M 2.2 BIOS to get it working for CP/M 3, but hopefully it won't take me too long to work it out. -
Break it down into simple steps.
CP/M3 has some tools to make this easer. You should use them as they can create some of the data structures that CP/M3 needs an uses.
Step one is to modify your current CP/M2 BIOS code to work with CP/M3 tools and code.
Your source should assembly properly using CP/M3's relocating assembler.
When you have this, modify your BIOS source to be compatible with CP/M3's changes.
When you have this working you have a non-banked CP/M3 system.
This is a good point to test and get working RAM & ROM disks in banked memory.
When you have this working then add bank control to CP/M3
Now you can work on modifying your BIOS to work banked.
=====
Your current CP/M system is just using 64k of RAM
You know your Z80 can read and write RAM.
Simple CP/M wants to read/write 128 byte blocks on storage
Start with a 16K ram disk for your CPM.
Ram disk = 16K total with 128 byte blocks or sectors.
Your CP/M programs will end up in your BIOS at top of Z80's 64k memory.
Your code will need to
1. move data to/from a buffer in high memory BIOS.
Source or Destination will be in current 64K memory.
The other will be storage, the ram drive.
so if write Move source ram to buffer
bank swap
if write then move buffer to RAM disk sector.
if read then move from Ram disk sector to buffer.
bank swap back
if read then move buffer to ram.
CP.M data structures tells your code all it needs to know.
A sector is 128 bytes
Read/write
where in Z80 64k memory for 128 byte block
what sector, track, drive.
If you pick good numbers your code gets easer.
Using 128 sectors a track lets you use track value to select what bank of 16k
This is fine if you do not need to put os system before the directory on disk.
Best to use a power of 2 for sectors per track.
Using 64 sectors per track will put one bit in track value that is not needed for bank select. So each power of 2 smaller tracks per sector value is from 128 adds a bit not needed for bank select.
With raw read/write, CP/M's format code turns it into a CP/M disk drive.
CP/M's put system turns it into a system disk
When you get this working, expand drive to have more then one bank used.
When you get to this point, a swap from ram to rom gives you a read from rom but no CP/M directory.
Adding the Flash Rom's software write protect code for writes then gives you a working disk stored on Flash Rom.
Simple steps that you can code to test for proper operation.
-
Okay, quick question regarding the hardware ROM write enable - will this work?
The idea is that the ~WE pin is held high, unless the switch is closed when the ~WE is pulled low and the warning LED illuminates. My electronics skills aren't great, so I thought I'd just check to make sure this would work as intended? -
No. /WE needs to be driven by the Z80 /WR signal (probably buffered due to fanout limitations). Put the switch in series with the signal with the pullup resistor on the FLASH side of it. If you want an indicator LED, use a DPST switch and use the other pole for the LED.
As an alternative, if you need to mount the switch off-board, or must use a SPST switch, insert an OR gate in line with the /WR signal, and supply a logic level from a switch to the other input. The extra propagation delay is preferable to running a fast logic control signal to a front panel switch and back. You cant wire the switch as you have drawn as the LED will prevent the level going low enough for a valid logic 0. Move the logic takeoff point to the LED cathode and a 4K7 resistor across the LED to fix it. -
Right, so based on Ian.M's feedback I've come up with the below:
... but I have no idea where or how to wire up a warning LED with this arrangement?
The switch type I'm using isn't because of any particular reason, its just that I have a few of these knocking about in a drawer. -
To get better at this you need to understand small parts and then put them together into something that works.
Gain some knowledge.
First look at drawing before this with Led.
What is the voltage at top of led ( D1 pin 2 ) with switch opened and closed?
What is logic Low voltage range for /WR pin of ram?
What is logic High voltage range for /WR pin of ram?
Now re-read the last part of Ian.M's post again.
Now dig into lan.M's post an you have some answers to last drawing.
Hint, logic is logic, output of switch is a logic output.
Now last drawing.
Question is "do you trust your switch and what happens if it has a poor connection?"
Look at what you want to happen at U4 pin B
If that connection from S1 pin C1 comes loose, what is at U4 pin B?
You have all the answers you need to answer your question from Ian.M's post.
Now go a step further and change how switch is connected.
Wire the switch with C1 connected to ground.
If you understand Ian.M's post, this is a small change.
Now what happens when connection to U4 pin B gets disconnected or switch fails?
Do not make it hard, take simple steps from first drawing to improversion of last drawing.
Start here in post
You should know answers to my above questions if you go step by step changing circuit as lan.M suggests.
You cant wire the switch as you have drawn as the LED will prevent the level going low enough for a valid logic 0. Move the logic takeoff point to the LED cathode and a 4K7 resistor across the LED to fix it.
Understanding now will save you time later.
Now continue reading lan.M's post.
-
How about using the HD64180 ?. it already has an MMU giving access to 512K of memory plus other facilities. It was marketed as a "Super Z80" and sold by Zilog as the Z180. You can still find them : https://www.ebay.com/itm/Hitachi-64180-Kits-HD64180-MPU-TC551001-128K-SRAM-W27C020-EEPROM-DIP32-/161337103516
An example of its use is at https://www-users.cs.york.ac.uk/~pcc/Circuits/64180/doc.html
Ken -
How about using the HD64180 ?. it already has an MMU giving access to 512K of memory plus other facilities. It was marketed as a "Super Z80" and sold by Zilog as the Z180. You can still find them : https://www.ebay.com/itm/Hitachi-64180-Kits-HD64180-MPU-TC551001-128K-SRAM-W27C020-EEPROM-DIP32-/161337103516
An example of its use is at https://www-users.cs.york.ac.uk/~pcc/Circuits/64180/doc.html
Ken
Thanks Ken - but the reason I haven't gone for a more modern processor / microcontroller is because it defeats the purpose of doing all this in the first place - to build something similar in capability to my first ever computer, and maybe learn something about electronics at the same time.You have all the answers you need to answer your question from Ian.M's post.
Now go a step further and change how switch is connected.
Wire the switch with C1 connected to ground.
If you understand Ian.M's post, this is a small change.
Now what happens when connection to U4 pin B gets disconnected or switch fails?
Do not make it hard, take simple steps from first drawing to improversion of last drawing.
Start here in post
You should know answers to my above questions if you go step by step changing circuit as lan.M suggests.
You cant wire the switch as you have drawn as the LED will prevent the level going low enough for a valid logic 0. Move the logic takeoff point to the LED cathode and a 4K7 resistor across the LED to fix it.
Understanding now will save you time later.
Now continue reading lan.M's post.
I feel as though I'm groping around for solutions here, C, I'll admit. I don't know whether it's because I've misread what Ian.M and you have written, or if it's because I just don't grasp how it all works.
Here's the latest version, based off of what you've explained and a re-reading of Ian.M's post:
It's probably entirely wrong but, if it's not, how does the LED not light up when the switch is open? Surely it's earthed via U4:B? And what is the purpose of the 4K7 resistor in parallel with the LED? -
It's probably entirely wrong but, if it's not, how does the LED not light up when the switch is open? Surely it's earthed via U4:B? And what is the purpose of the 4K7 resistor in parallel with the LED?
The 4.7k resistor pulls input U4:B up fully preventing the LED from lighting up. Open TTL inputs do not really require pull-ups but they are a good idea.
-
Your last will work!
The proper connection for the 4K7 is S1 C2 to +5VQuoteSurely it's earthed via U4:B? And what is the purpose of the 4K7 resistor in parallel with the LED?
First U4 B is an input, as such very little current can flow out, it is high resistance.
A poor way to think about it, when you put your volt meter across the switch does the led light?
Meter is high resistance.
LED's are very poor diodes.
You get to thinking that diodes are great, current flows in one direction and nothing in the other, NOT THE CASE.
As the voltage across diode increases a small current flows until at some point the current starts increasing fast with little change in voltage.
LED's have a very high Vo that changes by type and color of led.
So looking at your last,
You remove the switch and your are write protected.
If you put the 4K7 resistor close to U4 B then you could even have LED get disconnected and still be in write protected mode.
-
Thanks Ken - but the reason I haven't gone for a more modern processor / microcontroller is because it defeats the purpose of doing all this in the first place - to build something similar in capability to my first ever computer, and maybe learn something about electronics at the same time.
Then why all this talking about flash memory and extreme amounts of memory? Imagine that the memory cost is about 5 UKP per kilobyte static RAM and build with what you "can afford".