Log inRegister an accountBrowse CSDbHelp & documentationFacts & StatisticsThe forumsAvailable RSS-feeds on CSDbSupport CSDb Commodore 64 Scene Database
You are not logged in - nap
CSDb User Forums


Forums > C64 Coding > GCR decoding on the fly
2013-03-31 12:46
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....
 
2013-04-23 19:01
doynax
Account closed

Registered: Oct 2004
Posts: 212
Thanks for the info!

Quoting tlr
Graham claims 280-320 rpm. TNT has only seen 295-305 rpm.
The drives I've encountered have all been very close to 300 rpm, even over time (i.e since '85 or so).
Ouch. Speed-zone 3 written at 320 RPM and read back at 280 is only 22 1/4 cycles per byte.

Quoting tlr
That said, it should be possible to allow three 0's in a row as long as the data rate (+ jitter) coming from the disk is strictly faster than the bit clock in the drive in all situations.
This requires you to write at a higher bit rate than you read.
Interesting. So with proper authoring and a devilishly clever algorithm we might theoretically squeeze out 15 bits per 16-bit word of entropy.
2013-04-25 07:56
Krill

Registered: Apr 2002
Posts: 2982
My loader uses acceleration, too, originally suggested by Graham.
.define MINSTPSP                 $18 ; min. r/w head stepping speed on 1541/41-C/41-II/70/71/71CR
This is a value which should be safe even on old 1541s. (The unit is 256 cycles per half-track, so the same as the original firmware would write to a timer hi-byte.)
.define MAXSTPSP                 $10 ; max. r/w head stepping speed on 1541/41-C/41-II/70/71/71CR
These figures have been used for years now, without any negative reports so far.
.define STEPRACC                 $1c ; r/w head stepping acceleration on 1541/41-C/41-II/70/71/71CR
Acceleration is above figure, added once every timer lo-byte underflow. See source for details ;)
2013-04-25 08:07
Krill

Registered: Apr 2002
Posts: 2982
Quoting doynax
- Which illegal opcodes, if any, may safely be relied upon?
Same as for the 6510, minus SAX. SAX is reportedly not working on HCL's 1541 clone (using a Synertec 6502 clone), plus i suspect it to be generally a bad idea when used on the bus port bits. Data and clock might be updated at different times within a cycle. (But this might not be an issue after all.)

Quoting doynax
As an aside how am I supposed to handle multiple IEC devices on the bus in a two-bit IRQ loader? My best idea so far is to manually detect and handle as many of them as possible by installing code to put them into tight ATN-acknowledgement loops to avoid blocking the DATA line, but presumably that will fail miserably on many devices.
This is what i will add to my loader, too. First tests worked just fine with loading from any drive in a 4-units daisy chain using standard CBM cables. I do have one or the other cycle more in the transfer loop compared to your ultra-tight fixed VIC bank approach, though. :)
The actual problem though is that the other drives have to be somewhat protocol-savvy to correctly decide when to reset, as i do use a watchdog approach so you can safely reset the host computer at any time without locking up your drives, or you can cart-freeze and implicitly uninstall by using standard KERNAL drive access. (Not all C-64s issue a reset signal via serial.)
2013-04-25 10:39
doynax
Account closed

Registered: Oct 2004
Posts: 212
Quoting Krill
My loader uses acceleration, too, originally suggested by Graham.
.
.
.
Acceleration is above figure, added once every timer lo-byte underflow. See source for details ;)
Thanks for the timing data!
I realize that it isn't much of an issue in demos but in my current project I'm forced to do an awful lot of random-access.

Quoting Krill
Same as for the 6510, minus SAX. SAX is reportedly not working on HCL's 1541 clone (using a Synertec 6502 clone), plus i suspect it to be generally a bad idea when used on the bus port bits. Data and clock might be updated at different times within a cycle. (But this might not be an issue after all.)
Damn :(
As you've probably guessed my transfer loop relies on SAX to mask out the ATN acknowledgment.

Oh, well.. I suppose that extra "DCR" accommodation cycle should free up some space.

Quoting Krill
This is what i will add to my loader, too. First tests worked just fine with loading from any drive in a 4-units daisy chain using standard CBM cables.
Good to know I'm at least on the right track.
Have you encountered any IEC devices where this scheme won't work? Personally I have no experience with printers or modems or anything besides floppy drives really.

Quoting Krill
The actual problem though is that the other drives have to be somewhat protocol-savvy to correctly decide when to reset, as i do use a watchdog approach so you can safely reset the host computer at any time without locking up your drives, or you can cart-freeze and implicitly uninstall by using standard KERNAL drive access. (Not all C-64s issue a reset signal via serial.)
Thanks for the heads up! The reset signal not being reliable is precisely the kind of thing to catch the inexperienced drive coder by surprise.

Unfortunately I rather trash all of RAM, including using the full stack and zero-page as buffers, so routing a hardware timer interrupt through the ROM vectors may take a bit of juggling.
2013-04-25 13:45
Krill

Registered: Apr 2002
Posts: 2982
Quoting doynax
I realize that it isn't much of an issue in demos but in my current project I'm forced to do an awful lot of random-access.
Yes, and this is precisely where acceleration comes in handy.

Quoting doynax
As you've probably guessed my transfer loop relies on SAX to mask out the ATN acknowledgment.
If my suspicion about different timing on different bit positions doesn't hold nor matter, it's alright to demand genuine C= gear. :)

