Thanks User Name for the kind words Yes life is busy. 3 children in high school, working 70h a week, garden and fences to maintain (today I had both cows and kangaroos in the garden eating my plants!). I guess everyone has a secret, and mine is that I decided some years ago to give up watching television. Nothing much on anyway and it frees up so much time.
@rogloh, I'm going to get a few of the minimalist boards made (Z80, Propeller, eeprom, sram. That idea of sharing the I2C and SD card has made so many more things possible. It is fantastic to know it works.
I guess everyone has a secret, and mine is that I decided some years ago to give up watching television.
Hey, that was my secret. I guess it's more widespread than I thought. Not sure what happened to the time it free'd up though. I seem to be able to consume any gains in free time with sleeping:(
@rogloh, I'm going to get a few of the minimalist boards made (Z80, Propeller, eeprom, sram. That idea of sharing the I2C and SD card has made so many more things possible. It is fantastic to know it works.
Cool. Yes a minimalist approach would be really nice.
Also very glad the I2C+SD thing worked and that I could assist a fellow Aussie into retro stuff. ;-)
Hey, that was my secret. I guess it's more widespread than I thought. Not sure what happened to the time it free'd up though. I seem to be able to consume any gains in free time with sleeping:(
Anyway, I'm watching this thread with interest.
This thread is seriously more interesting that TV, said another reformed TV addict.
Even the commercials here are cool.
SHE always vegitates in front of the TV with endless soaps and cookery programs, and then has a go at me for staring into computer screens. I always retort "At least am trying to become, slightly, less thick" (God knows it's a long journey).
Anyway as the average room, here at work has 50+ screens, or sub screens, why would I want to watch any more at home?
In the last 24 hours so i was involved many readings on interesting user manuals and datasheets.
Then, when i went back to this thread, I was surprised by how expedite you an all the other participants are in the job of driving projects to the real world.
Truly amazing.
I must warn at first that I have no previous experience with Ilitek's 9325, nor the MCP23008 and only minimal ones with the Propeller 1 itself, so my opinions will only reflect my readings.
Reviewing the Z80 Minimalist you published in the intent of getting a few made for the first time, a couple of connections attracted my attention and I believe they should be rerouted for better results, as follows:
- According to Ilitek's datasheet, nRESET is an active low input pin, whose obvious use is explained by it's name.
Since it appears to be very infrequently used other than just a natural 'power on state' follow up or, in extreme situations of total lose of synchrony with the driving software, a 'last resource' interface restart, it can be directly tied to the Z80 nRESET input.
This behavior could be associated with provisions for a 'Warm Boot', 'First gather data, then check and finaly react' alternate at system's software Z80's equation side.
In my belief, any watchdog timeouts were to be controlled by the Propeller itself, then it will be the tracking agent and also the remedy provider for any unintended behavior, and thus, be itself aware from the misfunction probable origin and takeover strategy.
Moreover, by the fact that 'cold' and 'warm' boots are meant to be Propeller managed tasks, the nRESET line should be connected to a Propeller controlled circuit, kind of an open collector inverter with a pull up at Z80/Ilitek's side.
In order to do this, three more resistors and a NPN transistor are to be added between the Prop pin and the nRESET line.
In this approach, as long as the Prop is under reset, its output pin wil be tristaded, then the transistor will be driven in saturation by the two series associated resistors, causing nRESET to stay LOW during the whole Prop cold boot.
Afterwards, under the control of Propeller's program, the pin will be put in a 'LOW' driven state, cutting transistor's conduction and releasing the nRESET line.
As a bonus, a Prop pin will be spared, but not for a long time, as follows.
- By the fact that is a direct connection at the data bus level, the minimalist approach does not allows for any different data to be traversed to the display interface, other than the one Z80 is gathering. And there are no provisions for a nBUSRQ/nBUSAK interlocked bus protocol, nor an alternate generator to drive the address lines, so the Z80 will be driving them and also the control lines at the time of display write operations.
Also taking in account that nMREQ is directly tied to the RAM as nCE and that the RAM itself will be decoding all de available address range, to differ the read/write cycles destination one must implement display access using I/O cycles.
This thinking points to the need of distinct address spaces to differ the Propeller from the display, as seen by the Z80.
And also the need to properly reserve ample room for blocked I/O data transfers between the Z80 and Ilitek's interface.
Then there comes the need to use two address lines, says A15 to differ between the two, and A14 to internally discriminate between access groups.
Sure, nCS keeps going from Propeller's pin to Ilitek's interface, since at least one COG will be reacting in accordance with (nIOREQ AND A15) to properly sort whose access its intended to do.
But i'm sorry, the Propeller could never write nor read to/from Ilitek's interface because there is no nBUSRQ/nBUSAK interlock at all, so there is no need for it to independently control Ilitek's RS line, then A14 could handle this.
That said, we finaly have an uncompromised pin to spare. Or not?
-In my own vision, there is no reason to don't connect the Illitek's nRD signal to the Z80's one. Some interesting knowledge and a little improvement in debugging could be gained here. There is a whole O.S. running in the background, perhaps it will be useful in a foreseable future. No loss at all.
- I do not know if the other DBn data pins (10 at all) are directed from the connector to Ilitek's chip, but if there are connections, to follow the datasheet, they must be tied to GND. Since Ilitek's timming specs has provisions for a full 10MHz bandwidth at bus transactions, even if we don't use it's maximum, its advisable to respect its mandatory settings.
If there is no intent to do any connections to Ilitek's 10 lower DBn lines, at least pulling them down to GND thru a low valued x10 resistor SIP pack could handle the situation. If it is the present and intended reality, please ignore the following paragraph.
Having so many free address lines, out of any tasks of I/O port discrimination, and in case there is already a viable connection to the rest of Ilitek's chip DBn lines, I was thinking about using Z80's A07 thru A00 to gain a 16 bit interface to Ilitek's chip? What about faster colour fills, at least, as an upgrade bonus? For 'WRITE ONLY' operations, for sure, but that seems to be an at least interesting possibility. The pull downs still apply, for the whole 12 lines. More on this subject latter. But remember, if the "MUST", written on Ilitek's documents, is a mandatory specification, then only a low valued pull down resistor set will handle this.
- At the I/O expander, I've seen you've connected its nRST and INT pins to +3.3V. As I said, I've no experience with its uses, but according its datasheet, INT is a programmable polarity output, so it seems to me its advisable to left it unconnected or directly tied to Z80's nINT line. Since nINT can be ignored by disabling it, if we doesn't need it, no harm at all. The benefits of doing such a connection, can be enjoyed at a latter time.
For the nRST pin, I wonder if its not practical to connect it to the Propeller's similar input. Acting this way, a 'fresh' interface will be found by the Prop, when it begins its setup.
-Two last minute additions:
The spared pin gained elsewhere on the above lines, can be connected to nM1, to help discriminating Z80's I/O cycles from INTA ones. Then one can use nINT behavior under various Z80 modes and 'stuff' vectors or a few instructions into the Z80 and taste a bit of processor slavery.
nMREQ and nBUSRQ can be connected to spare pins at the expander. In a 'purist' approach, one more for nBUSAK. Bloatware, at the hard side? No. Using SIPs to PullUp all control lines and also the not yet elsewhere pulled address ones, your bonus will be a bunch of mailboxes for the Propeller share access with the Z80, spread inside top RAM. The old 55AAh role playing game. Also a way to verify bank switching operations.
In the hope for everyone's indulgence and acknowledging to all the differing opinions....specially yours, Dr_Acula.
Sorry for any typos and none schematics at all!
Please forget this nonsense about Nm1 I wrote at the end of my previous post. I shot a mosquito and let the elephant pass. What we really need is to control the pin / CS RAM using a Propeller pin. Only then can we make the Z80 read and follow the instructions directly injected by the program that runs inside the Propeller with the purpose of transferring the initial contents of the RAM.
I was too anxious and wrapped myself in my own thoughts. Every day, every hour, get up one more lesson. Ourselves, perhaps. You are never too old to learn or too young to know how to do anything.
I leave the remains of my previous post untouched, may be of value later, who knows?
Grateful to all for your patience.
Yanomami
P.S. As an alternative to not slow down access to the Z80 RAM, an OR gate should be used, combining nMREQ with a Propeller pin, instead of simply requiring that all accesses RAM depended on a signal processed internally by a PASM routine.
One of the more limiting constraint that Dr. A has at the moment with this project is board size.
That "next-size-up" really bumps up the cost of having boards made.
But we all hope that his efforts here are just the start of something really great.
My personal vision (of HIS project! )
I'd like to see a board with all surface mount chips that mounts neatly behind a (little bit larger) display
with a nice hot lithium battery tucked in behind that.
All external connectors on one side- even if it means having to use miniature connectors for some of it.
I can accept a cable adapter for that if need be.
On the other end of the board (along one side maybe?) would be a Z-80 I/O bus connector.
Just a pin header or edge connector? with the necessary signals to allow an expansion unit for whatever the user
wants to tack onto it. The data bus, lower address bus and appropriate control signals (buffered, of course)
Something like the expansion bus on the TRS80-Model III functionally - but "stack-able".
That, of course, would mean the I/O space would have to be decoded so that the Prop doesn't
hog it all.
The whole unit should be no larger than a cell phone (with a big brother about the size of a pad?)
and be completely functional right there in your hand without anything else plugged into it.
Pocket CP/M. In color, with a touch screen. Awesome.
I think there's a market for such a device too. Even at a limited production price!
Maybe just among us geeks, but there are a whole lot of us in that category.
I'm still reading through post #98. Lots of great ideas there - I'll try to get them into a board.
Re the /rd line not being decoded on the touchscreen, there is a reason for that - some of the touchscreens run on 3V and some run on 5V. They use the same 40 pin socket and if you put a 5V one in and did a /rd, it would put 5V on our 3V Z80 bus. But yes, if you were careful and only used 3V touchscreens it would be fine to add the /rd line.
@cavelamb, that sounds a great idea. Ok, first build a working model with DIP parts, then change over to surface mount. I'm sure it would all fit as there are only a few chips. And yes, bring out a Z80 bus with all the control pins, and /busrq and the interrupt pins as well. A 40 or 50 pin box header should be fine.
We have a design that works with just a Z80, ram chip and propeller. I'm going to go back though and see what benefits there might be from adding just a few 74xx chips. eg things like an octal latch to talk to the touchscreen /RS, /CS and /Reset pins so the Z80 controls the touchscreen rather than the propeller, and decoding the ports like cavelamb says, so the prop doesn't hog them all.
Thank you for all your patience and willingness, spending so much time in deciphering what i meant to describe on my former posts.
It's my fault, sir!
My written english skills are far worse than the reading ones, so I must develop a richer vocabulary, in order to don't chain together so many words, as it turns to be unacceptably long and confusing.
I undoubtly have a tendency to do it this way.
In the future, even if and when I finaly attain this level of knowledge, I must manage to refrain my natural prolixity impulses and spend a little more time, figuring out how to explain my thoughts in acceptable minimalist ways.
At least as minimalist as your present design resulted to be.
Having said all this, thanks too for your explanation about the caveats on the /RD signal usefulness versus display's operating voltage. Annotated here!
There is nothing at all wrong with your English. It is very good.
I am trying to work out your "Z80ish". We both speak that language! I think you have some very clever ideas and I am trying to work out how to use them
I fixed the floating D8_D15 on the touchscreen like you suggest. Great idea.
I am going to bring all the Z80 pins to a header as cavelamb suggests. To keep things really simple, the Z80 has 40 pins and 40 pin headers are cheap and why not use the same pin numbers as the Z80?
I don't know about the MCP23008 INT line. What sort of interrupts could you trap? Would it be faster or slower than trapping an iorq? Lots to think about.
The MCP23008 reset line does not matter much - the pin can be reset by a software command on the I2C bus but I have never needed to do this as the chip seems very reliable.
re
I was thinking about using Z80's A07 thru A00 to gain a 16 bit interface to Ilitek's chip? What about faster colour fills, at least, as an upgrade bonus? For 'WRITE ONLY' operations, for sure, but that seems to be an at least interesting possibility. The pull downs still apply, for the whole 12 lines. More on this subject latter. But remember, if the "MUST", written on Ilitek's documents, is a mandatory specification, then only a low valued pull down resistor set will handle this.
Ok, that could be very clever. Now, cavelamb says he wants all the ports available and I agree. But... is there an undocumented feature of the Z80 that allows 65536 ports instead of just 256? ie OUT command to port C actually sends to port BC Maybe I am remembering something from a long time ago? But if it is true, then maybe you could decode Z80 A8-A15 instead, and use that to send 16 bit data to the touchscreen?
Yes in deed, the Z80 can address 65536 I/O ports. The Sinclair Spectrum used that to scan the keyboard matrix I believe. Uncle Clive was always keen on using such undocumented tricks with his chips to minimize circuitry and cost.
And yikes that document is complicated. No wonder you had so much trouble with emulating the DAA instruction.
So ok, I might choose to use port 0 to talk to the propeller. Decode that with a '138. And I might choose to use port 1 to talk to the touchscreen.
So to send out 16 bit data (one pixel, RRRRRGG_GGGBBBBB), I put the low byte in A, I put 00000001 in register C, and I put the high byte in register B, and send it out. Hmm - that could speed up the display refresh...
I'd like to see a board with all surface mount chips that mounts neatly behind a (little bit larger) display
with a nice hot lithium battery tucked in behind that.
All external connectors on one side- even if it means having to use miniature connectors for some of it.
I can accept a cable adapter for that if need be.
On the other end of the board (along one side maybe?) would be a Z-80 I/O bus connector.
Just a pin header or edge connector? with the necessary signals to allow an expansion unit for whatever the user
wants to tack onto it. The data bus, lower address bus and appropriate control signals (buffered, of course)
Something like the expansion bus on the TRS80-Model III functionally - but "stack-able".
That, of course, would mean the I/O space would have to be decoded so that the Prop doesn't
hog it all.
The whole unit should be no larger than a cell phone (with a big brother about the size of a pad?)
and be completely functional right there in your hand without anything else plugged into it.
Ok, this one is for you!
I went up one size to 10x15cm and there is a lot of spare space on the board now. Maybe room for another 5 or 6 chips. And if it works, easily could be shrunk down by using surface mount to fit under the touchscreen.
One could add a prototyping area. Or buffer the external Z80 bus with some '245s. Or add some more real world chips (A to D and D to A on the I2C bus). Or add some more digital I/O. Or have the memory banking controlled more directly by the Z80.
I was looking at your latest schematic and noticed that you would not be able to get a /CS signal from the 138 decoder into the propeller during an I/O read because your 74HC138 has the /WR signal as its G2A input. So I think you want to connect in /IORQ and perhaps some high address pin (to split up the I/O port range to internal vs external for example) as the G2A, G2B signals of the 138. With this the Z80 can still access the propeller resources with some I/O reads. You might also want to consider connecting in M1 as the G1 input instead of tying to 3V3, so you don't inadvertently decode an interrupt ack cycle.
Otherwise it is looking pretty good and versatile for a larger more expandable system. This larger variant gives you the Z80 expansion, the 512k banked RAM and more touchscreen control over the minimal approach.
Roger - good find. Yes, if cavelamb wants to use the interrupts properly, need to decode M1. Is this correct?
A3 to one of the low enables, /iorq to the other, and M1 to the high enable. That gives 16 ports - 3 used so 13 spare.
@heater - you know, SymbOS looks perfect. Some of the harder things, like two processes wanting access to the SD card at the same time might be possible to handle on the Propeller. It would be slower, but say process 1 was reading a file, and process 2 comes online and wants a different file, Spin could close the first file, open the second file, serve the block of data, shut down the second file, open the first file again. Not as efficient of course, as reading a full block. But it may only need a few new variables within existing spin code to keep track of things. ie read block n from file x. Is file x already open - if yes, get the block. If no, then close whatever file is open and then open the new file.
From the perspective of whatever OS is on the Z80, it behaves as a multitasking OS, and this replicates a huge chunk of MP/M, and may greatly simplify your SymbOS as well.
Much of SymbOS is familiar. Most of the operating system commands are in KyeDOS. There is a playlist manager for songs which would go well with existing propeller wav players.SymbOS would handle things like selecting which song to play. Spin would actually play the song.
There is a nice synergy between the Z80 and the Propeller here. Sure, Spin can play a song, but the code to do this uses up most of the propeller memory so it is hard to write a decent songlist manager. Hand that over to a Z80 operating system.
This could work!
One thing that struck me as an inefficiency with MP/M is that CP/M processes spend a lot of time simply polling for inputs, like a keypress. If an MP/M process is given a 50ms slice of time, it is a bit of a waste just spending that polling. Maybe better to poll a few times and if nothing there, cede control to the next process (which might be doing something like a maths intensive calculation). I wonder if SymbOS addresses this?
From a hardware perspective, if we are thinking multi tasking OS, then the I2C device doing the bank switching (and then issuing a reset in the new bank) is not as fast as it could be. Maybe better to split the ram into two 32k banks in the traditional Z80 way and do bank switching via the latch? See attached schematic - add bank switching under Z80 control. Schematic changed to reflect this.
Reading through the developer documentation http://www.symbos.de/download.htm it seems they are using 16k banks and not the 32k banks in the schematic attached. So re the attached schematic, can that be done with one more OR gate and one more latch output?
Addit - re the graphics, the propeller could do this on VGA/TV and touchscreen easily. Hmm - might need a mouse for VGA and TV.
Yeah, though I would probably picked A7 instead of A3 to split the I/O address range in half and leaving larger blocks of addresses to decode for any external periperals that might need them. You could even use A15 with the 16 bit I/O addressing capability of the Z80 but of course that can get a bit more complicated to control.
And buffering the expansion signals would be a very good idea.
Protect the core circuits from the outside world!
A multi-tasking OS would be nice, but I'd aim at cp/m 2.2 first.
It's simpler to implement. Easier to debug.
Character oriented instead of graphics. (but I got a hook on that already ).
And I'd stick to the A0-A7 I/O addressing - for the same reason.
KISS!
Take the upper or lower 128 for the system I/O, and leave the other for expansion.
16 bit I/O addressing to the LCD display makes sense if it's really faster.
But memory mapping it would be even faster than that.
No automatic I/O WAIT state.
But again, KISS - get it running first.
I was looking at the function calls this morning.
Character and RAW I/O are pretty straight forward, but there will be some fun stuff to deal with!
The new stuff could be implemented via function 50H 60h (not used by CP/M 2.2)
Touch screen / mouse returns.
Graphics writes and reads (!) - Character reads from the screen?
SELECTING THE DESIRED DISPLAY??? VGA vs LCD (Function 153 from MPM?)
Audio out?
Drop a Real Time Clock chip in there maybe?
I'm very fond of DS3231 (easy on the board layout). (function 104-105 CP/M3 - MPM)
SD card gets run through Functions 13 - 46 (disk access).
Probably gonna HAVE to implement USERS to keep it from being completely cluttered.
User 0 as the common file, the rest would be selected like folders or floppies.
Might want to re-label P11 to Z80 CLK in a couple of places.
And the P9 and P10 labels coming off of the 138.
So, Z80 Halt, IORQ, MREW, Busreq and Busack, M1, Int, NMI, Wait, Rd, Wr are all straight Z80 signals (without the prop messing with them) ?
There is nothing at all wrong with your English. It is very good.
I am trying to work out your "Z80ish". We both speak that language! I think you have some very clever ideas and I am trying to work out how to use them
I fixed the floating D8_D15 on the touchscreen like you suggest. Great idea.
I am going to bring all the Z80 pins to a header as cavelamb suggests. To keep things really simple, the Z80 has 40 pins and 40 pin headers are cheap and why not use the same pin numbers as the Z80?
I don't know about the MCP23008 INT line. What sort of interrupts could you trap? Would it be faster or slower than trapping an iorq? Lots to think about.
The MCP23008 reset line does not matter much - the pin can be reset by a software command on the I2C bus but I have never needed to do this as the chip seems very reliable.
re
Ok, that could be very clever. Now, cavelamb says he wants all the ports available and I agree. But... is there an undocumented feature of the Z80 that allows 65536 ports instead of just 256? ie OUT command to port C actually sends to port BC Maybe I am remembering something from a long time ago? But if it is true, then maybe you could decode Z80 A8-A15 instead, and use that to send 16 bit data to the touchscreen?
Dr_Acula
Your words show what a kindly and educated person you are, for sure!
In case I'll do have any chance to visit Australia, i'll surely try to personaly express my admiration.
The reason I've been thinking about connecting the /RST line of the expander to the Propeller one was my lack of knowledge about every possible caveat on MCP23008 interface programming.
As my personal remembrances about using I2C bus connected interfaces are more than ten years outdated, I wonder if its not common to see specs telling a bloat of procedures on how to restart from loose of sync, between the commanding processor and bus connected peripherals.
A freshly restarted piece of hardware could demand fewer lines of code to be set at a known operational state, moreover when its outputs could be at command in some time timing dependent tasks.
Maybe this isn't such the case, but, just if......
That was the underlying thought that drove my wonderings.
I've been thinking some more multitasking and banked memory. I need to study the SymbOS source code a bit more, but it may be helpful to have an interrupt so the propeller can handle the time slicing. Maybe connect NMI to one of the MCP23008 outputs? If someone wanted to use NMI from another board, that would be fine as the default state of a MCP23008 pin is HiZ.
And that leads to a slightly different banking system as NMI jumps to a location in low memory, so it might be better to have the low 256 bytes of ram as the common memory for all banks. I have a schematic idea for that.
It may need a mouse for the SymbOS. That latest board had I2C and SD taking 6 pins but we can use rogloh's combo idea and save two pins for the mouse. We still will have enough pins for stereo sound, and for prop/Z80 comms to have both a data and a status byte.
Agree CPM 2.2 first before more complicated things.
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?
I'll try to explain, in short if possible, the sequence of events that IMHO will allow the proposed system to work flawlessly:
Power on the board - the Propeller, its associated port expander, the Z80 and the display interface got enough reset (polarity as of each ones own needs).
Reset released from the Propeller (and the port expander, if it requires this to be ready to be programmed by the Propeller as soon as possible), but still active to the Z80 (and display interface).
The Propeller is on charge, loads its programm from its external memory and begins executing it.
After starting the needed COG(s), at least one of them begins clocking the Z80, as to ensure its internal reset takes place (3 clocks, minimum, as per Zilog's user manuals).
A Z80, under reset, tri-states its address and data buses, but not the control signals, so care is to be taken to not interpret anything the wrong way.
The COG that will be in charge of commanding the Z80 during its boot, prepares itself to do this job. Perhaps in tight sync with the one that clocks Z80, which is maintaining it under reset.
The boot loop controller COG requests to the reset controller to release the chains, ready to decode Z80 control signals, in order to 'stuff' the first instruction(s) to its data bus. The Ram chip, for sure, must be maintained at a disabled state, at least for read, since the Propeller will be 'feeding' the data bus during the whole session.
After the Z80 ( doing its first and real 'cold boot') understands the first instructions, that might include at least some INI - INIR, if preferred, or LDI - LDIR (wiser, because winning this challenge, we will sure be capable of doing a memory mapped display interface access) it gets data (and keeps getting instructions too, there is a protocol to be exercised here, but it is simpler than most people can imagine to do), from the Propeller, and writes that data to the RAM, starting from 0000h, sequentialy till the end of needed program memory, or, perhaps, till the end of the real 'z80 not so cold boot' or any meaningful name it will be choosen for.
To be continued .... if needed.:cool:
Attempting to not extend a post more than reasonably, i'll continue to explain my thought, latter.
Re the ram /CE line, can you explain the problem a bit more.
There are two ways to talk to the Z80. The first is during a bootstrap, and during this the Z80 will be reset and will try to read from ram location zero and at that point /MREQ will be low. The propeller puts some data into the ram chip, then puts a zero on the data bus, the Z80 thinks it is a NOP and continues to address number 1.
The second scenario is when the Z80 is sending or receiving data from the propeller. That is with an IN or an OUT instruction, and during those instructions the /IORQ line will be low and the /MREQ will be high so the ram is not enabled.
But you are right, with this schematic you can't dump data directly from ram to the touchscreen. Several reasons why not, including using the D8-D15 on the touchscreen from A8-A15. It isn't as good as the other designs, maybe not quite as fast? But it will be easier to code for and maybe it is easier to code something simple first, and then do the clever things later.
The Ram chip, for sure, must be maintained at a disabled state
I think the ram needs to be enabled, not disabled, so that the bootstrap program can be written into the ram?
The 'stealth' technic i'd mentioned before, is a way to use /NMI in an almost 'normal' way, without disrupting any RAM memory contents, irrespective to the O.S. the Z80 is running.
It's, in fact, an extended (and interesting) use of the 'Z80 cold boot one' procedure, described in my last post.
I called it 'stealth', you'd bet, because one can absolutely force it to execute each and every code sequence it would, irrespective to RAM's or something else's content, at the same address of other data or programm code, provided none of the other 'normal' circuits will be 'shorting' or doing 'competitive stuffing' at the same time.
For sure, provided the Propeller has eight COGs, 'cooperative stuffing' is allowed and sure an almost desired behavior, because a true speed gain could be devised here.
Re the ram /CE line, can you explain the problem a bit more.
There are two ways to talk to the Z80. The first is during a bootstrap, and during this the Z80 will be reset and will try to read from ram location zero and at that point /MREQ will be low. The propeller puts some data into the ram chip, then puts a zero on the data bus, the Z80 thinks it is a NOP and continues to address number 1.
The second scenario is when the Z80 is sending or receiving data from the propeller. That is with an IN or an OUT instruction, and during those instructions the /IORQ line will be low and the /MREQ will be high so the ram is not enabled.
I think the ram needs to be enabled, not disabled, so that the bootstrap program can be written into the ram?
Dr_Acula
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.
You have not the need to switch banks or so, carefully crafting the fetches, you'd first output in Z80's data bus, the Propeller furnished 'data', not yet a NOP, for sure, but realy the instruction that will reside at this address (sequentialy), then the Propeller 'clocks' that data into the RAM chip using the RAM's /WR line, because the addressing wil be done by a 'steady and waiting for a NOP' Z80.
After the data (now part of a stored programm) was saved into the RAM, the Propeller finaly outputs a NOP and proceed wit the clocking sequence, till the next 'fetch cycle' occurs, and so on....:thumb:
It's in fact a cooperative task, between the Propeller who furnishes 'code' as 'data' to be put into the RAM, and 'data' (NOPS) as 'code', to foolish the Z80 its reading a string of NOPS from the RAM, whose contents became to pile as a new 'not so cold boot phase two' or, if one needs, up to a full O.S.
During 'cold boot phase one', RAM's contents will be never READ by the Z80, only the Propeller can do it, perhaps for verifying its contents after writing.
If one needs 'not so cold boot phase two', then the programm stored at 'cold boot phase one' will be executed by the Z80, reading from (and writing to, if needed) the RAM.
Comments
@rogloh, I'm going to get a few of the minimalist boards made (Z80, Propeller, eeprom, sram. That idea of sharing the I2C and SD card has made so many more things possible. It is fantastic to know it works.
Hey, that was my secret. I guess it's more widespread than I thought. Not sure what happened to the time it free'd up though. I seem to be able to consume any gains in free time with sleeping:(
Anyway, I'm watching this thread with interest.
Cool. Yes a minimalist approach would be really nice.
Also very glad the I2C+SD thing worked and that I could assist a fellow Aussie into retro stuff. ;-)
Cheers!
Roger.
Arnold Schwarzenegger was in Australia recently and his advice is to "sleep faster" http://motivatingdaily.com/tag/arnold-schwarzenegger/
This thread is seriously more interesting that TV, said another reformed TV addict.
Even the commercials here are cool.
Anyway as the average room, here at work has 50+ screens, or sub screens, why would I want to watch any more at home?
Alan
In the last 24 hours so i was involved many readings on interesting user manuals and datasheets.
Then, when i went back to this thread, I was surprised by how expedite you an all the other participants are in the job of driving projects to the real world.
Truly amazing.
I must warn at first that I have no previous experience with Ilitek's 9325, nor the MCP23008 and only minimal ones with the Propeller 1 itself, so my opinions will only reflect my readings.
Reviewing the Z80 Minimalist you published in the intent of getting a few made for the first time, a couple of connections attracted my attention and I believe they should be rerouted for better results, as follows:
- According to Ilitek's datasheet, nRESET is an active low input pin, whose obvious use is explained by it's name.
Since it appears to be very infrequently used other than just a natural 'power on state' follow up or, in extreme situations of total lose of synchrony with the driving software, a 'last resource' interface restart, it can be directly tied to the Z80 nRESET input.
This behavior could be associated with provisions for a 'Warm Boot', 'First gather data, then check and finaly react' alternate at system's software Z80's equation side.
In my belief, any watchdog timeouts were to be controlled by the Propeller itself, then it will be the tracking agent and also the remedy provider for any unintended behavior, and thus, be itself aware from the misfunction probable origin and takeover strategy.
Moreover, by the fact that 'cold' and 'warm' boots are meant to be Propeller managed tasks, the nRESET line should be connected to a Propeller controlled circuit, kind of an open collector inverter with a pull up at Z80/Ilitek's side.
In order to do this, three more resistors and a NPN transistor are to be added between the Prop pin and the nRESET line.
In this approach, as long as the Prop is under reset, its output pin wil be tristaded, then the transistor will be driven in saturation by the two series associated resistors, causing nRESET to stay LOW during the whole Prop cold boot.
Afterwards, under the control of Propeller's program, the pin will be put in a 'LOW' driven state, cutting transistor's conduction and releasing the nRESET line.
As a bonus, a Prop pin will be spared, but not for a long time, as follows.
- By the fact that is a direct connection at the data bus level, the minimalist approach does not allows for any different data to be traversed to the display interface, other than the one Z80 is gathering. And there are no provisions for a nBUSRQ/nBUSAK interlocked bus protocol, nor an alternate generator to drive the address lines, so the Z80 will be driving them and also the control lines at the time of display write operations.
Also taking in account that nMREQ is directly tied to the RAM as nCE and that the RAM itself will be decoding all de available address range, to differ the read/write cycles destination one must implement display access using I/O cycles.
This thinking points to the need of distinct address spaces to differ the Propeller from the display, as seen by the Z80.
And also the need to properly reserve ample room for blocked I/O data transfers between the Z80 and Ilitek's interface.
Then there comes the need to use two address lines, says A15 to differ between the two, and A14 to internally discriminate between access groups.
Sure, nCS keeps going from Propeller's pin to Ilitek's interface, since at least one COG will be reacting in accordance with (nIOREQ AND A15) to properly sort whose access its intended to do.
But i'm sorry, the Propeller could never write nor read to/from Ilitek's interface because there is no nBUSRQ/nBUSAK interlock at all, so there is no need for it to independently control Ilitek's RS line, then A14 could handle this.
That said, we finaly have an uncompromised pin to spare. Or not?
-In my own vision, there is no reason to don't connect the Illitek's nRD signal to the Z80's one. Some interesting knowledge and a little improvement in debugging could be gained here. There is a whole O.S. running in the background, perhaps it will be useful in a foreseable future. No loss at all.
- I do not know if the other DBn data pins (10 at all) are directed from the connector to Ilitek's chip, but if there are connections, to follow the datasheet, they must be tied to GND. Since Ilitek's timming specs has provisions for a full 10MHz bandwidth at bus transactions, even if we don't use it's maximum, its advisable to respect its mandatory settings.
If there is no intent to do any connections to Ilitek's 10 lower DBn lines, at least pulling them down to GND thru a low valued x10 resistor SIP pack could handle the situation. If it is the present and intended reality, please ignore the following paragraph.
Having so many free address lines, out of any tasks of I/O port discrimination, and in case there is already a viable connection to the rest of Ilitek's chip DBn lines, I was thinking about using Z80's A07 thru A00 to gain a 16 bit interface to Ilitek's chip? What about faster colour fills, at least, as an upgrade bonus? For 'WRITE ONLY' operations, for sure, but that seems to be an at least interesting possibility. The pull downs still apply, for the whole 12 lines. More on this subject latter. But remember, if the "MUST", written on Ilitek's documents, is a mandatory specification, then only a low valued pull down resistor set will handle this.
- At the I/O expander, I've seen you've connected its nRST and INT pins to +3.3V. As I said, I've no experience with its uses, but according its datasheet, INT is a programmable polarity output, so it seems to me its advisable to left it unconnected or directly tied to Z80's nINT line. Since nINT can be ignored by disabling it, if we doesn't need it, no harm at all. The benefits of doing such a connection, can be enjoyed at a latter time.
For the nRST pin, I wonder if its not practical to connect it to the Propeller's similar input. Acting this way, a 'fresh' interface will be found by the Prop, when it begins its setup.
-Two last minute additions:
The spared pin gained elsewhere on the above lines, can be connected to nM1, to help discriminating Z80's I/O cycles from INTA ones. Then one can use nINT behavior under various Z80 modes and 'stuff' vectors or a few instructions into the Z80 and taste a bit of processor slavery.
nMREQ and nBUSRQ can be connected to spare pins at the expander. In a 'purist' approach, one more for nBUSAK. Bloatware, at the hard side? No. Using SIPs to PullUp all control lines and also the not yet elsewhere pulled address ones, your bonus will be a bunch of mailboxes for the Propeller share access with the Z80, spread inside top RAM. The old 55AAh role playing game. Also a way to verify bank switching operations.
In the hope for everyone's indulgence and acknowledging to all the differing opinions....specially yours, Dr_Acula.
Sorry for any typos and none schematics at all!
Yanomani
Please forget this nonsense about Nm1 I wrote at the end of my previous post. I shot a mosquito and let the elephant pass. What we really need is to control the pin / CS RAM using a Propeller pin. Only then can we make the Z80 read and follow the instructions directly injected by the program that runs inside the Propeller with the purpose of transferring the initial contents of the RAM.
I was too anxious and wrapped myself in my own thoughts. Every day, every hour, get up one more lesson. Ourselves, perhaps. You are never too old to learn or too young to know how to do anything.
I leave the remains of my previous post untouched, may be of value later, who knows?
Grateful to all for your patience.
Yanomami
P.S. As an alternative to not slow down access to the Z80 RAM, an OR gate should be used, combining nMREQ with a Propeller pin, instead of simply requiring that all accesses RAM depended on a signal processed internally by a PASM routine.
That "next-size-up" really bumps up the cost of having boards made.
But we all hope that his efforts here are just the start of something really great.
My personal vision (of HIS project!
I'd like to see a board with all surface mount chips that mounts neatly behind a (little bit larger) display
with a nice hot lithium battery tucked in behind that.
All external connectors on one side- even if it means having to use miniature connectors for some of it.
I can accept a cable adapter for that if need be.
On the other end of the board (along one side maybe?) would be a Z-80 I/O bus connector.
Just a pin header or edge connector? with the necessary signals to allow an expansion unit for whatever the user
wants to tack onto it. The data bus, lower address bus and appropriate control signals (buffered, of course)
Something like the expansion bus on the TRS80-Model III functionally - but "stack-able".
That, of course, would mean the I/O space would have to be decoded so that the Prop doesn't
hog it all.
The whole unit should be no larger than a cell phone (with a big brother about the size of a pad?)
and be completely functional right there in your hand without anything else plugged into it.
Pocket CP/M. In color, with a touch screen. Awesome.
I think there's a market for such a device too. Even at a limited production price!
Maybe just among us geeks, but there are a whole lot of us in that category.
Re the /rd line not being decoded on the touchscreen, there is a reason for that - some of the touchscreens run on 3V and some run on 5V. They use the same 40 pin socket and if you put a 5V one in and did a /rd, it would put 5V on our 3V Z80 bus. But yes, if you were careful and only used 3V touchscreens it would be fine to add the /rd line.
@cavelamb, that sounds a great idea. Ok, first build a working model with DIP parts, then change over to surface mount. I'm sure it would all fit as there are only a few chips. And yes, bring out a Z80 bus with all the control pins, and /busrq and the interrupt pins as well. A 40 or 50 pin box header should be fine.
We have a design that works with just a Z80, ram chip and propeller. I'm going to go back though and see what benefits there might be from adding just a few 74xx chips. eg things like an octal latch to talk to the touchscreen /RS, /CS and /Reset pins so the Z80 controls the touchscreen rather than the propeller, and decoding the ports like cavelamb says, so the prop doesn't hog them all.
I'd love to have a little 'pocket CP/M in color'.
Thank you for all your patience and willingness, spending so much time in deciphering what i meant to describe on my former posts.
It's my fault, sir!
My written english skills are far worse than the reading ones, so I must develop a richer vocabulary, in order to don't chain together so many words, as it turns to be unacceptably long and confusing.
I undoubtly have a tendency to do it this way.
In the future, even if and when I finaly attain this level of knowledge, I must manage to refrain my natural prolixity impulses and spend a little more time, figuring out how to explain my thoughts in acceptable minimalist ways.
At least as minimalist as your present design resulted to be.
Having said all this, thanks too for your explanation about the caveats on the /RD signal usefulness versus display's operating voltage. Annotated here!
Yanomani
There is nothing at all wrong with your English. It is very good.
I am trying to work out your "Z80ish". We both speak that language! I think you have some very clever ideas and I am trying to work out how to use them
I fixed the floating D8_D15 on the touchscreen like you suggest. Great idea.
I am going to bring all the Z80 pins to a header as cavelamb suggests. To keep things really simple, the Z80 has 40 pins and 40 pin headers are cheap and why not use the same pin numbers as the Z80?
I don't know about the MCP23008 INT line. What sort of interrupts could you trap? Would it be faster or slower than trapping an iorq? Lots to think about.
The MCP23008 reset line does not matter much - the pin can be reset by a software command on the I2C bus but I have never needed to do this as the chip seems very reliable.
re
Ok, that could be very clever. Now, cavelamb says he wants all the ports available and I agree. But... is there an undocumented feature of the Z80 that allows 65536 ports instead of just 256? ie OUT command to port C actually sends to port BC Maybe I am remembering something from a long time ago? But if it is true, then maybe you could decode Z80 A8-A15 instead, and use that to send 16 bit data to the touchscreen?
Yes in deed, the Z80 can address 65536 I/O ports. The Sinclair Spectrum used that to scan the keyboard matrix I believe. Uncle Clive was always keen on using such undocumented tricks with his chips to minimize circuitry and cost.
It's described here: http://z80.info/z80undoc3.txt along with a ton of other useful stuff.
And yikes that document is complicated. No wonder you had so much trouble with emulating the DAA instruction.
So ok, I might choose to use port 0 to talk to the propeller. Decode that with a '138. And I might choose to use port 1 to talk to the touchscreen.
So to send out 16 bit data (one pixel, RRRRRGG_GGGBBBBB), I put the low byte in A, I put 00000001 in register C, and I put the high byte in register B, and send it out. Hmm - that could speed up the display refresh...
Oh yeah. Don't expect ZiCog to be implementing all the undocumented instructions ever. I bet PullMoll did though.
cavelamb said
Ok, this one is for you!
I went up one size to 10x15cm and there is a lot of spare space on the board now. Maybe room for another 5 or 6 chips. And if it works, easily could be shrunk down by using surface mount to fit under the touchscreen.
One could add a prototyping area. Or buffer the external Z80 bus with some '245s. Or add some more real world chips (A to D and D to A on the I2C bus). Or add some more digital I/O. Or have the memory banking controlled more directly by the Z80.
Hit me with some suggestions!
I was looking at your latest schematic and noticed that you would not be able to get a /CS signal from the 138 decoder into the propeller during an I/O read because your 74HC138 has the /WR signal as its G2A input. So I think you want to connect in /IORQ and perhaps some high address pin (to split up the I/O port range to internal vs external for example) as the G2A, G2B signals of the 138. With this the Z80 can still access the propeller resources with some I/O reads. You might also want to consider connecting in M1 as the G1 input instead of tying to 3V3, so you don't inadvertently decode an interrupt ack cycle.
Otherwise it is looking pretty good and versatile for a larger more expandable system. This larger variant gives you the Z80 expansion, the 512k banked RAM and more touchscreen control over the minimal approach.
Nice.
Roger.
Arrange for your Z80 board to be able to run SymbOS: http://en.wikipedia.org/wiki/SymbOS
A3 to one of the low enables, /iorq to the other, and M1 to the high enable. That gives 16 ports - 3 used so 13 spare.
@heater - you know, SymbOS looks perfect. Some of the harder things, like two processes wanting access to the SD card at the same time might be possible to handle on the Propeller. It would be slower, but say process 1 was reading a file, and process 2 comes online and wants a different file, Spin could close the first file, open the second file, serve the block of data, shut down the second file, open the first file again. Not as efficient of course, as reading a full block. But it may only need a few new variables within existing spin code to keep track of things. ie read block n from file x. Is file x already open - if yes, get the block. If no, then close whatever file is open and then open the new file.
From the perspective of whatever OS is on the Z80, it behaves as a multitasking OS, and this replicates a huge chunk of MP/M, and may greatly simplify your SymbOS as well.
Much of SymbOS is familiar. Most of the operating system commands are in KyeDOS. There is a playlist manager for songs which would go well with existing propeller wav players.SymbOS would handle things like selecting which song to play. Spin would actually play the song.
There is a nice synergy between the Z80 and the Propeller here. Sure, Spin can play a song, but the code to do this uses up most of the propeller memory so it is hard to write a decent songlist manager. Hand that over to a Z80 operating system.
This could work!
One thing that struck me as an inefficiency with MP/M is that CP/M processes spend a lot of time simply polling for inputs, like a keypress. If an MP/M process is given a 50ms slice of time, it is a bit of a waste just spending that polling. Maybe better to poll a few times and if nothing there, cede control to the next process (which might be doing something like a maths intensive calculation). I wonder if SymbOS addresses this?
From a hardware perspective, if we are thinking multi tasking OS, then the I2C device doing the bank switching (and then issuing a reset in the new bank) is not as fast as it could be. Maybe better to split the ram into two 32k banks in the traditional Z80 way and do bank switching via the latch? See attached schematic - add bank switching under Z80 control. Schematic changed to reflect this.
Reading through the developer documentation http://www.symbos.de/download.htm it seems they are using 16k banks and not the 32k banks in the schematic attached. So re the attached schematic, can that be done with one more OR gate and one more latch output?
Addit - re the graphics, the propeller could do this on VGA/TV and touchscreen easily. Hmm - might need a mouse for VGA and TV.
And buffering the expansion signals would be a very good idea.
Protect the core circuits from the outside world!
A multi-tasking OS would be nice, but I'd aim at cp/m 2.2 first.
It's simpler to implement. Easier to debug.
Character oriented instead of graphics. (but I got a hook on that already
And I'd stick to the A0-A7 I/O addressing - for the same reason.
KISS!
Take the upper or lower 128 for the system I/O, and leave the other for expansion.
16 bit I/O addressing to the LCD display makes sense if it's really faster.
But memory mapping it would be even faster than that.
No automatic I/O WAIT state.
But again, KISS - get it running first.
I was looking at the function calls this morning.
Character and RAW I/O are pretty straight forward, but there will be some fun stuff to deal with!
The new stuff could be implemented via function 50H 60h (not used by CP/M 2.2)
Touch screen / mouse returns.
Graphics writes and reads (!) - Character reads from the screen?
SELECTING THE DESIRED DISPLAY??? VGA vs LCD (Function 153 from MPM?)
Audio out?
Drop a Real Time Clock chip in there maybe?
I'm very fond of DS3231 (easy on the board layout). (function 104-105 CP/M3 - MPM)
SD card gets run through Functions 13 - 46 (disk access).
Probably gonna HAVE to implement USERS to keep it from being completely cluttered.
User 0 as the common file, the rest would be selected like folders or floppies.
Might want to re-label P11 to Z80 CLK in a couple of places.
And the P9 and P10 labels coming off of the 138.
So, Z80 Halt, IORQ, MREW, Busreq and Busack, M1, Int, NMI, Wait, Rd, Wr are all straight Z80 signals (without the prop messing with them) ?
Clk, and ?? are fudged?
Now, about multi-banked memory...
Dr_Acula
Your words show what a kindly and educated person you are, for sure!
In case I'll do have any chance to visit Australia, i'll surely try to personaly express my admiration.
The reason I've been thinking about connecting the /RST line of the expander to the Propeller one was my lack of knowledge about every possible caveat on MCP23008 interface programming.
As my personal remembrances about using I2C bus connected interfaces are more than ten years outdated, I wonder if its not common to see specs telling a bloat of procedures on how to restart from loose of sync, between the commanding processor and bus connected peripherals.
A freshly restarted piece of hardware could demand fewer lines of code to be set at a known operational state, moreover when its outputs could be at command in some time timing dependent tasks.
Maybe this isn't such the case, but, just if......
That was the underlying thought that drove my wonderings.
Yanomani
I've been thinking some more multitasking and banked memory. I need to study the SymbOS source code a bit more, but it may be helpful to have an interrupt so the propeller can handle the time slicing. Maybe connect NMI to one of the MCP23008 outputs? If someone wanted to use NMI from another board, that would be fine as the default state of a MCP23008 pin is HiZ.
And that leads to a slightly different banking system as NMI jumps to a location in low memory, so it might be better to have the low 256 bytes of ram as the common memory for all banks. I have a schematic idea for that.
It may need a mouse for the SymbOS. That latest board had I2C and SD taking 6 pins but we can use rogloh's combo idea and save two pins for the mouse. We still will have enough pins for stereo sound, and for prop/Z80 comms to have both a data and a status byte.
Agree CPM 2.2 first before more complicated things.
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
I'll try to explain, in short if possible, the sequence of events that IMHO will allow the proposed system to work flawlessly:
Power on the board - the Propeller, its associated port expander, the Z80 and the display interface got enough reset (polarity as of each ones own needs).
Reset released from the Propeller (and the port expander, if it requires this to be ready to be programmed by the Propeller as soon as possible), but still active to the Z80 (and display interface).
The Propeller is on charge, loads its programm from its external memory and begins executing it.
After starting the needed COG(s), at least one of them begins clocking the Z80, as to ensure its internal reset takes place (3 clocks, minimum, as per Zilog's user manuals).
A Z80, under reset, tri-states its address and data buses, but not the control signals, so care is to be taken to not interpret anything the wrong way.
The COG that will be in charge of commanding the Z80 during its boot, prepares itself to do this job. Perhaps in tight sync with the one that clocks Z80, which is maintaining it under reset.
The boot loop controller COG requests to the reset controller to release the chains, ready to decode Z80 control signals, in order to 'stuff' the first instruction(s) to its data bus. The Ram chip, for sure, must be maintained at a disabled state, at least for read, since the Propeller will be 'feeding' the data bus during the whole session.
After the Z80 ( doing its first and real 'cold boot') understands the first instructions, that might include at least some INI - INIR, if preferred, or LDI - LDIR (wiser, because winning this challenge, we will sure be capable of doing a memory mapped display interface access) it gets data (and keeps getting instructions too, there is a protocol to be exercised here, but it is simpler than most people can imagine to do), from the Propeller, and writes that data to the RAM, starting from 0000h, sequentialy till the end of needed program memory, or, perhaps, till the end of the real 'z80 not so cold boot' or any meaningful name it will be choosen for.
To be continued .... if needed.:cool:
Attempting to not extend a post more than reasonably, i'll continue to explain my thought, latter.
Cheers
Yanomani
Re NMI, I agree. Would /INT work instead?
Re the ram /CE line, can you explain the problem a bit more.
There are two ways to talk to the Z80. The first is during a bootstrap, and during this the Z80 will be reset and will try to read from ram location zero and at that point /MREQ will be low. The propeller puts some data into the ram chip, then puts a zero on the data bus, the Z80 thinks it is a NOP and continues to address number 1.
The second scenario is when the Z80 is sending or receiving data from the propeller. That is with an IN or an OUT instruction, and during those instructions the /IORQ line will be low and the /MREQ will be high so the ram is not enabled.
But you are right, with this schematic you can't dump data directly from ram to the touchscreen. Several reasons why not, including using the D8-D15 on the touchscreen from A8-A15. It isn't as good as the other designs, maybe not quite as fast? But it will be easier to code for and maybe it is easier to code something simple first, and then do the clever things later.
I think the ram needs to be enabled, not disabled, so that the bootstrap program can be written into the ram?
The 'stealth' technic i'd mentioned before, is a way to use /NMI in an almost 'normal' way, without disrupting any RAM memory contents, irrespective to the O.S. the Z80 is running.
It's, in fact, an extended (and interesting) use of the 'Z80 cold boot one' procedure, described in my last post.
I called it 'stealth', you'd bet, because one can absolutely force it to execute each and every code sequence it would, irrespective to RAM's or something else's content, at the same address of other data or programm code, provided none of the other 'normal' circuits will be 'shorting' or doing 'competitive stuffing' at the same time.
For sure, provided the Propeller has eight COGs, 'cooperative stuffing' is allowed and sure an almost desired behavior, because a true speed gain could be devised here.
Yanomani
Dr_Acula
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.
You have not the need to switch banks or so, carefully crafting the fetches, you'd first output in Z80's data bus, the Propeller furnished 'data', not yet a NOP, for sure, but realy the instruction that will reside at this address (sequentialy), then the Propeller 'clocks' that data into the RAM chip using the RAM's /WR line, because the addressing wil be done by a 'steady and waiting for a NOP' Z80.
After the data (now part of a stored programm) was saved into the RAM, the Propeller finaly outputs a NOP and proceed wit the clocking sequence, till the next 'fetch cycle' occurs, and so on....:thumb:
It's in fact a cooperative task, between the Propeller who furnishes 'code' as 'data' to be put into the RAM, and 'data' (NOPS) as 'code', to foolish the Z80 its reading a string of NOPS from the RAM, whose contents became to pile as a new 'not so cold boot phase two' or, if one needs, up to a full O.S.
During 'cold boot phase one', RAM's contents will be never READ by the Z80, only the Propeller can do it, perhaps for verifying its contents after writing.
If one needs 'not so cold boot phase two', then the programm stored at 'cold boot phase one' will be executed by the Z80, reading from (and writing to, if needed) the RAM.
Yanomani