Issue 8 and WiFi

Nagging hardware related question? Post here!
Dave
SandySuperQDave
Posts: 1447
Joined: Sat Jan 22, 2011 6:52 am
Location: Austin, TX
Contact:

Issue 8 and WiFi

Postby Dave » Wed Jul 19, 2017 11:17 pm

I started writing this as a reply to the WiFi thread, but it grew into something more and needs its own thread.

We've almost finished the design of the SSQB interface card, but got sidelined by working on the Issue 8, which is a rationalized QL motherboard. I have put an ESP-32S on it on the far right edge so the antenna is roughly where the 1377 used to be. Nasta believes this may cause some RF problems with the keyboard membrane. I say let's try it and measure the results to quantify the problem, if any.

The goal of the Issue 8 is to do a 'best version' of the QL with clean signals, and omitting the technologies we're leaving behind. Microdrives and UHF/composite video are gone. We have retained the QL net ports for now, because wifi/ethernet isn't actually working on this board yet, but once it is, they will likely go too. The board is heavily re-organized. I have placed the ESP board on the QL serial port 2, before the 1488/1489 using a simple TTL inverter/level shifter.
Screen Shot 2017-07-19 at 2.43.37 PM.png
The Issue 8 CPU card as it currently looks.

Bottom left to right 2x 512K SRAM, 64K EPROM, 8301 with 74HCT245 below, 2x 64kx4 DRAM, 8302. Above the SRAM is a 68008FN, above EPROM is a GAL20V8. Above the membrane connectors, sideways, is the 8049. The ESP-32S hangs off the right side of the board, so the antenna is out from under the metal keyboard plate.

Currently, all IO goes to that 2x20 connector at the back, which then goes to a 2-layer IO board which runs the entire IO length at the back of the QL. This saves around £15-20 per board. The IO board is long and thin, and costs little to make. The 4-layer CPU board is rectangular and optimal for manufacturing. If we didn't do it that way, production on the PCB would be around 3x the cost. The main idea behind this is that as we make improvements, you could replace the IO board or the CPU board. The IO board as currently planned: QL net x2, 9v barrel connector, RGB, 10/100 ethernet port, Ser1 d-sub, CTRL1 & 2 d-subs (German QL layout).

We've been held back for a long time by the QL's custom ICs. They suck.

The above all matters as it gives a context to our other decisions. For example, when we design a standalone ESP-32 wifi card, do we do it around existing serial (too slow!) around a common fast UART, or around the SuperIO UART we plan to use in future versions of the QL to replace... well.... almost everything. We have a couple of decisions to make there. I own a huge pile of SuperIO chips, the PC87307. They contain, conveniently: 2x 16550 UART (1.5mbaud) 1x parallel, 1x 8477 floppy controller as used on SGC, kbd/mouse controller, battery backed real time clock, power management, 16 GPIOs all in a handy dandy 160 pin QFP package!

I received an email last weekend complaining that we're being slow and wasting people's time. I'm sorry. What we're doing is complex, and the decisions we make will have a lasting impact. Also, it took 18 months for a team of 20+ people with massive resources to develop the QL. We're three people with few resources using very rusty memories and £50! We pretty much have one chance to do each step, no mis-steps, and we need to be well supported by purchases along the way because making things is expensive and we have to spend the money up front and then hope it sells. Emails like that disproportionately demoralize and demotivate me. They're far worse than sending requests for specific and limited help to people who are experts in a subject area and getting a no, or no reply at all.

Here's things we could use help with, if people want to pick up a nice little project for when the summer nights shorten and the air starts getting crisp:

  • Configuring the 87307 SuperIO within the 64K from $10000-$1FFFF so each device appears at a rational address, is configured/configurable correctly eg: as to baud rate
  • Using the ESP-32S or 87307 GPIOs to operate a keyboard membrane
  • Using the ESP-32S bluetooth to operate a bluetooth keyboard and/or mouse
That's our top three hit list. Who's up for a project?

Your dev team: Nasta, Lau and me.


thorsinclair
Trump Card
Posts: 161
Joined: Mon Jan 10, 2011 5:08 pm

Re: Issue 8 and WiFi

Postby thorsinclair » Thu Jul 20, 2017 2:53 pm

Don't get demoralized by individuals, there is people out there appreciating the risks you are taking and expecting to get their hands on your products. Having involved such an experienced QL hardware developer as Nasta is super! Just continue what you are doing and keep us in the loop! Thanks and fingers crossed!


martyn_hill
Trump Card
Posts: 183
Joined: Sat Oct 25, 2014 9:53 am

Re: Issue 8 and WiFi

Postby martyn_hill » Fri Jul 21, 2017 12:30 pm

This is great stuff, Dave, Lau and Nasta! Pay no heed to any whining :-)

Once my QLAN to USB Bridge device project is completed to a reasonable degree, I would be happy to pick up any remaining of those three current to-do's...

(I will miss the MDVs, though - pure sentimentality, I know, plus a little awe for how they ever even worked at all!)

M.


Dave
SandySuperQDave
Posts: 1447
Joined: Sat Jan 22, 2011 6:52 am
Location: Austin, TX
Contact:

Re: Issue 8 and WiFi

Postby Dave » Fri Jul 21, 2017 4:59 pm

I don't know. I can honestly say I have no fondness for microdrives. I was actually physically bullied over them as a teenager. The other kids were playing with their shiny new 3.5" drives in 1985 when I got my first QL from Dixon's. I think it's fair to say I equate microdrives with asbestos, thalidomide and trickle down economics.


Dave
SandySuperQDave
Posts: 1447
Joined: Sat Jan 22, 2011 6:52 am
Location: Austin, TX
Contact:

