So the Z80 reset line can be a slow pin. I am not entirely sure but I think that one of either /RD or /WR can be a slow pin too. (for an IORQ, if we detect that IORQ is low, and then test either /rd or /wr and it is high, the other must be low.).
Good call on the MCP23017 much better then the I2C register I was going to use. Available at digikey for @ $1.64 cdn for the DIP version 300mm.
During an interrupt the Z80 will pull /IORQ low and /M1 low /RD and /WT will stay high. So you must watch both the /RD and /WT lines if you are generating interrupt requests.
Nothing to do with Z80 I/O but there is also a case where the Z80 will pull /MREQ low and both /RD and /WT will remain high. At the end of each opcode fetch cycle the Z80 will perform a memory refresh cycle. During a refresh cycle the z80 will pull /MREQ and /RFSH low to indicate a memory refresh cycle used with dynamic ram.
Good call on the MCP23017 much better then the I2C register I was going to use. Available at digikey for @ $1.64 cdn for the DIP version 300mm.
If you are looking at using this chip I have some code I wrote that could be useful. The obex already has driver code for the MCP23008 and then someone else wrote a MCP23017 driver, and then I took that and added some variables that are like the OUTA and DIRA registers of the propeller, so you have one long that defines pins being high or low and another long that defines input (HiZ) or output.
Are you thinking of adding interrupts? If so, and if an interrupt changes IORQ, then do we need to monitor the interrupt pins?
@rogloh, intriguing idea there. I need coffee before pondering that further!
The original Mini80 does just that. The bottom board contains the Z80, Prop chip, RAM... The top board is a 100x50 color ansi terminal connected via a 4 wire RS232 (CMOS levels).. You realy need a 4 wire interface for a fast terminal. You could easly create a single board with both projects.
The ansi terminal and the first Mini80 prototype can be found on my website www.shaels.net if you want to have a look.
OMG. That's exactly what I was talking about. I'm so tempted to build one based on your design. (but I think I'll lurk this thread just a little more and see if you guys come up with a breadboard version with even fewer parts.)
After browsing the Z80 timing diagrams I think I might have possibly found a software sequence to solve the potential SRAM write glitch during my wired OR reset idea if SRAMs use a simultaneous /WR and /OE low condition to actually do a write (as I think they do from what I recall of SRAMs).
When you are about to reset the Z80, you would stop the prop counter clocking the Z80 and start to clock it manually, waiting for /RD to go low as it eventually will during regular opcode fetches or other memory reads. Make sure it is not an I/O cycle by checking /IORQ is high. If it is an I/O cycle, just resume clocking and try again.
Once you know it is a memory read because /IORQ was high, you can force the /IORQ low (creating a CPU /WAIT condition) then read the byte data on the data bus. Then you issue /RD and /WR low which will eventually reset the Z80 in three more clock cycles. In the meantime before driving the clock again, also drive the data bus from the propeller with the data bus value you read above, so the SRAM will be written back the same data value it was already outputting from the current Z80 address, and this last address should remain on the address bus given you are also holding /WAIT low. Clock it individually at least three more cycles and the Z80 should be reset, it will then pull /MREQ high and this will disable the SRAM /CS pin as well. Then you can safely release all /IORQ, /RD, and /WR signals and start the bootup sequence. It's a little tricky but I think this may potentially ensure a clean reset which would help warm reboots. If clean warm reboots from the prop are not needed, none of this is really required. Still want to ensure the SRAM really behaves this way, otherwise we could create a bus clash if the prop drives the data bus at the wrong time.
For a fail safe you would want to include a timeout after some number of CPU cycles when looking for the /RD going low in case the CPU has halted and is not doing opcode fetches. In these cases it should be safe to do a /RESET anyway.
This idea really only suits the minimalist version, without external expansion on the Z80 bus. Because who knows how that hardware would respond when driving all the control signals in this way.
I know this doesn't have some of the features we have discussed (eg A0 to decode ports), but this is a board I am thinking of making. I am cheating a little, as it talks to a motherboard that has a MCP23017 on it so that isn't strictly minimalist, but the general concept is there is a 50 pin header coming off that motherboard with 30 "fast" propeller pins and another 16 "slow" propeller pins. I'm not doing complicated things sharing the SD card and the I2C bus, so there are only 12 real propeller pins left to talk to the Z80. The Z80 reset and the three memory bank select pins are "slow" pins.
This board is very simple. 50 pin header to the propeller motherboard. One Z80, one ram chip, and then a 40 pin expansion header and that 40 pin header has the pin numbers the same as a 40 pin Z80 chip.
I need to think about it some more, but I think it could be better to make Z80_WR a "slow" pin. It slows down the bootstrap, but once the bootstrap is running, for talking to ports, if iorq is low then it is either a read or a write, and so testing Z80_RD would be enough. That would free up a fast pin which could be used for A0.
Changing banks would be slow, because it would involve doing a reset which is an I2C command. So at bootup one might need to bootstrap in 8 programs, one to each bank.
There are lots of spare "slow" propeller pins and maybe there could be scope to connect those to some of the Z80 pins like busrq, int, nmi?
Are you thinking of adding interrupts? If so, and if an interrupt changes IORQ, then do we need to monitor the interrupt pins?
I did not want to use the Z80 interrupts if I could avoid it.
The first interrupt mode of the Z80 (mode 0) uses a fixed Z80 code address that lies in a memory region used by CPM.
The second interrupt mode of the Z80 (mode 1) uses a single opcode returned by the interrupting device. Normaly the opcode is one of the reset opcode (RST0..RST7) not all reset codes can be used because they are used by CPM (debugger) or lie in a region of memory used by CPM.
The final Z80 interrupt mode is mode 2. This mode uses a jump table to control what code is executed in respone to a /INT signal. The mode requires Z80 peripheral chips. While the Z80 CPU has increased in speed most Z80 peripheral chips max out at about 4..6Mhz. Early Z80 based systems often used the Z80-CTC timer chip to implement the correct interrupt signals and hand shake required by the Z80 CPU.
Since CPM is a linear operating system (not threaded) there is little to gain by using interrupts.
RE: Remove 74vlc367;
Got back to the task of replacing the 74lvc367 with series resistors. Turns out that the changes to the boot loader are not as simple as I first thought.
After the Prop chip writes a byte of boot code to the RAM it must disable the RAM in order to place a Z80 NOP instruction on the data buss. The current design allows the /RD line on the RAM chip to be pulled high while at the same time still allows the Prop chip to monitor the Z80 /RD line to know when the Z80 has completed the opcode fetch.
If the /RD and /WT lines use series resistors and are forced inactive (high) by the Prop chip we will no longer be able to read the end of the Z80 opcode fetch cycle by monitoring the Z80 /RD line. At the Prop /RD line input will alway be read as a high.
One solution is to use the Prop pin that currently control the 74lvc367 buffer enable and use it as the active high chip select on the RAM chip. This allows the RAM chip to be disabled while the /RD line is active.
Another solution is to have the Prop chip clock the Z80 the required number of cycles to complete the opcode fetch cycle and not watch the Z80 /RD signal.
The first solution requires the least amount of changes to the code but the number of required Prop pins to control the Z80 remains the same. The second solution would free one pin on the Prop chip for other uses but requires more code in the Prop COG controling the Z80. There are not a lot of free code words available in the Z80 control COG (@16) now, after this change there will not be any.
Since CPM is a linear operating system (not threaded) there is little to gain by using interrupts.
Yes I think that might be the conclusion I come to as well.
.....Not sure which is the correct way to do this.
Good points there. I've just dusted off the Zilog Data Book and on page 5 are the timing diagrams. Picture attached. The timing looks pretty straightforward and fits with the experiments I did showing it needed two clocks.
Z80ResetLow ' set reset low
Z80Clock(5) ' clock several times to register the reset
Z80ResetHigh ' set reset high
Z80WaitForRdLow ' clock until rd goes low, at this point address should be 00000000_00000000
repeat i from 0 to 63 ' make sure number is bigger than DAT program
Z80WriteByteToRam(byte[@Z80BootProgram][i]) ' move a byte into ram
Z80DataBusNOP ' sets data bus to zero, Z80 reads this as a NOP and proceeds to next instruction
Z80Clock(2) ' two clocks, rd will be high at the end of this
Z80WaitForRdLow ' clock and wait until reads next value
Re running out of cog space, what I have been thinking is that there are two separate processes here - loading a bootloader, and transferring data. Loading the bootloader is only done once and the program seemed to fit in under 64 bytes, so I figured this could be in Spin and it wouldn't matter if it was slow.
The data transfer code needs to be much faster so it needs to be in a cog, but if you removed the bootloader code, would that free up more space?
I know this doesn't have some of the features we have discussed (eg A0 to decode ports), but this is a board I am thinking of making. I am cheating a little, as it talks to a motherboard that has a MCP23017 on it so that isn't strictly minimalist, but the general concept is there is a 50 pin header coming off that motherboard with 30 "fast" propeller pins and another 16 "slow" propeller pins. I'm not doing complicated things sharing the SD card and the I2C bus, so there are only 12 real propeller pins left to talk to the Z80. The Z80 reset and the three memory bank select pins are "slow" pins.
This board is very simple. 50 pin header to the propeller motherboard. One Z80, one ram chip, and then a 40 pin expansion header and that 40 pin header has the pin numbers the same as a 40 pin Z80 chip.
I need to think about it some more, but I think it could be better to make Z80_WR a "slow" pin. It slows down the bootstrap, but once the bootstrap is running, for talking to ports, if iorq is low then it is either a read or a write, and so testing Z80_RD would be enough. That would free up a fast pin which could be used for A0.
Changing banks would be slow, because it would involve doing a reset which is an I2C command. So at bootup one might need to bootstrap in 8 programs, one to each bank.
There are lots of spare "slow" propeller pins and maybe there could be scope to connect those to some of the Z80 pins like busrq, int, nmi?
This looks quite cool but I think I've lost track of what you're doing. What Propeller board does this plug into? Quickstart?
This looks quite cool but I think I've lost track of what you're doing. What Propeller board does this plug into? Quickstart?
Is it time for the Christmas Shopping List?
Just piddling around with it, looks like it would be a simple all-thru-hole project.
With a printed board.
MGH Designs DNA board with the SD card reset to (16-20)
Then all one needs are he Z80. RAM and logic chips.
I briefly thought about building one by hand, but that's not gonna happen any more..
I need a circuit board...
This project only uses one side of the propeller platform, using only Ports(P0 - P15).
It's only four chips - Z80, RAM, and logic.
Also a suggestion for running "with or without" resistors for 5 volt operations.
For debugging and simple testing, many propeller boards should work. Leave out keyboard and displays and sound for the moment and just debug through the propeller terminal program. Then later, add an SD card, but we are not quite at the stage of needing an SD card yet. So really, just any propeller chip or board with 12 to 14 pins free, a Z80 and a ram chip.
For debugging and simple testing, many propeller boards should work. Leave out keyboard and displays and sound for the moment and just debug through the propeller terminal program. Then later, add an SD card, but we are not quite at the stage of needing an SD card yet. So really, just any propeller chip or board with 12 to 14 pins free, a Z80 and a ram chip.
Yup yup
Like the one I was trying to hand draw (above).
Propeller Platform format.
Just hook it up and go?
For debugging and simple testing, many propeller boards should work. Leave out keyboard and displays and sound for the moment and just debug through the propeller terminal program. Then later, add an SD card, but we are not quite at the stage of needing an SD card yet. So really, just any propeller chip or board with 12 to 14 pins free, a Z80 and a ram chip.
I don't suppose anyone here has any interest in making a 6809+Propeller board? I always thought that was a lot more interesting than the Z80.
6809 + propeller board? Checking the datasheet now http://www.classiccmp.org/dunfield/r/6809e.pdf Address and data and control lines. Any 6809 experts here who could comment on the NOP stuffing concept?
Like the one I was trying to hand draw (above).
Propeller Platform format.
Just hook it up and go?
Sounds good. Just needs ram, Z80 and two or three low value resistors eg 220R and some pullups (not all of the pullups may be needed, and for testing, there are quite a few Z80 pins eg busrq, nmi, int that can be simply connected to the V+).
6809 + propeller board? Checking the datasheet now http://www.classiccmp.org/dunfield/r/6809e.pdf Address and data and control lines. Any 6809 experts here who could comment on the NOP stuffing concept?
Sounds good. Just needs ram, Z80 and two or three low value resistors eg 220R and some pullups (not all of the pullups may be needed, and for testing, there are quite a few Z80 pins eg busrq, nmi, int that can be simply connected to the V+).
Not really an expert, but from the data sheet and what little I recall it should be possible. It fetches a reset vector (start address) from FFFE and FFFF and uses that as the start address. Feeding 00h to the data bus during that time will set the program counter to location 0000h, so writing to the ram and then feeding NOP's ( 11h ) for each subsequent fetch should load the bootstrap to the ram and increment the program counter. Looks like it should be no harder than what was done for the Z80, and possibly even slightly simpler.
Be careful. As far as I understand the 6809 was not exactly a "static" device like the Z80. That is to say if you stalled the clock for too long it forgot what it was doing.
Some years ago a guy was trying to make a multi-6809 machine and ran into this problem when trying to get them to share RAM.
Sadly I cannot find a link to that project.
Be careful. As far as I understand the 6809 was not exactly a "static" device like the Z80. That is to say if you stalled the clock for too long it forgot what it was doing.
Some years ago a guy was trying to make a multi-6809 machine and ran into this problem when trying to get them to share RAM.
Sadly I cannot find a link to that project.
Heater
I'm not sure if this is the project you have mentioned above, but this one seems to be very well documented.
The full schematic redrawn...
Could truly use another set of eyes on this as a double check?
Leading to this:
Address and data buses wired, shift register in, some control signals in.
Still need to hook up the signals to the Propeller Platform headers.
Here is a young chap talking about his retro Z80 project. Building a Z80 computer from zero. Including a quick lesson in how we got started programming even before we had assemblers.
It's a bit off topic here as he is using an eZ80 but it warms my heart that there are still youngsters around getting into this kind of thing. It's also a great intro to that particular chip. The debug interface sounds great, I did not realize that you could just turn it on and start typing code into it for example.
One nice feature - this chip simply extends all the registers from 16 bit to 24 bit. So that is how it addresses more memory. Would greatly simplify things like MP/M and all the banked memory Z80 schematics out there. No more complicated bank switching hardware.
Well I guess we may need to hybridise this with the Propeller?
As an aside, I have three boards being built. A propeller motherboard, with SD, keyboard, audio out, vga, tv, analog i/o, onboard regs and two 50 pin headers. Board 2 has a Z80 and sram and 3 resistors. Board three has lots 46 leds - red for high and green for low with buffers so high impedance inputs, so it is a giant logic probe. I'm bringing the Z80 pins out onto a 50 pin header as well, so it is possible to build two led boards, one for the prop interface and one for the Z80 interface. Should make debugging easier, especially when the Z80 gets clocked really slowly by the propeller.
Going back to the eZ80, these boards might be able to interface with that board noah1989 has made. I like the idea of pushing the Z80 up to crazy fast speeds. Anyone got a link to a really simple schematic that adds a decent amount of fast memory to the eZ80?
I have not looked at any eZ80 specs but are you sure about that 24 bit register business?
Our young video maker there was talking about a new register in the eZ80 that is used to set the top bits of the address bus.
I have not looked at any eZ80 specs but are you sure about that 24 bit register business?
Our young video maker there was talking about a new register in the eZ80 that is used to set the top bits of the address bus.
MBASE register.
Very much like the x86's segment register, I think.
Until it is switched back to Z80 mode. Then I'm not so sure...?
In Z80 mode it looks like MBASE is just loaded with an 8 bit offset to use as a base
(16 bit) address. In effect "paging" the entire 64 K address space through the larger
24 bit address space.
MBASE seems to be the equivalent of adding an 8 bit latch to a Z80 to create a 24 bit address bus that allows 16MB of ram to be addressed as 256 blocks of 64KB. It can not be accessed in Z80 mode so Z80 code running in one of the 64KB blocks can not corrupt other blocks.
So, a 64KB master OS running in ADL mode and 255 tasks (cpm, games, etc.) each running in their own memory block in Z80 mode would be possible. Sounds like fun.
They used a Z8 instead of a Propeller, and an EZ80 (of course) but basically the same tricks.
50 mhz CP/M, anyone?
1" x 2" board?
The idea here was to design and build a small CP/M computer using readily available parts.
This page provides an overview of the board design and software.
Interested readers can find more detail in the schematic and source code referenced at the
end of this page. (Actually, no they can't - but would like to...)
I've been following this thread for a few months now and whilst my house is in the midst of a rewire I thought I'd
post a link to some work I've been doing using Z80 and Propeller (and PIC / CPLD / ISA / VGA) as part of a challenge.
I started off a few years ago with thw Chameleon Dev board from Nurve, I gto a Speccy16 emu eorking but only with a boot time of 2 mintues!
(no Ram - so SPI between PIC and Prop memory for video output )
What I'm curreently doing fits well with some of the discussions here. I'm at the stage where I want to access some VRAM from either the 1st Prop, a (second addition Prop)
or via CPLD/ISA/VGA or dsPIC/VGA
The prop is used to the hilt running periph and z80 clock/control lines - you can do some intrresting things with the clockrunnign off the prop.
My apoligies for my typing, i have a left hand nervous condition.
I would be interested in any thougts on my project, in particular I am planning to use the spare EPROM slot for a VRAM chip, then piggyback a Prop / PIC onto the chip to output VGA etc.
Comments
Good call on the MCP23017 much better then the I2C register I was going to use. Available at digikey for @ $1.64 cdn for the DIP version 300mm.
During an interrupt the Z80 will pull /IORQ low and /M1 low /RD and /WT will stay high. So you must watch both the /RD and /WT lines if you are generating interrupt requests.
Nothing to do with Z80 I/O but there is also a case where the Z80 will pull /MREQ low and both /RD and /WT will remain high. At the end of each opcode fetch cycle the Z80 will perform a memory refresh cycle. During a refresh cycle the z80 will pull /MREQ and /RFSH low to indicate a memory refresh cycle used with dynamic ram.
If you are looking at using this chip I have some code I wrote that could be useful. The obex already has driver code for the MCP23008 and then someone else wrote a MCP23017 driver, and then I took that and added some variables that are like the OUTA and DIRA registers of the propeller, so you have one long that defines pins being high or low and another long that defines input (HiZ) or output.
Are you thinking of adding interrupts? If so, and if an interrupt changes IORQ, then do we need to monitor the interrupt pins?
@rogloh, intriguing idea there. I need coffee before pondering that further!
OMG. That's exactly what I was talking about. I'm so tempted to build one based on your design. (but I think I'll lurk this thread just a little more and see if you guys come up with a breadboard version with even fewer parts.)
Jeff
When you are about to reset the Z80, you would stop the prop counter clocking the Z80 and start to clock it manually, waiting for /RD to go low as it eventually will during regular opcode fetches or other memory reads. Make sure it is not an I/O cycle by checking /IORQ is high. If it is an I/O cycle, just resume clocking and try again.
Once you know it is a memory read because /IORQ was high, you can force the /IORQ low (creating a CPU /WAIT condition) then read the byte data on the data bus. Then you issue /RD and /WR low which will eventually reset the Z80 in three more clock cycles. In the meantime before driving the clock again, also drive the data bus from the propeller with the data bus value you read above, so the SRAM will be written back the same data value it was already outputting from the current Z80 address, and this last address should remain on the address bus given you are also holding /WAIT low. Clock it individually at least three more cycles and the Z80 should be reset, it will then pull /MREQ high and this will disable the SRAM /CS pin as well. Then you can safely release all /IORQ, /RD, and /WR signals and start the bootup sequence. It's a little tricky but I think this may potentially ensure a clean reset which would help warm reboots. If clean warm reboots from the prop are not needed, none of this is really required. Still want to ensure the SRAM really behaves this way, otherwise we could create a bus clash if the prop drives the data bus at the wrong time.
For a fail safe you would want to include a timeout after some number of CPU cycles when looking for the /RD going low in case the CPU has halted and is not doing opcode fetches. In these cases it should be safe to do a /RESET anyway.
This idea really only suits the minimalist version, without external expansion on the Z80 bus. Because who knows how that hardware would respond when driving all the control signals in this way.
Roger.
This board is very simple. 50 pin header to the propeller motherboard. One Z80, one ram chip, and then a 40 pin expansion header and that 40 pin header has the pin numbers the same as a 40 pin Z80 chip.
I need to think about it some more, but I think it could be better to make Z80_WR a "slow" pin. It slows down the bootstrap, but once the bootstrap is running, for talking to ports, if iorq is low then it is either a read or a write, and so testing Z80_RD would be enough. That would free up a fast pin which could be used for A0.
Changing banks would be slow, because it would involve doing a reset which is an I2C command. So at bootup one might need to bootstrap in 8 programs, one to each bank.
There are lots of spare "slow" propeller pins and maybe there could be scope to connect those to some of the Z80 pins like busrq, int, nmi?
I did not want to use the Z80 interrupts if I could avoid it.
The first interrupt mode of the Z80 (mode 0) uses a fixed Z80 code address that lies in a memory region used by CPM.
The second interrupt mode of the Z80 (mode 1) uses a single opcode returned by the interrupting device. Normaly the opcode is one of the reset opcode (RST0..RST7) not all reset codes can be used because they are used by CPM (debugger) or lie in a region of memory used by CPM.
The final Z80 interrupt mode is mode 2. This mode uses a jump table to control what code is executed in respone to a /INT signal. The mode requires Z80 peripheral chips. While the Z80 CPU has increased in speed most Z80 peripheral chips max out at about 4..6Mhz. Early Z80 based systems often used the Z80-CTC timer chip to implement the correct interrupt signals and hand shake required by the Z80 CPU.
Since CPM is a linear operating system (not threaded) there is little to gain by using interrupts.
RE: Remove 74vlc367;
Got back to the task of replacing the 74lvc367 with series resistors. Turns out that the changes to the boot loader are not as simple as I first thought.
After the Prop chip writes a byte of boot code to the RAM it must disable the RAM in order to place a Z80 NOP instruction on the data buss. The current design allows the /RD line on the RAM chip to be pulled high while at the same time still allows the Prop chip to monitor the Z80 /RD line to know when the Z80 has completed the opcode fetch.
If the /RD and /WT lines use series resistors and are forced inactive (high) by the Prop chip we will no longer be able to read the end of the Z80 opcode fetch cycle by monitoring the Z80 /RD line. At the Prop /RD line input will alway be read as a high.
One solution is to use the Prop pin that currently control the 74lvc367 buffer enable and use it as the active high chip select on the RAM chip. This allows the RAM chip to be disabled while the /RD line is active.
Another solution is to have the Prop chip clock the Z80 the required number of cycles to complete the opcode fetch cycle and not watch the Z80 /RD signal.
The first solution requires the least amount of changes to the code but the number of required Prop pins to control the Z80 remains the same. The second solution would free one pin on the Prop chip for other uses but requires more code in the Prop COG controling the Z80. There are not a lot of free code words available in the Z80 control COG (@16) now, after this change there will not be any.
Not sure which is the correct way to do this.
Yes I think that might be the conclusion I come to as well.
Good points there. I've just dusted off the Zilog Data Book and on page 5 are the timing diagrams. Picture attached. The timing looks pretty straightforward and fits with the experiments I did showing it needed two clocks.
Z80ResetLow ' set reset low Z80Clock(5) ' clock several times to register the reset Z80ResetHigh ' set reset high Z80WaitForRdLow ' clock until rd goes low, at this point address should be 00000000_00000000 repeat i from 0 to 63 ' make sure number is bigger than DAT program Z80WriteByteToRam(byte[@Z80BootProgram][i]) ' move a byte into ram Z80DataBusNOP ' sets data bus to zero, Z80 reads this as a NOP and proceeds to next instruction Z80Clock(2) ' two clocks, rd will be high at the end of this Z80WaitForRdLow ' clock and wait until reads next valueRe running out of cog space, what I have been thinking is that there are two separate processes here - loading a bootloader, and transferring data. Loading the bootloader is only done once and the program seemed to fit in under 64 bytes, so I figured this could be in Spin and it wouldn't matter if it was slow.
The data transfer code needs to be much faster so it needs to be in a cog, but if you removed the bootloader code, would that free up more space?
Woops, sorry about that. I'm racing ahead as usual. It plugs into this board - which hasn't been made but will be very soon.
Is it time for the Christmas Shopping List?
Just piddling around with it, looks like it would be a simple all-thru-hole project.
With a printed board.
MGH Designs DNA board with the SD card reset to (16-20)
Then all one needs are he Z80. RAM and logic chips.
I briefly thought about building one by hand, but that's not gonna happen any more..
I need a circuit board...
This project only uses one side of the propeller platform, using only Ports(P0 - P15).
It's only four chips - Z80, RAM, and logic.
Also a suggestion for running "with or without" resistors for 5 volt operations.
Yup yup
Like the one I was trying to hand draw (above).
Propeller Platform format.
Just hook it up and go?
Sounds good. Just needs ram, Z80 and two or three low value resistors eg 220R and some pullups (not all of the pullups may be needed, and for testing, there are quite a few Z80 pins eg busrq, nmi, int that can be simply connected to the V+).
Not really an expert, but from the data sheet and what little I recall it should be possible. It fetches a reset vector (start address) from FFFE and FFFF and uses that as the start address. Feeding 00h to the data bus during that time will set the program counter to location 0000h, so writing to the ram and then feeding NOP's ( 11h ) for each subsequent fetch should load the bootstrap to the ram and increment the program counter. Looks like it should be no harder than what was done for the Z80, and possibly even slightly simpler.
Some years ago a guy was trying to make a multi-6809 machine and ran into this problem when trying to get them to share RAM.
Sadly I cannot find a link to that project.
Heater
I'm not sure if this is the project you have mentioned above, but this one seems to be very well documented.
Multiprocessing for the Impoverished: a multi-6809 system http://www.bradrodriguez.com/papers/6809cpu.htm
The five part article can be accessed thru: http://www.bradrodriguez.com/papers/index.html
I hope it will help a bit.
Yanomani
The full schematic redrawn...
Could truly use another set of eyes on this as a double check?
Leading to this:
Address and data buses wired, shift register in, some control signals in.
Still need to hook up the signals to the Propeller Platform headers.
Then we get to see if it works?
Are you using /Wait at all?
And what's the story on replacing the '367 with resistors?
I saved a place for the chip - just in case.
It's a bit off topic here as he is using an eZ80 but it warms my heart that there are still youngsters around getting into this kind of thing. It's also a great intro to that particular chip. The debug interface sounds great, I did not realize that you could just turn it on and start typing code into it for example.
http://www.youtube.com/watch?v=cKoRRA4MyM4#t=136
One nice feature - this chip simply extends all the registers from 16 bit to 24 bit. So that is how it addresses more memory. Would greatly simplify things like MP/M and all the banked memory Z80 schematics out there. No more complicated bank switching hardware.
Well I guess we may need to hybridise this with the Propeller?
As an aside, I have three boards being built. A propeller motherboard, with SD, keyboard, audio out, vga, tv, analog i/o, onboard regs and two 50 pin headers. Board 2 has a Z80 and sram and 3 resistors. Board three has lots 46 leds - red for high and green for low with buffers so high impedance inputs, so it is a giant logic probe. I'm bringing the Z80 pins out onto a 50 pin header as well, so it is possible to build two led boards, one for the prop interface and one for the Z80 interface. Should make debugging easier, especially when the Z80 gets clocked really slowly by the propeller.
Going back to the eZ80, these boards might be able to interface with that board noah1989 has made. I like the idea of pushing the Z80 up to crazy fast speeds. Anyone got a link to a really simple schematic that adds a decent amount of fast memory to the eZ80?
I have not looked at any eZ80 specs but are you sure about that 24 bit register business?
Our young video maker there was talking about a new register in the eZ80 that is used to set the top bits of the address bus.
MBASE register.
Very much like the x86's segment register, I think.
Until it is switched back to Z80 mode. Then I'm not so sure...?
In Z80 mode it looks like MBASE is just loaded with an 8 bit offset to use as a base
(16 bit) address. In effect "paging" the entire 64 K address space through the larger
24 bit address space.
It's a trip.
http://www.zilog.com/docs/um0077.pdf
Here is my old favorite : http://www.ferretronix.com/tech/zilog/captain_zilog_3.jpg
And here he is still fighting on a Zilog : http://www.zilog.com/captain_zilog/
MBASE seems to be the equivalent of adding an 8 bit latch to a Z80 to create a 24 bit address bus that allows 16MB of ram to be addressed as 256 blocks of 64KB. It can not be accessed in Z80 mode so Z80 code running in one of the 64KB blocks can not corrupt other blocks.
So, a 64KB master OS running in ADL mode and 255 tasks (cpm, games, etc.) each running in their own memory block in Z80 mode would be possible. Sounds like fun.
They used a Z8 instead of a Propeller, and an EZ80 (of course) but basically the same tricks.
50 mhz CP/M, anyone?
1" x 2" board?
The idea here was to design and build a small CP/M computer using readily available parts.
This page provides an overview of the board design and software.
Interested readers can find more detail in the schematic and source code referenced at the
end of this page. (Actually, no they can't - but would like to...)
I've been following this thread for a few months now and whilst my house is in the midst of a rewire I thought I'd
post a link to some work I've been doing using Z80 and Propeller (and PIC / CPLD / ISA / VGA) as part of a challenge.
I started off a few years ago with thw Chameleon Dev board from Nurve, I gto a Speccy16 emu eorking but only with a boot time of 2 mintues!
(no Ram - so SPI between PIC and Prop memory for video output
What I'm curreently doing fits well with some of the discussions here. I'm at the stage where I want to access some VRAM from either the 1st Prop, a (second addition Prop)
or via CPLD/ISA/VGA or dsPIC/VGA
The prop is used to the hilt running periph and z80 clock/control lines - you can do some intrresting things with the clockrunnign off the prop.
My apoligies for my typing, i have a left hand nervous condition.
http://www.camputerslynx.info/PALE/index.htm
http://www.youtube.com/watch?v=jfKKZKMjEUY
I would be interested in any thougts on my project, in particular I am planning to use the spare EPROM slot for a VRAM chip, then piggyback a Prop / PIC onto the chip to output VGA etc.
Warm Rgs to everyone from Mid Wales,
Peter
What you are doing seems suitably daft, welcome to the forum!
I have drifted off course (again) and have stated on a real Z80(B) board. I haven't got enough 74LS32's so it's time for a CPLD (isn't it?)
I spent about 20 years in Wales (Cardiff) with HTV and BBC TX. You'll have to forgive my typing too, I have a 70's education ;-)
Alan
And pls forgive my typing too - I learned to type on an old 1930s typewriter that where the 'o' punched a hole in the paper.