| |
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....
|
| |
Krill
Registered: Apr 2002
Posts: 2821 |
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: 607 |
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: 2821 |
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: 2821 |
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. |
| |
sailor
Registered: Jan 2002
Posts: 90 |
FWIW a sd2iec(and ide64) iffl release, Into Hinterland World +4
I did some tests, and since it will be of no use on my HD only, perhaps some SD2IEC users will be happy over it..
Proof of concept, but as mentioned before, no surprise it works, only downside is probably to revert to kernal calls and everything that comes with it. Native support would be better...... |
| |
Fix
Registered: Feb 2003
Posts: 54 |
Why not supporting all the other drives too?
1541, 1571 and 1581...
Like a .D64 on a SD2iec/IDE64 with IFFL support? |
| |
Fungus
Registered: Sep 2002
Posts: 607 |
I think it was just more to prove that its possible to do without much effort, and also file saving outside the iffl. So kudos sailor.
I foresee sd2iec support being added to n0sd0s in the future when GRG is free to do so. However it will have the drawbacks of being slow as balls even with jiffy/jaffy and no real IRQ-loading/saving support. Native support would indeed be great. |
| |
sailor
Registered: Jan 2002
Posts: 90 |
@fix. The loader was late to the party, we released the game with support for most of the drives (n0sd0s) some time ago.
This version uses the same iffl-file as the previous release, thus adding even more compatibility.
In a normal case, it'd be one release with all the loaders in one.. |
| |
Krill
Registered: Apr 2002
Posts: 2821 |
Quoting FungusI foresee sd2iec support being added to n0sd0s in the future when GRG is free to do so. However it will have the drawbacks of being slow as balls even with jiffy/jaffy and no real IRQ-loading/saving support. Native support would indeed be great. Why slow and no IRQ? SD2IEC's native ELOAD protocol provides both fast and interruptible transfers, as cadaver has pointed out, at least in the drive->computer direction. |
| |
Fix
Registered: Feb 2003
Posts: 54 |
SD2IEC/IDE64 IFFL support has been around for over ~2 years with support for 15x1 drives + save inside IFFL.
You will get automatic support for IDE64 since it use same code as SD2IEC.
Saving outside IFFL is also quite easy if you have enough free memory.
The challenge is have support for 15x1 drives with save outside IFFL due to limited memory in drive and at the same time have that function with SD2IEC/IDE64.
@Sailor: Good work if you managed to add this at an party!!! |
| Previous - 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 - Next |
