Thanks cavelamb, still a picture is worth a thousand words of mine, wobbling throughout a post.
I'm going to complain solely that one can use a single gate inverter, or any other spare inverting function, to solely process the /IORQ signal.
In the absolute absence of any available victims, one of these internaly biased BJT's and a pullup resistor will cost almost nothing in real state and money.
The exemption of interrupt acknowledge cycles from latching the lower address lines and letting them being read at the data bus side, adds about nothing to the intended solution.
INTA cycles does not presents any /RD nor /WR controlling signals, so that's the way to clearly distinguish them from I/O operations.
The same applies to /RD or /WR without /IORQ; except for a flawed Z80 erratic behavior, they must be an instruction fetch or memory read (/RD alone), or memory write (/WR alone) operations.
Elaborating a bit, if at any point, you need to exercise some MODE 2 interrupts, or peacefully live with any of Z80's peripheral chips, then you'll certainly enjoy knowing the exact vector that was sent by the device that wins the daysi-chained IEI/IEO scheme, and caused the Z80's to capture the interrupt service routine start address, using (256 x Ireg + Vector) as a pointer in a jump address table.
I register contents is something you could preview, or at least extract with the help of a code snippet.
Interrupt vectors are such a kind of flying entities, some times behaving as Autobots, then some Decepticons do start a riot, then you blink an eye, and everything changed again.
Add a paged memory strategy, perhaps a interrupt driven one, to the scenario.
I'd agreed 100% with Chip's design philosophy, when i realized that the way he chooses for Propellers to deal with on-the-fly events, is the best one.
The terms "Bogus" and "OS bugs" do share the same letters, and many times, the same origins... Interrupts!
But, trying to guess where to put some wise breakpoints, only to stop the bull run with a shaking hand, always seems to me some kind of painfull russian roulette!
Props are a winning bet!
Yes that should work. I'll try it when I get home from work.
I must say that the Propeller makes a perfect debugging tool for things like this. I don't know exactly how many clock cycles the above is going to take, but I know that it is very easy to write Spin code and download and test things quickly and when the /rd line goes low and all the higher address lines go high, it has made the jump.
Thanks Yanomani!
Thank you, Dr_Acula, for the opportunity you gave me to help a bit!
@Yanomani - I found that data sheet, thanks for the link. It contains useful timing information.
I am looking at response time for the prop to detect the Z80's I/O accesses and respond, either by issuing the /WAIT to buy more time or stopping the Z80 clock. I want to see how this compares with Z80 clock speed. The data sheet only shows the information for 5V +/- 10% voltage and 0-70C tempature range not 3.3V so take them with a grain of salt. But they can be still be used to get a very rough indication of where we stand and what might be possible.
For the wait method: You need to drop /WAIT within a maximum amount of time after /RD (or /WR) and /IORQ both go low.
There is a small delay before /RD (or /WR) goes low after a clock edge. You need to have /WAIT issued before 1.5 x the Z80 clock period minus a setup time following this same clock edge. This table computes the maximum response time you have after detecting the /IORQ and /RD edge in the prop and the number of propeller clocks this corresponds to at 80MHz before the /WAIT must go low. Times are in nanoseconds.
There is no way 20MHz is possible without external hardware doing the /WAIT.
For 10MHz you might be able to generate if the combination of the "waitpeq" and "and outa, mask" operations can complete within 6 clocks after the edge. It might just be possible - it will be very close but worth a go. 6 MHz down should be very doable.
For the clock stopping method: On I/O reads (which is the tighter case compared to I/O writes) you need to stop the clock before the Z80 latches its read data from the data bus.
Without waits, you have to stop the clock within 2.5 x the Z80 clock period minus the /RD low delay. The Data setup time is also shown but it should not factor into the computation if you stop the clock in time, however once the prop presents the I/O read data on the bus you will need to wait at least this amount of time before you can start the clock again. Time are in nanoseconds.
If you are controlling the clock in software as fast as you can, and polling /IORQ to be low with something like this code below you can only clock the Z80 as fast as 20M/6 = 3.3MHz if the prop runs at 80MHz and you want a symmetric clock output.
loop xor outa, clockmask
test iorq_mask, ina wz
if_nz jmp #loop
' .. pause toggling the clock pin and do the IORQ here
If instead you are controlling the clock using a counter you will need to do a WAITPEQ on the /IORQ, then stop the counter clocking as soon as possible. I expect this takes at least 5 propeller clocks, (at best) 1 for the waitpeq detection to compete if it was already running, and 4 for the write to CTRA register to stop it, assuming no other internal delays inside the prop itself (which there might be - I don't know). I'm not sure that 20MHz is achievable - it's really tight. Probably 10-12MHz is more resonable to expect?
Roger.
ps. you can always buy a 20MHz rated Z80 CPU and clock it slower. The numbers above indicate using each particular MHz rated Z80 but there is no reason you can't underclock a faster one, that will help too.
Thank you, rogloh and you've a great job done, calculating all those relationships!
Your work makes me wonder if (it's only a dream) and how you can use WAITVID stuff to bitbang Z80's clock wave shape, based on your knowledge of 'what sequence of events to do next', and using some more COGs in sync as needed to keep things under Propeller's tight control, boosting overall system's performance!
No, no, no! It's just a dream, sure it will be impossible to do!:cool:
Waitvid for a faster clock? Intriguing. I haven't ported my code from spin to pasm yet, but it will be interesting to see how fast things can go. The ram chip I am using is 55ns so that might be a limiting factor, but I think faster ram chips are available.
Ok, here is another crazy idea. What would happen if you connected the Z80 /IORQ to /WAIT ? Would it simply latch up the Z80 and stop it running the first time it does an OUT or IN instruction. Not very exciting. Others have mentioned latches. But what if you connected the Z80 /IORQ and /WAIT pins together with a 220R resistor. Now connect the /WAIT pin to a propeller pin (it could be the pin that was used for the /IORQ sampling).
Z80 is running along super fast and executes a /IORQ and latches up. Now it is only necessary to sample this propeller pin infrequently. Unroll a lot of high/low/high/low clock instructions in pasm and sample every 10th clock pulse. Or even another cog can do the sampling and the clock can be run from a faster waitvid.
Can the /WAIT be cleared? It seems to me it should work. The Z80 is in latchup. Propeller samples the /WAIT line (which actually reflects the /IORQ line via the resistor) and samples /rd and /wr and the data bus and puts data on the bus or reads from the bus. And then it forces the /WAIT line high (which won't harm the /IORQ line as the resistor limits the current) and clocks the Z80 until /IORQ goes high (2 or 3 clocks), and then makes the propeller pin HiZ.
Ok, here is another crazy idea. What would happen if you connected the Z80 /IORQ to /WAIT ? Would it simply latch up the Z80 and stop it running the first time it does an OUT or IN instruction. Not very exciting. Others have mentioned latches. But what if you connected the Z80 /IORQ and /WAIT pins together with a 220R resistor. Now connect the /WAIT pin to a propeller pin (it could be the pin that was used for the /IORQ sampling).
Had a very similar idea myself a few days back but didn't take it further. In minimalist systems with no other I/O but the prop, we could use the same scheme with the /RD, /WR resistors and connect it like this.
Z80 /IORQ - 220 ohm resistor - prop pin & Z80 /WAIT (/WAIT also gets pulled up via a 10k on Z80's /IORQ side whenever IORQ is tri-stated).
Then for each I/O access the wait is auto-triggered, and the prop has as long as it wants to respond. All the prop pin has to do at the end of the I/O transaction is to pull its own /IORQ line high for 1-2 Z80 clock cycles (this may need tuning) and force /WAIT to go high. The /WAIT will go high, and /IORQ will be deasserted by the Z80, then the prop has to tristate its /IORQ sense pin and wait for /IORQ to go low again to start again. There is no problem with simultaneously bus driving because the 220 ohm resistor saves us. May want to use a slightly higher value.
NICE because it also saves a pin and we get stereo out again with the WAIT as well !!!!
I hope you can do a simple mod on your board and try this out Dr_Acula. If I can I will try it too in my setup in the next couple of days hopefully.
Only catch I see might be the interrupt acknowledge cycles. They need to be handled as well because /WAIT is sampled for those too. But prop can look for /IORQ low and /RD high and /WR high to deal with it.
Not only for a faster clock. There is a lot more behind the scene.
When the Z80 was conceived, even a 2.5 MHz crystal was a very expensive part.
You had to carefully select its cut shape and oscillation mode to match the intended application.
Adding loading caps and an inverter ring to create a 'quasi stable' oscillator, that faithfully started at almost every power on, and can be repeated many thousands of times, perhaps millions, under different relative humidity, temperature and biasing conditions, could consume all your hair and nails, for weeks.
Your eyes were saturated by many hours of exposure to warm whites, blurry greens or hepatic yellowish oscilloscope screens, behind some orangish reticulated "bird nets", in search for the holy grail biasing network, that accomplishes all of the above AND a reasonable 50/50 square wave.
Pray God many times, so it keeps forever running, provided there is a proper power source applied to it.
Your fingers were injured by repeatedly adjusting the time base and fine scale controls.
Tap a single nail tip at the DC bias adjustment knob, and everything just vanishes from the screen or start sliding right or leftwards, like a crazy race car, running near a bright and endless fence.
Just after a couple of sweaty hours, and a decision must be taken: you need to focus the wave shape at the screen, your DVM lcd or the white paper sheets with specs, calculations and "guess what" side notes. You simply can't do any two of them with the single pair of eyes you had born with. The more your brain focus, the less your peripheric vision can catch anything. Co-workers have to call your name (or alias) many and many times, before your forgotten mouth can release a simple Huuuuummmmm??? And when you finaly reacts and acknowledges their callings, after many attempts, it's your turn to get a Huuuuummmmm???
From a generally unaware outsider's perspective, during spurious visiting seasons, a group of alien scalped bovine-like speaking individuals, was convicted inside a flashing and fuming environment, full of every strange piece of equipment, doing whatever kind of work they used to do, only God knows how to or why.
The reason that droves me to occupy as much of the post space with the abobe 'retro' remembrances, is to fully explain why we could now use the Propeller, and bennefit from its capacity, to fully enjoy a precisely shaped clocking scheme.
Carefully studying the timming relationship between each clock's up and down edges, and the corresponding control signal changes, derived from such edges, one can clearly devise a timing relationship between them.
If one chooses to use faster parts, e.g. 20MHz ones, then you must stay at uninteresting states, only the minimum amount of time required to complete all those DETERMINISTIC control signal changes.
After all the needed controlling signals had settled, then the clock toggles state, and remains there an specific amount of time, just to complete the intended cycle tasks.
Cycle by cycle re-shapping the clock LOW and HIGH periods, is the way you can enjoy the maximum instructions per second rate. without having to agregate a single WAIT.
When the Z80 was conceived, even a 2.5 MHz crystal was a very expensive part.
Agree. This from wikipedia
In 1965, typical quantity-one pricing for the SN5400 (military grade, in ceramic welded flat-pack) was around 22 USD.[11] As of 2007, individual commercial-grade chips in molded epoxy (plastic) packages can be purchased for approximately 0.25 USD each, depending on the particular chip.
Schematic idea attached - faster clock by trapping IN and OUT instructions and latching up the Z80. Means the propeller only has to check occasionally for port requests.
Yes I'm not sure about /wait either. I'm writing all the code first in Spin and then later will move over to Pasm. Benchmark test on this site http://bytecruft.blogspot.com.au/2012/08/rudimentary-benchmarks-for-parallax.html suggests that the fastest Spin can clock the Z80 is about 50Khz. That is plenty fast enough for small bootloaders, but initial tests suggest that CP/M would take far too long to load. Pasm is over 100x faster.
Hmm, maybe I'm not getting everything, but why would you want / need to load CP/M (or anything else than the bootloader) via the Propeller?
In my (simplistic) view, once the Z80 has it's bootloader, it simply takes control over the rest of the machine. I must be missing something.
Once the Z80 has it's boot loader it will want to read sectors from disk (which are CP/M or whatever program).
To do that it will ask the propeller to read the sectors from SD. I'm sure that will be faster than having the Z80 bit bang the SD commands and data and it saves code space in the Z80.
Presumably the Prop provides one or more I/O ports through which the Z80 can drive things and exchange data.
Hmm, maybe I'm not getting everything, but why would you want / need to load CP/M (or anything else than the bootloader) via the Propeller?
In my (simplistic) view, once the Z80 has it's bootloader, it simply takes control over the rest of the machine. I must be missing something.
Good point. I'm not sure at which point control gets handed to the Z80.
Thinking from a very practical point of view, the best solution is the one with the smallest propeller code. That then gives the most hub ram for the display (I'd like the option of text or graphics objects). So as soon as possible, the Z80 needs to be reading data from the SD card rather than data from a Spin program. That means a small bootloader, and pass some simple SD commands through ports, eg Open a File, Read Block, Move to Z80 Ram, Close File. Maybe Port 1 is OpenFile, and that gets passed through to the appropriate routine in a Spin object?
KyeDOS can load and run other programs. So KyeDOS can start off in Text mode, then completely reload a binary image off the SD card with Graphics mode (or any pre-compiled Spin program). Once the Z80 is running, it might be useful for the Z80 to be able to pass commands to something like KyeDOS. So the Z80 would then be able to change display objects on the fly, reboot the propeller via a software command, all sorts of clever things.
I haven't really thought that far ahead. Up until now, the aim is to do this with the minimum parts, so it is easy to breadboard and then more people can get involved. With just two chips in post #188 it is now quite simple.
When I designed the Mini80 I wanted to implement a memory banking feature that required 4 of the gates on the 74lv367 buffer. So I used the two extra gates on the 367 to buffer the Z80 /RD and /WT lines. I no longer want the memory banking feature and would like to use the idea of serial resistors on the Z80 /RD and /WT lines to remove the 74LV367 from the design. This would give me one more pin for general I/O.
Has anyone prototyped a Z80 system using the serial resistors on the /RD and /WT lines and then run the Z80 at full speed (say 5Mhz .. 10Mhz)? During the boot loader phase the Z80 is not being clocked at any where near full speed.
Has anyone prototyped a Z80 system using the serial resistors on the /RD and /WT lines and then run the Z80 at full speed (say 5Mhz .. 10Mhz)? During the boot loader phase the Z80 is not being clocked at any where near full speed.
I haven't clocked it at full speed yet. (Too busy with work to test out the circuit in post #188). I would assume the concern would be rise and fall times? Ok, quick search for "input capacitance" for a Z80 and it is 5pf. Plug 220R and 5pf into an online RC low pass filter calculator and it gives an answer of 144Mhz. http://sim.okawa-denshi.jp/en/CRtool.php which has some plots of the transients too. Rolloff doesn't start till about 40Mhz. So it should work fine in theory
If the /RD and /WT pins of the Z80 where close to a perfect source (no internal resistance or capacitance) I would agrree with your analysis. However the low current source and sink capabilities of the Z80 control signals can not considered a perfect source. This combined with the stray capacitance and inductance of the connection will all combine to cause roll off and affect the rise and fall time of the signal. While I agree that at a low frequency this effect would be negligible the question becomes at what frequency will the effect cause failure. This why I asked if any one has actualy tested the design.
The color touch screen that Dr. Acula is/was pursuing is to make a CP/M-in-a-box box.
that could fit in a pocket. A pocket CP/M computer.
With the programming languages and tools available it would be pretty much a cracker jack box.
Do-anything-you-want magic box.
---when he finally gets back to it .. .
Right now, I think he is realizing a dream of hacking the Z80 in the wild.
Shael?
Are there any pre-fab circuit boards for the Mini80 as drawn?
Just the basic serial I/O CP/M machine?
I was studying the existing Propeller boards that might host such a project.
One that would provide a working USB line, regulated power supplies (usually 5v0 and 3v3)
boot EEPROM, and an SD card.
I think the Hodges DNA board might be fairly easy.
The SD card wiring is set by solder-blobs on the bottom.
Without the blobs, the address can be set to almost anything-
solder a wire to the center pad. Just don't blob now!
That way it could match existing software?
(but even if the SD card needs to be tweeked, so what?)
A Propeller Platform Shield with a Z80, RAM, and 74hc165?
(assuming the resistor trick works?)
Option for series resistors between Prop and Z80.
Option for all the console goodies block to it (SD, VGA, Key, Mouse)
I do not have any board layout for the Min80. Board layout not my thing. The PDF on my website is meant to be a replacment for a hand drawn schematic and needs a lot of cleanup work before using as a board layout.
If you just need a 3.3 volt supply the new "Propeller Project Board USB" seams to have enough space to build a simple Mini80 prototype. If you need a 5 volt regulator then I would pickup the "3x4 Blank Proto Board" and just add the required voltage regulator(s). Compared to connectimg the Z80 and RAM adding the voltage regulator(s) should be simple. I do not know much about 3rd party boards, maybe someone else has a suggestion for a sutable board.
This why I asked if any one has actualy tested the design.
I agree we need to do a proper experiment and eliminate confounding factors. In a previous design (which was more like yours and used '245s to isolate lines) I had trouble clocking over about 1Mhz. So there was some other factor on that board as well, and if we do an experiment with the resistors and it can't go over a certain speed, we would need to be sure whether it was the resistors or some other cause.
I'm trying to think of an experiment that we could do. A breadboard design where one can quickly change from gates to resistors and keep pushing the frequency up until it fails.
I do not have any board layout for the Min80. Board layout not my thing. The PDF on my website is meant to be a replacment for a hand drawn schematic and needs a lot of cleanup work before using as a board layout.
If you just need a 3.3 volt supply the new "Propeller Project Board USB" seams to have enough space to build a simple Mini80 prototype. If you need a 5 volt regulator then I would pickup the "3x4 Blank Proto Board" and just add the required voltage regulator(s). Compared to connectimg the Z80 and RAM adding the voltage regulator(s) should be simple. I do not know much about 3rd party boards, maybe someone else has a suggestion for a sutiable board.
The Propeller Platform is one of the Propeller standard boards.
Simple cheap way of adding circuitry to a Propeller.
There are several people who make boards for that platform.
A Z80, a RAM chip and a 165 on a daughter-board might get a
Propeller Platform up and running Mini80.
It's the selection of pins for the SD card that are at issue.
CPMSYSTEM.SPIN is expecting the Micro SD card on pins 24-27.
Martin's board just might work - with a fix.
It is strapped to default P0-P3, but can be changed to use
The DNA board (a Propeller Platform) offers the option of (P0 - P4) or (P16 - P20)
That's the solder block options on the bottom of the board.
There is nothing in the Mini80 using P16-20, so strap that sucker and run with it.
Easier all the way around that way.
While on the subject, Shael, do you have apart number for the RAM chip?
I thought I saw it some place, but can't right now.
Has anyone prototyped a Z80 system using the serial resistors on the /RD and /WT lines and then run the Z80 at full speed (say 5Mhz .. 10Mhz)? During the boot loader phase the Z80 is not being clocked at any where near full speed.
I have prototyped it on a breadboard and am running a 5V 4MHz rated NMOS Z80 at 2.5MHz and at 3.3V, but not full speed yet. Suprisingly undervolting it to 3.3V apparently worked okay on the breadboard. It was not really stress tested however so I would like to spend more time to try it at its full rated speed of 4MHz and run RAM tests etc to be more confident but have to plan other things right now and just can't really give it any more attention unfortunately (I really want to).
My resistors used on the /RD and /WR signals were 2.2k between prop and Z80. I also had some 4.7k pullups on the Z80 side of these signals to the supply. This same setup worked for me both at 5V and 3.3V. I think Dr_Acula is planning much lower resistances for these resistors, actually 10x lower. I wanted my resistors to be larger for the 5V to 3.3V protection when I was running at 5V. Using 220 ohms should improve the rise/fall times over what I had by around the same 10x factor (unless the NMOS Z80 had less much less capacitance than a CMOS version to begin with). So based on this preliminary result I'm still expecting there's a reasonable chance the signal integrity will be okay. CMOS Z80's may be able to push more current through the resistors during logic high as well compared to the older NMOS one I have and that should help even more.
I have to complete a couple of articles on my website and then I should be able to get back to this project. I took a quick look at my Min80 prototype and the changes to the hardware should not take much effort. The software changes should only affect the boot loader code so I am going to give it a try. I was not comfortable using the low resistance value (@ 220 ohms) it is good to know that it may work at a higher resistance.
Hi Richard;
The memory chips I got came from www.jameco.com they use various suppliers. They only list one 3.3 volt 128K RAM in DIP format.
The only pins that would cause a problem is if the SD card was on pins P0...P7 all the other pin numbers can be altered (as far as I can remember).
If the 74lv367 can be removed, I want to revisit removing the 74hc165 as well.
For my own use I would like to end up with the following I/O for my next prototype;
1) 2 pin mono TV out 80x24 ansi terminal. (2 COGs)
2) 2 pin PS2 keyboard (1 COG)
3) 4 pin Rs232 port (could also be used to program Prop chip) (1 COG)
4) I2C 16 bit register (16 bits of low speed I/O, printer, control relay, Led, read switches...) (1 COG)
5) I2C RTC
6) 4 pin SD card interface. (1 COG)
There is no room for a VGA display because it would need 2 COGs for video rasterizer. If I need a VGA terminal can always use a PropTerm connected to the RS232 or I2C. This gives a complete computer comparable to many of the early CPM systems you could buy at the time.
I can see how maybe the 'LV367 could be removed, but the 'HC165 serves a higher purpose...
How would the low address byte be returned?
Looking at the max clock rates for some of the byte-wide transparent latches, it still looks
like a 8MHZ or so top operating speed for the Z80. The 'LVC367 can do better than that - maybe twice that?.
LEGO sketch for wigging out the wires. and the signals to the RAM chip..etc
It's a simple little circuit, really.
Using a 74LVC540 would top out about 20 mhz for the Z80
(5.1 ns is not bad though)
Is it possible to slow the speed down just for IORQ?
What I'm wondering is that because the propeller has control of the clock it is possible to do things that are a bit non-standard. So with a latchup where /IORQ goes to /WAIT (resistor, or latch or flip flop), then any IORQ instruction can be processed as slow as needed. Then speed it back up. Most of the time it will be running at full speed which is just the Z80 and Ram so it is super simple and not limited by the speed of any other chips.
If you apply both /INT low and /WAIT low at the same time the Z80 will respond to the /INT signal as long as the /WAIT is not applied before T2 of the currently executing opcode. The /INT signal is read at the end of the currently executing opcode.
If you wait until /IORQ and /M1 to go low then stop the clock you can take as long as you want as the Z80 is a static core.
The first issue I can think of is that the /INT signal is async to the Z80 so if the /WAIT and /INT go low while in an opcode before T2 (or one clock later if an I/O opcode) then /WAIT will prevent the Z80 from executing the /INT signal.
The second point applies to mode 2 interrupts on the Z80 only. In mode 2 interrupts must be held until the interrupt responce code executes an EOI opcode indicating the interrupt service routine is completed.
In the case of the Min80 I stop the clock for all I/O operations, let the Prop handle the request then restart the Z80 clock. This way an I/O operation can take as long as required.
Hi Richard;
The I/O I specified for my next prototype will require 14 pins. If I can remove the 74lv367 that frees up a pin on the Prop. There are 2 dedicated pins for the 74hc165 if this IC is also removed that makes 3 free pins plus 2 left over from the I.O gives me five free pins.
With five pins I could read the port address directly a from the Z80 but will only have a 32 port address range. If I can map all the I/O into a 32 port address range no need for the 74hc165.
1) 2 pin mono TV out 80x24 ansi terminal. (2 COGs)
........
There is no room for a VGA display because it would need 2 COGs for video rasterizer. If I need a VGA terminal can always use a PropTerm connected to the RS232 or I2C. This gives a complete computer comparable to many of the early CPM systems you could buy at the time.
How about using a second Propeller with VGA display? (2 pin serial)
This thread has been one of the most interesting reads all month...
How about using a second Propeller with VGA display? (2 pin serial)
Jeff
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.
@Shael - you have some brilliant ideas. Running the whole thing at lower voltage. Booting with less chips. I'm having trouble keeping up!
The second point applies to mode 2 interrupts on the Z80 only. In mode 2 interrupts must be held until the interrupt responce code executes an EOI opcode indicating the interrupt service routine is completed.
Mode 2 interrupts you say? Back to the Z80 manual...
Back now. Ok, I think I am coming up to speed with what you are doing.
The I/O I specified for my next prototype will require 14 pins.
Yes I have been drawing up a schematic with 14 pins as well. The propeller never seems to have enough pins and so I am designing a board with a MCP23017. Ok, it is another chip so not truly minimalist. But what I want is a 50 pin header coming off the propeller motherboard - some pins for voltages, then the 32 propeller pins P0-P31. And then I'm going to call the 16 I/O pins from the MCP23017 as P32-P47 and think of them as 'slow propeller' pins.
I think it may make interfacing to other boards easier as sometimes pins need to be fast and sometimes they can be slow. An example is the 4 pins to talk to an SD card. The DI, DO and Clk pins need to be fast. But the /CS pin can be a slow pin. And that saves a fast propeller pin for something else.
Ditto things like diagnostic leds - they can be slow pins.
In a general sense, all the pins needed to boot up the Z80 can be slow pins. If that saves some fast pins for the IORQ interface, that has to be useful.
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.).
So three pins saved so far. I'm still in two minds about mono or stereo sound - that might save another pin. Maybe that means more address pins available and hence more ports available?
Lots of possibilities and fun to think about all the designs we could build
@Shael - you have some brilliant ideas. Running the whole thing at lower voltage. Booting with less chips. I'm having trouble keeping up!
Mode 2 interrupts you say? Back to the Z80 manual...
Back now. Ok, I think I am coming up to speed with what you are doing.
Yes I have been drawing up a schematic with 14 pins as well. The propeller never seems to have enough pins and so I am designing a board with a MCP23017. Ok, it is another chip so not truly minimalist. But what I want is a 50 pin header coming off the propeller motherboard - some pins for voltages, then the 32 propeller pins P0-P31. And then I'm going to call the 16 I/O pins from the MCP23017 as P32-P47 and think of them as 'slow propeller' pins.
I think it may make interfacing to other boards easier as sometimes pins need to be fast and sometimes they can be slow. An example is the 4 pins to talk to an SD card. The DI, DO and Clk pins need to be fast. But the /CS pin can be a slow pin. And that saves a fast propeller pin for something else.
Ditto things like diagnostic leds - they can be slow pins.
In a general sense, all the pins needed to boot up the Z80 can be slow pins. If that saves some fast pins for the IORQ interface, that has to be useful.
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.).
So three pins saved so far. I'm still in two minds about mono or stereo sound - that might save another pin. Maybe that means more address pins available and hence more ports available?
Lots of possibilities and fun to think about all the designs we could build
Here's another crazy idea I had to save another pin...it's a bit of a hack but it might work if more pins are needed.
Just wondering for a minimalist version if we could multi purpose /WR and /RD outputs on the prop even further to create the /RESET for the Z80. How about 2 diodes with a wired or function between them? I don't think during "normal" Z80 functions they could both be low. Care would obviously need to be taken during the bootloading sequence to prevent multiple resets if the prop is driving both read and write lines. Also if both signals are active I wonder if the SRAM would want to do a read or a write? Perhaps /MREQ (/CS) could remain high to prevent any access, but I guess there still exists a possibility of a brief SRAM write during the reset that could potentially overwrite memory, that may be bad for warm booting systems.
You would want a fairly large pulldown resistor, eg more than 2 times pullup resistors on the /RD and /WR bus lines on the prop side to keep the Z80 reset pin voltage high enough during any times while no-one is actively driving both /WR and /RD high, though maybe that's only possible if /BUSACK is active and Z80 tri-states these pins.
Comments
Thanks cavelamb, still a picture is worth a thousand words of mine, wobbling throughout a post.
I'm going to complain solely that one can use a single gate inverter, or any other spare inverting function, to solely process the /IORQ signal.
In the absolute absence of any available victims, one of these internaly biased BJT's and a pullup resistor will cost almost nothing in real state and money.
The exemption of interrupt acknowledge cycles from latching the lower address lines and letting them being read at the data bus side, adds about nothing to the intended solution.
INTA cycles does not presents any /RD nor /WR controlling signals, so that's the way to clearly distinguish them from I/O operations.
The same applies to /RD or /WR without /IORQ; except for a flawed Z80 erratic behavior, they must be an instruction fetch or memory read (/RD alone), or memory write (/WR alone) operations.
Elaborating a bit, if at any point, you need to exercise some MODE 2 interrupts, or peacefully live with any of Z80's peripheral chips, then you'll certainly enjoy knowing the exact vector that was sent by the device that wins the daysi-chained IEI/IEO scheme, and caused the Z80's to capture the interrupt service routine start address, using (256 x Ireg + Vector) as a pointer in a jump address table.
I register contents is something you could preview, or at least extract with the help of a code snippet.
Interrupt vectors are such a kind of flying entities, some times behaving as Autobots, then some Decepticons do start a riot, then you blink an eye, and everything changed again.
Add a paged memory strategy, perhaps a interrupt driven one, to the scenario.
I'd agreed 100% with Chip's design philosophy, when i realized that the way he chooses for Propellers to deal with on-the-fly events, is the best one.
The terms "Bogus" and "OS bugs" do share the same letters, and many times, the same origins... Interrupts!
But, trying to guess where to put some wise breakpoints, only to stop the bull run with a shaking hand, always seems to me some kind of painfull russian roulette!
Props are a winning bet!
Yanomani
Thank you, Dr_Acula, for the opportunity you gave me to help a bit!
Yanomani
Thank you, rogloh and you've a great job done, calculating all those relationships!
Your work makes me wonder if (it's only a dream) and how you can use WAITVID stuff to bitbang Z80's clock wave shape, based on your knowledge of 'what sequence of events to do next', and using some more COGs in sync as needed to keep things under Propeller's tight control, boosting overall system's performance!
No, no, no! It's just a dream, sure it will be impossible to do!:cool:
Yanomani
Ok, here is another crazy idea. What would happen if you connected the Z80 /IORQ to /WAIT ? Would it simply latch up the Z80 and stop it running the first time it does an OUT or IN instruction. Not very exciting. Others have mentioned latches. But what if you connected the Z80 /IORQ and /WAIT pins together with a 220R resistor. Now connect the /WAIT pin to a propeller pin (it could be the pin that was used for the /IORQ sampling).
Z80 is running along super fast and executes a /IORQ and latches up. Now it is only necessary to sample this propeller pin infrequently. Unroll a lot of high/low/high/low clock instructions in pasm and sample every 10th clock pulse. Or even another cog can do the sampling and the clock can be run from a faster waitvid.
Can the /WAIT be cleared? It seems to me it should work. The Z80 is in latchup. Propeller samples the /WAIT line (which actually reflects the /IORQ line via the resistor) and samples /rd and /wr and the data bus and puts data on the bus or reads from the bus. And then it forces the /WAIT line high (which won't harm the /IORQ line as the resistor limits the current) and clocks the Z80 until /IORQ goes high (2 or 3 clocks), and then makes the propeller pin HiZ.
There has to be some sort of obvious catch...
Z80 /IORQ - 220 ohm resistor - prop pin & Z80 /WAIT (/WAIT also gets pulled up via a 10k on Z80's /IORQ side whenever IORQ is tri-stated).
Then for each I/O access the wait is auto-triggered, and the prop has as long as it wants to respond. All the prop pin has to do at the end of the I/O transaction is to pull its own /IORQ line high for 1-2 Z80 clock cycles (this may need tuning) and force /WAIT to go high. The /WAIT will go high, and /IORQ will be deasserted by the Z80, then the prop has to tristate its /IORQ sense pin and wait for /IORQ to go low again to start again. There is no problem with simultaneously bus driving because the 220 ohm resistor saves us. May want to use a slightly higher value.
NICE because it also saves a pin and we get stereo out again with the WAIT as well !!!!
I hope you can do a simple mod on your board and try this out Dr_Acula. If I can I will try it too in my setup in the next couple of days hopefully.
Only catch I see might be the interrupt acknowledge cycles. They need to be handled as well because /WAIT is sampled for those too. But prop can look for /IORQ low and /RD high and /WR high to deal with it.
Roger.
Not only for a faster clock. There is a lot more behind the scene.
When the Z80 was conceived, even a 2.5 MHz crystal was a very expensive part.
You had to carefully select its cut shape and oscillation mode to match the intended application.
Adding loading caps and an inverter ring to create a 'quasi stable' oscillator, that faithfully started at almost every power on, and can be repeated many thousands of times, perhaps millions, under different relative humidity, temperature and biasing conditions, could consume all your hair and nails, for weeks.
Your eyes were saturated by many hours of exposure to warm whites, blurry greens or hepatic yellowish oscilloscope screens, behind some orangish reticulated "bird nets", in search for the holy grail biasing network, that accomplishes all of the above AND a reasonable 50/50 square wave.
Pray God many times, so it keeps forever running, provided there is a proper power source applied to it.
Your fingers were injured by repeatedly adjusting the time base and fine scale controls.
Tap a single nail tip at the DC bias adjustment knob, and everything just vanishes from the screen or start sliding right or leftwards, like a crazy race car, running near a bright and endless fence.
Just after a couple of sweaty hours, and a decision must be taken: you need to focus the wave shape at the screen, your DVM lcd or the white paper sheets with specs, calculations and "guess what" side notes. You simply can't do any two of them with the single pair of eyes you had born with. The more your brain focus, the less your peripheric vision can catch anything. Co-workers have to call your name (or alias) many and many times, before your forgotten mouth can release a simple Huuuuummmmm??? And when you finaly reacts and acknowledges their callings, after many attempts, it's your turn to get a Huuuuummmmm???
From a generally unaware outsider's perspective, during spurious visiting seasons, a group of alien scalped bovine-like speaking individuals, was convicted inside a flashing and fuming environment, full of every strange piece of equipment, doing whatever kind of work they used to do, only God knows how to or why.
The reason that droves me to occupy as much of the post space with the abobe 'retro' remembrances, is to fully explain why we could now use the Propeller, and bennefit from its capacity, to fully enjoy a precisely shaped clocking scheme.
Carefully studying the timming relationship between each clock's up and down edges, and the corresponding control signal changes, derived from such edges, one can clearly devise a timing relationship between them.
If one chooses to use faster parts, e.g. 20MHz ones, then you must stay at uninteresting states, only the minimum amount of time required to complete all those DETERMINISTIC control signal changes.
After all the needed controlling signals had settled, then the clock toggles state, and remains there an specific amount of time, just to complete the intended cycle tasks.
Cycle by cycle re-shapping the clock LOW and HIGH periods, is the way you can enjoy the maximum instructions per second rate. without having to agregate a single WAIT.
Yanomani
Agree. This from wikipedia
Schematic idea attached - faster clock by trapping IN and OUT instructions and latching up the Z80. Means the propeller only has to check occasionally for port requests.
In my (simplistic) view, once the Z80 has it's bootloader, it simply takes control over the rest of the machine. I must be missing something.
To do that it will ask the propeller to read the sectors from SD. I'm sure that will be faster than having the Z80 bit bang the SD commands and data and it saves code space in the Z80.
Presumably the Prop provides one or more I/O ports through which the Z80 can drive things and exchange data.
Good point. I'm not sure at which point control gets handed to the Z80.
Thinking from a very practical point of view, the best solution is the one with the smallest propeller code. That then gives the most hub ram for the display (I'd like the option of text or graphics objects). So as soon as possible, the Z80 needs to be reading data from the SD card rather than data from a Spin program. That means a small bootloader, and pass some simple SD commands through ports, eg Open a File, Read Block, Move to Z80 Ram, Close File. Maybe Port 1 is OpenFile, and that gets passed through to the appropriate routine in a Spin object?
KyeDOS can load and run other programs. So KyeDOS can start off in Text mode, then completely reload a binary image off the SD card with Graphics mode (or any pre-compiled Spin program). Once the Z80 is running, it might be useful for the Z80 to be able to pass commands to something like KyeDOS. So the Z80 would then be able to change display objects on the fly, reboot the propeller via a software command, all sorts of clever things.
I haven't really thought that far ahead. Up until now, the aim is to do this with the minimum parts, so it is easy to breadboard and then more people can get involved. With just two chips in post #188 it is now quite simple.
Place it in front, to the rear, below or above of you. The other options tends to lead to the other half getting into a right strop!
When I designed the Mini80 I wanted to implement a memory banking feature that required 4 of the gates on the 74lv367 buffer. So I used the two extra gates on the 367 to buffer the Z80 /RD and /WT lines. I no longer want the memory banking feature and would like to use the idea of serial resistors on the Z80 /RD and /WT lines to remove the 74LV367 from the design. This would give me one more pin for general I/O.
Has anyone prototyped a Z80 system using the serial resistors on the /RD and /WT lines and then run the Z80 at full speed (say 5Mhz .. 10Mhz)? During the boot loader phase the Z80 is not being clocked at any where near full speed.
I haven't clocked it at full speed yet. (Too busy with work to test out the circuit in post #188). I would assume the concern would be rise and fall times? Ok, quick search for "input capacitance" for a Z80 and it is 5pf. Plug 220R and 5pf into an online RC low pass filter calculator and it gives an answer of 144Mhz. http://sim.okawa-denshi.jp/en/CRtool.php which has some plots of the transients too. Rolloff doesn't start till about 40Mhz. So it should work fine in theory
If the /RD and /WT pins of the Z80 where close to a perfect source (no internal resistance or capacitance) I would agrree with your analysis. However the low current source and sink capabilities of the Z80 control signals can not considered a perfect source. This combined with the stray capacitance and inductance of the connection will all combine to cause roll off and affect the rise and fall time of the signal. While I agree that at a low frequency this effect would be negligible the question becomes at what frequency will the effect cause failure. This why I asked if any one has actualy tested the design.
that could fit in a pocket. A pocket CP/M computer.
With the programming languages and tools available it would be pretty much a cracker jack box.
Do-anything-you-want magic box.
---when he finally gets back to it .. .
Right now, I think he is realizing a dream of hacking the Z80 in the wild.
Shael?
Are there any pre-fab circuit boards for the Mini80 as drawn?
Just the basic serial I/O CP/M machine?
I was studying the existing Propeller boards that might host such a project.
One that would provide a working USB line, regulated power supplies (usually 5v0 and 3v3)
boot EEPROM, and an SD card.
I think the Hodges DNA board might be fairly easy.
The SD card wiring is set by solder-blobs on the bottom.
Without the blobs, the address can be set to almost anything-
solder a wire to the center pad. Just don't blob now!
That way it could match existing software?
(but even if the SD card needs to be tweeked, so what?)
A Propeller Platform Shield with a Z80, RAM, and 74hc165?
(assuming the resistor trick works?)
Option for series resistors between Prop and Z80.
Option for all the console goodies block to it (SD, VGA, Key, Mouse)
A "Mini80 Shield"?
I do not have any board layout for the Min80. Board layout not my thing. The PDF on my website is meant to be a replacment for a hand drawn schematic and needs a lot of cleanup work before using as a board layout.
If you just need a 3.3 volt supply the new "Propeller Project Board USB" seams to have enough space to build a simple Mini80 prototype. If you need a 5 volt regulator then I would pickup the "3x4 Blank Proto Board" and just add the required voltage regulator(s). Compared to connectimg the Z80 and RAM adding the voltage regulator(s) should be simple. I do not know much about 3rd party boards, maybe someone else has a suggestion for a sutable board.
I agree we need to do a proper experiment and eliminate confounding factors. In a previous design (which was more like yours and used '245s to isolate lines) I had trouble clocking over about 1Mhz. So there was some other factor on that board as well, and if we do an experiment with the resistors and it can't go over a certain speed, we would need to be sure whether it was the resistors or some other cause.
I'm trying to think of an experiment that we could do. A breadboard design where one can quickly change from gates to resistors and keep pushing the frequency up until it fails.
The Propeller Platform is one of the Propeller standard boards.
Simple cheap way of adding circuitry to a Propeller.
There are several people who make boards for that platform.
A Z80, a RAM chip and a 165 on a daughter-board might get a
Propeller Platform up and running Mini80.
It's the selection of pins for the SD card that are at issue.
CPMSYSTEM.SPIN is expecting the Micro SD card on pins 24-27.
Martin's board just might work - with a fix.
It is strapped to default P0-P3, but can be changed to use
The DNA board (a Propeller Platform) offers the option of (P0 - P4) or (P16 - P20)
That's the solder block options on the bottom of the board.
There is nothing in the Mini80 using P16-20, so strap that sucker and run with it.
Easier all the way around that way.
While on the subject, Shael, do you have apart number for the RAM chip?
I thought I saw it some place, but can't right now.
I have prototyped it on a breadboard and am running a 5V 4MHz rated NMOS Z80 at 2.5MHz and at 3.3V, but not full speed yet. Suprisingly undervolting it to 3.3V apparently worked okay on the breadboard. It was not really stress tested however so I would like to spend more time to try it at its full rated speed of 4MHz and run RAM tests etc to be more confident but have to plan other things right now and just can't really give it any more attention unfortunately (I really want to).
My resistors used on the /RD and /WR signals were 2.2k between prop and Z80. I also had some 4.7k pullups on the Z80 side of these signals to the supply. This same setup worked for me both at 5V and 3.3V. I think Dr_Acula is planning much lower resistances for these resistors, actually 10x lower. I wanted my resistors to be larger for the 5V to 3.3V protection when I was running at 5V. Using 220 ohms should improve the rise/fall times over what I had by around the same 10x factor (unless the NMOS Z80 had less much less capacitance than a CMOS version to begin with). So based on this preliminary result I'm still expecting there's a reasonable chance the signal integrity will be okay. CMOS Z80's may be able to push more current through the resistors during logic high as well compared to the older NMOS one I have and that should help even more.
Roger.
I have to complete a couple of articles on my website and then I should be able to get back to this project. I took a quick look at my Min80 prototype and the changes to the hardware should not take much effort. The software changes should only affect the boot loader code so I am going to give it a try. I was not comfortable using the low resistance value (@ 220 ohms) it is good to know that it may work at a higher resistance.
Hi Richard;
The memory chips I got came from www.jameco.com they use various suppliers. They only list one 3.3 volt 128K RAM in DIP format.
The only pins that would cause a problem is if the SD card was on pins P0...P7 all the other pin numbers can be altered (as far as I can remember).
If the 74lv367 can be removed, I want to revisit removing the 74hc165 as well.
For my own use I would like to end up with the following I/O for my next prototype;
1) 2 pin mono TV out 80x24 ansi terminal. (2 COGs)
2) 2 pin PS2 keyboard (1 COG)
3) 4 pin Rs232 port (could also be used to program Prop chip) (1 COG)
4) I2C 16 bit register (16 bits of low speed I/O, printer, control relay, Led, read switches...) (1 COG)
5) I2C RTC
6) 4 pin SD card interface. (1 COG)
There is no room for a VGA display because it would need 2 COGs for video rasterizer. If I need a VGA terminal can always use a PropTerm connected to the RS232 or I2C. This gives a complete computer comparable to many of the early CPM systems you could buy at the time.
How would the low address byte be returned?
Looking at the max clock rates for some of the byte-wide transparent latches, it still looks
like a 8MHZ or so top operating speed for the Z80. The 'LVC367 can do better than that - maybe twice that?.
LEGO sketch for wigging out the wires. and the signals to the RAM chip..etc
It's a simple little circuit, really.
A current sketch of a parallel address latch version of the Mini80.
Did you have something different in mind?
Using a 74LVC540 would top out about 20 mhz for the Z80
(5.1 ns is not bad though)
HC version of that chip should run comfortably at 10 mhz.
About the same as it is with the 'HC/LVC165.
Is it possible to slow the speed down just for IORQ?
What I'm wondering is that because the propeller has control of the clock it is possible to do things that are a bit non-standard. So with a latchup where /IORQ goes to /WAIT (resistor, or latch or flip flop), then any IORQ instruction can be processed as slow as needed. Then speed it back up. Most of the time it will be running at full speed which is just the Z80 and Ram so it is super simple and not limited by the speed of any other chips.
If you apply both /INT low and /WAIT low at the same time the Z80 will respond to the /INT signal as long as the /WAIT is not applied before T2 of the currently executing opcode. The /INT signal is read at the end of the currently executing opcode.
If you wait until /IORQ and /M1 to go low then stop the clock you can take as long as you want as the Z80 is a static core.
The first issue I can think of is that the /INT signal is async to the Z80 so if the /WAIT and /INT go low while in an opcode before T2 (or one clock later if an I/O opcode) then /WAIT will prevent the Z80 from executing the /INT signal.
The second point applies to mode 2 interrupts on the Z80 only. In mode 2 interrupts must be held until the interrupt responce code executes an EOI opcode indicating the interrupt service routine is completed.
In the case of the Min80 I stop the clock for all I/O operations, let the Prop handle the request then restart the Z80 clock. This way an I/O operation can take as long as required.
Hi Richard;
The I/O I specified for my next prototype will require 14 pins. If I can remove the 74lv367 that frees up a pin on the Prop. There are 2 dedicated pins for the 74hc165 if this IC is also removed that makes 3 free pins plus 2 left over from the I.O gives me five free pins.
With five pins I could read the port address directly a from the Z80 but will only have a 32 port address range. If I can map all the I/O into a 32 port address range no need for the 74hc165.
How about using a second Propeller with VGA display? (2 pin serial)
This thread has been one of the most interesting reads all month...
Jeff
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.
Mode 2 interrupts you say? Back to the Z80 manual...
Back now. Ok, I think I am coming up to speed with what you are doing.
Yes I have been drawing up a schematic with 14 pins as well. The propeller never seems to have enough pins and so I am designing a board with a MCP23017. Ok, it is another chip so not truly minimalist. But what I want is a 50 pin header coming off the propeller motherboard - some pins for voltages, then the 32 propeller pins P0-P31. And then I'm going to call the 16 I/O pins from the MCP23017 as P32-P47 and think of them as 'slow propeller' pins.
I think it may make interfacing to other boards easier as sometimes pins need to be fast and sometimes they can be slow. An example is the 4 pins to talk to an SD card. The DI, DO and Clk pins need to be fast. But the /CS pin can be a slow pin. And that saves a fast propeller pin for something else.
Ditto things like diagnostic leds - they can be slow pins.
In a general sense, all the pins needed to boot up the Z80 can be slow pins. If that saves some fast pins for the IORQ interface, that has to be useful.
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.).
So three pins saved so far. I'm still in two minds about mono or stereo sound - that might save another pin. Maybe that means more address pins available and hence more ports available?
Lots of possibilities and fun to think about all the designs we could build
Here's another crazy idea I had to save another pin...it's a bit of a hack but it might work if more pins are needed.
Just wondering for a minimalist version if we could multi purpose /WR and /RD outputs on the prop even further to create the /RESET for the Z80. How about 2 diodes with a wired or function between them? I don't think during "normal" Z80 functions they could both be low. Care would obviously need to be taken during the bootloading sequence to prevent multiple resets if the prop is driving both read and write lines. Also if both signals are active I wonder if the SRAM would want to do a read or a write? Perhaps /MREQ (/CS) could remain high to prevent any access, but I guess there still exists a possibility of a brief SRAM write during the reset that could potentially overwrite memory, that may be bad for warm booting systems.
You would want a fairly large pulldown resistor, eg more than 2 times pullup resistors on the /RD and /WR bus lines on the prop side to keep the Z80 reset pin voltage high enough during any times while no-one is actively driving both /WR and /RD high, though maybe that's only possible if /BUSACK is active and Z80 tri-states these pins.
Vcc | Pullup Resistor | | Z80 /RD <---- Current Resistor -----> Prop /RD < ---------------bus ----------------------> SRAM /OE | |+ Diode |- Pulldown | GND <--- Resistor---------------------------------------> Z80 /RESET | | Vcc |- | Diode Pullup Resistor |+ | | | Z80 /WR <----- Current Resistor -----> Prop /WR <---------------bus ------------------------> SRAM /WE