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 > running code in the drive
2003-03-06 09:12
Oswald

Registered: Apr 2002
Posts: 5017
running code in the drive

Hi guys!

I would like to do calculations using the drive's cpu, but I am a lamer in drivecoding :)

can anyone help me out with a source code of:

1. a code->drive transfer routine
2. a byte send/receive routine on the drive/c64 side

preferably the send/rcv routine would survive sprites, irqs, etc :)

thanks in advance

Oswald
 
... 3 posts hidden. Click here to view all posts....
 
2003-03-06 13:23
MagerValp

Registered: Dec 2001
Posts: 1055
Quote: oh well, I >knew< I wont make this without learning to code the drive, it would have been too nice if some1 could help with sources :) thanx for the link anyway it really looks like something that will make me understand all this stuff :)

but still.. if anyone has already done this, sources are still welcome warmly :)


Those rants contains commented source to an IRQ loader. It has all the transfer protocols you need to communicate, and the source is easy to follow.
2003-03-06 21:32
Krill

Registered: Apr 2002
Posts: 2839
Alright... Oswald asked me for something like that aeons ago already. I'll release it with the next versions of my loaders. And yes, there actually are sprite-safe versions of them...
2003-03-06 23:03
raven
Account closed

Registered: Jan 2002
Posts: 137
Sprite-safe aka 2bit+ATN ;)
2003-03-07 08:58
Oswald

Registered: Apr 2002
Posts: 5017
yeah, actually yesterday I looked into master Krill's sources :) but the specialty of his sources to me, is that I simply dont understand a shit of it :) his tasm sources looks to me like reassembled stuff, self modding, sta *-blah&blahblah all the way :)

those rants arent quite useful to me, as the explained irq loader is not sprite/irq safe... and I dont want to figure out how to do that myself.. yes I am lazy, yes I dont want to learn drivecoding :) I think I could extract the byte send/rcv routines from krill's loaders, but one thing is not clear for me.. how would I tell the drive wether I want to send or rcv ?:) anyway krill saved the day.. I have also sent him an email about this yesterday :)

thanx Krill, and others :)
2003-03-07 09:30
cadaver

Registered: Feb 2002
Posts: 1153
There shouldn't be anything spr/irq-unsafe in the 1st (1-bit) covertbitops loader, except that the diskdrive side can't be interrupted while sending a byte? Of course, it'll be slow..
2003-03-07 09:32
cadaver

Registered: Feb 2002
Posts: 1153
Anyway, based on the problem you're trying to solve, and even as it's not about loading at all, the c64 & drive must communicate using some beforehand known way (protocol). For example, the typical fastloader is:

<C64 sends fixed amount of bytes - filename>
<1541 sends the bytes within the file, and EOF/errorcode so that C64 knows when to stop reading)
<repeat ad infinitum>
2003-03-07 17:26
raven
Account closed

Registered: Jan 2002
Posts: 137
@cadavar:

1bit will be too slow for what Oswald needs.
2bit with ATN is fast & completely safe with any effect, as long as you dont write to $dd00 without ANDing it first (like some VIC routines do).
2003-03-08 00:38
6R6

Registered: Feb 2002
Posts: 244
Why does 2bit-ATN only work with one drive ?
Atleast, thats what Krill's sources say.

(Has it to do with the c64 only one having ATN out?)

-glennrg
2003-03-08 01:09
Stryyker

Registered: Dec 2001
Posts: 465
when ATN is activated all serial devices listen. If you hit some magical sequence then the other devices (perhaps always?) will be setting serial data too which the C64 will try to read. That is why ATN free load systems can be safe with multidevice systems.
2003-03-15 17:25
Krill

Registered: Apr 2002
Posts: 2839
Hmm I already coded some new parts using drive code and rather fast transfer protocols sending things like 200 by 3 bits over to the c64 in the lower border, each frame. Now the problem with them is that they need to be _very_ customized to achieve this speed, so in the end one must fully understand the whole deal to optimize it that much. When I will some time manage to release some stuff like that as stand-alones, those solutions will most probably be quite generic, i.e. quite slow in this case. Maybe I should also write some tutorials for them mags on things like that... ;)
Previous - 1 | 2 - 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
mutetus/Ald ^ Ons
Jetboy/Elysium
Bieno/Commodore Plus
kbs/Pht/Lxt
jmin
CreaMD/React
Mason/Unicess
t0m3000/ibex-crew
Guests online: 233
Top Demos
1 Next Level  (9.8)
2 Mojo  (9.7)
3 Coma Light 13  (9.7)
4 Edge of Disgrace  (9.6)
5 Comaland 100%  (9.6)
6 No Bounds  (9.6)
7 Uncensored  (9.6)
8 The Ghost  (9.6)
9 Wonderland XIV  (9.6)
10 Bromance  (9.6)
Top onefile Demos
1 It's More Fun to Com..  (9.8)
2 Party Elk 2  (9.7)
3 Cubic Dream  (9.6)
4 Copper Booze  (9.5)
5 Rainbow Connection  (9.5)
6 TRSAC, Gabber & Pebe..  (9.5)
7 Onscreen 5k  (9.5)
8 Wafer Demo  (9.5)
9 Dawnfall V1.1  (9.5)
10 Quadrants  (9.5)
Top Groups
1 Oxyron  (9.3)
2 Nostalgia  (9.3)
3 Booze Design  (9.3)
4 Censor Design  (9.3)
5 Crest  (9.3)
Top Webmasters
1 Slaygon  (9.7)
2 Perff  (9.6)
3 Morpheus  (9.5)
4 Sabbi  (9.5)
5 CreaMD  (9.1)

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