| |
Krill
Registered: Apr 2002
Posts: 2825 |
Release id #197710 : Transwarp v0.64
General Q&A thread, also report problems and error logs here. |
|
... 162 posts hidden. Click here to view all posts....
|
| |
Peacemaker
Registered: Sep 2004
Posts: 243 |
i have no clue about fastloaders or loaders in general. maybe a stupid question. but any chance to get a very fast irqloader version of your loader (great work btw)for our demos? :)
greets |
| |
BiGFooT
Registered: Mar 2002
Posts: 31 |
Quote: I wonder... for the fallback standard-format loader, would there be any interest in support for a parallel connection?
Looking at my notes, it may well be this could turn out to load even faster than Transwarp-encoded files over serial.
Just dumping out my realistic opinion here:
For daily use? Not really. Parallel transfer was a good solution back in time for backup purposes and to speed up the damn slow serial transfer. I don't see the this advantage today. Casual collectors use the standard variants, a few old farts have speed/dolphin machines and drives but I don't see the value of it. A fast, reliable serial fastloader is the best and more than enough for everyone. If there is a way to support the not real "replacements" (*IEC, anything not Ultimate) that would be the best for every user.
On the other point, an even faster experimental tool will be amazed and praised but won't be widely used at all further than trying it out. |
| |
Krill
Registered: Apr 2002
Posts: 2825 |
Quoting BiGFooTA fast, reliable serial fastloader is the best and more than enough for everyone. Noted. :)
Quoting BiGFooTIf there is a way to support the not real "replacements" (*IEC, anything not Ultimate) that would be the best for every user. Yes, i've been thinking about adding a fallback for SD2IEC and the like, using block-read commands and decoding on the C-64 side.
But then i still don't like the idea of explicit SD2IEC support... would probably have patched the firmware to support Krill's Loader, Repository Version 184 in the meantime otherwise. =) |
| |
Count Zero
Registered: Jan 2003
Posts: 1820 |
I think parallel cables are too few in use and even spread nowadays. Even in the old times not many people had them equipped I'd say.
Of course would be interesting to see speed differences and all but I suppose the work to put into that is not well spend, hm? :) |
| |
BiGFooT
Registered: Mar 2002
Posts: 31 |
Quoting KrillYes, i've been thinking about adding a fallback for SD2IEC and the like, using block-read commands and decoding on the C-64 side.
But then i still don't like the idea of explicit SD2IEC support... would probably have patched the firmware to support Krill's Loader, Repository Version 184 in the meantime otherwise. =)
Don't sit upside-down on a horse... Nope, those devices firmware should support your "damn fast" loader as it was the case with Dreamload. In any other case kernal fallback will always work, no need to support it explicitly. With "support" I've meant that you can aid/help 'em out if necessary.
If it's a must and they don't bother with yours, then there is a dedicated fastloader for those users. Even building a custom AR/RR ROM with different fastloader options would be lovely but no one really care about it. At least I don't. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11100 |
join #easyflash on freenode and talk to Unseen i say =) |
| |
Krill
Registered: Apr 2002
Posts: 2825 |
Quoting BiGFooTEven building a custom AR/RR ROM with different fastloader options would be lovely but no one really care about it. At least I don't. Plan is to add Transwarp including fallback fastloader for standard format (and saver for Transwarp encoding) to tlr's Superfluid V0.7 at some point. Would you care about that? =) |
| |
Burglar
Registered: Dec 2004
Posts: 1031 |
Quoting Krillwould there be any interest in support for a parallel connection? yes! its fairly easy to solder and is supported by vice. main issue would be no 1541u support for that afaik.
im already using a parallel setup by default (with dolphindos), as u know |
| |
Krill
Registered: Apr 2002
Posts: 2825 |
Another size-coding trick, but it's quite obvious in hindsight and also not new. =)
Transwarp buffers block data of up to 21 * $1f = $028b bytes per track in drive RAM, which are then transferred while stepping to the next track.
These 21 buffers are scattered in drive RAM (in rather harmless regions so the custom code can return control to ROM after loading without a soft reset).
The buffer addresses are stored in a table of 21 bytes, that is, 16-bit addresses are packed into 8-bit entries.
The table looks like this:>8:0082 c0 11 51 71 91 02 b2 d2 03 23 43 63 83 a3 c3 e3
>8:0092 04 24 44 64 84 The encoded addresses are $00c0, $0110, $0150, etc.
So, an address from that table can be depacked like this:.8:0578 B7 82 LAX $82,Y; read address table entry
.8:057a A2 0F LDX #$0F ; hi-byte mask
[...]
.8:0586 8F 92 05 SAX $0592; buffer address hi-byte
.8:0589 29 F0 AND #$F0 ; lo-byte mask
.8:058b 8D 91 05 STA $0591; buffer address lo-byte Note that the 4:4 granularity is arbitrary. With the 2K RAM of a 1541, it could also have been 5:3 to encode addresses from $0000 to $07f8 in steps of 8. (But for sync time-outs with removed disks etc., the code requires a dummy buffer in unmapped address space somewhere between $0800 and $1000.) |
| |
Copyfault
Registered: Dec 2001
Posts: 466 |
Really nice!
Looking at this code fragment, I'm wondering wether SHX could be used to shave off another cycle (and two bytes)...
ldx $82,y ; read address table entry
lda #$f0 ; lo-byte mask
sax $0691 ; store lo-byte to buffer@$06xx
shx $0692-offset,y ; mask hi-byte with #$07 and store to buffer
Ok, depends on quite some things (first of all, buffer location at $0600 must be allowed and hi-byte may never go over $07, offset=y so it must be known,...), but what I find most interesting: does an SHX used on the drive's cpu reliably have this "&h+1"-masking going on? It has no RDY-line, so should be the case... |
| Previous - 1 | ... | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | ... | 18 - Next |
