A new QL emulator

[RWAP]

Cesar Hernandez Bano has managed to add QL emulation (at least the start up screen) to his ZEsarUX emulator:

https://youtu.be/8czvSwHj5es

[Outsoft]

olè

[chernandezba]

Hi

Yes! I'm currently working on adding QL emulation.
I'm fighting with keyboard emulation, I looked at mame sources and also at uqlx sources. But I don't understand it all.

Any one knows a detailed guide about IPC protocol? Specially the keyboard part...

Cheers
Cesar

[dilwyn]

Hi

Yes! I'm currently working on adding QL emulation.
I'm fighting with keyboard emulation, I looked at mame sources and also at uqlx sources. But I don't understand it all.

Any one knows a detailed guide about IPC protocol? Specially the keyboard part...

Cheers
Cesar

Hi Cesar,
The closest I can think of is the commented 8049 IPC chip code disassembly on http://www.dilwyn.me.uk/docs/disassem/index.html

I have never looked at it in great detail to see if the information you want is in there, sorry.

You might also get some insight from looking at the JM ROM, JS ROM and Minerva ROM sources at the same page. Various items on the documentation pages may contain snippets of information - have a look through http://www.dilwyn.me.uk/docs/asm/index.html for example.

There is also the SMSQ/E sources available from SMSQ/E Registrar Wolfgang Lenerz at http://www.wlenerz.com/smsqe/

Try to contact one of the other QL emulator authors (some can be contacted through their websites - follow links from http://www.dilwyn.me.uk/emu/index.html )

[chernandezba]

Thanks a lot dilwyn
I've taken a fast look at IPC rom source and I think it could be very useful for me. Also looking at other emulator source code can help me with my goal. I already looked at uqlx sources but I think it emulates the keyboard by intercepting traps at rom instead of emulating the IPC

Regards
Cesar

[Outsoft]

Thanks a lot dilwyn
I've taken a fast look at IPC rom source and I think it could be very useful for me. Also looking at other emulator source code can help me with my goal. I already looked at uqlx sources but I think it emulates the keyboard by intercepting traps at rom instead of emulating the IPC

Regards
Cesar

Great Job!

[XorA]

Thanks a lot dilwyn
I've taken a fast look at IPC rom source and I think it could be very useful for me. Also looking at other emulator source code can help me with my goal. I already looked at uqlx sources but I think it emulates the keyboard by intercepting traps at rom instead of emulating the IPC

I think mame emulates the IPC, so you can probably get ideas from there,

G

[mk79]

I did write an IPC emulation once... 20 years ago. I've switched QPC to SMSQ/E before finishing SER etc., but the keyboard did work. Any particular question? It's a fairly simple bit-banging protocol.

[chernandezba]

I did write an IPC emulation once... 20 years ago. I've switched QPC to SMSQ/E before finishing SER etc., but the keyboard did work. Any particular question? It's a fairly simple bit-banging protocol.

Thanks. Well the particular question is how the IPC ports works? Is there any document that explains how these I/o ports are programmed?

[tofro]

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:

Code: Select all

* ipcmd : IPC link commands
        nolist

* command nibbles sent to IPC:

*rset_cmd equ    0       resets the IPC software

stat_cmd equ    1       report input status
* returns a byte, the bits of which are:
ipc..kb equ     0       set if data available in keyboard buffer, or key held
ipc..so equ     1       set if sound is still being generated
*               2       set if kbd shift setting has changed, with key held
*               3       set if key held down
ipc..s1 equ     4       set if input is pending from RS232 channel 1
ipc..s2 equ     5       set if input is pending from RS232 channel 2
ipc..wp equ     6       return state of p26, currently not connected
*               7       was set if serial transfer was being zapped, now zero

ops1_cmd equ    2       open RS232 channel 1
ops2_cmd equ    3       open RS232 channel 2
cls1_cmd equ    4       close RS232 channel 1
cls2_cmd equ    5       close RS232 channel 2
* These open/close RS232 channels, affecting handshaking.

rds1_cmd equ    6       read RS232 channel 1
rds2_cmd equ    7       read RS232 channel 2
* These return a byte with a count in the ls 6 bits of how many received
* serial channel bytes are to follow. The ms 2 bits contain status info...
* Silly, but the following implies that the IPC must never send more than...
sbsize  equ     25      minimmum space needed to receive whole IPC RS232 buffer

rdkb_cmd equ    8       read keyboard
* This returns one nibble, plus up to 7 nibble/byte pairs:
* first nibble, ms bit: set if final last keydef is still held
* first nibble, ls 3 bits: count of keydefs to follow.
* then, for each of the 0..7 keydefs:
* nibble, bits are 3210=lsca: lost keys (last set only), shift, ctrl and alt.
* byte, bits are 76543210=00colrow: column and row as keyrow table.
* There is a version of the IPC used on the thor that will also return keydef
* values for a keypad. This needs looking up.

kbdr_cmd equ    9       keyboard direct read
* kbdr_cmd requires one nibble which selects the row to be read.
* The top bit of this is ignored (at least on standard IPC's...).
* It responds with a byte whose bits indicate which of the up to eight keys on
* the specified row of the keyrow table are held down.

inso_cmd equ    10      initiate sound process
* This requires no less than 64 bits of data. it starts sound generation.
* Note that the 16 bit values below need to have their ls 8 bits sent first!
* 8 bits pitch 1
* 8 bits pitch 2
* 16 bits interval between steps
* 16 bits duration (0=forever)
* 4 bits signed step in pitch
* 4 bits wrap
* 4 bits randomness (none unless msb is set)
* 4 bits fuziness (none unless msb is set)

kiso_cmd equ    11      immediately stop sound generation

*mdrs_cmd equ    12      microdrive reduced sensitivity
* This expects one nibble, of which only the lsb is significant. This was
* intended for allowing marginal tapes to be handled, but had a strange side
* effect of causing permanent level 2 interrupts! the QView capsled kit steals
* This bit of h/w (on leg of the chip) to drive the led.
* Hermes uses a parameter value of 9 to switch on its clever handling, when the
* reset command becomes an extended functionally command and the test command
* will return the complemented byte value.

baud_cmd equ    13      change baud rate
* This expects one nibble, of which the 3 lsbs select the baud rate for both
* serial channels. The msb is ignored. Values 7 down to zero correspond to baud
* rates 75/300/600/1200/2400/4800/9600/19200.
* The actual clock rate is supplied from the PC to the IPC, but this command is
* also needed in the IPC for timing out transfers!

*rand_cmd equ    14      random number generator, returns a sixteen bit number.

*test_cmd equ    15      test, expects a byte, which it then sends back.

* Communication with the IPC is done using the following bit serial protocol.

* Commands and data are sent msb first, by writing a byte containg %11x0 to
* location pc_ipcwr ($18023), where the "x" is one data bit. Bit 6 at location
* pc_ipcrd ($18020) is then examined, waiting for it to go zero to indicate
* that the bit has been received by the IPC.

* 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.

* Note: pc_tdata ($18022) is where full 8 bit data bytes are sent for serial
* output, with the PC interrupting whenever it is ready for more.

        list

Hope this helps,
Tobias