Log inRegister an accountBrowse CSDbHelp & documentationFacts & StatisticsThe forumsAvailable RSS-feeds on CSDbSupport CSDb Commodore 64 Scene Database
 Welcome to our latest new user Harvey ! (Registered 2024-11-25) You are not logged in - nap
CSDb User Forums


Forums > CSDb Entries > Release id #187773 : Alternate Reality - The City +11D
2020-02-15 17:47
jcompton

Registered: Feb 2006
Posts: 70
Release id #187773 : Alternate Reality - The City +11D

With a dramatically improved saver and a trainer, it is now much much easier to live long enough to stumble into the original game's bugs!

Notably:

- Certain potion effects (Potions of Protection +1/+2) modify the wrong area of memory and may not actually provide any benefit whatsoever.

- These potion-related memory trashes can affect playfield graphics like door labels and mountain backdrops.

- Too many potion effects will crash the game!

- Banks may exhibit erratic behavior at times.

- Upon transitioning from a building back to the game map, the game sometimes "forgets" whether you are outdoors or in an "enclosed area."

- The game mostly hides the mirroring of door labels, but forgets to do so in certain types of Enclosed Areas, so words like "SHOP" and "TAVERN" will appear reversed on the bottom of the door.

- In silent interiors there's a horrible buzzing sound when the SID should probably just be turned off.
 
... 92 posts hidden. Click here to view all posts....
 
2020-02-26 10:21
Bacchus

Registered: Jan 2002
Posts: 156
@rastlin

Bigfoots entry was super impressive. Taking all the texts and making a dictionary, replacing the words in the actual texts with references to the dictionary. This is literally a cross file sequence crunch, which proved super efficient.


And it's also interesting to see that the "inferior" SD2IEC support "SEEK".

/Bacchus
2020-02-26 11:33
Krill

Registered: Apr 2002
Posts: 2969
Quoting Bacchus
With the SD2IEC seek, you must port the scan table back to the computer.
The loader would seek to fixed static offsets within the IFFL file, so what you would do is call the loader with 6-bit file index (non-SD2IEC case) and 18-bit seek position (SD2IEC case) in A, X, Y - hardcoded into the game.

Quoting Bacchus
I think the part where Krill gets it a bit wrong is that you rarely have any memory to play with. Squeezing in loader, depacker and the buffers they both need is normally quite a challenge. Adding a cache (scantable of just a cached scan result) is not really feasible.
A reasonably fast (IRQ optional) loader takes about $80 bytes after installation. ChristopherJam's tinycrunch (pack-ratio quite reasonable) adds another $80-ish bytes.
No extra buffers are required (depacking is fully in-place), so that's a page on the C-64 side.

On the drive-side, when throwing out things like directory parsing and buffering, interleave detection and out-of-order/speculative loading (but still keeping full on-the-fly block reading+GCR-decoding+checksumming, trackstep and transfer routines), my loader's current 1541 drive-code side leaves about $0300 bytes free to use.
That's 256 IFFL track/sector/offset entries (scanned on install).

How little space on the C-64 side or how many IFFL files are we talking about?
2020-02-26 13:10
Bacchus

Registered: Jan 2002
Posts: 156
There is never a fixed amount of memory available. Basically, the less memory you have available, the more functionality you must be ready sacrifice.

You want limieted use of zeropage, small files, reasonably fast loader, compatibility with a variety of drives, REU support, compatible save and so on. The more the merrier, but if all won't fit you start scaling down the requirements.

I have come to enjoy Cadaver + Exomizer 3. It's a super robust combination and all the times it failed on me, it was as *I* had done something wrong.

I can link files to so that they become subfiles (the first generation of IFFL), I can just turn off the fastloader flag and then all of kernal is available - including save. It's fast, it's compatible and the files on disk pack really well.

So all in all the benefits outperform any option I have seen. The only key drawback is that, for EVERY release, Hedning feel an unstoppable urge to ask why I don't do IFFL as I "have N0SD0S". :-P

/Bacchus
2020-02-26 13:21
Krill

Registered: Apr 2002
Posts: 2969
Okay, so which part about available memory did i "get a bit wrong", then?
2020-02-26 13:44
Bacchus

