Re: Fast GCR decoding?

From: A. Fachat <afachat_at_gmx.de>
Date: Sun, 13 Jan 2013 21:26:02 +0100
Message-ID: <13c35971dc3.279a.b4d1f2b66006003a6acd9b1a7b71c3b1@gmx.de>
The dual drives do it with a separate gcr rom. Look for that on my 
petindex site http://www.6502.org/users/andre/petindex
(sorry, only on mobile device right now)
André


Gesendet mit AquaMail für Android
http://www.aqua-mail.com


Am 13. Januar 2013 17:47:10 schrieb Gerrit Heitsch <gerrit@laosinh.s.bawue.de>:
> On 01/13/2013 05:27 PM, silverdr@wfmh.org.pl 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?
>
> I thought GCR is a 10/8 encoding, meaning you get 10 Bits off the disk
> which translate to 8 Bits. That would mean you need a 1 KByte table to
> do decoding full bytes by lookup table.
>
> If you do it by nibble, you need a table with 32 entries.
>
>   Gerrit
>
>
>
>        Message was sent through the cbm-hackers mailing list



       Message was sent through the cbm-hackers mailing list
Received on 2013-01-13 21:00:02

Archive generated by hypermail 2.2.0.