| |
Didi
Registered: Nov 2011
Posts: 487 |
Advice for fastest 1541 compatible fastloader
I need advice for a very fast non-IRQ fastloader for 1541 compatible drives which is freely available. I've been away for some years, maybe there has been some new developments the past 10 years. |
|
| |
Didi
Registered: Nov 2011
Posts: 487 |
Topic missed. Anyone else?
Screen may be switched off while loading, maximum speed is the main target. |
| |
j0x
Registered: Mar 2004
Posts: 215 |
Mafiosino at Forum64 did a loader which transmits a full sector in two revolutions using stock GCR:
http://www.forum64.de/wbb3/board25-coder-unter-sich/board308-pr..
There are more threads on this loader at that forum, IIRC.
|
| |
Didi
Registered: Nov 2011
Posts: 487 |
The Mafiosino loader looks promising, will have a try... thanks! |
| |
ready.
Registered: Feb 2003
Posts: 441 |
sorry if the question might sound silly but what is the difference between IRQ and non-IRQ loaders?
In one demo I had to code the drive access so that it ran as a background program and leave the IRQ free for the effects, I used Dream Load. But to me the difference is just a matter of where you call the loader: inside the IRQ or outside of the IRQ. |
| |
cadaver
Registered: Feb 2002
Posts: 1160 |
IRQ-loader means one which allows IRQs to run without disturbing either the IRQs (unacceptably much) or the loader timing. Almost always this means calling the loader from outside IRQ, as the other way around it must be specialized to the program in question.
Non-IRQ fastloaders don't allow IRQs at all and blank the screen so that they can utilize stricter timing and therefore better loading speed, like the Action Replay loader.
|
| |
Skate
Registered: Jul 2003
Posts: 494 |
@Didi: I just remembered that once i've used a loader created by a cartridge (probably Action Replay VI) using an option like "write fastloader to disc". It was very easy to modify and use as a non-irq loader. It was quite fast, too. You can give it a try if other loaders doesn't suit you. |
| |
algorithm
Registered: May 2002
Posts: 705 |
This is what i did with the AR turbotabe. Only slight modifications were required.
I had also modified a loader (cant remember which one) to allow parts to run while part was loading (code can be found in the digital fantasies megademo. A piece of crap made by me over 15 years ago |
| |
QuasaR
Registered: Dec 2001
Posts: 145 |
DreamLoad?! |
| |
algorithm
Registered: May 2002
Posts: 705 |
Quote: DreamLoad?!
No! This was a tape loader that ran under high priority irq or nmi, cant remember which one it was. but allowed main code to run whatever it wanted without interfering with the loader (ofcourse no solid rasters (although raster /screen splits were still possible |
| |
Frantic
Registered: Mar 2003
Posts: 1648 |
Algorith: I believe Quasar didn't respond to you. :) |
| |
titan_ae
Account closed
Registered: Jun 2002
Posts: 46 |
fastest non irq loader i saw till now was "most access" from oliver stiller, he used it on the "amica paint" disc.maybe a big NO GO - the pre-reading of the Directory is needed.
|
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
the AR one (and the track1b loader mentioned above) is much faster than most access ... another faster one would be "superdisk" from input64. |
| |
Zaz
Account closed
Registered: Mar 2004
Posts: 33 |
So did anyone ever do a (non-GCR) loader that can read a track in one revolution on a stock c64+1541? It should be possible... |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
krill is working on that =) |
| |
Graham
Account closed
Registered: Dec 2002
Posts: 990 |
Quoting ZazSo did anyone ever do a (non-GCR) loader that can read a track in one revolution on a stock c64+1541? It should be possible...
Only if that format stores less than 2k on that track, because otherwise you cannot buffer it in 1541 RAM :) |
| |
j0x
Registered: Mar 2004
Posts: 215 |
Assuming Didi wants to use this loader for cracks, the requirement of a track buffer in C64 RAM may be prohibitive. The AR gets around the problem by placing this buffer in AR RAM, but that's cheating :) You can assume ideal sector interleave or you can be clever and load directly to C64 RAM in the order in which the sectors are placed on the disk, but you'll need a full revolution to ensure not writing past the end of file in memory (some sectors in a track may not belong to the current file, and you can't know that unless you've followed the (t,s)-chain).
Edit: Removed question |
| |
Zaz
Account closed
Registered: Mar 2004
Posts: 33 |
Quote: Quoting ZazSo did anyone ever do a (non-GCR) loader that can read a track in one revolution on a stock c64+1541? It should be possible...
Only if that format stores less than 2k on that track, because otherwise you cannot buffer it in 1541 RAM :)
Of course it would have to stream to C64 while reading.
I actually designed the critical parts of such a loader but didn't complete it because I couldn't think of anything to use it for :) |
| |
Krill
Registered: Apr 2002
Posts: 2980 |
For plain GCR, Mafiosino's loader should be fastest (around 20x), but it requires a lot of memory to buffer a raw track.
Fastloaders without track buffers (like the loaders written to disk by AR and other cartridges) are around 12x-15x.
If custom encoding with less than 256 bytes per block is an option, Heureka-Sprint is the fastest i know (around 25x, $e0 bytes per block), and it works with plain d64 and standard GCR disk copiers.
As groepaz said, i am currently working on a 50x fastloader (reading, transferring and checksumming a track in one revolution) with a custom encoding that yields $c0 bytes per block, also with d64/standard GCR compatibility. |
| |
Krill
Registered: Apr 2002
Posts: 2980 |
Quote: Of course it would have to stream to C64 while reading.
I actually designed the critical parts of such a loader but didn't complete it because I couldn't think of anything to use it for :)
Do you still have those bits? I'd like to have a look at that and compare with my ideas for a one-revolution serial fastloader. :) |
| |
Zaz
Account closed
Registered: Mar 2004
Posts: 33 |
Sounds like you're aiming higher than me with the compatibility and all, but PM me your e-mail and I'll give you an outline. If there's anything new or useful in my design, I'll share whatever I have.
So far it's my own design notes and a spreadsheet of code/cycle timings...
|
| |
ChristopherJam
Registered: Aug 2004
Posts: 1409 |
I did create a format that had only one sync per track back in the day; I can't remember whether it took one or two passes to read it, but the only way I managed to write was using a drive that a friend had added a parallel port to (soldered a cable from an IO port on a drive chip to a c64 user port connector).
At the time I was thinking it would be a great way to copy protect a game I was working on. Not so good for demo distribution, mind. |
| |
Krill
Registered: Apr 2002
Posts: 2980 |
That sounds very much like what the V-MAX! guys did, see http://markus.brenner.de/mnib/vmaxtech.txt. (And as stated there, the later Vorpal doesn't need any hardware syncs at all on a track.)
The hardware sync is not necessarily a sector-starting sync, as they proved, so yeah, your format might have been readable in more than 1 revolution with a vanilla 1541.
What was your aim when coming up with this idea? :) |
| |
Zaphod
Registered: Jun 2012
Posts: 63 |
If you are willing to use your own GCR, the fastest non irq loader is Vorpal V1 (25x speedup) or one of it's MANY MANY clones (Warp*25,Laser Load, Heureka Sprint, etc) every one of these was shamelessly ripped from Vorpal, and grants a 25x speedup. The tradeoff is more disk space used, because a less efficient gcr format is used so it can be decoded fast enough to handle an interleave of TWO.
You cannot fastcopy these with a single drive, but ANY NIBBLER, even the simplest and fastest, will copy the disk. This includes those 25 second dual drive copiers, which are actually incredibly basic (and fast) nibblers.
Mafiosino's loader seems to be the fastest screen blanker that uses standard GCR.
The fastest IRQ loader that uses standard GCR is krill's loader. Using non standard GCR, v-max is probably the fastest irq loader.
Note that the vorpal utility kit has been dumped, so you CAN use the original. Heuerka Sprint is also available. With a bit of ASM hackery, it's doable.
Kinda crazy that vorpal v1 is still state of the art in non irq loaders. :) |
| |
Kabuto
Account closed
Registered: Sep 2004
Posts: 58 |
This thread reminds me to an idea I had recently albeit it's slightly OT since it won't be the fastest fastloader:
It uses a custom GCR encoding that can fit 7 bits into 8 raw bits. It assumes that any encoding is permitted that does not have 3 "0" bits or 9 "1" bits in a row. That's close to the theoretical limit (about 7.01 bits per 8 raw bits IIRC).
Instead of ridiculously long GCR intervals it uses a kind of arithmetical entropy encoder since different raw bytes have different internal "expressiveness" values - e.g. after a byte ending with bits 00 there can't be a byte starting with 0 while the next bytes after a byte ending with bits 01 won't be limited as much (everything goes as long as it's not 9 1's in a row - within GCR limits of course).
I did a quick pen & paper writeup of a sample decoder - it's possible to decode bytes as they come in from the electronics at realtime into drive memory, however, due to the data rate being so high (about 1 byte every 30 cycles), it will be impossible to transmit the sector just read during the next sector so every track will take like 3 revolutions. |
| |
Krill
Registered: Apr 2002
Posts: 2980 |
Zaphod77: The Heureka-Sprint format is encoded on top of plain GCR, so it can be stored on d64 and be copied with standard disk backup software just fine.
Kabuto: Your idea reminds me of one i wrote up on paper (and with a test encoder/decoder), but i didn't come anywhere close to your format/data ratio - in the end i could encode about 270 bytes per block (so slightly more than 80% density, which is better than GCR still), however with the big benefit of fully decoding and checksumming the data on the fly while reading. Can you tell me a bit more about your approach? |
| |
Kabuto
Account closed
Registered: Sep 2004
Posts: 58 |
@Krill: in another thread. I don't want to hijack this thread :) |
| |
theWizard
Account closed
Registered: Jul 2007
Posts: 109 |
i cant remember the name of it but here is what it looked like maybe someone else can remember the name ..
some swedish guy made it
it wrote to 0400 when it started , blanked the screen to border blue , disk started thump thump thump then a loud crack when it finished .. ( it totally disregarded everything and just loaded zero error checking etc it was fast as f**k) .
it was the fastest loader for a c64 disk i ever seen and it was used in an old demo ( no idea what demo though sorry forgot ) and ported to a normal disk loader , sys to start it was 2048 ( i think )
good luck if you get it take a look at the code from it btw if anyone can remember the name il get it again as well because the disk i have it on is dammaged. |
| |
AlienTech
Account closed
Registered: Nov 2019
Posts: 3 |
Quote: i cant remember the name of it but here is what it looked like maybe someone else can remember the name ..
some swedish guy made it
it wrote to 0400 when it started , blanked the screen to border blue , disk started thump thump thump then a loud crack when it finished .. ( it totally disregarded everything and just loaded zero error checking etc it was fast as f**k) .
it was the fastest loader for a c64 disk i ever seen and it was used in an old demo ( no idea what demo though sorry forgot ) and ported to a normal disk loader , sys to start it was 2048 ( i think )
good luck if you get it take a look at the code from it btw if anyone can remember the name il get it again as well because the disk i have it on is dammaged.
I saw it on a demo of a new Vorpal that Epyx was trying to sell. It used self modifying code on both the computer side as well as the drive side with some look up tables and using pre scrambled bytes which the serial transfer fixed. I dont think it was ever released and written by Scott Neleson. All copy protection companies were afraid of what it represented as they did not think it could get faster and said single rev transfer and read was impossible without losing 50% data storage, yet here was something which code store more than normal data on a disk and did it faster than anyone else thought possible. |
| |
AlexC
Registered: Jan 2008
Posts: 299 |
It would be awesome if someone could not only find it but also upload it here ;) |
| |
almightyc64
Registered: Feb 2006
Posts: 8 |
Quoting AlienTechI saw it on a demo of a new Vorpal that Epyx was trying to sell. It used self modifying code on both the computer side as well as the drive side with some look up tables and using pre scrambled bytes which the serial transfer fixed. I dont think it was ever released and written by Scott Neleson. All copy protection companies were afraid of what it represented as they did not think it could get faster and said single rev transfer and read was impossible without losing 50% data storage, yet here was something which code store more than normal data on a disk and did it faster than anyone else thought possible.
I wonder if it was Vorpal v2, if I remember correctly Scott Nelson from Epyx wrote the Vorpal fastload system, and version 2 didn't use any sync marks and couldn't be copied without expanded drive RAM or a parallel cable. It was used on some of Epyx's later titles like Street Sports Basketball.
I wonder if theWizard's message from 2013 describing the fastload system made by someone in Sweden was something like Rapidlok. His description of the sound brings Rapidlok to my mind anyway (used on lots of games from Accolade). |
| |
Krill
Registered: Apr 2002
Posts: 2980 |
Meanwhile, LordCrass made a fastloader/disk format to load at one revolution per track: https://www.lemon64.com/forum/viewtopic.php?t=65715 - and it's blazingly fast.
However, it isn't quite stable on real hardware.
Since his work is very similar to what i lined out on paper, i might at some point resume that project and see if it can be made reliable. Or if i can, anyways. =) |
| |
Frantic
Registered: Mar 2003
Posts: 1648 |
@krill: That would be damn cool if it worked! |
