8302<>8049 communications...

[Dave]

This is a branch off the previous 8049 thread here: http://www.theqlforum.com/viewtopic.php?f=2&t=2019

My question this time is to build up a small library of knowledge here about communication between the 8032 and 8049.

From the hardware perspective, the link between them is four lines.

BAUDX4, from 8302 pin 5 to 8049 pin 39
COMCTL, from 8302 pin 29 (labeled 22 on schematic) to 8049 /WR on pin 10 (direction control)
COMDATA, from 8302 pin 35 to 8049 pin 38
RESET, from 8302 pin 28 to 8049 pin 4 /RESET

Does anyone have any pre-prepared notes on this link? It'll save me a few hours of work documenting it. This would in part involve me reading the 8049 disassembly, which I suspect will be obtuse, and quite difficult for me

My objective here is to work on an 8049 replacement using a much more capable IC.

[Pr0f]

I've got bits and bobs I've scoured from various sources, both high level and low level..

The low level stuff:

75 Send bit to IPC
76 ---------------
77
78 1. ZX start bit (COMDATA = 0)
79 2. IPC clock (COMCTL = 0, COMTL = 1)
80 3. ZX data bit (COMDATA = 0/1)
81 4. IPC clock (COMCTL = 0, COMTL = 1)
82 5. ZX stop bit (COMDATA = 1)
83
84 Receive bit from IPC
85 --------------------
86
87 1. ZX start bit (COMDATA = 0)
88 2. IPC clock (COMCTL = 0, COMTL = 1)
89 3. IPC data bit (COMDATA = 0/1)
90 4. IPC clock (COMCTL = 0, COMTL = 1)
91 5. IPC stop bit (COMDATA = 1)

In the IPC it loops around reading the keyboard and checking the COMDATA line for activity - as soon as it sees the line change, it collects a nibble of 4 bits and uses this to branch into one of the routines - using a jump table:

; get IPCOM cmd or else scan keyboard
0200: 0A IN A,P2
0201: 53 80 ANL A,#80
0203: C6 07 JZ #0207 comdata=L?
0205: A4 00 JMP $500 scan keyboard
0207: F4 4F CALL $74F get 4bit data from ZX8302, ret A.lsb
0209: 03 0C ADD A,#0C
020B: B3 JMPP @A jump according IPCOM table $20C
;
; IPCOM jump table
020C: 1C DFB #1C 0: init IPC
020D: 28 DFB #28 1: get interrupt status
020E: 1E DFB #1E 2: open ser1
020F: 1E DFB #1E 3: open ser2
0210: 20 DFB #20 4: close ser1
0211: 20 DFB #20 5: close ser2
0212: 89 DFB #89 6: serial1 receive
0213: 89 DFB #89 7: serial2 receive
0214: 4D DFB #4D 8: read keyboard
0215: 76 DFB #76 9: keyrow
0216: 22 DFB #22 a: set sound
0217: 24 DFB #24 b: kill sound
0218: C3 DFB #C3 c: set P2.3
0219: CF DFB #CF d: set serial baudrate
021A: E3 DFB #E3 e: get random
021B: F0 DFB #F0 f: test
...
the respective routines sit after this table, and will collect additional nibbles or bytes as they require.

[Pr0f]

It's not dissimilar to the way ps/2 or spi or i2c work in using a clocking line and a data line - and the decision of who is reading or writing is defined by the protocol. The 8049 can only send data when it's asked, so the CPU is always in charge and will initiate any of the requests above when it needs data or work doing.

It does look like the 8049 should be capable of sending an interrupt to the CPU, to flag that it requires service, and in fact both interrupt lines are connected. This gives rise to that wonderful problem of CTRL ALT 7 which send a level 7 interrupt and resets the 8049 using it's startup sequence. This promptly cuts off the IPC from the rest of the QL, which hasn't initialised...

[Dave]

Yeah. I'm going to have to get the scope on it and figure out data rates, etc.

I just want to get keyboard working. The serial implementation isn't worth duplicating as a proper UART can do the job much more cleanly. Sound can come later.

[tofro]

Just for the record (even if the above already somewhat covers that by not covering it) - The BAUDX4 line is not used for communication between the 68k and the 8049 at all - It's simply providing a basic baud rate clock to the 8049 for the serial ports and has nothing to do with internal comms - So can be neglected for your current exercise.

With regards to similarity to PS/2: The IPC comms is in a way simpler and in a way more complex than that - There is no framing or similar involved here, no start, nor stop bits, so comms could easily be lost if one of the partners sends too many or not enough bits or misses bits. Both the 68k and 8049 code need to know exactly how many bits are to be sent/received for a specific message/command type, so the whole thing is not working based on a protocol, but rather a convention. In case this would go out of sync for any reason, there is nearly no chance to re-establish comms between the two partners.

Tobias

[Derek_Stewart]

Hi,

Could the 8302 and 8049 be combined into a FPGA chip?

[Pr0f]

There are several options I suppose - but it depends on how far up the 'pipe' you want to reengineer.

If the goal is to leave the ROM intact and not rewrite the MT.IPCOM trap, then you need to at least appear to be compatible with the ZX8302 / 8049 link.

Given this link is a 1 bit link, then you could easily replace the 8049 with anything capable of processing the serial stream - which is just about any small micro. However, the goal stated above was to replace the ZX8302 - so this changes the viewpoint somewhat - do you need to replicate that link exactly, or just emulate what it did?

It's entirely feasible to have a new ZX8302 that does the keyboard scan directly, and just responds back through the same interface that the ZX8302 presents to the QL.

You need to ask what functions you want to preserve on the ZX8302 - which will guide you towards replacing it.

I agree about serial comms - a UART / DUART could cover that off, which leaves the following functions:

RTC - a 4 byte counter with some additional logic to shuffle step it to allow setting it.
QL Network port
Microdrive functionallity
Keyboard scan
Keyrow scan
Sound

Something approximating to QL sound can be found in the AY 8910 chip found in speccy's and other 80's micro's, and there is VHDL code for it available to, meaning it could be ported / modified into a CPLD or FPGA. Simiar code exists for PS/2 keyboard. There are a number of small FPGA boards arround that could probably fill the role of the ZX8302/8049 as a combo and be plug in compatible to the 8302 socket. If you want to maintain the membrane keyboard and joysticks then you will probably want some flying cable and a plug in board where the 8049 was....

[Peter]

There are a number of small FPGA boards arround that could probably fill the role of the ZX8302/8049 as a combo and be plug in compatible to the 8302 socket.

Examples would be welcome! I don't know any available FPGA board with 5V tolerance. Let alone a board which is small enough to plug into that DIL socket.

Peter

[Pr0f]

There are a number of small FPGA boards arround that could probably fill the role of the ZX8302/8049 as a combo and be plug in compatible to the 8302 socket.

Examples would be welcome! I don't know any available FPGA board with 5V tolerance. Let alone a board which is small enough to plug into that DIL socket.

Peter

https://shop.trenz-electronic.de/en/Pro ... nik/GODIL/

[Pr0f]

That's slightly cheating as it has a couple of voltage translators on board. However, Dave is gifted in the hardware design area, so a 3.3V i/O based FPGA with some form of input conditioning, or a 5v tolerant device such as the device used in the QL_SD board (Lattice 4000 series?) - I know that's a CPLD, but the 4128 and 4256 have a good number of macro cells for building logic from.