QLUB Adapter - Initial Release...

[Peter]

There is and I've added a topic on the Off Topic section to explain the differences. It's at
viewtopic.php?f=9&t=3643 if anyone is interessted.

Thanks Norman! My question even had an almost on-topic backround. I was starting to have a look if Martyn's code could be ported to 68K.
My idea would be to cut down the Qzero to a 68K microcontroller with e.g. 64KB FLash, 48KB RAM and USB-serial device support.
Which I would open-source and provide as an alternative hardware, so development could be in the 68K realm.
Bringing it closer to the QL world and closer to what is of personal interest for me.
I have to admit I'd hardly find the time, but bringing microcontroller development back to 68K has some fascination for me.

[Peter]

I've moved the circuit from the breadboard to a permanent circuit and box:

Fantastic! Except the color

[NormanDunbar]

Hi Peter.

Time, is always in short supply.

Cheers,
Norm.

[Maskenlos]

Hi Martyn, all

I build up my QLUB by today and found the following issue:

1. Receiving files from QL works as long as the files are small. E.g. 2 line basic program. Longer Basic programs will be transmitted partly and then the transmission aborts.

2. Sending files to the QL totally do not work.

My setup:

On PC side: Windows 10 with QPC5 (tested also QPC4)

QL side: Minerva ROM, ABC K/B IF, GoldCard

Just found out: I got it running with uQLx (under Ubuntu) as well, basically same behavior but it receives longer files.

Any help, hint, advise is highly appreciated.

Thanks,

Stephan

[martyn_hill]

Fabulous!

Thanks Stephan.

So, a couple of questions and, if you are free tonight or tomorrow, why don;t he have another Zoom call to walk through some ideas?

1. What version of Minerva?
2. What version of TKv2 (embedded in your Gold Card)?
3. What Issue QL motherboard?
4. Have you tried sending the 'Blue_scr' display file, yet? If not, have a go and attach a screen-capture of whatever appears on the QL display (if anything at all...)

I'll email you with a Zoom URL to join when you're free...

M.

[M68008]

When you get time, would you be willing to share the overall dimensions/measurements of the apertures, etc? Did you purchase a ready-made project-box, or 3D-print one yourself?

It's a 3d printed box I designed. Here are the STL files:

QLUB_Box.zip

(3.73 MiB) Downloaded 93 times

It's a bit of a tight squeeze, and may or may not work with components different from the ones I used (except for the Teensy board, which has standard dimensions). The LED I used is 3x2 mm.

This is how the box looks when empty, and what I put inside it (Teensy++ 2.0 board, 2 audio jacks, small perfboard, LED connected to D6):

[martyn_hill]

OMG Daniele!

I'm sooo impressed (and increasingly embarrassed by my own casing effort!)

I must admit to being just a little proud to see the project that I've worked-on for so long actually working for others (smug grin!)

M.

[Peter]

Whilst on this (off-) topic and just as a little teaser - an updated version of the ND-Q68 driver that I am still testing can push over 700 kbps (that's bits per second, not bytes) between a pair of Q68s...

That's amazing. Roughly guessing about 60KB/s actual file transfer throughput, that's already a quarter of the ethernet throughput I see with TFTP at the moment.

I've been playing with the idea of replacing the physical layer for QL network to reliably get higher speeds and longer distances. I think CAN Bus transceivers would be quite ideal for that speed range, and would make the QLUB adapter even easier to solder. The downside is, that a QL/Q68 side adapter would also be needed, and I couldn't figure out a satisfying solution yet.

[martyn_hill]

Hi Peter!

That's amazing. Roughly guessing about 60KB/s actual file transfer throughput, that's already a quarter of the ethernet throughput I see with TFTP at the moment.

In practice, due to the mandatory inter-packet GAPS and other artifacts within the QLAN protocol, it measures about 32KB per sec - a display-file's worth. The bit-timing is 8x standard.

I'm confident I can squeeze a bit more out of it, but not until I can track down the culprit for the occasional lock-ups I observe at these higher bit-rates.

I have an almost complete design for a backwards-compatible enhancement to the Sinclair protocol, that would allow for dynamic/negotiated bit-timings and other capabilities between machines that can support them in a way that is invisible/transparent to any legacy machines also listening, whilst automatically reverting to the std timing and protocol as needed.

It wouldn't be as fast as the highest bit rate any given machine could support as, to be truly backwards-compatible, the packet transmission and timings must at least commence in the std fashion, only 'stepping-up' if a suitable response is received following the packet-header.

Anyways, something I'll pick up again in the future...

I've been playing with the idea of replacing the physical layer for QL network to reliably get higher speeds and longer distances. I think CAN Bus transceivers would be quite ideal for that speed range, and would make the QLUB adapter even easier to solder.

Yes, I researched various bus-transceivers as a replacement for the std hardware as a side project. Even devices considered obsolete these days could support a substantial upgrade to what we have today. And all without messing about with Ethernet...

The downside is, that a QL/Q68 side adapter would also be needed, and I couldn't figure out a satisfying solution yet.

Yes, any innovation in this area quickly returns to the important question - how would an typical QL user benefit from this?

[Peter]

Hi Martyn,

I have an almost complete design for a backwards-compatible enhancement to the Sinclair protocol, that would allow for dynamic/negotiated bit-timings and other capabilities between machines that can support them in a way that is invisible/transparent to any legacy machines also listening, whilst automatically reverting to the std timing and protocol as needed.

Amazing. Would be interesting which speed original machines could achieve with a perfect physical layer and rewritten code.

I've been playing with the idea of replacing the physical layer for QL network to reliably get higher speeds and longer distances. I think CAN Bus transceivers would be quite ideal for that speed range, and would make the QLUB adapter even easier to solder.

Yes, I researched various bus-transceivers as a replacement for the std hardware as a side project. Even devices considered obsolete these days could support a substantial upgrade to what we have today. And all without messing about with Ethernet...

A problem is that RX/TX normally need to be separate on the local side of the transceiver, and a power supply is required. While that's very easy for a tinkerer willing to do minimal soldering inside the QL, it's not a general solution.

The downside is, that a QL/Q68 side adapter would also be needed, and I couldn't figure out a satisfying solution yet.

Yes, any innovation in this area quickly returns to the important question - how would an typical QL user benefit from this?

My approach (without soldering inside the QL) was using the extra pins on a QL-SD (slightly modified logic) to attach a CAN transceiver, then patching the network code to use the corresponding addresses. But even if a QL-SD with builtin transceiver was for sale, that would still not cover 128 KB QLs, which you nicely include with your current solution.