eslapion wrote:AFAIK, there will be a problem with that.
The area which contains the game status saved is $1000-$123e and most of this areas becomes used by the screen codes if you install 8k+ RAM expansion which starts at BLK1 ($2000-$3FFF).
If you have full RAM expansion and do the patching as you suggest, you have to make sure BASIC doesn't detect it.
Well spotted. However, the patch can simply
relocate the screen to the position where it is with unexpanded (or +3K) RAM.
Three instructions in machine code: LDA #$1E:STA $0288:JSR $E518 (or POKE648,30:SYS58648 in BASIC) are all that is needed *) - ...
An alternative is to have RAM in BLK5 ($A000-$BFFF) or in the 3k RAM expansion area ($0400-$0FFF).
... instead of resorting to rather uncommon RAM configurations (BLK2+BLK3+BLK5 or RAMx+BLK2+BLK3, both *excluding* BLK1).
The aforementioned wedge for the screen colour change resides in the internal RAM, implying the Scott Adams adventures don't use all of it. Possibly the load/save patch could be put there too, and then the screen relocation "issue" also doesn't crop up.
*) in a related matter, temporarily "unexpanding" the VIC-20 from any kind of RAM expansion until the next power cycle or hard reset also needs the BASIC start and end to be adjusted correspondingly. That is done with
POKE642,16:POKE644,30:POKE648,30:SYS64818. POKE642,16 sets the start of BASIC, POKE644,30 the end of BASIC, POKE648,30 the screen base address and SYS64818 performs a soft reset (which excludes the RAM check but includes SYS58648). However, for these cartridge games, that adjustment of the BASIC pointers is not necessary.
P.S.
eslapion wrote:if you want to save to a disk drive, you'll have to make sure you either save under an unused filename or use the overwrite option.
You know the "@" drive command for save-with-replace is bugged on CBM disk drives and can lead to loss of data? Not because of the issue when not enough room is there for the new file, but because the remove procedure for the old file sometimes
frees the wrong blocks.
If you do it on your own disks, with your own drives, that's your own problem.
It will annoy a lot of people if it's put in a released program. Really no good idea to even
suggest its use.
The Right Thing to do is: either first scratch the old savegame (with the "S" DOS command) and then save; or - for the more paranoid
- with a savegame and a backup of it: (step 1) first scratch a possible remnant of the backup, then (step 2) rename SAVEGAME.DAT to SAVEGAME.BAK, and finally (step 3) save a new SAVEGAME.DAT.