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-20 16:56
Knight Rider

Registered: Mar 2005
Posts: 114
@Bacchus Regarding points : when I was in the "scene" in the 80's, I was too young to know about this. Now I am simply too old to care.

But this is my recommendation:

1) Make a .d64 with KERNAL loader and have files names tr-se to get your points.

in parallel

2) Make the best release (instant loading CRT/REU) and get satisfaction and appreciation from other old gits like us
2018-06-20 17:34
Raistlin

Registered: Mar 2007
Posts: 547
Re: "Firsties" / "Besties".. why not release a title twice? If it's an old title that it's unlikely for someone to release while you're working away at it, wait and release both at the same time ... if it's a new title, race for a firstie and then race for a bestie right after?

G*P in the 80s/90s would often release a game twice .. cracking it once so that people can play the new game ASAP ... and releasing it later with cheats, improved load times etc etc.
2018-06-20 17:43
chatGPZ

Registered: Dec 2001
Posts: 11088
giving any useful answer really needs some hard numbers here... depending on the number of "files" and their size... the solution is quite obvious :) so what is the problem exactly that needs to be solved?
2018-06-20 18:27
Bacchus

Registered: Jan 2002
Posts: 154
@Knight rider: That's how I did the Tink series. But that also only works up until 144 files (where the boot and docs file would take from that same pool). The Tink series loading was rather painful. Dir scanning to the last sector of track 18 and then load a file that was under a block. Painful!

@groepaz I do well understand that there are different scenarios. Under 128 files IFFLs and file loaders are OK, under 142 files IFFLS are sort of our unless you do funky stuff clustering and you can only do files. After 142 you need to do funky stuff.

The discussion gets really interesting only while the IFFL and standard file loaders are sort of out of scope.

For the sake of argument; let's assume five files of 20 blocks and then 400 "256 byte pages". That makes a total of 500 blocks.
2018-06-20 18:53
Knight Rider

Registered: Mar 2005
Posts: 114
is .d81 out of scope for points ??
2018-06-20 19:37
Bacchus

Registered: Jan 2002
Posts: 154
Points are only awarded for stuff that runs on stock 64.
2018-06-20 19:47
Tim
Account closed

Registered: Mar 2002
Posts: 467
Bacchus,

I'm not qualified to answer your question, but I do acknowledge the problem.. in some cases it's actually the reason why some releases are not done yet.

Good luck in Fairlight's attempt to combine points and quality, it is noticed, and it is respected.

Side note;
Having to make similar choices in our crew frequently, it is no secret that if you (or anyone for that matter) would start a quality rating system, it would certainly mean we shift even more resources in that direction.
2018-06-20 20:57
chatGPZ

Registered: Dec 2001
Posts: 11088
Quote:
For the sake of argument; let's assume five files of 20 blocks and then 400 "256 byte pages". That makes a total of 500 blocks.

you are missing "how much memory is there to use for it".

eg: your example is pretty trivial if you have 800 bytes for an index table
2018-06-20 22:22
Bacchus

Registered: Jan 2002
Posts: 154
You rarely have memory - you claim it ;)

Still, IMHO tables for over 256 is less trivial. Forget drive RAM. 400 files means 1200 bytes tables. Track, sector and offset. Times 400. That sort of memory is not common in any game.
2018-06-20 23:15
ChristopherJam

Registered: Aug 2004
Posts: 1359
…so then perhaps for each group of 4 source blocks, have the track/sector/offset of a record in the IFFL that itself contains four lightly compressed blocks, preceded by a header giving the compressed length of each of the four?

Then you only have 300 bytes of tables, 200 if you pad each group of four to a block boundary.

Of course, then you might have to read as many as three extra blocks, but they should all be on the same track most of the time.

(apologies if my terminology is off; I have zero experience in cracking, obviously)
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
hedning/G★P
cobbpg
Case/Padua
t0m3000/ibex-crew
CopAss/Leader
Malmix/Fatzone
csabanw
Yugorin/Samar Produc..
Guests online: 324
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 Crackers
1 Mr. Z  (9.9)
2 S!R  (9.9)
3 Mr Zero Page  (9.8)
4 Antitrack  (9.8)
5 OTD  (9.8)

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