| |
Raistlin
Registered: Mar 2007
Posts: 557 |
File Write During A Demo
So, I want to be able to write a small file out in the middle of my demo ... ideally without interrupting the IRQ music and other stuff that's playing.
When I try to do that, though, the file ends up corrupt.
Is there a good way to do this..?
I'm of course using the Kernal functions FFBA, FFBD, FFD8. And then FFD5 to try to load back.
Loading seems fine - but saving is corrupt..
If all else fails I guess i need to fade the music down and pause interrupts............ |
|
| |
cadaver
Registered: Feb 2002
Posts: 1153 |
If you want interrupts running, you need custom drivecode, as with loading. It's easiest if you already have preallocated the file from the disk, so you don't need to use the drive ROM routines for sector allocation, or doing it yourself. Receive the file data from C64 using your custom protocol, then write to the preallocated sector(s) using jobcode $90.
See MagerValp's ULoad3 for inspiration, it supports exactly this.
ULoad Model 3 release 1 |
| |
Raistlin
Registered: Mar 2007
Posts: 557 |
Ah, haha, thanks - made by a G*P member too... I guess I should’ve asked first on the secret internal channel ... oops :-)
Thanks for the help! |
| |
Krill
Registered: Apr 2002
Posts: 2839 |
You can actually save a file using KERNAL routines just fine while playing music with an interrupt. This might require calling the lower-level OPEN and CHROUT and other calls with some $dd00 polling in between, but interrupt variance is somewhere at 30 rasterlines, but that should not be audible for most (not all) tunes.
Of course, a couple of zeropage and lowmem variables need to be set correctly, and sprites disabled where the mainline code runs.
But, pray tell, why do you need to write data to disk in the middle of a demo? :) |
| |
Adam
Registered: Jul 2009
Posts: 321 |
Quoting KrillBut, pray tell, why do you need to write data to disk in the middle of a demo? :)
yeah, it has caught my attention too :) |
| |
Raistlin
Registered: Mar 2007
Posts: 557 |
"why do you need to write data to disk in the middle of a demo? :)"
Maybe it's the world's first fuzzy logic learning demo on C64? Or we made FaceSwap work in realtime on C64 using, umm, the LightPen (and probably a really bright torch)? |
| |
Adam
Registered: Jul 2009
Posts: 321 |
Quoting Raistlin"Or we made FaceSwap work in realtime on C64 using, umm, the LightPen (and probably a really bright torch)?
LOL. make it so! |
| |
algorithm
Registered: May 2002
Posts: 702 |
Ram permitting. perhaps keep a buffer somewhere with the data, and then shuffle around per part to keep it non-overwritten, then utilise this data during the demo parts.
You can then at the end of the demo do a single write to disk if need be. |
| |
Oswald
Registered: Apr 2002
Posts: 5017 |
one of my demos counts how many time it has been run, by writing to disc, and displays the # on startup :P |
| |
Krill
Registered: Apr 2002
Posts: 2839 |
Quoting Oswaldone of my demos counts how many time it has been run, by writing to disc, and displays the # on startup :P It probably writes to disk at start-up, with all KERNAL variables intact and no music running. Entirely different beast. |
| |
bubis
Account closed
Registered: Apr 2002
Posts: 18 |
The Plus/4 port of Bitfire has a save routine for C64 too. It works fine during interrupts, etc.
https://github.com/dotscha/bitfire/releases
"Pet's Rescue" uses Bitfire and this routine on Plus/4 for saving high scores. |
| |
AlexC
Registered: Jan 2008
Posts: 293 |
Quoting KrillBut, pray tell, why do you need to write data to disk in the middle of a demo? :)
Sounds like a demo copy protection scheme to me ;) |
