| |
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....
|
| |
hedning
Registered: Mar 2009
Posts: 4723 |
Quote: @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.
Well. We would probably use it more if we had NosDos, but we do not, unfortunately. NosDos is really awesome, and I know that as we worked with Triad a few times, as you know. Pristine stuff, that would, in my opinion, have been sweet in this release we are discussing, but even better in the Tink cracks... I really mean it. :) It would have made so much sense.
And just like we love doing stuff on the obsolete C64, we in GP try to embrace the whole C64 scene, including the BBS scene. Why let them out? They are as much part of this scene as the demo scene and cracking scene.
I'll stop asking now. Thanks for your link. And hey, the release still have my 10! <3 |
| |
Fungus
Registered: Sep 2002
Posts: 680 |
Adding Exo 3 (or any other uncruncher) to n0sd0s is a trivial 5 minute job due to the modular approach we took.
If SD2IEC supports SEEK, the offset table can just be used directly with some math, and no scanning needs to occur at all, also simple to add and could add some kernel driver to n0sd0s for that easily enough, the handshake is not that complex, it would never work with IRQ without some modifications and it would only support things such as music and no rasters/sprites which isn't a real IRQ loader anyways.
As for dealing with BAM, neither do I want to mess with that, but there is surely also a solution.
If you want to make a challenge, maybe I take you up on it if I can keep from being bored of C64 long enough and crack this game which I don't even like... I think I'd rather work on games I do like tbh.
Also this blog post you keep making is opinion, and opinions are like assholes, everyone has one. |
| |
Krill
Registered: Apr 2002
Posts: 2969 |
Quoting FungusIf SD2IEC supports SEEK, the offset table can just be used directly with some math No math required at all, the offsets are just that, offsets into the IFFL file, which can be used directly.
Quoting Fungusit would never work with IRQ without some modifications and it would only support things such as music and no rasters/sprites which isn't a real IRQ loader anyways. True, it's not real IRQ loading, but sprites (and things like open borders or rasters) are possible with the original serial protocol (AND a slow device like a vanilla 1541 with original ROM on the bus), within certain limits (like masking the sprites and timing-critical code sections with interrupt handlers, which need to have quite a bit of slack of about $20 rasterlines).
Most of KERNAL's serial bus calls can be used as well, but you're well-advised to reimplement the EOI stuff and do some $dd00 polling at strategic places before SEI. =) |
| |
cadaver
Registered: Feb 2002
Posts: 1160 |
Since SD2IEC's ELOAD protocol already works so that you open the file normally, then initiate ELOAD with a fake M/W + M/E, after which you receive the file bytes via a 2bit timed transfer, it stands to reason it should allow also seeking before the ELOAD init. That way you could have as good sprite and IRQ support as in a usual 2bit fastloader.
In general I see IFFL as too much hassle still. You'd need one more special path for IDE64 if you want to support that too. |
| |
Krill
Registered: Apr 2002
Posts: 2969 |
Quoting cadaverIn general I see IFFL as too much hassle still. You'd need one more special path for IDE64 if you want to support that too. Seems that IDE64 supports seek as well, and with the same command and syntax:15.1.1 Position
Seeking is supported in both relative and regular files.
[...]
Format:
"P"+CHR$(hchannel #i)+CHR$(hposition bits 0–7 #i)+
CHR$(hposition bits 8–15 #i)+CHR$(hposition bits 16–23 #i)+
CHR$(hposition bits 24–31 #i) (There is no mention of the higher bytes defaulting to 0 if not specified, but one could simply send them along always to maintain compatibility with both IDE64 and SD2IEC.) |
| |
Fungus
Registered: Sep 2002
Posts: 680 |
IDE64 is already supported in n0sd0s for more than a decade.
SD2IEC support has already been prototyped and works fine afaik. ;)
I don't see it as any more complex than any other loader. Krill's loader is way more complex imo to implement or understand the code with the ifdef hell it has. ;)
The tools to build the iffl are cmd line based and automated, it's no more difficult than copying files to a D64 with x1541. It's actually very easy and simple to implement, just pass a file number to load and if it's load or save.
I view this "too complex" thing as just nonsense tbh.
Also the thing with "scanning" taking some inordinate amount of time is also nonsense, the scanner takes less than 5 seconds for a 680 block file on a 1541, on CMD devices etc it's even faster. If it's slow, you're doing it wrong. |
| |
Krill
Registered: Apr 2002
Posts: 2969 |
Quoting FungusI don't see it as any more complex than any other loader. Krill's loader is way more complex imo to implement or understand the code with the ifdef hell it has. ;) make prg INSTALL=1000 RESIDENT=0200 ZP=02 then you would link/incbin install-c64.prg and loader-c64.prg and JSR to the calls listed in loadersymbols-c64.inc. Pretty easy.
No need to "understand" the actual implementation (as in: the code) including all the conditional assembly, that's my job. :) |
| |
Krill
Registered: Apr 2002
Posts: 2969 |
Quoting FungusI view this "too complex" thing as just nonsense tbh.
Also the thing with "scanning" taking some inordinate amount of time is also nonsense, the scanner takes less than 5 seconds for a 680 block file on a 1541, on CMD devices etc it's even faster. If it's slow, you're doing it wrong. Please quote anyone here saying IFFL was "too complex" or that scanning would take way too long. I believe the assertions were quite different. |
| Previous - 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 - Next |
