Re: Fast GCR decoding?

Hello Groepaz,

Monday, January 14, 2013, 9:25:18 PM, you wrote:

> On Sunday 13 January 2013, you wrote:
>> On 2013-01-13, at 07:30, Groepaz wrote:
>> >> Is there anything known that would be still faster? AFAIU
>> >> ProfessionalDOS does it faster but with help from its hardware. Anyone
>> >> heard of faster than 1571 but pure software based decoding?
>> > 
>> > thats basically just an eprom with an huge lookup table though (the cbm
>> > dual drives do it in a similar way)
>> 
>> Like putting bits on address lines and reading the outcome from data lines?
>> It could be an option, depending on how "huge" the table has to be... It
>> can't be 40 bits so some bit fiddling has to be done anyway.
>> 
>> Also I found a post by Jim Drew on Lemon64, where he admitted to have
>> decoded GCR in real time thanks to extra RAM on the SC+ card and "creative
>> tables". Since he's got "only" 8K of extra RAM, he had a hard limit on the
>> size of the table. If I fit into 8K and have GCR decoded in RT I can't
>> have any more wishes ;-) How is it done in dual drives?

> he didnt do it in "realtime" (as in: decode on the fly in a single revolution)
> - he did pretty much the same as AR did (and everyone else really). you can
> generally assume its like that when jim starts babbling =P


Hey! - I'm claiming grumpy old fart status here, Groepaz :P :)

I must confess, I can't see how GCR>binary conversion can possibly be
done by the 6502 in real time, as the data is being hoovered off the
R/W head, without a MASSIVE indexed table. About the only way that
"COULD" be claimed if it was done of the GCR-ENCODED cached track, as
it was being squirted out to the C64. The necessary comms delays would
give the CPU sufficient cycles to convert the data "on the fly".
Perhaps that was what Jim was referring to.

I've had a preliminary look at the DolphinDOS ROM (I'll post the
binary a bit later on).

Normal CBM DOS ROMS in a 1541 sit at $C000-$FFFF, with RAM at
$0000-$07FF (ROM code starts at $C100). I/O is at $1800, and $1C00 (in the form of 2 6522 VIA's)

DolphinDOS adds RAM at $8000 through $9FFF, and replaces and extends the CBM DOS
ROMS - and now resides from $A000 through $FFFF.


With DolphinDOS enabled, the $C100>$FFFF (which corresponds to the normal
1541 ROM address space) is almost exactly standard, save redirects to
a jump table at $A000 for specific routines,and code spillover from
the new ROM area into $C000-$C0FF.

After the jump table are the specific routines for the augmented
parallel comms routines (which seem to initiate through IEC serial,
and do the bulk xfer via the parallel port - bit7 seems to be a test
for parallel port cable existence), and the caching drive read code.
There is a fair bit of code I haven't worked through yet after the
jump table that concerns itself with sector header assembly and
preparation, and sector handling in the augmented RAM area - and most significantly ALL the ROM space between
$B000 and $BE00 appears to be one big table. My guess would be a GCR
lookup table.
I haven't had a chance too look further (only had an hour or so
today).

Julian


       Message was sent through the cbm-hackers mailing list