I was about to suggest the MESS source might be a good place to start.
As for replacing it, you'd probably not be able to replace the ZX8302 with a microcontroller as you suggest as there is no way such a device could respond quickly enough to say a memory request.
You could possibly replace the 8049 with another controller as long as you kept to the protocol used to communicate with the ZX8302. But as far as replacing the ZX8302 itself you'd want to be looking at a CPLD or FPGA as a replacement as it basically contains logic functions. That should be dooable.
Cheers.
Phill.
ZX8302- is anything concrete known abut it ?
Re: ZX8302- is anything concrete known abut it ?
Ahh that may be doable, but you would indeed need some logic to interface to the rest of the QL, at the very least you would need some level shifters as a modern microcontroller fast enough to emulate the 68008 is probably going to be 3.3V 
You also have to make it look like a 68008 bus to the rest of the system as that is what it will be expecting.
I dare say you could get a major improvement in speed of IPC communication if you just mapped a byte wide communication port into the 68008 memory map (e.g. the slave parallel of the various PICs), it would sure beat the very inefficient serial protocol that the ZX8302 <--> IPC communication uses.....
Cheers.
Phill.
You also have to make it look like a 68008 bus to the rest of the system as that is what it will be expecting.
I dare say you could get a major improvement in speed of IPC communication if you just mapped a byte wide communication port into the 68008 memory map (e.g. the slave parallel of the various PICs), it would sure beat the very inefficient serial protocol that the ZX8302 <--> IPC communication uses.....
Cheers.
Phill.
Re: ZX8302- is anything concrete known abut it ?
Re: your original question:
The QL's hardware registers ($18000-$18003 - mainly "real" time clock and IPC comms and $18020-$18003 - Display, Microdrives and RS232, plus the Interrupt enables/status for 4 supported interrupt sources) are described - somewhat - in the QL Technical guide, Chapter 10, Page 57 in my edition. What the single bits mean is described in the Appendix, chapter 18.13, page 172+
So, the hardware is pretty well documented (as there isn't much to document
)
Minerva 1.98 compiles fine using the Quanta/GST assembler - What's missing from the official sources (Dilwyn) is a Makefile or somesuch.
Tobias
The QL's hardware registers ($18000-$18003 - mainly "real" time clock and IPC comms and $18020-$18003 - Display, Microdrives and RS232, plus the Interrupt enables/status for 4 supported interrupt sources) are described - somewhat - in the QL Technical guide, Chapter 10, Page 57 in my edition. What the single bits mean is described in the Appendix, chapter 18.13, page 172+
So, the hardware is pretty well documented (as there isn't much to document
)Minerva 1.98 compiles fine using the Quanta/GST assembler - What's missing from the official sources (Dilwyn) is a Makefile or somesuch.
Tobias
ʎɐqǝ ɯoɹɟ ǝq oʇ ƃuᴉoƃ ʇou sᴉ pɹɐoqʎǝʞ ʇxǝu ʎɯ 'ɹɐǝp ɥO
Re: ZX8302- is anything concrete known abut it ?
What Tobias said. The QL addresses all of it's on-board peripherals in a very small block of 64 bytes starting at $18000. The only other thing that uses this 16k block is the QIMI mouse, ~256 bytes at the top of it ($1BF00..1BFFF). The rest can be freely used although Aurora decodes $18100..1BEFF as the extra Ioa rea, the signal is available on a pin on the extended ROM slot. This can be used to simply decode simple peripherals. Expect upcoming hardware to use parts of this area! In particular, uIDE will use a 256 byte chunk there. One of the problems with re-doing hardware that has to run old programs is that the first 256 bytes at $18000 have to be emulated. My proposal is to include the whole 16k and decode axtra hardware in there - since it has to be there anyway. So far QL/Aurora uses the bottom 256 bytes, QIMI uses the top 256 bytes.
Obviously, since originally it's the 8301 that does the decoding, pulling DSMCL high when these addresses appear on the bus will also disable the 8301 registers. Aurora aims to be compatible with that and will disable anything it maps onto an address if DSMCL is pulled high when that address appears on the bus.
Re replacing the 8302, yes please. I wish there were some simple uCs with a small dual port RAM or somesuch thing, i.e. a host port. Alternatively, a small CPLD coupled to a small uC would do this nicely. It's the uC that would do all the real work. Even the cheapest PIC or AVR would so far better than the hardware inside an 8302.
Obviously, since originally it's the 8301 that does the decoding, pulling DSMCL high when these addresses appear on the bus will also disable the 8301 registers. Aurora aims to be compatible with that and will disable anything it maps onto an address if DSMCL is pulled high when that address appears on the bus.
Re replacing the 8302, yes please. I wish there were some simple uCs with a small dual port RAM or somesuch thing, i.e. a host port. Alternatively, a small CPLD coupled to a small uC would do this nicely. It's the uC that would do all the real work. Even the cheapest PIC or AVR would so far better than the hardware inside an 8302.