| |
Thundax
Registered: Oct 2013
Posts: 4 |
Saving routines
Heyz,
I am trying to put a loader and saver in my codework for a game, but it's quite a challenge.
The loaders are no problem at all... They work fine.
The saver is a huge problem at the moment, though.
I need the saver to save files including the ability to overwrite files (for hiscores etc.). It would be great if it would be a fast loader and even better when it's also an irq-loader.
Here is what I tried:
- Plushdos 1-bit saver: Saving works fine (as the only save solution that works for me now), but overwriting a file isn't possible with this saver (also in the manual). I don't have a seperate scratch routine which works, so the saver isn't that useful when I can't overwrite any files.
- Plushdos 1/2-bit disksystem: Saving is only possible by tracks/sectors. I try to understand how tracks/sectors work, and I think I should be able to put the savefiles on fixed tracks/sectors, but I don't know how to edit the tracks/sectors of a file. Dirmaster has the ability to view the file properties but editing tracks/sectors doesn't work. I tried to use the BAM-editor, but I can't change/don't know how to change the tracks/sectors of a file. Beside of that I don't even know if the saver in the 2-bit disksystem can overwrite at all. So that's even a question.
- I tried basic IO kernal for saving, like on codebase: http://codebase64.org/doku.php?id=base:saving_a_file . I put this code 1-on-1 in C64 assembler and tried to run it. But nothing happens at all. Just a small second and it reaches the end of the code and saved nothing... Why isn't this even working?
- Googled a lot, but couldn't find anything additional useful for my problem.
Btw, I'm using an Ultimate II+, but that should run fine I guess.. Certainly with basic IO stuff...
So my main question:
How can I easily load and save (preferrable fast and irq) files with the ability to overwrite files? Preferrably by only filenames and without tracks/sector sh1t?
Hope some of you have an answer to this. It's driving me mad and takes me a couple of days now. I need to get this solved otherwise I can't release it at all... :(
Please answer in common simple easy accessible english :) I'm not a tech wizkid :P Sample routines or common loaders/savers with explanation which do the trick would be great instead of (deep) technical discussions which I don't understand.
Eventually on #C-64
Thanks in advance!
The one who gives me the working solution gets a free LED bouncing ball @X! :D
Grtz, Thundax |
|
| |
JackAsser
Registered: Jun 2002
Posts: 1987 |
I can help you with kernel save. Just implemented it in EotB. Please PM with a link to you code so that I csn see how your environment is. |
| |
Krill
Registered: Apr 2002
Posts: 2822 |
Quoting Thundax- Plushdos 1-bit saver: Saving works fine (as the only save solution that works for me now), but overwriting a file isn't possible with this saver (also in the manual). I don't have a seperate scratch routine which works, so the saver isn't that useful when I can't overwrite any files. Sending a scratch command to the drive is fairly easy, and it should also be possible to play a tune while doing that. (Interrupt delay is something like 30 or $30 rasterlines max., IIRC.)
I can help you set that up. But depending on what you want to save, the T/S approach might be ok, too. Maybe i should write that saver plugin for the new loader at some point. :) |
| |
MagerValp
Registered: Dec 2001
Posts: 1055 |
https://csdb.dk/release/?id=78121&show=summary#summary |
| |
Thundax
Registered: Oct 2013
Posts: 4 |
Thank you for your replies.
Jackasser: Thanks for messaging me. Awaiting your answer.
Krill: Thanks a lot for your help. It would be very cool if there comes out a new version of the fast 1-bit irq saver with overwrite function. :D
Magervalp: Thanks for the link. I already was looking at that one, but as far as I can see it only saves files by tracks/sectors and not even new files? I don't know how to work with tracks/sectors yet, and it's certainly not flexible. So I doubt if it's still a solution for me atm... :s
Myself: Well, found a bug in my code for the basic IO kernal save routine... That one works now, but it isn't a fastsaver neither an irq saver.. So that one is a last workaround if other options are out... :s |
| |
JackAsser
Registered: Jun 2002
Posts: 1987 |
Regarding save with overwrite just prepend with @0: like ”@0:name” as filename |
| |
Martin Piper
Registered: Nov 2007
Posts: 631 |
https://github.com/martinpiper/C64Public/blob/master/BerzerkRed..
SaveHiScore
IRQ saver used in Berzerk Redux.
Example drive init usage here
https://github.com/martinpiper/C64Public/blob/master/IRQDisk/Te.. |
| |
Moloch
Registered: Jan 2002
Posts: 2891 |
Not a good idea to use save with replace (@0:filename) as the patch from Commodore was only applied to newer models of the 1541 |
| |
JackAsser
Registered: Jun 2002
Posts: 1987 |
Quote: Not a good idea to use save with replace (@0:filename) as the patch from Commodore was only applied to newer models of the 1541
Oh dang! |
| |
oziphantom
Registered: Oct 2014
Posts: 478 |
It can easily be migtigated if need be. see https://www.atarimagazines.com/compute/issue65/save_with_replac..
Basically you either reset the drive, or if you have control over such things make sure all operations just before it, specify the drive number. So if you do load"0:yourfiles" you will be safe. There is a test program in above, not sure if you always have to do the 0: or if it is just before.
This needs to be tested.. off to get the old roms for testing.. |
| |
oziphantom
Registered: Oct 2014
Posts: 478 |
I can't get it to happen in VICE |
| |
chatGPZ
Registered: Dec 2001
Posts: 11092 |
but you would trust an atari mag? jeeez |
| |
oziphantom
Registered: Oct 2014
Posts: 478 |
Its from Compute! |
| |
chatGPZ
Registered: Dec 2001
Posts: 11092 |
you even expect me to not stop reading the url at "atari"? jeez
and as for the original topic - no, you really have to scratch before save, or you WILL run into problems sooner or later. actually the proper fail safe way would be:
- save new file with temporary name
- scratch old file
- rename new file |
| |
Danzig
Registered: Jun 2002
Posts: 428 |
Quote: you even expect me to not stop reading the url at "atari"? jeez
and as for the original topic - no, you really have to scratch before save, or you WILL run into problems sooner or later. actually the proper fail safe way would be:
- save new file with temporary name
- scratch old file
- rename new file
Pleez follow this advice! |
| |
Thundax
Registered: Oct 2013
Posts: 4 |
Thank you all for your replies!
I'll be working on them the coming few days... |
| |
Krill
Registered: Apr 2002
Posts: 2822 |
I think i'll fix either the Plushdos IRQ 1-bit saver or the 2-bit saver from Fixup #$00 to support save-with-replace.
So, do you have sprites while saving?
If not, i'll go for the 2-bit saver, as the source is there in the release (no need to dig out the older 1-bit saver source) and it's slightly younger and of course theoretically faster.
Oh, and you might want to consider using the 2bit IRQ loader in Fixup #$00 as it's meant to go together with the saver. Both don't require extra installing/uninstalling. The routines come with a third one, the IRQ dir displayer, and all of them were used in +h Emu-Fuxx0r V2.0 to do all that with music playing. |
| |
bubis
Account closed
Registered: Apr 2002
Posts: 18 |
Have I mentioned that Bitfire+4 has a save routine too that works with C64/Plus4?
https://github.com/dotscha/bitfire/releases |
| |
Krill
Registered: Apr 2002
Posts: 2822 |
Quoting bubisHave I mentioned that Bitfire+4 has a save routine too that works with C64/Plus4?
https://github.com/dotscha/bitfire/releases
You did, in this https://csdb.dk/forums/?roomid=11&topicid=131808#131841 thread.
But taking a quick glance at it, seems quite low-level.
Takes track/sector argument, then a call for each block, plus prepare/finish calls, overwrites sectors regardless of BAM and with a fixed interleave, doesn't update BAM or directory. |
| |
bubis
Account closed
Registered: Apr 2002
Posts: 18 |
Exactly, its only purpose is to overwrite existing Bitfire files. Perfect for saving high scores or other fixed size files that has a dedicated place on the disk. |
| |
Krill
Registered: Apr 2002
Posts: 2822 |
Yes, but not suited for save-games. But i have the feeling Thundax just wants to save scores, hence save-with-replace. |
| |
bubis
Account closed
Registered: Apr 2002
Posts: 18 |
Its only use case is saving games and high scores at the moment and it works fine. ;) |
| |
Krill
Registered: Apr 2002
Posts: 2822 |
Very much depends on the use-case at hand.
In a tournament-type game stretched over different sessions with different tournaments going on, you'd want something that handles save-games well, i.e., multiple files preferrably on standard-format empty disks.
If it's just for saving highscores on the game disk itself, then, yeah. :) |
| |
MagerValp
Registered: Dec 2001
Posts: 1055 |
Quoting ThundaxMagervalp: Thanks for the link. I already was looking at that one, but as far as I can see it only saves files by tracks/sectors and not even new files? I don't know how to work with tracks/sectors yet, and it's certainly not flexible. So I doubt if it's still a solution for me atm... :s
Look at the sample code, it loads the directory and caches T/S for each file. But you're right that it can't create new files, it can only overwrite existing ones. |
| |
ChristopherJam
Registered: Aug 2004
Posts: 1370 |
Quoting bubis… files that have a dedicated place on the disk.
Speaking of those, perhaps a good time for me to point out that BakeDisk64 lets you specify starting tk,se and interleave per file :) |
| |
Krill
Registered: Apr 2002
Posts: 2822 |
And the new CC1541 coming with Krill's Loader, Repository Version 166 has something similar, too! :D
-s value Next file sector interleave, after each file
if negative, do not consider large tail gap (unlike standard)
the interleave value falls back to the default value set by -S
-r track Restrict next file blocks to the specified track or higher
-b sector Set next file beginning sector to the specified value |
