QLUB Adapter - Initial Release...

Nagging hardware related question? Post here!
martyn_hill
Aurora
Posts: 909
Joined: Sat Oct 25, 2014 9:53 am

Re: QLUB Adapter - Initial Release...

Post by martyn_hill »

Peter wrote:Amazing. Would be interesting which speed original machines could achieve with a perfect physical layer and rewritten code.
My early assessment was that a basic QL could just about reach 1.5x the current bit-rate, which didn't seem worth the effort...

Any further improvement would require new hardware, whilst keeping to the Sinclair protocol - basically to relegate the bit-banging to a third-party device and with a suitable - simple enough - adjustment to the physical-layer driver to read/write 8-bit bytes - effectively a custom UART solution, by which time, we might as well define a completely modern hardware interface.

I did also explore how the MDV extension port could be used - its not trivial but given that it's already byte-parallel and running at dual-100 kbps AND synchronous (8bits => 8bits, unlike the async NET port where 8bits => 14bits), would be a big step-up... Being differential Manchester-encoded by the humble ZX8302 also makes it ready for wireless (zero DC offset) and fit for longer cable runs...

All these ideas float about my head, when I'm not doing anything actually useful. :-)


Derek_Stewart
Font of All Knowledge
Posts: 3932
Joined: Mon Dec 20, 2010 11:40 am
Location: Sunny Runcorn, Cheshire, UK

Re: QLUB Adapter - Initial Release...

Post by Derek_Stewart »

Hi,

I have looked into having Daniel's case printed by a 3D Print Company.

I have estimates for £3 per case with the logo lid, in Black PLA.

If anyone is interested, I could build the adapter into the above case.


Regards,

Derek
Maskenlos
Over Heated PSU
Posts: 138
Joined: Sat Nov 03, 2018 12:14 pm

Re: QLUB Adapter - Initial Release...

Post by Maskenlos »

Due to the great support from Martyn we made some progress.
Finally we figured out that bi-directional transfer is possible without GC. Plugin in the GC will lead to non-transfer from QPC to QL.
Does anyone else who tried out the QLUB has observed similar behavior? In my case, GC 3 Eprom 2.32?


Stephan


User avatar
mk79
QL Wafer Drive
Posts: 1349
Joined: Sun Feb 02, 2014 10:54 am
Location: Esslingen/Germany
Contact:

Re: QLUB Adapter - Initial Release...

Post by mk79 »

Derek_Stewart wrote:I have looked into having Daniel's case printed by a 3D Print Company.

I have estimates for £3 per case with the logo lid, in Black PLA.
Wow, that's pretty good. How many do you need to order to get that price?


Derek_Stewart
Font of All Knowledge
Posts: 3932
Joined: Mon Dec 20, 2010 11:40 am
Location: Sunny Runcorn, Cheshire, UK

Re: QLUB Adapter - Initial Release...

Post by Derek_Stewart »

mk79 wrote:
Derek_Stewart wrote:I have looked into having Daniel's case printed by a 3D Print Company.

I have estimates for £3 per case with the logo lid, in Black PLA.
Wow, that's pretty good. How many do you need to order to get that price?
HI,

That was for a batch order of 5.

Since I do not know what the quality and surface finish is like and how many required, so a small batch.


Regards,

Derek
afx
Trump Card
Posts: 171
Joined: Tue Dec 28, 2010 10:23 pm

Re: QLUB Adapter - Initial Release...

Post by afx »

Derek_Stewart wrote:Hi,

I have looked into having Daniel's case printed by a 3D Print Company.

I have estimates for £3 per case with the logo lid, in Black PLA.

If anyone is interested, I could build the adapter into the above case.
Hi Dereck, does your offer include the complete kit (box, teensy, and soldered components)?

