How is one supposed to launch SJLOAD07?

[nbla000]

I really would like to update my releases with a consolidated version pack of SJLOAD and would have no problems if it came as two separate binaries for PAL and NTSC.

Don't worry, once I've succefully tested it also with pi1541 (both PAL and NTSC), I will find old sources and I will publish the new version 09.

The reference is the timing as delivered by original CBM drive JiffyDOS installations. The bit time length needs to be right and the delay between synchronisation and first bit time needs to be correct as well. That can't be done right just by assembling one version of code and the emulation telling you "everything's in order - move along, move along!". At least both (bit time) length and (synchronisation) delay need to be stress-tested

Beleve me, I'm stressing it a lot

It was tested also by using a NTSC machine + 1541 Jiffy drive (the most critical drive, based on my experience) with a self loading loop program for over an hour without problems. In any case, any further problem can be fixed once released, I just wish to be sure that current detected problems with pi1541 where solved before to release it, nothing else.

Sorry for confusion. I and @srowe were talking about code in https://github.com/ops/sj20

This version supports PAL and NTSC.

OK, thanks for point it out.

[Mike]

The reference is the timing as delivered by original CBM drive JiffyDOS installations. The bit time length needs to be right and the delay between synchronisation and first bit time needs to be correct as well. That can't be done right just by assembling one version of code and the emulation telling you "everything's in order - move along, move along!". At least both (bit time) length and (synchronisation) delay need to be stress-tested

Believe me, I'm stressing it a lot

As you cropped my quote just at the most interesting part:

Stressing not only means to let such a test running for a prolonged time. The timing could be at the brink and you might just be lucky to keep within the windows of the bit times at all times still.

I explicitly meant to break the timing on purpose with an out-of-bound synchronisation delay and bit time lengths in the computer-side code to see the limits of the transfer loop. The delay and bit time length then should be set to give the transfer loop the most leeway. This helps a lot to make the transfer loop robust against frequency drifts and the like.

[pixel]

Wow! That code is a pleasure to watch! My version clearly belongs into the rubbish bin.

What's the maximum transfer speed you got out of it so far?

[nbla000]

Stressing not only means to let such a test running for a prolonged time. The timing could be at the brink and you might just be lucky to keep within the windows of the bit times at all times still.

I explicitly meant to break the timing on purpose with an out-of-bound synchronisation delay and bit time lengths in the computer-side code to see the limits of the transfer loop. The delay and bit time length then should be set to give the transfer loop the most leeway. This helps a lot to make the transfer loop robust against frequency drifts and the like.

What you said it's absolutely right.

I wish to point out that SJLOAD porting for Vic-20 was a Diddl work, with version 07 I've fixed some minimal issues and improved it a bit but core code was not modified as listed also on AUTHORS file present in ops repository.

After a bit some Mega-Cart users reported me SJLOAD07 issues by using it from NTSC machines mainly with 1541 Jiffy drives and If I'm not wrong also with a 1571 Jiffy drive so I analized SJLOAD code and compared it with JiffyDos PAL Vic-20 kernal routines and noticed that is pratically identical so I checked and compared all SJLOAD routines with JiffyDos NTSC Vic-20 kernal routines and I've noticed just few difference riported also on the NTSC version of SJLOAD08.

I'm not a technical expert like you Mike, you are my guru for "hard-core" matterns but considering that SJLOAD code Is similar if not identical to JiffyDos kernal PAL/NTSC, I'm quite confident that it works, at least I've not received any issue report from 2011 both from PAL and NTSC machines while I've received positive feedback (not stress test) with "jiffed" 1541, 1541-II, 1571, 1581 using PAL or NTSC machines and also from SD2IEC devices of course.

I don't remember now my modifies, I have to find my sources but looking on ops repository I think they are quite similar, mainly PHA PLA NOP, code required to increase or decrease sync time I guess.