Log inRegister an accountBrowse CSDbHelp & documentationFacts & StatisticsThe forumsAvailable RSS-feeds on CSDbSupport CSDb Commodore 64 Scene Database
You are not logged in 
CSDb User Forums


Forums > CSDb Entries > Release id #167152 : Krill's Loader, repository version 164
2018-08-13 21:37
Krill

Registered: Apr 2002
Posts: 1308
Release id #167152 : Krill's Loader, repository version 164

If no problems emerge (i know they will, but anyways)... I can explain a bit about the full on-the-fly GCR block read+decode+checksumming.
 
... 36 posts hidden. Click here to view all posts....
 
2018-08-28 22:07
Sparta

Registered: Feb 2017
Posts: 12
Yes, you got it. Spartan stepping uses the transfer loop to pace half-track steps instead of a timer. :)

I respectfully disagree with your second point. The computer-side code does not need to know whether the currently transferred block is the final block of a track. Thus, code can be simplified. Fetching and transferring a block takes roughly 27000-29000 cycles depending on speed zones. Spartan stepping adds 17 cycles to this (72 vs. 72.06 bycles/block transfer). I do not think this causes a significant delay resulting in missing the next block. The total loss while loading a full 35-track disk is 664*17= 11288 cycles, spread out evenly. Shrydar stepping, on the other hand, adds 12*256*34=104448 cycles delay. The difference is about 10-fold.

After the on-the-fly GCR loop and the 72-cycles/byte transfer loop, Spartan stepping was the first thing that resulted in a significant speed improvement in my loader.

I can see your point in your third comment. Your code's complexity-to-tightness ratio is extremely high. :)
2018-08-29 11:14
ChristopherJam

Registered: Aug 2004
Posts: 992
shrydar here.

Yes, I have wondered about doing a half track step mid transfer too, but I think the pertinent performance metric is percentage time saved, which even at interleave of three is only 0.5% (3072 cycles every 600,000 - and that's assuming no errors, and either perfectly aligned tracks or out of order loading).

Either shrydar stepping or spartan stepping is a huge improvement over the old "wait until you're about to try and read the next block, then spend 60+ bycles on stepping and stabilisation" mind. The biggest win is almost certainly from allowing the head to settle during the transfer.

I'm still undecided about when to do the second step in Marmaload; my own loader development's been on hold while I've been distracted by crunchers and demo effects.

At this rate I suspect that'll remain the case until I've at least one production out the door using Krill's instead - we'll see :)
2018-08-29 11:30
Krill

Registered: Apr 2002
Posts: 1308
Quoting Sparta
I respectfully disagree with your second point. The computer-side code does not need to know whether the currently transferred block is the final block of a track.
You're probably right there. But the first and third points alone seem to prohibit Spartan Stepping in my case. And yes, what Shrydar aka ChristopherJam said. :)
2018-08-29 16:32
Sparta

Registered: Feb 2017
Posts: 12
Quoting ChristopherJam
The biggest win is almost certainly from allowing the head to settle during the transfer.


Agreed on this. In my loader Sparkle, which will never be as versatile as Krill's, I think I am going to settle (huh) with the best of both worlds. I.e. I will time the second half-track step in the transfer loop about 12 bycles after the first one to allow enough time for the head to settle. Call it the Spartan Shrydar Step. :))

P.S. I was aware of the mysterious Shrydar's identity. Google knows everything. :)
2018-08-30 10:10
bubis

Registered: Apr 2002
Posts: 17
Quote: Quoting ChristopherJam
The biggest win is almost certainly from allowing the head to settle during the transfer.


Agreed on this. In my loader Sparkle, which will never be as versatile as Krill's, I think I am going to settle (huh) with the best of both worlds. I.e. I will time the second half-track step in the transfer loop about 12 bycles after the first one to allow enough time for the head to settle. Call it the Spartan Shrydar Step. :))

P.S. I was aware of the mysterious Shrydar's identity. Google knows everything. :)


We just don't know who you are, my Hungarian fellow. :)
2019-03-13 06:39
map

