| |
Krill
Registered: Apr 2002
Posts: 2982 |
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....
|
| |
BiGFooT
Registered: Mar 2002
Posts: 33 |
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: 11391 |
join #easyflash on freenode and talk to Unseen i say =) |
| |
Krill
Registered: Apr 2002
Posts: 2982 |
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: 1105 |
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: 2982 |
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: 478 |
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... |
| |
chatGPZ
Registered: Dec 2001
Posts: 11391 |
that calls for some new test programs :) |
| |
Krill
Registered: Apr 2002
Posts: 2982 |
Quoting Copyfaultdoes 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... Afaik, it's reliable on all 6502 (and variants with illegals) systems without DMA interference. But yes, what Groepaz said. :)
And of course i optimised only as much as needed. =) (And Y is the buffer number and thus not a constant.) |
| |
Copyfault
Registered: Dec 2001
Posts: 478 |
Yes, y is the buffer no. (and thus not const), you wrote that in your post... but the SHX was too tempting so I dared to share the thought;) |
| |
Oswald
Registered: Apr 2002
Posts: 5095 |
transfering while stepping track, awesome idea :) remembers me when I tried to "stream" load vector anim, and it always stopped for track stepping haha. |
| Previous - 1 | ... | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | ... | 18 - Next |
