| |
Oswald
Registered: Apr 2002
Posts: 5017 |
drivecoding
Hi people!
I have looked for info on the topic with google, but I think there is very little info on this out there. Anyone can post some useful links?
other questions:
- anyone can give me a sourcecode which would upload any kind of prg to the drive, and execute it ?
- why atn cant be used to send bits ?
- where is the entry point in the drive rom of the soft reset routine?
|
|
... 11 posts hidden. Click here to view all posts....
|
| |
Hoogo
Registered: Jun 2002
Posts: 102 |
Quote: it doesnt quite looks so in krill's source, he reads ATN IN without taking care of the state of DATA and CLK, but there is this fiddling with ATN OUT, even he cant explain why its there...
That ATN-Out in the floppy is not simply connected to the ATN-line like all the other in/outs... Damn, why can't I remember all the special things about it??
Krill's source looks like that to me: He wants to transfer bytes from Floppy to C64. The C64 alters ATN to ask for a new pair of bits. ATN-Out in the drive is set according to the state of the ATN-Line, so the DATA-Line works again and he can transfer without waiting for ATN 0. |
| |
cadaver
Registered: Feb 2002
Posts: 1153 |
Beware the wrath of NTSC power users if you go with using the ATN-line :) |
| |
raven
Account closed
Registered: Jan 2002
Posts: 137 |
Ok.. lets put some things in order.
Been awhile since i coded my loader but this is what i
remember:
First of all, this waits for ATN HI, not LO (as stated in
the source).
bit$1800
bpl *-3
Bit #7 is set to 1 when ATN signal on the bus is present.
Now, when a device gets the ATN signal from the 64 the hardware automatically responds to let the 64 know
it got the signal.
The response comes either in DATA or CLK (cant remember exactly which one).
In order to disable the auto-response, bit #4 of $1800
must be set to 1.
This is a must! right after the 64 sends an ATN HI signal,
you must set bit #4 to 1 or you'll get data corrupted.
Hope this helps :)
|
| |
anix
Account closed
Registered: Feb 2004
Posts: 35 |
maybe a bit off topic but i thought it might be appropriate...
anyone ever notice that digital world / samar makes the led on 1571 (others?) fade in and out while the demo runs? i thought it was neat :)
|
| |
Oswald
Registered: Apr 2002
Posts: 5017 |
raven: yep now krill's protocol is clear to me :)
anix: flashing the led is easy, it worx on 1541's too, altho you can just turn on/off the led with 1 bit, but if you -with changing periods of time- turn it on off fast, you can make it look brighter, darker. |
| |
anix
Account closed
Registered: Feb 2004
Posts: 35 |
oswald: i see, like pulse width modulation. |
| |
anix
Account closed
Registered: Feb 2004
Posts: 35 |
can anyone explain how the action/retro replay ramloader works? or perhaps a url to the AR sourcecodes to read... |
| |
Krill
Registered: Apr 2002
Posts: 2839 |
the ar loader fetches all sectors of a track and sends them over to the c64, into the ar's extra ram, undecoded (afair). only there, they are decoded and copied to the correct locations in the c64's mem. the most impressive thing with that loader is the transfer protocol, syncing by adding a cycle or not each 4 transferred bytes. but what exactly do you want to know with that loader? i once re-coded it btw to work without any extra memory, still with a track buffer on the c64 side. but there is a way to get around wasting $1500 bytes of memory. though, haven't applied it to that ar-like loader. i used such a technique in my newer irq loaders, check fixup#$00 for sources. fixup#$01 will be released when i find some more spare time for boring tasks like copypasting better routines to exisiting loaders ;) |
| |
Count Zero
Registered: Jan 2003
Posts: 1821 |
Krill explained it nicely.
The CRC decoding is indeed done on the c64 side. Still, the drivecode is pretty huge and even a single block file requires reading and transfer of a whole track ..
l8r
Count Zero/CyberpunX/SCS*TRC |
| |
Krill
Registered: Apr 2002
Posts: 2839 |
count zero: not with the approach i use. it scans a track for the needed sectors on the drive side, then fetches and transfers only those sectors.
it's ages ago since i had a look at that ar loader and my copy of it, still i think this technique can be applied to it. and it's not noticeably slower, since you need only one revolution to scan the sector links. and it's faster for the first and last track of a file, and faster for files with only a few blocks. the drive ram, however, might not be large enough for an updated ar loader, i still have to evaluate that. |
| Previous - 1 | 2 | 3 - Next |
