| |
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....
|
| |
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. |
| |
Krill
Registered: Apr 2002
Posts: 2982 |
Quoting Oswaldtransfering while stepping track, awesome idea :) remembers me when I tried to "stream" load vector anim, and it always stopped for track stepping haha. I think stepping itself is not to blame for the hiccup. =)
The normal* stepping duration in Transwarp is $90 (144) bycles, that's a fifth (18%) of a revolution, or 4 sectors. So for a regular interleave 4 loader, that means just one missed block. Plus they would use shorter stepping times, usually around $30-$40 bycles. (The $90 setting was determined experimentally, it was the safest setting across all test drives.)
However, the loader you used probably did not load blocks out of order, and then the mean waiting time for a block after trackstep is half a revolution, a tenth of a second, and the worst case double that time.
* With secondary addresses >= 2, the track step times for either or both half-track steps can be increased for drives with particularly long settle times or slow steppers, in order to counter stepping-related loading problems.
Bits 3..1 increase the overall stepping time: +2 = $a0, +4 = $b0, +6 = $c0, ..., +14 = $0100 bycles.
Bits 7..4 increase the time between first and second half-track step: +16, +32 etc. would shift the relation further towards the overall stepping time.
So loading a Transwarp file with ,8,255 would be pretty slow. =)
Having the secondary address take on more meanings than just loading to BASIC start or saved address, i was slightly dismayed to see BiGFoot use ,8,8 out of an old learned habit. =D |
| |
Count Zero
Registered: Jan 2003
Posts: 1940 |
https://codebase64.org/feed.php
Tap tap tap ... oh, thats the sound of my drive sometimes recently - not the frequency of your codebase submissions! :) |
| Previous - 1 | ... | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | ... | 18 - Next |
