I'm new to the forum and to the world of QLs, having bought a QL around 3 weeks ago!

I've been tinkering with the QL network in order to create an SD card based 'file server' for the QL, and after a lot of reading of documentation, logic analysing and head scratching I finally got the QL network protocol working (I'm using an STM32F103 aka 'Blue Pill' board as the file server). I can now save basic programs using 'save neto_63', and load with 'load neti_63', and can load and save binary data with lbytes & sbytes.Here's where I've been having a problem - I recently bought on of tetroid's ROM switchers (great item!), and found that while my 'file server' works fine with the stock ROMs and Minerva, as soon as I install the Toolkit 2 ROM I can no longer load files, although saving still works OK.When I try to load a file with TK2 using 'load neti_63', I just receive the message 'bad parameter'. I've used the logic analyser to see what's going on, and I've found that under TK2, the first header and block is acknowledged, but no further communication occurs. I've tried tweaking the protocol timings, but to no avail. Frankly, at this point I'm stuck, so I'm hoping that some of you with more experience of QL networking maybe able to suggest what's going wrong.

You might also try using a lower network station number than 63, as that is the highest allowed. In case there is a problem with using the highest station number with Toolkit 2. There is a problem with using N8_ and the Toolkit 2 file server FSERVE.

I have been using that document as a reference for the original QL network protocol. I assumed that TK2 would be backward compatible with the original protocol as the documentation only mentions a modified protocol for the broadcast message and the FSERVE protocol. I'm a little baffled by the fact that TK2 issues an ACK for the first block - usually if there is anything wrong with the block (e.g timing issues/bad checksum) you do not receive an ACK - it's an odd one!

I'll certainly give the lower station number a try - I'll post back with the results later.

Well, I've tried a variety of different NET ids for both the file server and the QL, but I'm still getting the same problem.

I also did some experimentation on the header & data checksums to see how TK2 would respond, and it responded as expected:

- an invalid header checksum yielded no ACK response at all, - a valid header checksum and invalid data checksum yielded an ACK for the header, but no ACK for the data, - valid checksums for both checksums yielded ACK responses for both.

Firstly, well done on getting this far with your project! My own experience suggests that you'll get a lot of satisfaction out of exploring the QL's NET capability - simple though it is!

I believe I can explain the behaviour you are seeing when switching from stock QDOS/Minerva to the much enhanced TK2 NET driver, but I'll need to wait until my lunch break before I can validate the assessment.

In short however, you are seeing a dfifference in how QDOS and TK2 respond to the S*Basic command LOAD (bp_load) call and the difference in requirements between then with regard to the simple 15-byte 'serial-header.'

Stand-by!

Last edited by martyn_hill on Wed May 01, 2019 10:39 am, edited 1 time in total.

So, I've manageed to take a look at both the latest Minerva and TK2 source and can confirm the following, which should help you understand what you are seeing:

a) SAVE across both QDOS/TK2 will only store the program ASCII characters - there is never a file-header added - in fact SAVE and LIST share the very same code in this regard.b) In Minerva/QDOS, the SuperBasic LOAD cmd simply attempts to open the named file and stream the bytes/characters without any effort to first validate the presence of a 'file-header.' This works because LOAD will quietly accept/expect an EOF as a means of terminating the operation - no previous knowledge of file-length or type is required, so a file header is simply not expected.c) In TK2 on the otherhand, due to the way that Default paths are checked and code shared between all the LOAD/SAVE variant routines, immediately after opening a file for input, a call is made to read-in the first 15 (or 64 if a directory device) bytes of a file-header and a simple check made (Type-0 in the case for LOAD.) The actual LOAD operation is again terminated at EOF. The header-read routine itself checks for the presence of a 255d/FFh flag as the very first byte of the header and will return an error if not found - and it is likely this error that is being passed back to LOAD to give the 'Bad parameter' error.

Now, I suspect that you used SAVE or similar to generate the file that you are now attempting to re-load via the NET from your SD-Card 'file-server', thus there will be no file-header available unless steps are taken to add one. This doesn't upset QDOS/Minerva LOADing as described, but will upset TK2....

SBYTES on the otherhand will have generated the file-header, and thus you won't have hit the problem when re-loading via LBYTES using the replacement TK2 NET driver - only for LOAD.

To get the LOAD to function across the NET as required, simply add the 15-byte (serial) header to the front of your SAVEd file on the SD Card, by for example using the TK2 command "COPY_H" , thus:

COPY_H <source_program_filename> TO 'neto_63'

Or you could go the long way and manually PRINT the 255d/FFh byte plus remainder of the 14-byte header to 'neto_63', followed immediately by the ASCII characters of the S*Basic program file.

In practice, only the first 1+4+1 bytes are of any significance - the flag-byte, the LONGINTEGER file-length that immediately follows, then the File-type (0) byte. The remaining bytes of the standard serial file-header are not relevant here and are not checked at all.

(In fact, even with COPY_H, TK2 only seems to populate the first 1+4+2 bytes of the header that is sent when copying a type-0 file - the other bytes appear to be random rubbish probably left behind in the buffer.)

Thank-you for your comprehensive explanation as to what could be happening - you were exactly right! I added the missing header to the file and it loaded as expected - Success!Of course, this now breaks the loading of BASIC files on the stock roms - I'll have to make my 'file server' switch between the formats.

It does seem odd that TK2 SAVEs BASIC files (over the network) without the header, but expects a header on LOAD.

The only main problem I have now is that trying to LOAD over the network with TK2 + Minerva causes the QL to hang (I see no response at all on the network with the logic analyser) - Could this be related to the LBYTES issue you discovered in an earlier thread?

Anyway, again, thank-you for your valuable insight into this issue - it is very much appreciated. I'm sure I'll be discussing more networking issues with you when I get round to trying to understand the FSERVE protocol.

jll745562 wrote: It does seem odd that TK2 SAVEs BASIC files (over the network) without the header, but expects a header on LOAD.

I agree - arguably a design-bug in TK2. Worth noting that it probably won't be just over the network, but over any 'simple serial' device where the FFh+14-byte header is used. E.g. LOADing over the SERial port or from the MEM device.

It's fine when loading from a file/directory device as a full header is always added by the device-driver itself, even though the SAVE cmd doesn't bother. I'll check this point another day...

As LOAD should not require a header (and doesn't in QDOS), my view is that the error in design is there, rather than with the header-less SAVE.

jll745562 wrote:The only main problem I have now is that trying to LOAD over the network with TK2 + Minerva causes the QL to hang (I see no response at all on the network with the logic analyser) - Could this be related to the LBYTES issue you discovered in an earlier thread?

It could well be due to the same cause, yes. Which version of Minerva are you using? Marcel's 'I/O Fix' version of Minerva addresses that particular issue.

Keep us posted - and more than happy to share what learnings I've made during my own fun with the NET device...

Why do they put lightning conductors on churches?If at first you don't succeed, don't take up skydiving!If you think your job is pointless, remember, there's someone in Germany who fits indicators to BMWs.