If so I am interested (I don't have the skills to solder the components :( ... ).

Greetings.


Derek_Stewart
Font of All Knowledge
Posts: 3932
Joined: Mon Dec 20, 2010 11:40 am
Location: Sunny Runcorn, Cheshire, UK

Re: QLUB Adapter - Initial Release...

Post by Derek_Stewart »

afx wrote:
Derek_Stewart wrote:Hi,

I have looked into having Daniel's case printed by a 3D Print Company.

I have estimates for £3 per case with the logo lid, in Black PLA.

If anyone is interested, I could build the adapter into the above case.
Hi Dereck, does your offer include the complete kit (box, teensy, and soldered components)?

If so I am interested (I don't have the skills to solder the components :( ... ).

Greetings.
Hi,

This is only the case, there is the cost of the Tweensy and other components.

I think the QLNetwork wiring can be made in line with the wiring to the QL Net Connectors, and shrink wrapped for insulation. So removing the need for a PCB.

I will make one up to see if the Transistor can be included in a shrink wrapped wired system.


Regards,

Derek
martyn_hill
Aurora
Posts: 909
Joined: Sat Oct 25, 2014 9:53 am

Re: QLUB Adapter - Initial Release...

Post by martyn_hill »

Hi again Stephan!
Maskenlos wrote:...we made some progress. Finally we figured out that bi-directional transfer is possible without GC. Plugin in the GC will lead to non-transfer from QPC to QL.
Thanks for your time and patience yesterday - it was quite productive!

Just to summarise for any others about to build and try the QLUB adapter - and especially any GC owners - Stephan found that, whilst he could receive files successfully from his GC equipped Minerva-based QL, he could not receive from the QLUB Adapter/Emulator.

This will be due to the Timing Constants used in the GC TK2 Net driver and prompted me to re-review the GC Patching (thanks Marcel!) to the original NET driver and along the way re-discovered a useful SBASIC routine bundled with the GC source called 'nettime_bas' which gives a convenient mechanism to adjust the three key Timing Constants interactively.

For Stephan and anyone else who hits a similar issue with GC, SGC or QXL based systems, adjusting the TCs in this way should provide an easier way to resolve residual NET timing issues between their QL systems, including the QLUB.

For convenience, I've taken nettime_bas from the source distribution, added a few comments and provide it here:

[EDIT - corrected nettime_bas uploaded.]
nettime_bas.zip
(1.16 KiB) Downloaded 96 times
Last edited by martyn_hill on Sun Jan 31, 2021 6:20 pm, edited 1 time in total.


martyn_hill
Aurora
Posts: 909
Joined: Sat Oct 25, 2014 9:53 am

Re: QLUB Adapter - Initial Release...

Post by martyn_hill »

Hi again everyone

I thought it might be helpful to write a short description for anyone wishing to gain a better understanding about the role of the all-important 'Timing Constants' around which the QLAN NET driver is designed. I plan a more full description in the second article in the 'Networking the QL' series (haven't read Part 1 yet? See earlier in this thread.)

All-in, there are 16 such Timing Constants (TCs) used in different situations or during the various phases of sending or receiving a packet in the Sinclair Network Standard protocol. In the earlier NET driver versions included in QDOS and Minerva, these timing constants are effectively hard-coded in to the software timing-loops that are used to introduce the required time-delays.

The NET TCs are word-sized values used (mostly) as a count to a DBRA loop to 'waste' CPU cycles at suitable points in the code and, it should be noted, not directly linear in terms of the effective time delay they introduce due to the fact that the loops they appear-in vary according to what else is being executed within the loop itself. Thus the absolute value of each TC does not necessarily relate to the value of any other but, as you would expect, the larger the TC value, the longer the introduced delay.

In later versions of TK2 (perhaps it was always thus?) - which include a complete rewrite of the NET driver - these TCs are helpfully exposed and stored within an extended driver 'Physical' Definition Block within RAM and can be usefully reviewed and manipulated there should the need arise. The 'nettime_bas' program from the SGC ROM source does precisely this by first identifying the address of the (active) definition block for the NET driver and then extracting/modifying the relevant word-sized values at known offsets.

In some versions of the TK2 NET driver, some of the crude DBRA timing-loops are replaced with clever use of m68k instructions that can be made to take longer or shorter amounts of time programatically - e.g. ROR and similar with different values in the Data register that specify how many bit positions to rotate the operand. Use of such techniques typically allows more fine-grained control, at the loss of overall resolution - i.e. only useful for very small delays.

NB. The redesign of the NET driver in TK2 means that the actual TC values used are very different than those hard-coded values in the original QDOS driver, but they achieve the same thing.

[Aside: Given the availability of a high-precision hardware Counter/Timer in the Q68, it was possible to re-design the NET driver for the Q68 (ND-Q68) around the HW Timer and dispense with the nasty software timing-loops altogether... None the less, TCs are used in ND-Q68 in precisely the same way as native QL hardware/drivers, but here instead the TCs are direct reflections of the time delay they introduce (and are long, instead of word sized...)]

Fortunately, of the 16 TCs, only three are especially critical and typically it is only one or more of these that may need adjustment to get two otherwise recalcitrant NET stations to communicate (more) reliably. I'll just discuss these three TCs here, but bear in mind that all 16 TCs play important roles within the Sinclair protocol definition, especially in relation to 'timeouts.'

A quick revision of the format of the serial data down the wire may help here; within both the NET Header and the Packet/block that follows it, each 8-bit byte occupies a 14(ish) bit 'frame' composed of a couple of active LEAD-bits, one inactive START bit, 8x DATA bits followed by a one or more active STOP bits. The 13 & 14'th bits are really just the time it takes to loop round again, whilst the NET output remains active. The Sinclair standard defines the bit-time at 11.2 microseconds each.

As will be familiar to any UART programmers out there, the most important aspect in receiving asynchronous serial data is in the detection of the (falling) edge of the START bit. For this, we are entirely reliant on the CPU cycle-time and the design of the driver code to detect the START bit as rapidly as possible - we don't have any hardware to do this for us.

Once detected (which may be a few microseconds after it actually occurs), we can now start 'counting time' and here comes in the first of the three critical TCs:

1. "ndt_rdly" (Read DeLaY) times the delay between detection of START and the mid-way point in to the first DATA bit - Bit-0 as it happens (LSBit first...). This may be 1.5x the usual bit-time, or else a 1/2 bit time to be followed immediately by a full bit-time, depending upon driver 'vintage' - the effect is the same. We thus 'skip' over the START bit altogether once detected.

2."ndt_rbit" (Read BIT) is the second important TC and is used to time the delay between each subsequent Bit - 2 through 7 (and in later versions of Minerva, which go-on to check the presence of the first STOP bit.)

On the sending side, only one TC is defined and used across the whole byte-frame:
3. "ndt_send" defines the timing for each bit - including the START, DATA and STOP bits, which are effectively combined in to a 12-14 bit word. Whilst its effect on the delay between bits equals that of ndt_rbit, ndt_send may or may not equal the same, absolute value as ndt_rbit - again, depends on the design of the various driver versions.

Enough theory...

In practice (or 'In my experience'), once you have two stations almost talking to each other, it is only "ndt_rdly" that needs further refinement to get reliable comms.

Finally, don't forget that, given the 'handshaking' used in the protocol, to send successfully, not only your send-timings but your read-timings must also be aligned with the peer-station - and vice-versa.
Last edited by martyn_hill on Sun Jan 31, 2021 6:42 pm, edited 1 time in total.


martyn_hill
Aurora
Posts: 909
Joined: Sat Oct 25, 2014 9:53 am

Re: QLUB Adapter - Initial Release...

Post by martyn_hill »

Oops...

In my earlier post where I attached the 'nettime_bas' program from the SGC ROM source distribution, turns out that QPC/SBASIC objects to the use of 'loc' as a variable name - clashing with LOCal keyword, I guess.

I've updated that post with a revised version ('loc' changed to 'location'). Thanks to Stephan for pointing it out.


Post Reply