| |
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....
|
| |
Burglar
Registered: Dec 2004
Posts: 1088 |
Quote:@burglar How do you do it if you don't scan? Quote:You scan to the required file on demand, building the track/sector/offset table piece-wise, which is what Burglar did (if i got him right). heh, sadly no, that would be smart :)
nah, I took the quick&dirty route, I just cache scan result on track 18 sector 18. this allowed for a quick recover after saveing a game, I actually just "rescan".
in other mods of my iffl, I reserve first sector for highscore and use a safe 1bit irq friendly save routine. don't wanna hassle with BAM ;P |
| |
MagerValp
Registered: Dec 2001
Posts: 1074 |
Quoting Krillfully-random file access in some hypothetical malicious game
That's really just your average rpg or adventure game :) |
| |
Krill
Registered: Apr 2002
Posts: 2969 |
Quoting MagerValpQuoting Krillfully-random file access in some hypothetical malicious game
That's really just your average rpg or adventure game :) And here i was thinking that the average RPG/adventure game would be based on some kind of decision tree and also limit the amount of disk juggling by not going full random. :) |
| |
sailor
Registered: Jan 2002
Posts: 90 |
Just like Krill mentions, there is support for SEEK in sd2iec. I use it in JaffyDOS V1.3 Kernal for SD2IEC for the mkd64/71/81 commands.
..and with that said, I did a quick'n'dirty convert of an old release into "sd2iec iffl" and it runs ok (no surprise).. well, it did not run on someone elses sd2iec but thats probably another discussion regarding firmware, hardware, dirty code, something.
A few considerations, you are stuck with kernal loading which depends on zeropages and vectors which you need to (re)store. IRQ will be lacking and having the loader up high in memory will be a problem. It will have its limitations.. and another loader to test with the game.
However, since you are in kernal you can choose to have the savefile handled inside IFFL or separate file by standard load/save calls... and then you need a savefile export/import to the native IFFL.. and.. and.....
Interesting discussion though :)
Edit: There was discussion about implementing native n0sd0s-iffl loadersupport into sd2iec when some strange pirate-game was released.. A few flavours of n0sd0s exists, so it'd need to emulate multiple drive-side code.. not sure if there is space for more loaders in sd2iec. |
| |
Krill
Registered: Apr 2002
Posts: 2969 |
Quoting sailorIRQ will be lacking Ah, with minor re-implementation of some KERNAL calls, you can play a standard SID tune glitchlessly during KERNAL load or save. =) The protocol on the bus is still the same. (Most likely not an option for cracks, of course.) |
| |
Bacchus
Registered: Jan 2002
Posts: 156 |
@burglar We swap out scan tables to a sector on disk before saving on Herakles. So if the disk is write protected ours wouldn't run I guess. I assumed your version would be the same.
Also the general logic in normal IFFL (not ULoad - that's an exception) is that the drive holds the loader and scan tables. With the SD2IEC seek, you must port the scan table back to the computer.
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.
/Bacchus |
| |
Raistlin
Registered: Mar 2007
Posts: 659 |
Crack Competition 2020:-
Alternate Reality - The City
Just putting this out there... it might stop all the arguing ;-p |
| |
Raistlin
Registered: Mar 2007
Posts: 659 |
And now I understand the Heracles references I keep reading ;-) ... interesting to see that the winner of the compo has never cracked anything since (maybe Bigfoot just likes the compos?).
C64 Cracking Competition 2015
Also nice to see MagerValp's loader in that winning entry :-) |
| |
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 |
| |
Krill
Registered: Apr 2002
Posts: 2969 |
Quoting BacchusWith 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 BacchusI 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? |
| Previous - 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 - Next |
