8302<>8049 communications...

[Dave]

Leaving here for reference and so it's searchable.

1 - T0 - NOT CONNECTED
2 - XTAL1
3 - XTAL2
4 - /RESET from 8302 RESETOUTL
5 - SS - tied to +5V thru 4K7
6 - /INT - Combined TXD/RXD (also on pin 21)
7 - EA (tied to GND thru 1K
8 - /RD - NOT CONNECTED
9 - /PSEN - NOT CONNECTED
10 - /WR from COMCTL 8302
11 - ALE - NOT CONNECTED
12 - DB0 - KBI0
13 - DB1 - KBI1
14 - DB2 - KBI2
15 - DB3 - KBI3
16 - DB4 - KBI4
17 - DB5 - KBI5
18 - DB6 - KBI6
19 - DB7 - KBI7
20 - GND
21 - Combined TXD/RXD (also on pin 6)
22 - Audio out
23 - /IPL0-2 from CPU
24 - /IPL1 from CPU
25 - PROG - NOT CONNECTED
26 - +5V
27 - P10 - KBO0
28 - P11 - KBO1
29 - P12 - KBO2
30 - P13 - KBO3
31 - P14 - KBO4
32 - P15 - KBO5
33 - P16 - KBO6
34 - P17 - KBO7
35 - J6 CTS
36 - J5 DTR
37 - P2-6 NOT CONNECTED
38 - COMDATA
39 - BAUDX4 from 8302
40 - +5V

[Dave]

Pins 6/21, the combined TXD/RXD:

In issue 5, these pass through two gates of IC27 - 74LS03 - and are the combined RXD from J5 pin 3 and CTXD from J6 pin 2.

In issue 6/7, these pass through a gate of IC38 - HAL16L8 - and are the combined RXD from J5 and CTXD from J6.

For clarity, and because it is counter-intuitive, J5 is SER2 and J6 is SER1.

We know from experience and the existence of SuperHermes that the 8049 native code is crap for handling the incoming serial data, that it passes that serial data on the 8049/8302 serial link also used for keyboard and audio data, and that this link is capable of higher bandwidth than the 8049. We know this because when the 8049 default code is replaced with SuperHermes code, serial throughput is intelligible to approx. 50% higher speeds.

If the 8049 is replaced with a device capable of handling 1.5mbit incoming serial on two ports simultaneously with some buffering, it strikes me that (SUBJECT TO CONDITIONS) replacing the 8302 by another device, it could speed the inter-device communications (which is the bottleneck) and then it's just a matter of QDOSMSQ's ability to service the 8302 replacement's device at up to bus speed.

The SUBJECT TO CONDITIONS is that this device would not support microdrives because of strict timing, and also would likely not support QLNET. A device that would fit this function would likely support an internal or external calendar clock, so timing functionality could be maintained.

[Peter]

The SUBJECT TO CONDITIONS is that this device would not support microdrives because of strict timing, and also would likely not support QLNET.

The QLNET timings depend almost completely on the 68K CPU and its memory. The added delay by the 8302 register accesses should be neglegible.
As far as I can see, replacing the 8302 by a different device should not endanger correct QLNET timings.

[Dave]

That's certainly true. Unfortunately, replacing the 8302/8049 with a single thread microcontroller has much more complicated timing than the 8302. It will be much harder to recreate the accurate timings needed for QLNET. I'm willing to do the work - it's just a lower priority. It strikes me, generally speaking, the 8302 just sits there and waits for some external event to happen, then is clocked through the event by the event itself. With a microcontroller, it sits there in its own little loop, and occasionally is disturbed by an external interrupt.

My knowledge of QLNET is low because I have never personally had a use for it. Instead, I have been enjoying WiFi that is fast enough even my Q68 can't bottle-neck it. I hope after this to have very fast access to WiFi. But that's another matter.

[tofro]

My knowledge of QLNET is low because I have never personally had a use for it. Instead, I have been enjoying WiFi that is fast enough even my Q68 can't bottle-neck it. I hope after this to have very fast access to WiFi. But that's another matter.

Technically, QLNET, is very, very simple (and, for that matter, it would be a shame to not implement it in new machines.) QLNet is only a bit-banged 1-bit input, 1-bit output digital port (and some transistors behind it to drive/detect the actual line).

Tobias

[Nasta]

QL net is a very simple thing hardware-wise but very CPU intensive for what you get.
As far as I can tell, it's a regular serial protocol with some added special conditions on the line, all not too difficult to emulate using a regular UART set up for the proper bit rate. One could very well program a small uC to translate from some serial protocol to communicate on a more abstract level (like SPI) with a CPU, to QL NET. It's only aim is to send and receive packets (the latter only if addressed or a broadcast packet is received) and it does not need to bother the CPU until it's either received something intended for it or sent a packet and asks if another is to be sent.

[mk79]

One could very well program a small uC to translate from some serial protocol to communicate on a more abstract level (like SPI) with a CPU, to QL NET. It's only aim is to send and receive packets (the latter only if addressed or a broadcast packet is received) and it does not need to bother the CPU until it's either received something intended for it or sent a packet and asks if another is to be sent.

Martyn was working on this for USB viewtopic.php?t=1985

[martyn_hill]

Martyn was working on this for USB viewtopic.php?t=1985

I was wondering when someone would spot that

Whilst there is still significant work to do to complete the QLUB adapter project, the state of the uC coding does already validate Nasta's proposal as far as off-loading the QNET packet-handling to a slave device. The remaining work on the QLUB remains how best to interface the uC to QDOS/SMSQE at the software level and is the part for which I have detailed designs and a working wrapper (in SBasic), but is still causing me a real headache to productise in C/assembler

In principal, a fast (say, at least 500 kbps) Serial port connection between QL and micro-controller could stand in lieu of the USB connection design of the QLUB - the reason for the need for a higher-bandwidth than the QNET itself supports is simply to avoid adding such latency to the exchange of packets as to render the protocol too sluggish to be effective; we have already waited for QNET to bit-bang at its c90 kbps rate between nodes - i.e. we need to minimise the impact of what is effectively a 'store-and-forward' messaging design.

Whilst incomplete, I provide here one of the working versions of the uC code just as FYI. About 33% of the code is debugging with another 50% consumed with the 'messaging protocol' between uC and USB host - the core bit-banging is then child's-play in comparison.

It's arguably a distraction from Dave's main focus of this thread but the principal of how to interface between host QL and slave uC is a common requirement and one that I have been exploring a great deal in the QLUB project over time. The sensitivity to link speed and latency is one of the main reasons why I opted for a uC with 'native USB' such as the Teensy ++2. You'll note from the uC source that the comms activity down the QNET wire is effectively batch-interleaved between host comms via USB, so deterministic timing of each activity is necessary.

if it weren't for the poor bandwidth of the 8302 -> 8x49 comms-link, the principal of that link is little different from more modern TWI standards such as I2C or SPI and could remain a suitable candidate if supped-up in speed.

BTW - given recent experience re-working the QNET driver around Q68's hardware-timer, I can say that any 8302 replacement should have a high precision timer included - it would make any further QNET driver development soooo much easier...

Sorry to steal the thread for a moment - back to you, Dave...

[mk79]

The remaining work on the QLUB remains how best to interface the uC to QDOS/SMSQE at the software level and is the part for which I have detailed designs and a working wrapper (in SBasic), but is still causing me a real headache to productise in C/assembler

My latest TK2 releases can be split into Net-Hardware access and Device driver-Layer so that only the timing critical Send/Receive Packet routines have to be in the ROM. In theory it’s only a matter of providing the 5 hardware access vectors (send packet, send server packet, read packet, read server packet and read broadcast) to make the whole driver work.

Marcel

[martyn_hill]

Hi Marcel - yes - I borrowed from your physical 'abstraction' approach on TK2 for the new Q68 driver

The QLUB design (and anything else that must converse with a co-processor/uC) needs a bit more wrapping-around to support the off-loading of asynchronous and complete packet-handling. My approach for QLUB was more 'ambitious' than really needed than for a straight 8302 -> uC comms link, but some of the same principals would still apply that go beyond the very helpful physical abstraction that you have developed in TK2.

Just by way of an example - in order to offload the packet handling, we need a way to send the 'request' to the uC, then track it's eventual 'reply' - whilst at the same time, potentially processing other send/recieve requests - which might be handled by the uC out of sequence with the earlier requests (which would depend instead upon the sequence of QNET activity). For this, I devised a 'messaging' protocol to wrap around each request/reply 'pair' - tagging each request with a unique 'Message ID' to disambiguate the potentially out of sequence replies from the uC and routing back to teh Channel or Job who made the initial request (and since left waiting in the IOSS with a NC error return.)

Not sure if that helps...