| |
lft
Registered: Jul 2007
Posts: 369 |
GCR decoding on the fly
Here's how to do it:
http://linusakesson.net/programming/gcr-decoding/index.php |
|
... 149 posts hidden. Click here to view all posts....
|
| |
Krill
Registered: Apr 2002
Posts: 2982 |
Quoting tlrCouldn't the $dd00 bank bits just be kept 00? Then switching can be done via $dd02.
Not sure about the possibility of your idea, but the $dd02 trick is often used already so that the VIC bank can be set by a simple lda #bank:sta $dd00 in IRQ handlers. This prevents possible visual glitches by IRQs hitting between loader-executed lda value/sta $dd00 (and saves masking overhead, too). So setting $dd02 from user code is forbidden, while in your idea, setting $dd00 is. |
| |
doynax
Account closed
Registered: Oct 2004
Posts: 212 |
Quoting KrillYes, this explains everything. :) Indeed. That explanation actually makes sense to me.
Quoting tlrCouldn't the $dd00 bank bits just be kept 00? Then switching can be done via $dd02. Why didn't I think of that?
The SLO keeps zeroes and the SRE doesn't appear reach the least-significant bits with any ones. I just ran a quick test by poking at $dd02 and I can't see any VIC bank switching during loading.
For the record the basic transfer loop looks something like this: ;(y = %00000100)
;16 cycles, raises ATN
and #%01100000 ;0ba00000
cmp $00,y
sty $dd00
slo $dd00 ;cba010--
;16 cycles, lowers ATN
inx
ror ;dcba010-
lsr ;0dcba010
cmp #%01000000
arr #%00111000 ;d00cba00
sre $dd00 ;dfecba--
;16 cycles, raises ATN
alr #%11111100 ;0dfecba0
sta merge+1
sty $dd00
slo $dd00 ;g-------
;16 cycles, lowers ATN
and #%10000000 ;g0000000
merge: adc #%00000000 ;gdfecbah
sta sector,x
sre $dd00-$04,y ;-ba----- I wonder if it would be possible to get the bits through in the right order without sacrificing performance.. |
| |
lft
Registered: Jul 2007
Posts: 369 |
Quoting tlr
Couldn't the $dd00 bank bits just be kept 00? Then switching can be done via $dd02.
No, unfortunately that won't work. When reading dd00, the bits still reflect what is on the lines. If bank 1 is selected in this way, the two least significant bits in dd00 were written as 00 and the bits in dd02 were written as 01. This makes the lines high-low, and so when you read dd00 you get 10. Now suppose you rotate right (the same applies for bank 2 if you rotate left). Even if you can control the bit that gets shifted in from the left to be a zero, this will write 01 to dd00. The lines are now high-high, and the wrong bank has been selected. |
| |
tlr
Registered: Sep 2003
Posts: 1791 |
Good point. Then RMW doesn't work unless the bit is forced low by the instruction, like the lsb when using SLO. |
| |
Krill
Registered: Apr 2002
Posts: 2982 |
Quoting doynaxI wonder if it would be possible to get the bits through in the right order without sacrificing performance..
This is one of the reasons i do this peculiar nibble-wise intermediate storing as mentioned by lft in his blog article. Since i have the block data in two pages of GCR nibbles in the drive RAM, i can do a table lookup (table size 32 bytes) while transferring, getting the bits nicely swapped and inverted into $1800 so that the computer receives them in the correct order and orientation. No extra table is needed on the computer side, thus yielding a minimum resident code size of $0100 bytes.
This, of course, has a few drawbacks, as in a few more cycles per byte and no easy possibility to checksum the data during transfer. |
| |
HCL
Registered: Feb 2003
Posts: 728 |
Quote:So setting $dd02 from user code is forbidden, while in your idea, setting $dd00 is. In my loader system, it's the other way around. Setting $dd00 in user code is forbidden. The loader uses $dd00 and the user uses $dd02, though it's still possible to use $dd00 in limited ways if you really have to..
@Doynax: Interesting transfer loop, do you really get out what you want there? :P. Gotta check it once again :). |
| |
Krill
Registered: Apr 2002
Posts: 2982 |
Quoting doynaxI wonder if it would be possible to get the bits through in the right order without sacrificing performance..
Hmm, looking at it a liitle longer, your problem is not only getting the bits over the wire in the right order, but also through your funky receive logics? :)
I guess it should be easy for you to simply shuffle the bits around on the disk so that it arrives in computer memory in the correct order. And in that case, no problem, is there? I mean, you sacrificed other general-use requirements (VIC bank) before, so.. :) |
| |
doynax
Account closed
Registered: Oct 2004
Posts: 212 |
Quoting tlrGood point. Then RMW doesn't work unless the bit is forced low by the instruction, :(
Quoting HCLInteresting transfer loop, do you really get out what you want there? :P. Gotta check it once again :). It is loading a compressed executable so I'd be somewhat surprised if it works despite dropping bits ;)
Quoting KrillI guess it should be easy for you to simply shuffle the bits around on the disk so that it arrives in computer memory in the correct order. And in that case, no problem, is there? I mean, you sacrificed other general-use requirements (VIC bank) before, so.. :) Pretty much though it is a tad inconvenient. Still, if a bit of pre-processing saves me a byte or a cycle I'm willing to do it.
The saving grace is that it's easy to reverse the transformation when uploading bytes to the drive, e.g. when saving, and thankfully the EOR checksum shouldn't care. |
| |
Danzig
Registered: Jun 2002
Posts: 441 |
Quote: Ah, for once i think i understand :). LFT, what is that book you have? everyone should have it ;).
Maybe this is the right moment: I still got the book "Das große Floppy Buch 1541" from Data Becker for sale.. Anyone? :D |
| |
chatGPZ
Registered: Dec 2001
Posts: 11391 |
protip: a pdf of that one is at spiros website =P |
| Previous - 1 | ... | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 - Next |
