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 > Replacing games loader ...
2018-06-20 01:03
Bacchus

Registered: Jan 2002
Posts: 154
Replacing games loader ...

OK, this on cracking but still highly related to coding.

Most games I fiddled with over the year call the loader using a parameter that was the index of the file. Using the same parameter as index for my IFFL or converting it to a two byte string starting the file name has worked well for me in most cases.

I am now facing two games that are not distributed yet (old, but no scene version is out) where there is a lot of data stored directly on the disk and the game then loads it using direct track and sector. Think of it like action adventures. The game loads strings or other really small things by loading T/S and then exctacting the needed part. It's hence not really "files" most of it and there are so many that a file per string is plainly not within reach.

I can think of a few approaches;
1) Keep it as data on disk. Allocate the sectors used and then store the files on the unallocated sectors. You can't compress it - it does take a full disk side any way you look at it. It does work, looks rather neat but cannot be counted as a firstie.

2) Make a big chunk of the data to a file and push it to a REU the first thing you do. The game become ever so much more playable and fast. And the file can be compressed efficiently. You do need a REU (or simply enable it in your emulator or Ultimate Cart) but it's also still not counted as a firstie.

3) Make a big file which you then need to scan as the original 256 byte sectors are now 254, so a sector that was a full page is by necessity spread over two sectors in a file based option. I guess you can also compress the sectors individually and think of the sectors as files in an IFFL. One IFFL file equals a sector. This is an ugly bitch but could be counted as a firstie.

Any other thought on this technical challenge? I must admit I am growing fond of the REU option, and the firstie restriction is the only thing that holds me back. The Tink games we just released had been perfect in REU version. Would have saved SO much work, loading would have been near instant and it would have been a release of two neat files.

Am I missing any options or can someone provide some lateral thinking, that opens up new options by finding approaches I have missed?
 
... 36 posts hidden. Click here to view all posts....
 
2018-06-21 14:15
Bacchus

Registered: Jan 2002
Posts: 154
So, scanning is needed.

Storing tables is needed.

And preserving memory is also needed.
2018-06-21 15:52
Martin Piper

Registered: Nov 2007
Posts: 629
It's these little puzzles that keep programming fun. :)
2018-06-21 16:37
Maxlide

Registered: Apr 2003
Posts: 29
Quote: It's these little puzzles that keep programming fun. :)

...or let you bite into your table :)
2018-06-21 17:50
chatGPZ

Registered: Dec 2001
Posts: 11088
Quote:
Strictly speaking you need less than 10 bits to store the track and sector, if you can spare a few bytes for a small div routine. Even so, that's 900 bytes for the tables, which is a lot.

when you are dealing with 400 chunks of 256 bytes you dont need to put the offset into the table (you can calculate it easily and fast)
2018-06-21 19:21
Oswald

Registered: Apr 2002
Posts: 5007
Quote: ...or let you bite into your table :)

you will not enjoy it finally working, not having had eatan half of the table :)
2018-06-21 19:53
ChristopherJam

Registered: Aug 2004
Posts: 1359
Oh! The piece of furniture your computer sits on!

I was trying to parse Maxlide's comment as being something about code overwriting the offset table or something, and utterly failing to make sense of it. Thanks Oswald.

*stops eating table*
2018-06-21 20:41
MagerValp

Registered: Dec 2001
Posts: 1055
Quote: Quote:
Strictly speaking you need less than 10 bits to store the track and sector, if you can spare a few bytes for a small div routine. Even so, that's 900 bytes for the tables, which is a lot.

when you are dealing with 400 chunks of 256 bytes you dont need to put the offset into the table (you can calculate it easily and fast)


I'm assuming that each block is crunched individually, and thus the size varies.

Another idea that I don't think I've ever seen done is to keep the T/S/O in an on disk directory file. It would have to be written after scanning on first launch, but the game could launch without scanning after that. No RAM required for the tables, but just like with regular file loads you need to seek to the directory before each file loads. Probably not great if you have 400 of them...
2018-06-21 21:01
Bacchus

Registered: Jan 2002
Posts: 154
@MagerValp: It has been done. I know for a fact - guilty as charged ... ;-)

We used that to swap out stuff in order to have the space to implement save in Herakles.
2018-06-21 21:41
MagerValp

Registered: Dec 2001
Posts: 1055
Oh neat!
2018-06-21 23:54
Jazzcat

Registered: Feb 2002
Posts: 1044
i would support and assist a gamers guide online for sure!
Previous - 1 | 2 | 3 | 4 | 5 - 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
iAN CooG/HVSC
Freeze/Blazon
Valsary/BD/ESM
Krill/Plush
MCM/ONSLAUGHT
Courage
t0m3000/ibex-crew
CopAss/Leader
Guests online: 303
Top Demos
1 Next Level  (9.8)
2 Mojo  (9.7)
3 Coma Light 13  (9.7)
4 Edge of Disgrace  (9.6)
5 No Bounds  (9.6)
6 Comaland 100%  (9.6)
7 Uncensored  (9.6)
8 The Ghost  (9.6)
9 Wonderland XIV  (9.6)
10 Bromance  (9.6)
Top onefile Demos
1 Party Elk 2  (9.7)
2 Cubic Dream  (9.6)
3 Copper Booze  (9.5)
4 Rainbow Connection  (9.5)
5 TRSAC, Gabber & Pebe..  (9.5)
6 Onscreen 5k  (9.5)
7 Dawnfall V1.1  (9.5)
8 Quadrants  (9.5)
9 Daah, Those Acid Pil..  (9.5)
10 Birth of a Flower  (9.5)
Top Groups
1 Booze Design  (9.3)
2 Nostalgia  (9.3)
3 Oxyron  (9.3)
4 Censor Design  (9.3)
5 Crest  (9.3)
Top Logo Graphicians
1 Sander  (10)
2 Facet  (9.7)
3 Mermaid  (9.4)
4 Pal  (9.4)
5 Shine  (9.3)

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