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

Reply via email to