I want to type in some listings and save them with csave in one file. First, i insert the tape image, for example Listings. Then i type in the listing. I save it with csave"A". Then the second listing. Csave"B"
Then i go to set position and select the listing i want to load with cload. All works fine.
However, when i restart my pc and load Listings, there are no programs (A and B) found. With other words, i lost my listings.
especially the 'Use Cassette Image Read Only' and 'Save Cassette Image As ...' options
By default, for security measures, the cassette images are used by blueMSX in read only mode. The changes are made by default only in the memory (with a copy of the image), not on the image.
You have 2 options:
OR deselect the 'Use Cassette Image Read Only' feature (not recommended!)
OR use the 'Save Cassette Image As ...' to save the modified image when you are sure that the listing is correct.
Btw, why don't you save the files on a disk image???
Thanks for your reply and information Mars2000. Those two options work for me. Great. However, i tried to save as a DSK image, but that didn't work out. I have to use diskmanager?
However, if you want to have directly an already formatted disk image, it's simpler to use Disk Manager. Tip: Always close Disk Manager when the disk image has been created befote using it in blueMSX.
You can also type them on a PC and load them in an MSX (if the listing doesn't contain MSX specific characters)... not sure what you're planning to do exactly. WHat is the final purpose of typing in the listing and saving it?
You can also type them on a PC and load them in an MSX (if the listing doesn't contain MSX specific characters)...
I don't recommend that, because it will be in ASCII mode, the loading is slower and the file takes more place in the memory. If you type very long listings or listings with a high number of variables and arrays, it's a real problem. It's always better to save (and load) in tokenized mode!!!
Also for the coherence between all archives. I dislike to find files saved in ASCII mode on a DSK image!
Just save it again on the emulated MSX to convert to tokenized mode ... Typing is just usually a lot more comfortable in a modern text editor.
It will not work with very long listings loaded in ASCII mode ... No enough memory message guaranteed when trying to load the very long listing ... and impossibility therefore to save in tokenized mode!!!
I know it will not happen with all listings, but I prefer to use and recommend a method that works in all cases.
Oh. Thanks for warning -- I'm doing my own digitization project I should've finished half a year ago and one game is so long that this could possibly be an issue (and I was going to store the games in ASCII mode for easier viewing outside emulators).
(The reason I'm typing them in an MSX emulator instead of a PC text editor is that the listings came with line-by-line checksums the MSX calculated after pressing Enter and showed the checksum in the bottom left corner.)
Hah, that's a very good reason Are you sure the programs weren't published on disks or tapes back in the day as well? (This happened for a few Dutch MSX magazines.)
I don't recommend that, because it will be in ASCII mode, the loading is slower and the file takes more place in the memory. If you type very long listings or listings with a high number of variables and arrays, it's a real problem. It's always better to save (and load) in tokenized mode!!!
A little bullshit warning here: The storage format has no effect to the memory consumption on MSX.
Regardless of the input method of the program, the program is always stored in MSX memory in tokenized format... When the file is loaded in tokenized format, it is just loaded in a format as it is normally stored in MSX memory and only the fixed memory pointers will be updated after the load operation. When the file is loaded in ASCII format, it is run trough kind of "keyboard emulation" that enters the whole program to the memory just like if you would type it from the keyboard. From memory consumption point of view the end result is exactly same, but load time is more long due to the fact that the program runs through the compression line by line and naturally the loadable size is bigger. The reason why the compression does not affect the total memory consumption is that there are reserved fixed size buffers (#F55E, #F41F) that are used for this purpose and they are located outside of normal usable user RAM area.
The whole ASCII handling is technically just redirection of standard input/output... just like ie. LLIST is as well.
Are you sure the programs weren't published on disks or tapes back in the day as well? (This happened for a few Dutch MSX magazines.) 