Re: Issue 8 and WiFi

Postby Dave » Fri Jul 21, 2017 5:10 pm

Has anyone ever implemented a 16550 UART and software to use it on a QL before? The two designs I saw previously for external serials used a 6402 and a 68328. If code to use the 16550 register set/layout exists already, can someone point it out to me?


Dave
SandySuperQDave
Posts: 1447
Joined: Sat Jan 22, 2011 6:52 am
Location: Austin, TX
Contact:

Re: Issue 8 and WiFi

Postby Dave » Fri Jul 21, 2017 7:37 pm

I did find a 68681 that fits nicely on a Motorola bus and has a moderately rational design, but 3 byte FIFO, are you kidding me? How do you put an external FIFO on that thing?


Silvester
Trump Card
Posts: 171
Joined: Thu Dec 12, 2013 10:14 am
Location: UK

Re: Issue 8 and WiFi

Postby Silvester » Sat Jul 22, 2017 11:27 am

Dave wrote:Has anyone ever implemented a 16550 UART and software to use it on a QL before? The two designs I saw previously for external serials used a 6402 and a 68328. If code to use the 16550 register set/layout exists already, can someone point it out to me?

I put a dual serial port ISA card (2x 16550) into Q40 (alongside original multiIO card) and it worked fine, so Q40 SMSQ sources must contain driver code for 16550 chip alone. In fact Q40 SMSQ docs state baud OK to 921600 if device supports it (my 16550's only upto 115200).

If your using 68008FN and EPROM for OS why bother with external FIFO. You could put UART off level 4 interrupt* and get simple ISR to fill QDOS queue. I used 68008FN on TC QL with 2x 6850 UARTs for two MIDI ports and it never missed a byte with mass simultaneous MIDI dumps. Minerva also allows large queues.

(* you need something like 74148 encoder for IPL inputs).


Dave
SandySuperQDave
Posts: 1447
Joined: Sat Jan 22, 2011 6:52 am
Location: Austin, TX
Contact:

Re: Issue 8 and WiFi

Postby Dave » Sat Jul 22, 2017 6:50 pm

What IC is on the multiIO card on that?


Nasta
Trump Card
Posts: 184
Joined: Sun Feb 12, 2012 2:02 am
Location: Zapresic, Croatia

Re: Issue 8 and WiFi

Postby Nasta » Sat Jul 22, 2017 11:40 pm

How about let's compare apples to apples...

The Q40 has a CPU that is almost two orders of magnitude faster than the original 68008, and, more importantly, large caches. This makes interrupt response quite fast. This fact was used on Q40 to drive various devices, originally sound, where interrupts occurred at 10KHz or 20kHz rates.
Having a polling interrupt at this sort of speed opens up quite a lot of possibility. Let's do a bit of math:
If your UART receiver is polled for a new received byte at 10kHz, assuming one byte transfer has a minimum of 10 bits (common start bit, 8 data bits, one stop bit setting), and polling must be faster or equal to the number of bytes received, we are looking at ~10lHz x 10 bits = 100k baud data rate. And that's not taking into account double buffering (the UART can receive a new byte while the previous is being held in the receive holding register, or any kind of FIFO. If we assume a 16 byte FIFO, then we have to satisfy that the FIFO must not ever overfill between two polls, and that essentially increases the maximum data rate by a factor of 16, so now it's 1.6Mbaud.
Increasing the poll frequency to 20kHz of course doubles the maximum data rate, and that's already more than the actual UART can handle.

THis kind of performance is possible on the 68008 but then the machine would scarcely be capable of much else while sustaining the data rate based solely on polling, 115200 would be about the maximum. With a 16 byte receive FIFO, 1Mbaud should be attainable but the rest of the machine will lag.

Regarding interrupts, as far as I know, all interrupts on the QL are level 2, so level 5 is still available and this is where a fast poll interrupt can be mapped.

A long time ago I had a nice talk with Tony Tebby about some real time OS matters, and he very convincingly made a case for using a polling chain rather than multiple level interrupts. Consider two or more devices that can be polled using a fast polled interrupt: the interrupt altency happens only once for a full chain scan, and devices can become synchronized so that there is very little additional overhead for handling multiple data streams. In the UART case above, one could program the FIFO to cause an interrupt when it's half full, but then youcan get as many interrupt entry overheads as there are devices - as it is completely unpredictable when the next interrupt is going to happen. In a polled chain, polling may find that one FIFO is nearly full, while the FIFOs on the other devices are much less full but still transfer all the data (however much there is in each device) without having to return from the interrupt handler only to be interrupted again. With a fast poll list, some added sophistication is possible, that can prevent parts of the list where slow devices are polled to be scanned on every fast poll, knowing in advance that these devices will not need servicing this time around (but, say, every other time, or every 4th time or every 8th time).

It should be noted that the UART in question is the epitome of how NOT to design an UART, and the FIFOs are largely senseless and made as an attempt to patch up a design which was completely flawed from the start. Instead they could have just implemented proper HARDWARE handshaking which is about 10 logic gates compared to hundreds for a FIFO. Really it's not that unexpected it would find it's use in a PC :/
Especially stupid is the use of a transmit FIFO which has NO interaction with the transmitter is completely useless - one still needs to handle the handshake byte by byte in software, and the FIFO actually just makes it more complicated!
Also, using the 16550 in FIFO mode requires dynamic setting of interrupt enables and flags depending on the state of the FIFO, which gets really complicated. In principle you can get away with receive idle timeout interrupts and FIFO threshold interrupts.



Return to “Hardware”

Who is online

Users browsing this forum: No registered users and 3 guests