Registered: Feb 2002
Posts: 8
Quoting Groepaz
python has the same problems, i think (is it a single exe requiring no install?) (the point is: right now "our" dev environment is completely freestanding requiring no msys or cygwin or any of that, and no installing either - breaking that is not an option :))

the problem with ca65 are at least nucrunch and tinycrunch, those will not build.


One possibility might here to use Pyinstaller with option --onefile to create an .exe from the .py.
https://pypi.org/project/PyInstaller/
Using the UPX packer you can minimize the filesize of the .exe.
2019-03-14 08:43
Krill

Registered: Apr 2002
Posts: 1308
Quoting Groepaz
python has the same problems, i think (is it a single exe requiring no install?) (the point is: right now "our" dev environment is completely freestanding requiring no msys or cygwin or any of that, and no installing either - breaking that is not an option :))
Apparently, this does seem to exist: http://winpython.github.io/ - "The easiest way to run Python [...] out of the box on any Windows PC, without installing anything!", "WinPython lives entirely in its own directory, without any OS installation" and similar claims. There's some small print, though, so YMMV*.

* "Your metrage may vary" in PAL-land.
2019-03-14 08:47
Krill

Registered: Apr 2002
Posts: 1308
Quoting map
Using the UPX packer you can minimize the filesize of the .exe.
Expect lots of Windows users to bemoan that their assorted snake-oil protection suite puts it into quarantine.
2019-03-15 06:11
ChristopherJam

Registered: Aug 2004
Posts: 992
Perhaps 'someone' should port tc_encode (the tinycrunch encoder) to c64? :D


Also, it's worth noting that the build issues with nucrunch and tinycrunch under newer versions of ca65 were fixed some time ago now.
2019-03-15 06:54
map

Registered: Feb 2002
Posts: 8
Quoting Krill
Quoting map
Using the UPX packer you can minimize the filesize of the .exe.
Expect lots of Windows users to bemoan that their assorted snake-oil protection suite puts it into quarantine.


True, but UPX is completely optional here.

Another hint: in case the target is to run the Python script using wine - the wine project only recently added the required libraries for the latest Python3. Not all Linux Distros have updated their packages yet.
Previous - 1 | 2 | 3 | 4 | 5 - Next
RefreshSubscribe to this thread:

You need to be logged in to post in the forum.

Search the forum:
Search   for   in  
All times are CET.
Search CSDb
Advanced
Users Online
Powerslave/ΤRIΛD
Dymo/G★P
bugjam
Rebok
Mason/Unicess
saimo
Durandal
iAN CooG/HVSC
Brittle/Necta!^Demozoo
Vizz
simun9/CMS
Yogibear/Protovision
Guests online: 59
Top Demos
1 Uncensored  (9.7)
2 Unboxed  (9.7)
3 Coma Light 13  (9.7)
4 Edge of Disgrace  (9.7)
5 Comaland 100%  (9.6)
6 Lunatico  (9.6)
7 The Shores of Reflec..  (9.5)
8 Rivalry  (9.5)
9 C=Bit 18  (9.5)
10 X Marks the Spot  (9.5)
Top onefile Demos
1 Instinct  (9.6)
2 Crystal Gazer  (9.6)
3 Dawnfall V1.1  (9.5)
4 Smile to the Sky  (9.5)
5 The Tuneful Eight [u..  (9.5)
6 Field Sort  (9.5)
7 Space Demo  (9.5)
8 The Tuneful Eight (U..  (9.5)
9 Daah, Those Acid Pil..  (9.5)
10 Innervasion  (9.5)
Top Groups
1 Performers  (9.6)
2 Oxyron  (9.4)
3 PriorArt  (9.4)
4 Fossil  (9.4)
5 Booze Design  (9.4)
Top Crackers
1 Mr. Z  (10)
2 S!R  (9.8)
3 Mr Zero Page  (9.7)
4 Janitor  (9.7)
5 Mitch  (9.6)

Home - Disclaimer
Copyright © No Name 2001-2019
Page generated in: 0.047 sec.