I guess everyone has a secret, and mine is that I decided some years ago to give up watching television.
Dr_Acula wrote: »
@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 seem to be able to consume any gains in free time with sleeping
Heater. wrote: »
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.
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.
And yikes that document is complicated
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.
Dr_Acula wrote: »
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.
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?
The Ram chip, for sure, must be maintained at a disabled state
Dr_Acula wrote: »
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?