A new QL emulator

[chernandezba]

Cesar,
from a technical (hardware) point of view, the keyboard/IPC interface is a serial port to a micro-controller. The QL is sending command strings (bit-banged), the 8049 (hopefully) sends some answers back. The protocol to the IPC is not 100% documented, though.

Some documentation on the available commands can be found in this manual:
http://www.dilwyn.me.uk/docs/manuals/qltm.pdf
(page 79, page 171)
The protocol to/from the IPC is nibble (half-byte) based.

The Minerva source codes have a description of the command format and registers involved as well:


Hope this helps,
Tobias

I see.. serial interface... it seems clearer now
Thanks a lot. I think this information will be very useful to add keyboard emulation.

Cheers

[chernandezba]

Cesar,
from a technical (hardware) point of view, the keyboard/IPC interface is a serial port to a micro-controller. The QL is sending command strings (bit-banged), the 8049 (hopefully) sends some answers back. The protocol to the IPC is not 100% documented, though.

Some documentation on the available commands can be found in this manual:
http://www.dilwyn.me.uk/docs/manuals/qltm.pdf
(page 79, page 171)
The protocol to/from the IPC is nibble (half-byte) based.

The Minerva source codes have a description of the command format and registers involved as well:



Hope this helps,
Tobias

The information says:

"
Commands and data are sent msb first, by writing a byte containg %11x0 to
* location pc_ipcwr , where the "x" is one data bit.

* Receiving data from the IPC is done by writing %1110 to pc_ipcwr for each bit
"

So. they use the same port, and that initial "x" could also be a 0... So how do you difference between the first and the second case? If you set x to 1, then the value is %1110, like the second case...

Or does the first case stop only when you write a nibble-4 bits (4 sentences %11x0, %11x0, %11x0, %11x0) ?

[tofro]

I understand the section as follows:

To send 11 = 0xb = %1011, you would do the following (in pseudo code):

Code: Select all

$18023 = %1110 : REM Send a "1" bit
REPEAT 
UNTIL $18020 & %1000000 == 0

$18023 = %1100 : REM Send a "0" bit
REPEAT 
UNTIL $18020 & %1000000 == 0

$18023 = %1110 : REM Send a "1" bit
REPEAT 
UNTIL $18020 & %1000000 == 0

$18023 = %1110 : REM Send a "1" bit
REPEAT 
UNTIL $18020 & %1000000 == 0

That is, bit 1 of what's written to $18023 is the actual data bit (MSB first), Bit 6 of $18020 going "0" signals you can do the next bit

In order to decide whether you send or receive, look at this section:

Receiving data from the IPC is done by writing %1110 to pc_ipcwr for each bit of the data, once again waiting for bit 6 at pc_ipcrd to go to zero, and* then reading bit 7 there as the data bit. The data is received msb first.

The reason behind effectively sending a one bit for each read is the way the hardware functions. There are only two wires between the PC and IPC to work with, and only one is bi-directional. Even this is limited, in that either end can force it to zero, but both ends must agree to make it a one. Hence when the PC is trying to read data from the IPC, it must be asserting a one in order to see whether the IPC is returning a one or zero bit.

That is, actually, there is no difference in sending and receiving. For sending, you ticker out the bits one after the other, effectially ignoring what comes back from the IPC (bit 7 in $18023) and only looking at the ready bit (bit 6), for receiving, you need to ticker out a "1" bit for every bit you want to receive (and then, obviously check that received bit in {7|$18023}. Works similar to the SPI protocol used by, for example SD cards, in case you happen to know that.

And, obviously, you need to know exactly when, what, and how many bits you want to send or receive, according to the protocol.

Thus
To receive 4 bits, you would do the following (in pseudo code):

Code: Select all

$18023 = %1110 : REM Send a don't care bit (needs to be "1" to actually do something, but will be ignored on other end)
REPEAT 
UNTIL $18020 & %1000000 == 0
rec[3] = $18020 & %10000000

$18023 = %1110 : REM Send a don't care bit (needs to be "1" to actually do something, but will be ignored on other end)
REPEAT 
UNTIL $18020 & %1000000 == 0
rec[2] = $18020 & %10000000

$18023 = %1110 : REM Send a don't care bit (needs to be "1" to actually do something, but will be ignored on other end)
REPEAT 
UNTIL $18020 & %1000000 == 0
rec[1] = $18020 & %10000000

$18023 = %1110 : REM Send a don't care bit (needs to be "1" to actually do something, but will be ignored on other end)
REPEAT 
UNTIL $18020 & %1000000 == 0
rec[0] = $18020 & %10000000

Tobias

[chernandezba]

Thanks!! It seems a lot clearer now and very simple
I will try it and tell you if it works for me.

Cheers

[chernandezba]

Well I have improved it a bit. Now I can read the first ipc commands (set baud rate) with its parameter (exactly 4 bits - a nibble).
But after that, I only have read ipc commands (no more writes) so no keyboard handling...
Anyone knows how are interrupts managed on the QL?

[tofro]

On a standard QL, the only interrupt that is actually driving the system is the timer interrupt all 1/50 (1/60) seconds (some exceptions apply which are not relevant here, though).

All hardware is polled for "data available" in the polling loop which is triggered by this timer.

Tobias

[chernandezba]

On a standard QL, the only interrupt that is actually driving the system is the timer interrupt all 1/50 (1/60) seconds (some exceptions apply which are not relevant here, though).

All hardware is polled for "data available" in the polling loop which is triggered by this timer.

Tobias

Thanks. You know which call/trap is generated with this interrupt?
In Z80 for example a IM1 interrupt calls to address 38H

[mk79]

On a standard QL, the only interrupt that is actually driving the system is the timer interrupt all 1/50 (1/60) seconds (some exceptions apply which are not relevant here, though).

All hardware is polled for "data available" in the polling loop which is triggered by this timer.

Not quite. It's true there is only one interrupt (level 2), but the polling event is just one source for the interrupt. The microdrives, serial ports or external hardware (floppy drive etc.) trigger it, too. The actual source can be read using the pc.intr register. The keyboard however is just polled.

[tofro]

Marcel,
that's why I said "there are exceptions....not relevant here"

Tobias