There is one important concern about using the Z80 /NMI, at least at CP/M realm.
Its the fact that, without 'stealth' technics (more on this subject later), one cannot manage to use the NMI routine entry address at 0066h since its inside the default FCB area, starting from 005Ch and that spans for 33 byte, ending at 007Dh.
Having your last schematics printed on a 6 sheet large mosaic, I noticed that the RAM /CE line is still straightly connected to Z80's /MREQ.
Have you realized that, doing this way, it became impossible to send instructions from the Propeller to be executed by the Z80, because each read or write operation that is to be memory directed, will enable the RAM chip thru /CE?
Moreover, if you desire to traverse data directly from memory to the display interface, without being forced to use solely Z80 I/O operations to do that, its necessary to de-gate the RAM during instruction fetches (and their associated immediate data or address components), in order to finally attain the desired behavior, i believed was intended, of using the Z80 as a 'mule beast' address carrier?
Yanomani
@Yanomani,
The general idea as far as I understand it would be to have the Propeller acting purely an I/O device during normal operation, but during bootup also intercepting the Z80's memory read accesses and overriding the /RD signal to the SRAM with its own output so the SRAM won't be accessed and drive the bus. Hence the current protection resistor on the /RD line to avoid a direct short. Meanwhile the Propeller feeds the data bus with bootup instructions that then write the bootcode to main memory. So there is no issue with the /MREQ driving /CE of the SRAM all the time from what I can tell. It is also required for the writes from the Z80.
Also I know the Microbee computers (somewhat successful Australian Z80 based computer around in the mid 80's) would run CP/M and also used /NMI when holding down the reset switch for 1-2 seconds or more. I don't know if they used any particular stealth techniques or relocated their FCBs somewhere else in memory. But it seemed to work out ok on that platform and was never a major issue from what I can tell during usage. So hopefully /NMI is possible to use for interrupts at least in some way. There's always the regular interrupt pin as well if needed.
Actually I just realized the Microbee did something special here during /NMI and full cold reset. It had what was known a "jump latch" which was activated upon /RESET or /NMI and would inject NOPs until the higher ROM address was decoded at which point it stopped and regular opcodes were returned. So you are right, and it did use a special stealth technique.
The circuit's proposed behavior, that I'm trying to describe, will enable things like 'stealth' breakpointing, even if your circuit used a Flash memory, or a two memory chips setup, RAM and Eprom, for example.
At any point, you will be able to stop (by say the use of a 'stealth' HALT instruction) that does not in fact resides in your memory at all. Does not 'bloats' code nor data space.
You will be able to 'pause', 'inspect' then 'react' inside any running system, from the outside in. Without leaving a clue, perhaps, of being there, as an untraceable sniffer!
Sure provided none registers nor RAM, port of something else's content is disturbed in the operation.
Actually I just realized the Microbee did something special here during /NMI and full cold reset. It had what was known a "jump latch" which was activated upon /RESET or /NMI and would inject NOPs until the higher ROM address was decoded at which point it stopped and regular opcodes were returned. So you are right, and it did use a special stealth technique.
Hi rogloh
But since we have no ROM nor FLASH, in fact nothing but the RAM itself, we must 'create our own', during 'cold boot phase one' to live with.
Your explainned technic could be of great value too, if needed, in a 'warm boot' situation, to 'skip' O.S. body, and hit a properly reserved area, at higher memory addresses.
Or even both technics can be combined, to create an operational ROM (perhaps protecting it from being written in a latter time, until the next power down cycle) at high memory, even at the last page....
Yanomani
P.S. I just realized that the 'jump latch' you explained in your post, must be de-gating normal RAM reads, or the circuit has some 'man in the middle' that 'defeats' data read from RAM memory, till the higher addressed ROM area is reached, by an almost 'walking in the (NOP) dark, blind zombie' Z80.
@Yanomani,
Yes it used a 74LS245 bidirectional transceiver on the Z80 databus and pulldown resistors between the CPU and this '245. When the jump latch was activated after reset it tristated this transceiver and the CPU only saw NOPs from the pulldowns until the address reached a ROM address and this jump latch was disabled. It was a pretty cool technique but probably not exclusive to microbees alone.
The RAM, during the 'cold boot one' period, must be disabled for read operations, in order to not conflict with the Propeller, that tries to 'stuff' instructions to be executed by the Z80. Those instructions, at their turns, will 'read' data from the Propeller (in fact, the programm that will be written to the RAM chip, before the Z80 can execute it, on 'not so cold boot' phase) then 'write' the programm sequence as 'data' into the RAM, during the very instruction 'fetch' cycle, if needed.
I know we haven't tested it as yet, but the theory is...
1) Reset
2) Clock the Z80 until detect /RD goes low.
At this point the Z80 would be reading data from address 0000H. The reality of a ram chip starting up is this address will contain a random byte. So, Z80 is reading random data. /MREQ is low and /RD is low and the ram chip is enabled.
3) The propeller puts a bootstrap byte on the data bus.
4) The propeller pulls /RD high which will work due to the current limiting resistor.
5) The propeller pulls /WR low and then high, which writes the byte into the ram
6) The propeller releases the /RD line which then goes low due to the Z80 pulling it low
7) The propeller then puts zero on the data bus.
8) The propeller then clocks the Z80 which then tries to read data from address 0001
As far as I can see, the ram has to be enabled otherwise data cannot be written to the ram.
After a bit of thinking, I realized that such technic we are trying to figure out how to properly do, can be viewed as a Z80 assisted (but as a 'mule address provider', it does not interfere with the 'data cargo' contents) DMA from the Propeller to the RAM, but since we have no pins to spare at Propeller's side, to do address generation, then we call for Z80's help to do this, for us.
The address lines will be 'the mule provided legs'.
The data the Propeller writes into the RAM, are the 'seeds' it plants in the way, before commanding the Z80 to do the next step.
The NOPs it feeds the Z80 with, are the 'carrots' it uses, to convince the Z80 to blindly follow programmer's intended behavior.
Its control lines, will be the 'symbols' it uses to inform to the Propeller, how many steps it has done since the beggining (reset).
I know we haven't tested it as yet, but the theory is...
1) Reset
2) Clock the Z80 until detect /RD goes low.
At this point the Z80 would be reading data from address 0000H. The reality of a ram chip starting up is this address will contain a random byte. So, Z80 is reading random data. /MREQ is low and /RD is low and the ram chip is enabled.
3) The propeller puts a bootstrap byte on the data bus.
4) The propeller pulls /RD high which will work due to the current limiting resistor.
5) The propeller pulls /WR low and then high, which writes the byte into the ram
6) The propeller releases the /RD line which then goes low due to the Z80 pulling it low
7) The propeller then puts zero on the data bus.
8) The propeller then clocks the Z80 which then tries to read data from address 0001
As far as I can see, the ram has to be enabled otherwise data cannot be written to the ram.
Yes, for sure, it must be anabled, under Propeller's control, for read and write to the RAM, were appropriate.
Aniway, the Propeller will be the solely data bus contents provider, during the whole 'cold boot one', except, perhaps, if it chooses to verify what was written inside the RAM, but without releasing the Z80 to do the next step, until the operation is done.
Then, with RAM's /RD and /WR held inactive, under Propellers control, it feeds the Z80 a NOP, and restarts clocking it, till the next /M1 and so on.
The Z80 will be the solely address provider, under control of Propeller's running code.
I just figured it now.
In a insight, I rememberd from many RAM datasheets, I'm not sure that's the present case with the RAM you use in the circuit, if we use /M1 from the Z80, gated at this specific time, as the RAM /WR signal, afterwards, when the Z80 pulls down the /RD line, it will be ignored by the RAM chip at all.
I must read the intended RAM datasheet, I recalled that behavior from 6116's one.
So, no need for an independent read control at this time, since /M1 will arrive even sooner than /MREQ. Maybe we must combine /MREQ with /M1 in an OR gate, that combined with a Propeller's generated Special Enable signal, will be finally ANDed with the Z80 /WR signal, to generate the early RAM /WR that will de-gate its data bus from being read at all.
When the Propeller finishes writing on it, it them de-gates its controlling signal, and reads back the data it just had written on it, verifying its contents, since now the RAM will be controlled by the steady /RD signal comming from the Z80.
Then the Propeller forces RAM /RD to go HIGH, tri-stating its output, and now the Propeller can enable it's own buffers, and send a NOP to the Z80.
I must read the RAM datasheet to check its behavior.
@Yanomani,
Yes it used a 74LS245 bidirectional transceiver on the Z80 databus and pulldown resistors between the CPU and this '245. When the jump latch was activated after reset it tristated this transceiver and the CPU only saw NOPs from the pulldowns until the address reached a ROM address and this jump latch was disabled. It was a pretty cool technique but probably not exclusive to microbees alone.
Just now i'm chomping an older than Matusalem quartz windowed 8k x 8 eprom, only to remember how tasty an almost steady bit used to be in the past.
Even the 'hardwired' term has not the same meaning.
I read on the newspaper, real memories are to be 'implanted' in the near future.
For now we, the ones who are not initiated at molecular biology (except sir Dr_Acula, perhaps), can finally 'implant' memories into an 'almost living' Z80. Without any ethic concerns, at least.
Yanomani
P.S> ONE more huge BINGO!!
As per AS6C4008 Alliance's datasheet!
Write cicle type 2, CE# controlled!!!
We even don't have to mess with RAM's /RD.. (P.S. III If properly crafted)
STOP THE PRESS!
ANOTHER NEWBORN FROM DR_ACULA's SHED!!!!
Cheers
Yanomani
P.S. II - Jumping as a mexican bean!
Sorry Dr_Acula, my fault!
Were are my manners and the education my parents teached me?
The honour and full rights are YOURS, to announce something!
Were are my manners at all?
Excuse my behavior and lack of serenity!:thumb:
You would need to be careful with the exact read/write sequence during bootup. There are at least two basic approaches here each with their own issues:
1) After reset prop clocks Z80 and waits for /RD to go low, prop then forces /RD high, prop outputs its own boot code onto data bus, prop pulses /WR low then high to write this byte to SRAM, prop releases /RD to be controlled by Z80, and lets this newly written opcode/data continue to be read/executed from the SRAM by the Z80 CPU by slowly clocking the Z80. This approach trashes some low memory (or at least until a jump instruction is executed) which may not be good for a warm boot.
2) After reset prop clocks Z80, during /RD detection prop overrides /RD signal to SRAM making it high and drives the data bus with opcodes at the correct time in each machine cycle and lets the Z80 then execute this code and write the bootcode data to SRAM (using the stack method as discussed above for example). This needs knowledge of when Z80 reads and writes are in progress based on the number of elapsed clock cycles during /RD and observation of the /WR line so you can tristate the prop data bus appropriately. Unfortunately by holding /RD high the prop won't exactly know when reads are really in progress as you need to release it to read the Z80's /RD state or dead reckon by counting clock cycles. You just don't want to release it and let the SRAM drive the bus while the prop is also driving it. So you can see it is harder to code and any timing errors can cause bus clashes however this approach can leave low memory fully intact (and that may support a warm boot).
Dr_Acula if you have spare pins on your i2c I/O expander you might want to add the real Z80 /RD signal so you can read it at all times (instead of reading the propeller's overidden version). That would help approach 2. Also having similar access to /MREQ and /M1 from the expander could help precisely figure out the boot sequence too.
This week if I find time I'm hoping to wire up my Z80 to my prop and SRAM (in a minimal system) and see if I can hack up a working boot sequence with only visibility of /RD and /WR. I'll have to put current limiting resistors on the data bus too in case my prop's bus driving timing is off anywhere and that should resolve the 5V to 3.3V issue I have as well.
Dr_Acula if you have spare pins on your i2c I/O expander you might want to add the real Z80 /RD signal so you can read it at all times
Agree. And there are quite a few spare pins. They may not all be needed as I think it only needs 3 pins, but it might make debugging easier.
I had some more crazy ideas last night. Add a second ram chip and the Z80 can now have over a megabyte of ram. And then, maybe with one HC245, isolate the second ram data bus, and send the data to the touchscreen. That creates a 16 bit bus for fast dumping of pixels to the touchscreen. And something Yanomani is worried about can be fixed - the three touchscreen control pins can be controlled either by the Z80 latch, or by the propeller with the VGA pins (no VGA display if using a touchscreen). Might need three OR or AND gates there. But what this means is one could experiment with different ways to send data to the touchscreen - either with OUT instructions or with the scheme similar to the bootstrap routine.
This week if I find time I'm hoping to wire up my Z80 to my prop and SRAM (in a minimal system)
That sounds great. There are still a lot of experiments to do that can be done with just a propeller, Z80 and ram chip. Especially with the communication protocols.
You made the inner child (sometimes not so fair, if you can understand me, just not to mention an eventual Parallax competitor ) that still insists to reside inside myself, happy again.
I was realy in a dizzy jumping session, faster than any of the mexican's kind could ever figure how to do it.
And, In my case, totaly free of any Cydia deshaisiana, living inside my body!
It was pure joy, after a long and tedious period, totaling 6.5 years, of self-imposed sabbatic years, to rediscover the happiness of thinking it the hard way (and perhaps soft too) again.
I had some more crazy ideas last night. Add a second ram chip and the Z80 can now have over a megabyte of ram. And then, maybe with one HC245, isolate the second ram data bus, and send the data to the touchscreen. That creates a 16 bit bus for fast dumping of pixels to the touchscreen.
Dr_Acula
Despite it's an old guy, the Z80 still has its inner power intact, so it can awfully cohabitate with two RAM chips, under the same roof.
Not a single legal concern at all.
It's simple like the old faithful wood cabinet clock, like the one my grandparents used to have, over the higher furniture piece of their's living room.
Its only a matter of TIC TAC, TIC TAC, TIC TAC, and so on, eternaly.
One RAM chip will be anabled when A0 is low, then it will carry evenly addressed bytes.
The other one, obviously, will be enabled when A0 goes high, so it will carry the oddly addressed ones.
Downstairs a bit, address lines will come, then up to A16 (from the bank selector, i.e., the expander) will be to the RAM connected.
Two straight lines of houses,
doors facing accross the lanes,
DATA rd., shown at the busses,
Teaching us, unfamiliar names.
Close to connector's gold-flashed pins,
seating as transparently-latched twins,
From the family's name 'LVC543, maybe,
Passing DATA rd. busses, to me.
Who I am? May someone ask,
The display, Sir! Did you forget?
On the desk top, for sure, thou doing your task,
Showing it all, for us, a rich 65k colour set!
Back to back, staying there to transceive,
the otherwise made compound,
from Z80's data bus perspective.
The same input, they'll receive,
twin powered mouths will then sound,
as a 16 full tune alternative.
And they are also imune to 5V logic swings, then the display you choose will be irrelevant.:cool:
Any chance of a few lines mentioning the Propeller?
Dr_Acula
Sure it was my fault, but...
I'd suposed that, even without any mention to it, no one will doubt that nothing of it will be possible, without the Propeller being there, at its full operational charge.
Kind of a recursive underlying thought, perhaps subliminar.
Since the first time I ever saw your thread, I figured that the Propeller will be commanding all of it.
I'm sure you figured out, my true motivation to write the poem, was to explain the way I'd understood about splitting the data bus in two and how it reaches at the display interface.
Even fully respecting Z.....'s work, I'd named its elder son a 'mule beast' address carrier, a 'blind zombie', to be under Propeller's control!:thumb:
Since the first time I ever saw your thread, I figured that the Propeller will be commanding all of it.
I am not sure who is the boss. The Z80 is running a program, sends an OUT command to the Propeller, which then puts the Z80 to sleep with fake NOPs and turns the Z80 into a zombie to create an incrementing address counter, then wakes the Z80 up again and the Z80 continues with its program. Neither chip is in charge. It is a synergy. Or maybe we could think of the propeller having 9 cogs now instead of 8?
You can also use the term 'parallax' at its raw meaning, and view as the Z80 will be being 'invaded' at its core, commanded by 'injected' stealthy technics, provided by the Propeller.
Its a matter of poit of view, thus the parallax term applies at its full sense!
I've been wondering if it's not possible to solve the following equations system:
- easy control signals management;
- enable a configurable memory address decoding;
- same as above, for paging schemes;
- idem for the above two, for I/O space;
- save precious Propeller COGs and pins;
- easy routing of fast switching signals;
- all of the above, in a modest budget scenario;
- and finaly, (perhaps) freeing some space on the circuit board;
- all of the above, using a couple of Parallax stock items;
I'd bet you figured out what I'm thinking about....
(in fact, you encouraged me a lot, before this could happen)
Yeah, sure, a SX48BD and a resonator.
Despite its EOL status, there are so many of them, just waiting to be used (perhaps abused too), in some creative ways.
Ubicom (after Scenix) was the first time reason that catched my eyes to Parallax's website.
Then I feel no guilty, showing here one of the designs I've done with their chips in the past.
It had certainly spared me a lot of work, if Chip's insight that originated the Propeller, started to hit his brain mere eight years before the date it had.
But, then, I would have never learned so much about doing fast, complex and reconfigurable logic, a lot easier and cheaper than many other options, at its time. There's no waste at all.
Since now you are merging both Z80's and Propeller's worlds, the 30 year time gap in between them could perhaps be filled with some kind of fast drying and shapeable resins.
Please, let me know if this also inspires you too.
And it comes as a 28 pin DIP and a surface mount chip with more pins.
Price is nice - $1.15 and $1.55
Pity it is EOL as of 2009. This is a very nice sweet spot for price vs pins vs performance.
Don't get me wrong, the propeller is great. But when you look at the price per pin, the additional support chips (download, reset, eeprom, xtal, pcb real estate), sometimes an old-school 74xx chip for 40c works out better.
Maybe I was late to the party, but what went wrong with the SX series? EOL too soon? No DIP version with more (and/or less) pins? The USB Key costing $60?
Sometimes I dream of the ultimate chip. Super fast - tens of nanoseconds between input and output. Cheap - under 5c a pin. Low power consumption. Programmable. Simple download circuit. No extra components needed. Multiple form factors - DIP in lots of pin sizes, surface mount etc. Imagine thinking "I need a 74xx374 latch and I haven't got one" and pulling a 20 pin chip out of the parts drawer (cost $1) put it in a zero force programmer, select 74HC374 from a list, and turn it into that chip. Even if it is only one time programmable and you make a mistake, who cares, put it in the 73HC374 parts drawer with all the other chips and use it later.
CPLDs and FPGAs et al just don't seem to tick all the boxes.
The SX series looks like it came close in some aspects.
And like Invent-O-Doc says, maybe the Prop2 is going to be the answer?
addit: I sent off some more boards to be made. There are now four versions in the pipeline somewhere between China and my shed. I tried fitting some chips on the board - not enough room for adding buffers to the expansion port, and not enough room for adding a second ram chip for 16 bit dumping. So I ended up adding a 23017 chip instead of a 23008 and that means there is a header with 8 general purpose I/O ports, and I added an I2C analog I/O chip so the board now has one analog output, 4 analog inputs, 8 digital I/O ports, one 40 pin header (all Z80 pins in order), keyboard, SD card, stereo out, VGA, TV, touchscreen. 10x15cm in size. Seed Studios have some great prices that can be even better if one optimises things, so 5 boards came to $45 with another $8 shipping, and 10 boards came to $55 with free shipping, so I got 10 boards. $5.50 each and if they work, that means I'll have some spare ones to send to anyone for free who wants to build one.
Don't get me wrong, the propeller is great. But when you look at the price per pin, the additional support chips (download, reset, eeprom, xtal, pcb real estate), sometimes an old-school 74xx chip for 40c works out better.
@Dr_Acula
I fully agree with your toughts and conclusions, for sure.
It was the time gap, between Propellers and Z80s launch dates, that inspired me to suggest a possible middle-aged solution, to achieve Ram memory's access decoding plus some extra features, including the possibility of freeing some of Propeller's pins.
I'll be closely following this thread, looking for any opportunity to contribute some way.
And like Invent-O-Doc says, maybe the Prop2 is going to be the answer?
@Dr_Acula and @Invent-O-Doc
I also fully agree with you. It will be the answer, for sure. Very soon!
Perhaps the Z80 can be dismissed too! A well deserved retirement!
I do not have any 6850 chips (I have a couple of 6402 UARTs) and so thought about having the Prop act as the UART bit. Again it is my Nascom addiction, the BASIC that is used is the M$ version from said (blessed) machine. Then I thought why not do more than just that - before long it becomes just as easy to do all that you are trying to do. I had remember that the Z80 could be NOP force fed, but I never realized that made it become a free address counter.
And .. I will not have to get WIN98 going on a PC for the EPROMs (although it will be something for one of the reserve PCs to do).
As for price per pin, RS and Farnell are doing a good job of keeping the Propeller "exclusive" over here.
And it comes as a 28 pin DIP and a surface mount chip with more pins.
Price is nice - $1.15 and $1.55
Pity it is EOL as of 2009. This is a very nice sweet spot for price vs pins vs performance.
Don't get me wrong, the propeller is great. But when you look at the price per pin, the additional support chips (download, reset, eeprom, xtal, pcb real estate), sometimes an old-school 74xx chip for 40c works out better.
Maybe I was late to the party, but what went wrong with the SX series? EOL too soon? No DIP version with more (and/or less) pins? The USB Key costing $60?
Sometimes I dream of the ultimate chip. Super fast - tens of nanoseconds between input and output. Cheap - under 5c a pin. Low power consumption. Programmable. Simple download circuit. No extra components needed. Multiple form factors - DIP in lots of pin sizes, surface mount etc. Imagine thinking "I need a 74xx374 latch and I haven't got one" and pulling a 20 pin chip out of the parts drawer (cost $1) put it in a zero force programmer, select 74HC374 from a list, and turn it into that chip. Even if it is only one time programmable and you make a mistake, who cares, put it in the 73HC374 parts drawer with all the other chips and use it later.
CPLDs and FPGAs et al just don't seem to tick all the boxes.
The SX series looks like it came close in some aspects.
And like Invent-O-Doc says, maybe the Prop2 is going to be the answer?
addit: I sent off some more boards to be made. There are now four versions in the pipeline somewhere between China and my shed. I tried fitting some chips on the board - not enough room for adding buffers to the expansion port, and not enough room for adding a second ram chip for 16 bit dumping. So I ended up adding a 23017 chip instead of a 23008 and that means there is a header with 8 general purpose I/O ports, and I added an I2C analog I/O chip so the board now has one analog output, 4 analog inputs, 8 digital I/O ports, one 40 pin header (all Z80 pins in order), keyboard, SD card, stereo out, VGA, TV, touchscreen. 10x15cm in size. Seed Studios have some great prices that can be even better if one optimises things, so 5 boards came to $45 with another $8 shipping, and 10 boards came to $55 with free shipping, so I got 10 boards. $5.50 each and if they work, that means I'll have some spare ones to send to anyone for free who wants to build one.
I'm in.
And would even offer to pay for the board and shipping.
I need a scope now.
Anybody know where to find an inexpensive scope?
I need a scope now.
Anybody know where to find an inexpensive scope?
You may not need a scope for this project - one clever thing the propeller can do is slow the clock right down to 1Hz, or even stop it. Makes debugging easier.
You may not need a scope for this project - one clever thing the propeller can do is slow the clock right down to 1Hz, or even stop it. Makes debugging easier.
I hear that!
In fact I've been sorta doing that.
Logic debugging with a multimeter.
Wouldn't try that with any other processor.
But there will likely be times when we need to look at set-up-and-hold relationships,
(especially with this project!)
and that has to be done at speed or it's not valid.
Someone reminded me of this resource this morning..
On this thread, there is a link to something PropCOMM/VGA_PDOS which is a terminal that was created for interaction between a Z80 system and the Propeller. It includes compatible Xmodem upload/download functionality. Perhaps it might be of some use to this project.
Someone reminded me of this resource this morning..
On this thread, there is a link to something PropCOMM/VGA_PDOS which is a terminal that was created for interaction between a Z80 system and the Propeller. It includes compatible Xmodem upload/download functionality. Perhaps it might be of some use to this project.
Jeff
I was just starting to look at console drivers, Jeff.
Hadn't seen that one yet, but it looks like a winner.
That solves one-half of the problem - getting stuff out of the Prop.
The other half of the problem is getting stuff INTO the prop.
That will require writing a custom BDOS on the Z80 side.
I haven't read though all the posts yet as I'm just back from holiday so this might have already been discussed but...
does the Z80 need to connect it's address lines to the Prop at all? Surely, if the Prop is controlling the Z80 clock and reset lines, and can stuff data onto the Z80 data bus, then the address lines are superfluous?
On reset we know exactly what addresses the Z80 thinks it's getting data from. As the Prop is feeding data/opcodes to the Z80 it knows what those opcodes are and can implement a virtual Z80 PC register internally. Opcodes will either increment the PC or reload the PC. The Prop just needs the PC control logic from a Z80 emulator. It can then then fetch opcodes and data from 'somewhere' and stuff them onto the Z80 data bus.
Comments
@Yanomani,
The general idea as far as I understand it would be to have the Propeller acting purely an I/O device during normal operation, but during bootup also intercepting the Z80's memory read accesses and overriding the /RD signal to the SRAM with its own output so the SRAM won't be accessed and drive the bus. Hence the current protection resistor on the /RD line to avoid a direct short. Meanwhile the Propeller feeds the data bus with bootup instructions that then write the bootcode to main memory. So there is no issue with the /MREQ driving /CE of the SRAM all the time from what I can tell. It is also required for the writes from the Z80.
Also I know the Microbee computers (somewhat successful Australian Z80 based computer around in the mid 80's) would run CP/M and also used /NMI when holding down the reset switch for 1-2 seconds or more. I don't know if they used any particular stealth techniques or relocated their FCBs somewhere else in memory. But it seemed to work out ok on that platform and was never a major issue from what I can tell during usage. So hopefully /NMI is possible to use for interrupts at least in some way. There's always the regular interrupt pin as well if needed.
Roger.
The circuit's proposed behavior, that I'm trying to describe, will enable things like 'stealth' breakpointing, even if your circuit used a Flash memory, or a two memory chips setup, RAM and Eprom, for example.
At any point, you will be able to stop (by say the use of a 'stealth' HALT instruction) that does not in fact resides in your memory at all. Does not 'bloats' code nor data space.
You will be able to 'pause', 'inspect' then 'react' inside any running system, from the outside in. Without leaving a clue, perhaps, of being there, as an untraceable sniffer!
Sure provided none registers nor RAM, port of something else's content is disturbed in the operation.
Yanomani
Hi rogloh
But since we have no ROM nor FLASH, in fact nothing but the RAM itself, we must 'create our own', during 'cold boot phase one' to live with.
Your explainned technic could be of great value too, if needed, in a 'warm boot' situation, to 'skip' O.S. body, and hit a properly reserved area, at higher memory addresses.
Or even both technics can be combined, to create an operational ROM (perhaps protecting it from being written in a latter time, until the next power down cycle) at high memory, even at the last page....
Yanomani
P.S. I just realized that the 'jump latch' you explained in your post, must be de-gating normal RAM reads, or the circuit has some 'man in the middle' that 'defeats' data read from RAM memory, till the higher addressed ROM area is reached, by an almost 'walking in the (NOP) dark, blind zombie' Z80.
Yes it used a 74LS245 bidirectional transceiver on the Z80 databus and pulldown resistors between the CPU and this '245. When the jump latch was activated after reset it tristated this transceiver and the CPU only saw NOPs from the pulldowns until the address reached a ROM address and this jump latch was disabled. It was a pretty cool technique but probably not exclusive to microbees alone.
I know we haven't tested it as yet, but the theory is...
1) Reset
2) Clock the Z80 until detect /RD goes low.
At this point the Z80 would be reading data from address 0000H. The reality of a ram chip starting up is this address will contain a random byte. So, Z80 is reading random data. /MREQ is low and /RD is low and the ram chip is enabled.
3) The propeller puts a bootstrap byte on the data bus.
4) The propeller pulls /RD high which will work due to the current limiting resistor.
5) The propeller pulls /WR low and then high, which writes the byte into the ram
6) The propeller releases the /RD line which then goes low due to the Z80 pulling it low
7) The propeller then puts zero on the data bus.
8) The propeller then clocks the Z80 which then tries to read data from address 0001
As far as I can see, the ram has to be enabled otherwise data cannot be written to the ram.
After a bit of thinking, I realized that such technic we are trying to figure out how to properly do, can be viewed as a Z80 assisted (but as a 'mule address provider', it does not interfere with the 'data cargo' contents) DMA from the Propeller to the RAM, but since we have no pins to spare at Propeller's side, to do address generation, then we call for Z80's help to do this, for us.
The address lines will be 'the mule provided legs'.
The data the Propeller writes into the RAM, are the 'seeds' it plants in the way, before commanding the Z80 to do the next step.
The NOPs it feeds the Z80 with, are the 'carrots' it uses, to convince the Z80 to blindly follow programmer's intended behavior.
Its control lines, will be the 'symbols' it uses to inform to the Propeller, how many steps it has done since the beggining (reset).
Yamomani
Yes, for sure, it must be anabled, under Propeller's control, for read and write to the RAM, were appropriate.
Aniway, the Propeller will be the solely data bus contents provider, during the whole 'cold boot one', except, perhaps, if it chooses to verify what was written inside the RAM, but without releasing the Z80 to do the next step, until the operation is done.
Then, with RAM's /RD and /WR held inactive, under Propellers control, it feeds the Z80 a NOP, and restarts clocking it, till the next /M1 and so on.
The Z80 will be the solely address provider, under control of Propeller's running code.
Yanomani
I just figured it now.
In a insight, I rememberd from many RAM datasheets, I'm not sure that's the present case with the RAM you use in the circuit, if we use /M1 from the Z80, gated at this specific time, as the RAM /WR signal, afterwards, when the Z80 pulls down the /RD line, it will be ignored by the RAM chip at all.
I must read the intended RAM datasheet, I recalled that behavior from 6116's one.
So, no need for an independent read control at this time, since /M1 will arrive even sooner than /MREQ. Maybe we must combine /MREQ with /M1 in an OR gate, that combined with a Propeller's generated Special Enable signal, will be finally ANDed with the Z80 /WR signal, to generate the early RAM /WR that will de-gate its data bus from being read at all.
When the Propeller finishes writing on it, it them de-gates its controlling signal, and reads back the data it just had written on it, verifying its contents, since now the RAM will be controlled by the steady /RD signal comming from the Z80.
Then the Propeller forces RAM /RD to go HIGH, tri-stating its output, and now the Propeller can enable it's own buffers, and send a NOP to the Z80.
I must read the RAM datasheet to check its behavior.
Yanomani
@rogloh
Bingo!
YES, FRAGILE
CANS AND BRAHMS
http://www.youtube.com/watch?v=pEYahmZGjY0
Just now i'm chomping an older than Matusalem quartz windowed 8k x 8 eprom, only to remember how tasty an almost steady bit used to be in the past.
Even the 'hardwired' term has not the same meaning.
I read on the newspaper, real memories are to be 'implanted' in the near future.
For now we, the ones who are not initiated at molecular biology (except sir Dr_Acula, perhaps), can finally 'implant' memories into an 'almost living' Z80. Without any ethic concerns, at least.
Yanomani
P.S> ONE more huge BINGO!!
As per AS6C4008 Alliance's datasheet!
Write cicle type 2, CE# controlled!!!
We even don't have to mess with RAM's /RD.. (P.S. III If properly crafted)
STOP THE PRESS!
ANOTHER NEWBORN FROM DR_ACULA's SHED!!!!
Cheers
Yanomani
P.S. II - Jumping as a mexican bean!
Sorry Dr_Acula, my fault!
Were are my manners and the education my parents teached me?
The honour and full rights are YOURS, to announce something!
Were are my manners at all?
Excuse my behavior and lack of serenity!:thumb:
Yanomani
1) After reset prop clocks Z80 and waits for /RD to go low, prop then forces /RD high, prop outputs its own boot code onto data bus, prop pulses /WR low then high to write this byte to SRAM, prop releases /RD to be controlled by Z80, and lets this newly written opcode/data continue to be read/executed from the SRAM by the Z80 CPU by slowly clocking the Z80. This approach trashes some low memory (or at least until a jump instruction is executed) which may not be good for a warm boot.
2) After reset prop clocks Z80, during /RD detection prop overrides /RD signal to SRAM making it high and drives the data bus with opcodes at the correct time in each machine cycle and lets the Z80 then execute this code and write the bootcode data to SRAM (using the stack method as discussed above for example). This needs knowledge of when Z80 reads and writes are in progress based on the number of elapsed clock cycles during /RD and observation of the /WR line so you can tristate the prop data bus appropriately. Unfortunately by holding /RD high the prop won't exactly know when reads are really in progress as you need to release it to read the Z80's /RD state or dead reckon by counting clock cycles. You just don't want to release it and let the SRAM drive the bus while the prop is also driving it. So you can see it is harder to code and any timing errors can cause bus clashes however this approach can leave low memory fully intact (and that may support a warm boot).
Dr_Acula if you have spare pins on your i2c I/O expander you might want to add the real Z80 /RD signal so you can read it at all times (instead of reading the propeller's overidden version). That would help approach 2. Also having similar access to /MREQ and /M1 from the expander could help precisely figure out the boot sequence too.
This week if I find time I'm hoping to wire up my Z80 to my prop and SRAM (in a minimal system) and see if I can hack up a working boot sequence with only visibility of /RD and /WR. I'll have to put current limiting resistors on the data bus too in case my prop's bus driving timing is off anywhere and that should resolve the 5V to 3.3V issue I have as well.
This makes me smile
Agree. And there are quite a few spare pins. They may not all be needed as I think it only needs 3 pins, but it might make debugging easier.
I had some more crazy ideas last night. Add a second ram chip and the Z80 can now have over a megabyte of ram. And then, maybe with one HC245, isolate the second ram data bus, and send the data to the touchscreen. That creates a 16 bit bus for fast dumping of pixels to the touchscreen. And something Yanomani is worried about can be fixed - the three touchscreen control pins can be controlled either by the Z80 latch, or by the propeller with the VGA pins (no VGA display if using a touchscreen). Might need three OR or AND gates there. But what this means is one could experiment with different ways to send data to the touchscreen - either with OUT instructions or with the scheme similar to the bootstrap routine.
That sounds great. There are still a lot of experiments to do that can be done with just a propeller, Z80 and ram chip. Especially with the communication protocols.
Dr_Acula
Thank you Sir for doing this!
Sincerely!
You made the inner child (sometimes not so fair, if you can understand me, just not to mention an eventual Parallax competitor
I was realy in a dizzy jumping session, faster than any of the mexican's kind could ever figure how to do it.
And, In my case, totaly free of any Cydia deshaisiana, living inside my body!
It was pure joy, after a long and tedious period, totaling 6.5 years, of self-imposed sabbatic years, to rediscover the happiness of thinking it the hard way (and perhaps soft too) again.
Yanomani
Dr_Acula
Despite it's an old guy, the Z80 still has its inner power intact, so it can awfully cohabitate with two RAM chips, under the same roof.
Not a single legal concern at all.
It's simple like the old faithful wood cabinet clock, like the one my grandparents used to have, over the higher furniture piece of their's living room.
Its only a matter of TIC TAC, TIC TAC, TIC TAC, and so on, eternaly.
One RAM chip will be anabled when A0 is low, then it will carry evenly addressed bytes.
The other one, obviously, will be enabled when A0 goes high, so it will carry the oddly addressed ones.
Downstairs a bit, address lines will come, then up to A16 (from the bank selector, i.e., the expander) will be to the RAM connected.
Two straight lines of houses,
doors facing accross the lanes,
DATA rd., shown at the busses,
Teaching us, unfamiliar names.
Close to connector's gold-flashed pins,
seating as transparently-latched twins,
From the family's name 'LVC543, maybe,
Passing DATA rd. busses, to me.
Who I am? May someone ask,
The display, Sir! Did you forget?
On the desk top, for sure, thou doing your task,
Showing it all, for us, a rich 65k colour set!
Back to back, staying there to transceive,
the otherwise made compound,
from Z80's data bus perspective.
The same input, they'll receive,
twin powered mouths will then sound,
as a 16 full tune alternative.
And they are also imune to 5V logic swings, then the display you choose will be irrelevant.:cool:
Yanomani
Any chance of a few lines mentioning the Propeller?
Dr_Acula
Sure it was my fault, but...
I'd suposed that, even without any mention to it, no one will doubt that nothing of it will be possible, without the Propeller being there, at its full operational charge.
Kind of a recursive underlying thought, perhaps subliminar.
Since the first time I ever saw your thread, I figured that the Propeller will be commanding all of it.
I'm sure you figured out, my true motivation to write the poem, was to explain the way I'd understood about splitting the data bus in two and how it reaches at the display interface.
Even fully respecting Z.....'s work, I'd named its elder son a 'mule beast' address carrier, a 'blind zombie', to be under Propeller's control!:thumb:
Yanomani
I am not sure who is the boss. The Z80 is running a program, sends an OUT command to the Propeller, which then puts the Z80 to sleep with fake NOPs and turns the Z80 into a zombie to create an incrementing address counter, then wakes the Z80 up again and the Z80 continues with its program. Neither chip is in charge. It is a synergy. Or maybe we could think of the propeller having 9 cogs now instead of 8?
Its a matter of poit of view, thus the parallax term applies at its full sense!
Yanomani
I've been wondering if it's not possible to solve the following equations system:
- easy control signals management;
- enable a configurable memory address decoding;
- same as above, for paging schemes;
- idem for the above two, for I/O space;
- save precious Propeller COGs and pins;
- easy routing of fast switching signals;
- all of the above, in a modest budget scenario;
- and finaly, (perhaps) freeing some space on the circuit board;
- all of the above, using a couple of Parallax stock items;
I'd bet you figured out what I'm thinking about....
(in fact, you encouraged me a lot, before this could happen)
Yeah, sure, a SX48BD and a resonator.
Despite its EOL status, there are so many of them, just waiting to be used (perhaps abused too), in some creative ways.
Ubicom (after Scenix) was the first time reason that catched my eyes to Parallax's website.
Then I feel no guilty, showing here one of the designs I've done with their chips in the past.
It had certainly spared me a lot of work, if Chip's insight that originated the Propeller, started to hit his brain mere eight years before the date it had.
But, then, I would have never learned so much about doing fast, complex and reconfigurable logic, a lot easier and cheaper than many other options, at its time. There's no waste at all.
Since now you are merging both Z80's and Propeller's worlds, the 30 year time gap in between them could perhaps be filled with some kind of fast drying and shapeable resins.
Please, let me know if this also inspires you too.
Yanomani
You know, this is really embarrassing to admit, but I have never heard of the SX series until now.
Datasheet http://www.parallax.com/Portals/0/Downloads/docs/prod/datast/SX48BD-Data-v1.5.pdf
End of life, yes, but looks like there are 129802 in stock http://www.parallax.com/tabid/138/List/0/CategoryID/15/Level/a/SortField/0/Default.aspx
And it comes as a 28 pin DIP and a surface mount chip with more pins.
Price is nice - $1.15 and $1.55
Pity it is EOL as of 2009. This is a very nice sweet spot for price vs pins vs performance.
Don't get me wrong, the propeller is great. But when you look at the price per pin, the additional support chips (download, reset, eeprom, xtal, pcb real estate), sometimes an old-school 74xx chip for 40c works out better.
Maybe I was late to the party, but what went wrong with the SX series? EOL too soon? No DIP version with more (and/or less) pins? The USB Key costing $60?
Sometimes I dream of the ultimate chip. Super fast - tens of nanoseconds between input and output. Cheap - under 5c a pin. Low power consumption. Programmable. Simple download circuit. No extra components needed. Multiple form factors - DIP in lots of pin sizes, surface mount etc. Imagine thinking "I need a 74xx374 latch and I haven't got one" and pulling a 20 pin chip out of the parts drawer (cost $1) put it in a zero force programmer, select 74HC374 from a list, and turn it into that chip. Even if it is only one time programmable and you make a mistake, who cares, put it in the 73HC374 parts drawer with all the other chips and use it later.
CPLDs and FPGAs et al just don't seem to tick all the boxes.
The SX series looks like it came close in some aspects.
And like Invent-O-Doc says, maybe the Prop2 is going to be the answer?
addit: I sent off some more boards to be made. There are now four versions in the pipeline somewhere between China and my shed. I tried fitting some chips on the board - not enough room for adding buffers to the expansion port, and not enough room for adding a second ram chip for 16 bit dumping. So I ended up adding a 23017 chip instead of a 23008 and that means there is a header with 8 general purpose I/O ports, and I added an I2C analog I/O chip so the board now has one analog output, 4 analog inputs, 8 digital I/O ports, one 40 pin header (all Z80 pins in order), keyboard, SD card, stereo out, VGA, TV, touchscreen. 10x15cm in size. Seed Studios have some great prices that can be even better if one optimises things, so 5 boards came to $45 with another $8 shipping, and 10 boards came to $55 with free shipping, so I got 10 boards. $5.50 each and if they work, that means I'll have some spare ones to send to anyone for free who wants to build one.
@Dr_Acula
I fully agree with your toughts and conclusions, for sure.
It was the time gap, between Propellers and Z80s launch dates, that inspired me to suggest a possible middle-aged solution, to achieve Ram memory's access decoding plus some extra features, including the possibility of freeing some of Propeller's pins.
I'll be closely following this thread, looking for any opportunity to contribute some way.
@Dr_Acula and @Invent-O-Doc
I also fully agree with you. It will be the answer, for sure. Very soon!
Perhaps the Z80 can be dismissed too! A well deserved retirement!
Yanomani
http://searle.hostei.com/grant/cpm/
I do not have any 6850 chips (I have a couple of 6402 UARTs) and so thought about having the Prop act as the UART bit. Again it is my Nascom addiction, the BASIC that is used is the M$ version from said (blessed) machine. Then I thought why not do more than just that - before long it becomes just as easy to do all that you are trying to do. I had remember that the Z80 could be NOP force fed, but I never realized that made it become a free address counter.
And .. I will not have to get WIN98 going on a PC for the EPROMs (although it will be something for one of the reserve PCs to do).
As for price per pin, RS and Farnell are doing a good job of keeping the Propeller "exclusive" over here.
I'm in.
And would even offer to pay for the board and shipping.
I need a scope now.
Anybody know where to find an inexpensive scope?
You may not need a scope for this project - one clever thing the propeller can do is slow the clock right down to 1Hz, or even stop it. Makes debugging easier.
I hear that!
In fact I've been sorta doing that.
Logic debugging with a multimeter.
Wouldn't try that with any other processor.
But there will likely be times when we need to look at set-up-and-hold relationships,
(especially with this project!)
and that has to be done at speed or it's not valid.
@Dr_A, I too would like to take you up on your offer for a board. (Price and shipping fine as well)
Jeff
On this thread, there is a link to something PropCOMM/VGA_PDOS which is a terminal that was created for interaction between a Z80 system and the Propeller. It includes compatible Xmodem upload/download functionality. Perhaps it might be of some use to this project.
Jeff
I was just starting to look at console drivers, Jeff.
Hadn't seen that one yet, but it looks like a winner.
That solves one-half of the problem - getting stuff out of the Prop.
The other half of the problem is getting stuff INTO the prop.
That will require writing a custom BDOS on the Z80 side.
does the Z80 need to connect it's address lines to the Prop at all? Surely, if the Prop is controlling the Z80 clock and reset lines, and can stuff data onto the Z80 data bus, then the address lines are superfluous?
On reset we know exactly what addresses the Z80 thinks it's getting data from. As the Prop is feeding data/opcodes to the Z80 it knows what those opcodes are and can implement a virtual Z80 PC register internally. Opcodes will either increment the PC or reload the PC. The Prop just needs the PC control logic from a Z80 emulator. It can then then fetch opcodes and data from 'somewhere' and stuff them onto the Z80 data bus.