| |
Krill
Registered: Apr 2002
Posts: 2982 |
Release id #197710 : Transwarp v0.64
General Q&A thread, also report problems and error logs here. |
|
| |
iAN CooG
Registered: May 2002
Posts: 3204 |
Black magic. Care to explain what the challenge consists of? I see 2 USR files, trying to add ,U after the filename it gets loaded in loop. Can one load them without altering the diskimage?
Other than that, I guess this is a world record. Cheers. |
| |
Krill
Registered: Apr 2002
Posts: 2982 |
The USR files are encrypted. The key is a 40-bit CBM float, passed as 4th parameter to load. I.e.,LOAD"CIPHERED",8,1,π will load the first encrypted file with pi as the key (with previously installed Transwarp).
The challenge for the crackers is finding the key for the other encrypted file. There are only about a million million possibilities, so can be bruteforced. =) |
| |
Burglar
Registered: Dec 2004
Posts: 1105 |
This is truly amazing, it really is loading at the same speed as the fastest iffl-scanners around and these usually don't communicate with the c64 during scan and they only decode the first 2 bytes to capture just the track/sector link.
Not sure if anyone noticed, but loading a transwarp file directly, transparently loads the bootloader first and then the main file. that's a really excellent feature!
so, whats next? obviously the main gripe is that it uses non-standard encoding. a tool that converts regular d64s to transwarp encoded ones should be easy to do, maybe use >35 tracks for the extra space needed. if u want, hit me up on irc, wouldnt mind writing a crossplatform tool like that.
and of course I want a nosound option :) |
| |
Copyfault
Registered: Dec 2001
Posts: 478 |
The screenshots suggest that the effective loading speed depends on the video format, with standard PAL being the fastest.
As I only have a standard PAL C64 I'm not able to do comparisons of all the different speeds on the real deals. If my assumption is correct: what's the reason behind it?
And what iAN said: a brief summary of the "ingredients" you mixed in this uber-tasteful code-cocktail would be absolutely nice :) |
| |
Krill
Registered: Apr 2002
Posts: 2982 |
Quoting Burglarand of course I want a nosound option :) Transwarp respects the MSGFLG = $9d setting. That is, when not loading in direct mode, from a running program, there is no sound and no flashing. =)
As for a converter, i guess some script magic with the upcoming cc1541 version would do, no? :) |
| |
Krill
Registered: Apr 2002
Posts: 2982 |
Quoting CopyfaultThe screenshots suggest that the effective loading speed depends on the video format, with standard PAL being the fastest. No, not at all. The "challenge" bit on NTSC in the GIF loads at 50x. The Dawnfall/NTSC bit merely illustrates that 50x is max speed, but not average. (And Dawnfall is one of the few one-filed demos to run flawlessly on NTSC, so...)
Loading speed is mostly depending on track zone. 1-17 is fastest, then it gets progressively slower on the upper track zones, as data on them is less dense.
Quoting CopyfaultAnd what iAN said: a brief summary of the "ingredients" you mixed in this uber-tasteful code-cocktail would be absolutely nice :) I thought iAN was mostly focusing on the challenge, but i can cook up a semblance of a white paper explaining things. =) |
| |
Jammer
Registered: Nov 2002
Posts: 1336 |
In general, is data preconverted that it doesn't have to be performed in runtime in 1541's ram? I'm total layman here, so my apologies :D |
| |
Copyfault
Registered: Dec 2001
Posts: 478 |
Quoting KrillQuoting CopyfaultThe screenshots suggest that the effective loading speed depends on the video format, with standard PAL being the fastest. No, not at all. The "challenge" bit on NTSC in the GIF loads at 50x. The Dawnfall/NTSC bit merely illustrates that 50x is max speed, but not average. (And Dawnfall is one of the few one-filed demos to run flawlessly on NTSC, so...)
Loading speed is mostly depending on track zone. 1-17 is fastest, then it gets progressively slower on the upper track zones, as data on them is less dense. Makes sense! Thanks for the hints, got a bit confused after seeing the sceendumps ;)
Quoting KrillQuoting CopyfaultAnd what iAN said: a brief summary of the "ingredients" you mixed in this uber-tasteful code-cocktail would be absolutely nice :) I thought iAN was mostly focusing on the challenge, but i can cook up a semblance of a white paper explaining things. =) Oops, maybe I misinterpreted what iAN wrote... but somthing white paperish would be extremly awesome. |
| |
iAN CooG
Registered: May 2002
Posts: 3204 |
I was just wondering how to load a usr file, usually you need to add ,U after the filename, I wasn't aware you had to load the standalone loader for these, as there was no instructions whatsoever. Some docs should be added to the release.
All I could determine is that ALL files just link to the same loader on track 18,16 and the bytes after the file name in the directory entries have "TW" plus the actual parameters to load the encoded files. Don't validate the d64s as it's just garbage for normal DOS. |
| |
Krill
Registered: Apr 2002
Posts: 2982 |
Quoting JammerIn general, is data preconverted that it doesn't have to be performed in runtime in 1541's ram? I'm total layman here, so my apologies :D Data is encoded differently. Plain Commodore GCR encodes 4 bytes raw to 5 bytes on disk, Transwarp encodes 3.5 bytes raw to 5 bytes on disk. (Thus only 223 = $df instead of 256 bytes per block, the 224th byte is the checksum.)
One trick is to encode those 3.5 bytes using a subset of plain Commodore GCR, such that it works just fine with d64 and regular transfer/copy solutions. Part of that trick is that decoding a GCR byte drive-side just takes a table lookup (4 cycles). =) |
... 162 posts hidden. Click here to view all posts....
|
| Previous - 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | ... | 18 - Next |
