SJLOAD-20 release 07
Moderator: Moderators
SJLOAD-20 release 07
SJLOAD-20 (für VIC-20) release 07 (thanks to nbla000!)
Release Info:
- Fixed the DEVICE NOT PRESENT Vic hang by using IECNAMOUT, DISK_LISTEN, DISK_TALK, DISK_CLOSE[_SA] present on FE3 r19
- Fixed the Drive not closed (on Jiffy drives) issue by calling DISK_CLOSE_LO routine on ends
- some new compile options for smaller code without messages, with std. messages, without Load/Save params, without SAVE
Binaries for $0400 and $B000 are included.
Source code is included.
Have fun!
Many thanks to nbla000 for his great workl!
.
download as usual from my HP: SJLOAD
Release Info:
- Fixed the DEVICE NOT PRESENT Vic hang by using IECNAMOUT, DISK_LISTEN, DISK_TALK, DISK_CLOSE[_SA] present on FE3 r19
- Fixed the Drive not closed (on Jiffy drives) issue by calling DISK_CLOSE_LO routine on ends
- some new compile options for smaller code without messages, with std. messages, without Load/Save params, without SAVE
Binaries for $0400 and $B000 are included.
Source code is included.
Have fun!
Many thanks to nbla000 for his great workl!
.
download as usual from my HP: SJLOAD
-
- Omega Star Commander
- Posts: 1371
- Joined: Thu Jan 31, 2008 2:12 pm
- Website: https://robert.hurst-ri.us
- Location: Providence, RI
- Occupation: Tech & Innovation
I am intrigued by this utility, but I don't understand its requirements to have successful operation. Do I need JiffyDOS in the kernal(s) to take advantage of this? Or is it natively compatible with uIEC/SD for faster loads, i.e., +8k programs like Berzerk and Quikman take 30-seconds to load from uIEC/SD now.
Any technology distinguishable from magic is insufficiently advanced.
https://robert.hurst-ri.us/rob/retrocomputing
https://robert.hurst-ri.us/rob/retrocomputing
- Pedro Lambrini
- Vic 20 Scientist
- Posts: 1132
- Joined: Mon Dec 01, 2008 11:36 am
SJLOAD-20 changes nearly all VIC-20 vectors for disk operation to make it Jiffy compatible.
In other word, if SJLOAD runs on your VIC, it is same as your VIC would have a Jiffy kernel.
For normal drives there is no difference.
For Jiffy drives you speed up all operations to jiffy speed. SD2IEC and µIEC are usable as "Jiffy drives".
Especially SD2IEC and µIEC have a big benefit of it. Cause this drive replacements has no mechanical slow downs (seek time, track change time, BAM access time, spin up time).
But all other Jiffy drives has also a big speed up.
Final Expansion 3 has a built in SJLOAD (diskloader, flasher). If you start with FE3 wedge you have also automatically SJLOAD resident in memory.
Anyhow a real Jiffy kernel has a benefit again SJLOAD:
+ It is much better integrated
+ It is available after a reset without loading.
+ last but not least it has a valid licence
SJLOAD is good for people who has Jiffy drives (or µIEC) but no Jiffy kernel. A real Jiffy kernel is much better.
In conclusion, currently no legal VIC-20 kernel is available. Maybe in future Jim Brain will offer us such a kernel. After this kernel is available there is no reason to support SJLOAD further and maybe all sources of SJLOAD-20 will be deleted.
In other word, if SJLOAD runs on your VIC, it is same as your VIC would have a Jiffy kernel.
For normal drives there is no difference.
For Jiffy drives you speed up all operations to jiffy speed. SD2IEC and µIEC are usable as "Jiffy drives".
Especially SD2IEC and µIEC have a big benefit of it. Cause this drive replacements has no mechanical slow downs (seek time, track change time, BAM access time, spin up time).
But all other Jiffy drives has also a big speed up.
Final Expansion 3 has a built in SJLOAD (diskloader, flasher). If you start with FE3 wedge you have also automatically SJLOAD resident in memory.
Anyhow a real Jiffy kernel has a benefit again SJLOAD:
+ It is much better integrated
+ It is available after a reset without loading.
+ last but not least it has a valid licence
SJLOAD is good for people who has Jiffy drives (or µIEC) but no Jiffy kernel. A real Jiffy kernel is much better.
In conclusion, currently no legal VIC-20 kernel is available. Maybe in future Jim Brain will offer us such a kernel. After this kernel is available there is no reason to support SJLOAD further and maybe all sources of SJLOAD-20 will be deleted.
-
- Omega Star Commander
- Posts: 1371
- Joined: Thu Jan 31, 2008 2:12 pm
- Website: https://robert.hurst-ri.us
- Location: Providence, RI
- Occupation: Tech & Innovation
Thanks for that detailed and complete explanation -- I will endeavor on checking out its performance on my VIC and uIEC drive.
Any chance of this getting integrated in Mega-Cart II with the built-in uIEC drive?
Any chance of this getting integrated in Mega-Cart II with the built-in uIEC drive?
Any technology distinguishable from magic is insufficiently advanced.
https://robert.hurst-ri.us/rob/retrocomputing
https://robert.hurst-ri.us/rob/retrocomputing
You'll be impressed, I was also.rhurst wrote:I will endeavor on checking out its performance on my VIC and uIEC drive.
There are plans for a MegaCart-II?! Good news!rhurst wrote:Any chance of this getting integrated in Mega-Cart II with the built-in uIEC drive?
I'm sure nbla000 will integrate SJLOAD-20 into MegaCart-II, he knows this tool very well now.
Is something public about MegaCart-II, something to read or pictures?
-
- Omega Star Commander
- Posts: 1371
- Joined: Thu Jan 31, 2008 2:12 pm
- Website: https://robert.hurst-ri.us
- Location: Providence, RI
- Occupation: Tech & Innovation
Er, I was sounding off a 'wish' for MCII ... I just want it all in one package. FE3 sounds grand, but I am just not into kits. For example, I would love to have one of uIEC drives modded to my datasette -- but I am too wary to hack away at hardware -- I am a nightmare with the soldering iron.
Any technology distinguishable from magic is insufficiently advanced.
https://robert.hurst-ri.us/rob/retrocomputing
https://robert.hurst-ri.us/rob/retrocomputing
Re: SJLOAD-20 release 07
Thanks to you for your vic porting, I've just found a problem and fixed.Diddl wrote:Many thanks to nbla000 for his great workl!
There are no plans for a MegaCart-II, btw I'm working on a firmware revision for a better integration with SD drives.Diddl wrote:There are plans for a MegaCart-II?! Good news!
My new CBM-FileBrowser will be integrated on new Mega-Cart units for example.
It's just a rhurst's dream at the momentIs something public about MegaCart-II, something to read or pictures?
Mega-Cart: the cartridge you plug in once and for all.
The VIC-20 JiffyDOS (and the Plus4 JiffyDOS) were developed by Maurice Randall. One can hope that Maurice will release the rights to those. As it stands, the above two kernels are legally in the hands of the few beta testers.Diddl wrote:In conclusion, currently no legal VIC-20 kernel is available. Maybe in future Jim Brain will offer us such a kernel.
Truly,
Robert Bernardo
Fresno Commodore User Group
http://videocam.net.au/fcug
The Other Group of Amigoids
http://www.calweb.com/~rabel1/
Southern California Commodore & Amiga Network
http://www.sccaners.org
I'd appreciate any help folks can offer in this area. I've been in contact with MR on a number of occasions lately about the VIC and +4 ports, but he is unwilling to license or otherwise offer the intellectual property. Legally, he cannot sell them without a JD license, but legally, I cannot sell them either without his consent/agreement, because MR does hold some portion of the rights to the ports.RobertBe wrote:The VIC-20 JiffyDOS (and the Plus4 JiffyDOS) were developed by Maurice Randall. One can hope that Maurice will release the rights to those. As it stands, the above two kernels are legally in the hands of the few beta testers.Diddl wrote:In conclusion, currently no legal VIC-20 kernel is available. Maybe in future Jim Brain will offer us such a kernel.
I am trying to alleviate the issue, but it requires re-porting the code. I've asked in here about someone re-porting the JD to the VIC, but as yet, no one has stepped up to help.
Jim
I've been taking a stab at porting JiffyDOS to the Vic-20 the past few days, and, as was quoted in the bounty thread, it seems very easy. So easy in fact that I've subconsciously been trying to make it harder for myself by retyping everything (including comments from the document linked to in the bounty) by hand. The problem is that between SJLoad and the C64 JiffyDOS, the result is going to be very near a duplicate of the original Vic-20 JiffyDOS.
The features requested in the bounty (generalizing the kernal for arbitrary screen sizes) also seems very easy. Not much will change even after implementing them.
Maybe this isn't a problem at all. The resulting ROMs won't be identical, but they're going to be extremely close.
Aside from the CIA vs VIA code, the only notable difference between the C64 JiffyDOS and the Vic20's is that some things are moved in the Vic20's to places that were previously unused (there are some jmps to and from these regions). And its fairly obvious when and where to do this. It's only necessary a few times. And, though in a different location, it is still the same code, so I guess it still is owned by the creator of the C64 version.
Anyway, to put it bluntly my question is: will the result of my work be legal?
BTW, I'm aware the bounty is closed. I don't want a reward if I succeed either. Diddl and nbla000 deserve one far more than I for SJLoad which is making the port so ridiculously easy. I'm also not following the "success will be defined as" guidelines exactly. Namely, I'm not doing conditional assembly, though I suppose I could do something like this to add that option:
#ifdef JIFFY
.source "jiffy.a65"
#else
.source "original.a65"
#endif
The features requested in the bounty (generalizing the kernal for arbitrary screen sizes) also seems very easy. Not much will change even after implementing them.
Maybe this isn't a problem at all. The resulting ROMs won't be identical, but they're going to be extremely close.
Aside from the CIA vs VIA code, the only notable difference between the C64 JiffyDOS and the Vic20's is that some things are moved in the Vic20's to places that were previously unused (there are some jmps to and from these regions). And its fairly obvious when and where to do this. It's only necessary a few times. And, though in a different location, it is still the same code, so I guess it still is owned by the creator of the C64 version.
Anyway, to put it bluntly my question is: will the result of my work be legal?
BTW, I'm aware the bounty is closed. I don't want a reward if I succeed either. Diddl and nbla000 deserve one far more than I for SJLoad which is making the port so ridiculously easy. I'm also not following the "success will be defined as" guidelines exactly. Namely, I'm not doing conditional assembly, though I suppose I could do something like this to add that option:
#ifdef JIFFY
.source "jiffy.a65"
#else
.source "original.a65"
#endif
The port has been authorized by the copyright owner, but even if not, there are no legal issues with the port itself.Wilson wrote:Anyway, to put it bluntly my question is: will the result of my work be legal?
Distributing it can get hairy, as one can tell.
However, there is more to the ROM changes than just the JIFFY code. Things like dir listings, printing from screen, etc., will act slightly differently due to the screen size.
And, bounty or not, I am happy to compensate a bit for the effort. Many people ask for the version, as they want a legit copy, but I can't oblige them.
Jim
Thanks for the response, Jim.
I'm happy to report that I finally have my ROM booting to the BASIC prompt. Things do not work quite as expected beyond that yet.
Indeed I am one of those people. My motivation is somewhat selfish in that regard.brain wrote:Many people ask for the version, as they want a legit copy, but I can't oblige them.
I'm happy to report that I finally have my ROM booting to the BASIC prompt. Things do not work quite as expected beyond that yet.
A little update.
Everything seems to work as expected with a non-JiffyDOS equipped drive. And the Jiffy routines seem to function fine on PAL machines (if VICE is anything to go by). So my next order of business is to get the same functionality on NTSC. I really have no idea why it isn't working right now, so who knows how long it'll take. After that, I'll work on replacing all the hard-coded screen junk with size independent code.. In order to squeeze it in I may remove the screen dump code. Another feature I thought would be nice is to allow the user to hold various keys on boot to force unexpanded memory or to not start the inserted cartridge. Any other suggestions are welcome.
Everything seems to work as expected with a non-JiffyDOS equipped drive. And the Jiffy routines seem to function fine on PAL machines (if VICE is anything to go by). So my next order of business is to get the same functionality on NTSC. I really have no idea why it isn't working right now, so who knows how long it'll take. After that, I'll work on replacing all the hard-coded screen junk with size independent code.. In order to squeeze it in I may remove the screen dump code. Another feature I thought would be nice is to allow the user to hold various keys on boot to force unexpanded memory or to not start the inserted cartridge. Any other suggestions are welcome.