Quoting doynax
Have you encountered any IEC devices where this scheme won't work? Personally I have no experience with printers or modems or anything besides floppy drives really.
Me neither, but i think it's okay to ignore those. I don't see why anybody should use printers and modems and whatnot on the serial bus of a C-64 these days. Those who do probably care more for GEOS rather than games or even demos.

Quoting doynax
Thanks for the heads up! The reset signal not being reliable is precisely the kind of thing to catch the inexperienced drive coder by surprise.
Oh, it works or doesn't quite reliably. Just that some ASSY #s do and some don't pull serial reset out low upon host reset.

Quoting doynax
Unfortunately I rather trash all of RAM, including using the full stack and zero-page as buffers, so routing a hardware timer interrupt through the ROM vectors may take a bit of juggling.
Same in my loader, there's basically not a single unused byte. But installing your own interrupt handler for watchdog purposes is not that difficult, you basically just run an "execute code in block" job and make sure that all other job codes are ineffective. Again, see source for details. :)
2013-04-25 13:52
Oswald

Registered: Apr 2002
Posts: 5095
that watchdog feature can kill your trackmo if you starve the loader's need for cpu for a few frames. ie, timer interrupt will trigger after a few frames thinking the machine has been reset, and will reset the drive.
2013-04-25 16:49
tlr

Registered: Sep 2003
Posts: 1791
Quoting Krill
Quoting doynax
- Which illegal opcodes, if any, may safely be relied upon?
Same as for the 6510, minus SAX. SAX is reportedly not working on HCL's 1541 clone (using a Synertec 6502 clone), plus i suspect it to be generally a bad idea when used on the bus port bits. Data and clock might be updated at different times within a cycle. (But this might not be an issue after all.)

Do you have anything to back that timing suspicion up?
I can't see how the bit timing could be different all the way out to the port pins. Surely there must be at least one pipe line step through the VIA so even if there is a difference in timing on the bus out from the 6502 it will be reclocked.
2013-04-25 18:43
chatGPZ

Registered: Dec 2001
Posts: 11391
also MiST from visual6502 actually did all the tests in a 1541 - with no sign of special behaviour.
2013-04-25 20:41
WVL

Registered: Mar 2002
Posts: 903
Quote: that watchdog feature can kill your trackmo if you starve the loader's need for cpu for a few frames. ie, timer interrupt will trigger after a few frames thinking the machine has been reset, and will reset the drive.

Had that problem aswell, was really happy I could pinpoint it with some help from Krill.. We could've known you could 'starve' a loader? :)
2013-04-25 20:54
Krill

Registered: Apr 2002
Posts: 2982
Yes, well, that was my fault mainly. I knew that the watchdog timeout is max. 65536 cycles, without any trick known to me to extend it without serious overhead or other repercussions, and at some point i noticed that this would be the problem.
Previous - 1 | ... | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 - Next
RefreshSubscribe to this thread:

You need to be logged in to post in the forum.

Search the forum:
Search   for   in  
All times are CET.
Search CSDb
Advanced
Users Online
Guests online: 60
Top Demos
1 Next Level  (9.7)
2 13:37  (9.7)
3 Coma Light 13  (9.6)
4 Edge of Disgrace  (9.6)
5 Mojo  (9.6)
6 Uncensored  (9.6)
7 The Demo Coder  (9.6)
8 Comaland 100%  (9.6)
9 What Is The Matrix 2  (9.6)
10 Wonderland XIV  (9.5)
Top onefile Demos
1 Layers  (9.7)
2 Cubic Dream  (9.6)
3 Party Elk 2  (9.6)
4 Copper Booze  (9.6)
5 Dawnfall V1.1  (9.5)
6 Rainbow Connection  (9.5)
7 Morph  (9.5)
8 Libertongo  (9.5)
9 Onscreen 5k  (9.5)
10 It's More Fun to Com..  (9.5)
Top Groups
1 Booze Design  (9.3)
2 Oxyron  (9.3)
3 Performers  (9.3)
4 Triad  (9.3)
5 Censor Design  (9.3)
Top Original Suppliers
1 Derbyshire Ram  (9.7)
2 Fungus  (9.3)
3 Black Beard  (9.2)
4 Baracuda  (9.2)
5 hedning  (9.1)

Home - Disclaimer
Copyright © No Name 2001-2025
Page generated in: 0.05 sec.