The Sinclair QL Forum

Chr$ wrote:I agree, silly little screens etc, but I was thinking of simply an app 'terminal' to send files to/from a QL [...]

For an original QL, access without emulator would require writing a specific Android program to support Martyn's adapter.
(For the Q68, I have already been using the standard TFTP protocol for transfer directly between a PC and the QL side filesystem. By both a JAVA GUI, and a commandline TFTP client, for which Android has similar solutions. Even over internet, by the way. But that's ethernet and off-topic here.)

I've nothing constructive to add here, except that I'm massively excited by this and will definitely be having a crack at building one this year. Serious props are due.

I don't know what has been thought through before now (I am new to the area, only bought a QL about a month ago) but I can't stop thinking about overlaying protocols on top and finding out what would and wouldn't work in practice.

martyn_hill wrote:Hi everyone!
<>

Great piece of work that, Martyn! I never had any real problems with my microdrives in the early days, but then I never really succeeded in getting QNET to work reliably. You seem to have nailed it!

As it stands, however, Im not sure Id be comfortable using this kind of network outside my home environment, eg over the Internet. There doesnt appear to be any security. Anyone with access to the network could wreak havoc on any other member if they wished. Any plans to address this before we get into networked gaming and things?

Hi Martyn,

thanks a lot for releasing the QLUB information. As I am waiting quite a while for it, I am happy to build one within this winter.

Happy new year to everybody and stay healthy.

Cheers,

Stephan

Hi Peter

Peter wrote:If Wolfgang has no better idea, and you don't find that approach too clumsy anyway, I could also have quick look into writing such a server at least for Linux and Windoze. Would it be better to define a packet format, or just go byte-by-byte?

I reckon a byte for byte approach would be preferable - the 'message protocol' I devised to wrap around the QLAN blocks is already packetised, and contains all the meta-data needed to synchronise/serialise the byte-stream.

I did a bit of research in to Java SERial handling libraries and can now appreciate why SMSQmulator doesn't currently support it! Seems such a simple capability to be missing from main-stream Java...

Hi Per!

pjw wrote:As it stands, however, Im not sure Id be comfortable using this kind of network outside my home environment, eg over the Internet.

Agreed - there is zero security in the Sinclair Network Standard itself, so any solution for routing over a public WAN would involve encapsulation in UDP (preferably) and streaming over a VPN-like tunnel.

The real issue here is that of the routing and addressing the remote network. Use of solutions like OpenVPN to handle the tunneling thereafter make the security side pretty trivial...

Martin Head's terrific work and experience on both his IP Network as well as the new (Q68) Ethernet drivers will come in handy here in due course - once I've completed the OS integration, encapsulation and routing over IP/UDP is a little further down my to-do list

Hi Chris!

Chr$ wrote:how about QL_USB? It may be clearer as to what it does).

Thanks, I considered a number of names for the project and the clash with that old publication title did come to mind, but embodying the concepts of 'QLAN', 'USB' and 'Bridging' together in the acronym just came together as QL, U and B, so it stuck...

Hi Stephen

Maskenlos wrote:thanks a lot for releasing the QLUB information. As I am waiting quite a while for it, I am happy to build one within this winter.

You are very welcome - it has indeed been a long time getting to even this early-release stage... Looking forward to hearing how you get on!

Hi GBejniet!

gbejniet wrote:I've nothing constructive to add here, except that I'm massively excited by this and will definitely be having a crack at building one this year.

It's helpful to me simply to hear that the project is of interest to you!

Meanwhile, I'm very happy to read the conversations sparked by this project

Well they say a journey begins with the first step - so I have downloaded the files - thanks for sharing I will begin to gather the needed bits into a the queue of boxes of projects I have, this may however jump that Queue...

Maybe a minimum build IF1 using the https://www.tindie.com/products/Charlie ... placement/ might be a way to use your improved Shadow ROM in an EPROM for the Spectrum End with less difficulty, it might even fit on my ZX Breakout Breadboard I have - I would definitely be interested in the needed patches for that at some point.

Hi Tim!

Timbucus wrote:Well they say a journey begins with the first step - so I have downloaded the files - thanks for sharing I will begin to gather the needed bits into a the queue of boxes of projects I have, this may however jump that Queue...

Good luck! Whilst the instructions may look daunting at first, in part that is due to trying to be sufficiently thorough in the documentation, rather than being inherently complex to assemble/program the device. I welcome feedback on the documentation - I did consciously leave some steps a bit vague just in the interests of getting something 'out there' before the end of the year - but otherwise fully intend to develop the documentation based on feedback.

Timbucus wrote:Maybe a minimum build IF1 using the https://www.tindie.com/products/Charlie ... placement/ might be a way to use your improved Shadow ROM in an EPROM for the Spectrum End with less difficulty, it might even fit on my ZX Breakout Breadboard I have - I would definitely be interested in the needed patches for that at some point.

Yes, I have used those break-out boards for the purpose of replacing the Shadow ROM and, with Charles' lovely vLA1, am planning to re-build a complete Interface-1 in due course.

I'll wait to see how much interest there is in enhancing the Shadow ROM before devoting time to fully documenting the required changes, but if you're comfortable to 'go it alone' for now, would be happy to share the ASM and asscociated ROM image that incorporate the Network code changes - I'll consider uploading the files here, but if you are especially impatient, PM me in the meantime.

Great!! QLUB is a long-awaited development.

I have been using the QL network between my PC (with QPC2), Q68 and QL (with SGG + QLSD) successfully for a long time.

The connection between Q68 and QPC2 is via RS232 with Sernet, ... but it would be more convenient to use QLNET to connect all machines, in this way the RS232 output of Q68 could be released for other purposes.

QLUB is definitely a great solution!!

Martin, once again, good job and congratulations.

Peter wrote:Much unlike Martyn's project, I never said the Q68 was intended an open-source solution. Most of the Q68 is closed source, and I have always been clear about that.

Same with QPC, that hasn't ever stopped you from bashing its closed-sourceness. You always go on and on about open source but almost never open source your own stuff.

But as you promote your MiSTer cores here as an open source alternative to the Q68, why do your website visitors not get any source code with the MiSTer binaries you publish?

A quote from my website, directly below the binaries: "The source code is currently available at my GitHub at https://github.com/MarcelKilgus/QL_MiSTer". Wow, that was really hard to find

Marcel

mk79 wrote:Same with QPC, that hasn't ever stopped you from bashing its closed-sourceness.

No, I didn't even mention QPC and don't care if it is closed or not. Apart from that, small scale hardware production of comprehensive circuits is a completely different issue than distributing software.

And even for HDL sources: The MiSTer is not based on your own hardware, but an Altera/Intel subsizdized development board, so of course no QLer had any investments that need a little protection. Comparing that to Q68 is very displaced in my opinion.