The Sinclair QL Forum

Hi Marcel,

I was looking at pictures of your QLUB interface board, what is the purpose of connector J3, which looks to something to do with the QL Net Connectors.

I assume that Header J4 is for extra interfacing to the Teensy

The pins under the Teensy, which corrspond to Teensy pins PA0-PA7, ALE have no connection?

I was going to do a PCB that was on top of the Teensy and the QL Net Connectors in the same footprint as the Teensy, reducing the size of case.

It seems that getting a nicely printed 3D printed case is really expensive, so maybe a cheaper solution is to use an existing ABS Plastic case for around a UK Pound.

Derek_Stewart wrote:I was looking at pictures of your QLUB interface board, what is the purpose of connector J3, which looks to something to do with the QL Net Connectors.

It's the same as the network connectors, just as a header in case somebody wants to connect it differently.

I assume that Header J4 is for extra interfacing to the Teensy

Yeah, traces are free, so I just include some even if not needed.

The pins under the Teensy, which corrspond to Teensy pins PA0-PA7, ALE have no connection?

No need.

It seems that getting a nicely printed 3D printed case is really expensive, so maybe a cheaper solution is to use an existing ABS Plastic case for around a UK Pound.

Depends, a 3D printed case costs me basically nothing But hat's why J3 is there, so if the case doesn't fit one can connect the network sockets differently.

Hi Marcel

The PCB is very well done and I like the module approach to the OpenScad file to produce the STL files

I.have a Davinci Jr 3D Printer, never used it. I was hoping to get a SLSmprinter, but do not really have the space operate a printer, no real workshop..Just a bedroom, which the wife to use it as bedroom!

I have got some PCBs from Chr$, so will see what I can produce.

I'm highly impressed with the various cases, boards etc around this, so I thought by way of contrast I would post a pic of my highly professional effort here:
Note the use of a junction box from some old ceiling lights to project quality. Also permanent marker

Just in case it's useful info, following on from testing with BLUE_scr, which was pretty much fine, I tried sending some more detailed graphic files (lots of Floyd-Steinberg dithering) and discovered that they worked a lot better with ndt_send set to 00B8h. Otherwise there was usually corruption. Again this is to an AH Issue 5.

Very nice, Gbejniet!

That difference in the ndt_send Timing Constant you needed to talk with your AH QL equates to a quarter of a microsecond (11.25us -> 11.5us) in a nominal 11.2us bit-frame.

When I analysed and compared the NET Recv routines across the various QDOS ROMs some time ago, I did spot that AH uses a longer delay between sampling successive bits (ndt_rbit). This would explain the need to extend ndt_send at the QLUB to better match the AH receiver.

All subsequent QDOS ROM versions settled on a shorter (and consistent) value for ndt_rbit.

For what its worth, that particular delay is introduced by a ROR instruction which takes longer to perform the rotate depending upon how many bit-positions are specified. In AH the number of bit-positions to rotate was specified at 26, whereas in all later ROMs is was 19. Each additional bit-position takes ROR an extra x2 CPU 'states' (each, half a CPU-CLK), adding just under 1 us per bit between AH and the rest.

Not enough to upset the first few bit-samples, but by the time you sample 8-bits, you effectively accrue around 6.5 us of additional delay in the byte-frame, sufficient to screw-up the sampling of the last (MSB) bit if you were also unlucky enough to be delayed in detecting the START bit, which happens periodically...

My (optimistic) speculation is that Sinclair made the AH NET routines align with the ZX Interface-1 timing which used a slightly longer bit-frame (11.4us), but just as likely it was a bug

Happy Networking...

Hi Martyn,

hope you are doing well?
I really hesitate but good not resist to ask. Any News about the F-Server?

Best regards and happy Weekend,

Stephan

Hi again Stephan!

There's never any harm in asking

I've made a lot of progress over the last few weeks - I'll spare you the details as its all quite mechanical stuff - and have overcome a number of issues in the original design.

As for when the next release will become available - sometime over the Summer, at a guess...

I'll post back here when I've got something more exciting to share

Just ordered a Teensy++ 2.0, they look as if the are getting rare now, the one I got was last from vendor, PJRC.com is now out of stock for good? (https://www.pjrc.com/store/teensypp.html), Nice to see the AT90USB1286 is still plentiful though, I don't suppose it would be difficult to make a QL specific board?

Edit: perhaps replace 'difficult' with 'impossible'

Silvester wrote:Just ordered a Teensy++ 2.0, they look as if the are getting rare now, the one I got was last from vendor, PJRC.com is now out of stock for good? (https://www.pjrc.com/store/teensypp.html), Nice to see the AT90USB1286 is still plentiful though, I don't suppose it would be difficult to make a QL specific board?

Edit: perhaps replace 'difficult' with 'impossible'

Hi,

I think you could correct, with difficult, but, Marcel created a PCB to connect the Teensy++ 2.0 PCB, with all the QL NET connections. Maybe it is just a matter of replacing the Teensy++ 2.0 part in the Kicad Schamtic with the Teensy++2.0 schamtic file: and alter the PCB file to include the Teensy++2.0 schematic details. Probably a CAD problem rather than a construction problem.

Is this worth doing?

Can other Tneesy++ 3 or 4 units be used?

Hi Silvester and Derek!

You are right of course - the Teensy++2 is getting next to impossible to source (I bought a few previously), but once I have finished the work on the native drivers for QDOS/SMSQE, I will start work on adapting the uC firmware for the later and more readily available 32-bit Teensies (v3.5, 3.6 and later).

As it stands, v2.2a and later of the firmware are already 'decoupled' from the uC clock-speed, so only a little more work is needed there to make them fit for the later devices.

The core reason for using the Teensies is that they are based on a uC with embedded USB support which massively improves the overall throughput to the host - necessary when you consider that the QLUB is operating in a 'store and forward' capacity and any additional latency in transferring each NET packet to/from the host (running an emulator) effectively slugs the overall performance below that of a native QL to QL setup - already pretty slow!

More to follow...