Excellent writeup, thanks Miguel! Your explanation does make it very clear why it is a read-only port :)
I was guessing the double read mechanism would be something like you outlined below. It's actually a very clever trick. If you want help with the software side of things I'll be glad to help where I can. I don't have tons of 68k Asm experience but have written some stuff on it. Best regards, Petri On Sun, Sep 26, 2010 at 9:27 PM, Miguel Angel Rodriguez Jodar <[email protected]> wrote: > El 26/09/2010 19:40, Petri Pellinen escribió: >> >> Hi Dilwyn, >> >> on the ROM connector. My initial assumption was that a manner of >> memory mapped I/O would be possible through the slot. > > Of course, but you mast take into account that: > - The ROMOEH signal goes active only with read bus cycles, not write cycles. > - There's no R/W signal on the ROM expansion connector (although it would be > possible to wire that signal on one of the unused pads). > > If you would decide to forget about the ROMOEH to perform true writes, you > would find that there's no AS or DS signals available too, so you would only > rely on the value of address lines to know when your device is being > addressed. Besides, there's no way to signal the end of the bus cycle, as > DTACK is not available too. > > So there's no way (AFAIK) a card plugged into the ROM expansion would know > when a write bus cycle is about to happen. This is because odd techniques > must be applied to perform a write using reads. > > One of them is, as explained, to reserve a region of the ROM address space > (0C000-0FFFF) which will hold your device hardware registers. That region > cannot be the last 512 bytes, i.e. 0FE00 - 0FFFF, because that region will > be reserved for our write scheme. Let's assume you will need at most 256 > hardware registers for your device (surely you will need far less than > this). > > Let's say you want to put a value "dd" (8 bits) into the register numbered > "aa" (8 bits). You first make a read bus cycle from address FEaa (and > discard the result). Your device captures the LSB of that address from the > CPU address lines and store it in an internal 8 bit "address" latch. Then, > you make a read from address FFdd (and again, discard the result). Your > device will take the LSB of the CPU address (actually the data you're going > to write) and will write it into the device register pointed by the > "address" register. > > Something like (not sure if this is correct assembly for 68000): > > move.l #$FEaa,a0 ; Where "aa" is the register number we want to write into. > move.b (a0),d0 ; Discard the result in D0. > move.l #$FFdd,a0 ; Where "dd" is the 8-bit value we want to write > move.b (a0),d0 ; Discard the result in D0. > ; Value "dd" has been writeen into register "aa". > > For normal reads, we'd just use a standard approach. Let's say your hardware > registers are mapped into addresses 0FD00-0FDFF . So, this will do the job: > > move.l #$FDaa,a0 ; We are going to read from register "aa" > move.b (a0),d0 ; Read it and store the result in D0. > >> If someone has any h/w designs lying around I would be happy to >> colllaborate and pitch in on the dreaded driver side of things. I can > > I've some ideas but I lack experience on writting 68k assembler and writting > directory drivers. I've just bought the "Advanced QL User Guide", and hope > to have enough time to read it carefully and start making experiments. > >> but, bitten by the retrocomputing bug, I would love to implement >> something on the original hardware. > > I have three original QL's, and no "modern" QL's, so if I do something, it > will be for the original hardware. > _______________________________________________ > QL-Users Mailing List > http://www.q-v-d.demon.co.uk/smsqe.htm > _______________________________________________ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