Registered: Jan 2002
Posts: 156
Memory available for directory caching. It becomes relevant only after you have a number of pages of files, and by that time the memory needed just isn't available.

/Bacchus
2020-02-26 13:50
Krill

Registered: Apr 2002
Posts: 2969
Quoting Bacchus
Memory available for directory caching. It becomes relevant only after you have a number of pages of files, and by that time the memory needed just isn't available.

/Bacchus
The directory is buffered in the drive, of course. Then a file entry takes:

- 2 bytes if loading by index
- 3 bytes if loading with a 1-char filename
- 4 bytes if loading with a full filename (stored as a 2-byte hash value).

So a directory buffer may take less memory than an IFFL T/S/O table, the same, or more, depending on what your requirements for the filenames are.

Edit: Oh, and it's still just a cache. There may always be more files on the disk than the cache can hold. Going to the dir track once in a while (but by far not for every loaded file) is okay, i guess.
2020-02-26 14:32
Frantic

Registered: Mar 2003
Posts: 1646
Quote:
The only key drawback is that, for EVERY release, Hedning feel an unstoppable urge to ask why I don't do IFFL as I "have N0SD0S". :-P


I find this very funny in all sorts of ways. :D
2020-02-26 15:52
jcompton

Registered: Feb 2006
Posts: 70
Quote: Crack Competition 2020:-

Alternate Reality - The City

Just putting this out there... it might stop all the arguing ;-p


If I get a vote, I'm calling for Wasteland 101%.

Single volume. Integrate the paragraphs.
2020-02-26 17:33
hedning

Registered: Mar 2009
Posts: 4723
Quote: Quote:
The only key drawback is that, for EVERY release, Hedning feel an unstoppable urge to ask why I don't do IFFL as I "have N0SD0S". :-P


I find this very funny in all sorts of ways. :D


Because Bacchus never answers I have to keep asking. :D He just rambles about how bad BBS’s are and so on.
2020-02-26 17:47
Bacchus

Registered: Jan 2002
Posts: 156
@hedning So now you can stop asking. I have said the same before and can repeat it but in my view IFFL is obsoleted - and BBS and first release only is a key part of the reason. I would use it in a competition, but if first is the only thing that counts - then really no.

Again;
http://bergatrollet.se/blog/2020/02/the-obsolescence-of-iffl/

And;
If not even your group is doing it, then you are in no position to ask it from someone else. (Supplying and have someone else do the cracking doesn't count).

/Bacchus

PS: And this BBS thing is just plain shit. Lame boring shit.
Previous - 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 - 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
Electric/Extend
kbs/Pht/Lxt
Bitbreaker/Performers
Jangler/Artline Desi..
Freeze/Blazon
bugjam
Krill/Plush
theK/ATL
rexbeng
Hydrogen/Glance
zscs
hedning/G★P
E$G/HF ⭐ 7
Barfly/Extend
Luca/FIRE
Guests online: 116
Top Demos
1 Next Level  (9.7)
2 13:37  (9.7)
3 Coma Light 13  (9.7)
4 Edge of Disgrace  (9.6)
5 Mojo  (9.6)
6 What Is The Matrix 2  (9.6)
7 The Demo Coder  (9.6)
8 Uncensored  (9.6)
9 Wonderland XIV  (9.6)
10 Comaland 100%  (9.6)
Top onefile Demos
1 Layers  (9.6)
2 Party Elk 2  (9.6)
3 Cubic Dream  (9.6)
4 Copper Booze  (9.6)
5 Libertongo  (9.5)
6 Rainbow Connection  (9.5)
7 Onscreen 5k  (9.5)
8 Morph  (9.5)
9 Dawnfall V1.1  (9.5)
10 It's More Fun to Com..  (9.5)
Top Groups
1 Performers  (9.3)
2 Booze Design  (9.3)
3 Oxyron  (9.3)
4 Nostalgia  (9.3)
5 Triad  (9.2)
Top NTSC-Fixers
1 Pudwerx  (10)
2 Booze  (9.7)
3 Stormbringer  (9.7)
4 Fungus  (9.6)
5 Grim Reaper  (9.3)

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