Corrupt end of basic program

[Soloman]

This happens to me in VICE regularly: When I saved a Basic program to disk or tape and I load it again I see, when I list it, a line of garbage with a strange linenumber at the end of the program. When I look it op in the monitor I see that the last line is not ending with three zero-bytes. A Basic-program ends in the memory with three zero bytes.

Here is an example. Nowadays I end the program with REM EOP, so I can see the end.

You see here the last word in the program in from $12FA with the space (20). Then it ends with zero, end of line, and then the pointer to the next line after the next line, $1307. That is strange, two zero-bytes are missing, they are at $1306. The line after REM EOP starts at $12FF with first te pointer after that line. Between $12FF and $1307 we see misery.

It is easy to repair: put 00 in locations $13FF and $1300 (End of program), but my question is: where does this come from? What am I doing wrong that this garbage arises?

(mod: thread moved to the Emulation and Cross Development section)

[Mike]

What tool did you use to create the program file in first place?

This error is typical for a BASIC program file that for whatever reason was saved with a missing last byte.

By itself, the SAVE command of BASIC does not produce that problem - but once a BASIC program is loaded that has been produced by a 3rd party tool that doesn't get things right, that issue even survives edits and further save actions.

For more details please check this post: https://sleepingelephant.com/ipw-web/bu ... &hilit=EOP

[Soloman]

What tool did you use to create the program file in first place?

This error is typical for a BASIC program file that for whatever reason was saved with a missing last byte.

By itself, the SAVE command of BASIC does not produce that problem - but once a BASIC program is loaded that has been produced by a 3rd party tool that doesn't get things right, that issue even survives edits and further save actions.

For more details please check this post: https://sleepingelephant.com/ipw-web/bu ... &hilit=EOP

I only use VICE. It happens 10% of the savings, and mostly at the end of the disk-directory or at the end of the tape. I made backups. I made a backup of this program with this error and didn't touch it after that. The backup is fine, curious. Other strange thing: I make backups of the floppies. The last backup contained this program, untouched, and it shows stranger things, like a repeat of some lines including the linenumbers. Looking into the monitor I saw it isn't the linepointer, but those lines are physically stored twice in the memory.
I only use VICE and I am not poking around. It occured from the first time I programmed some simple programs in VICE-VIC, without doing weird things.

VICE-version is 3.5, windows 10.

[Mike]

Hi,

I only use VICE. It happens 10% of the savings, and mostly at the end of the disk-directory or at the end of the tape. I made backups. I made a backup of this program with this error and didn't touch it after that. The backup is fine, curious. Other strange thing: I make backups of the floppies. The last backup contained this program, untouched, and it shows stranger things, like a repeat of some lines including the linenumbers. Looking into the monitor I saw it isn't the linepointer, but those lines are physically stored twice in the memory.

I would not be able to confirm your experience.

While I am aware that it is surely possible to 'shoot' the programs in memory and during data transfer, the kind of errors you described could be attributed to stray POKEs into BASIC memory, using save-and-replace on the drive - with True Drive Emulation (TDE) on - and other reasons you would encounter on real hardware as well.

Exactly how do you create those backups, for example? Within VICE, with TDE on, with two disk images images mounted and using a native copy program? In emulation, it is far easier during program development to keep TDE off, use a PC directory for file storage instead of a disk image and keeping a journal of the process by using date stamped project directories. Working 'old skool' - within disk images only - requires you to never use save-and-replace, instead using the DOS scratch command or saving edited programs under a new name. Same principle applies to tape use, and the quasi-analog nature of TAP files exposes you to the same fault mechanisms that would occur on real hardware (like 'stripping' off the end of the preceding program by starting the save of a new program too early on tape).

I only use VICE and I am not poking around. It occured from the first time I programmed some simple programs in VICE-VIC, without doing weird things.

It is very unlikely that you found a bug in VICE here. There are conceivable scenarios how the issues you describe could happen, yes, but you would get them the same way on real hardware.

Greetings,

Michael

[srowe]

Have you got a short BASIC loader program that then chains a longer BASIC program? This combination causes the end of the second program to be overwritten by variables, in this case the start of variables (VARTAB) is not updated.

[groepaz]

It is very unlikely that you found a bug in VICE here.

Yes. However, if there is a reliable way to reproduce this, i'd still like to know

[Soloman]

I am pretty sure it is not a bug in VICE, because it happens too often and I can't find anything about it on the internet. And no, I never use the @-replace-option when saving the program. My programs always begin with OPEN 15,8,15,"S0:program":CLOSE15: SAVE "program",8
And I start the program with setting the pointers after chaining.

Making backups I do outside VICE, just in Windows, copying .d64- and tap-files to a save place.
Maybe it is the old version in combination of the environment. I have a private computer, but I use this one almost never. I have a computer from work. Monday to friday I work on it, in a separate environment. In the weekend I use this computer for programming in Java (BleuJ) and VICE outside the working environment. BlueJ works perfect on it. It's true that everything is protected and limited, like internet, and no USB. That's the reason I cannot install a newer version of VICE. The computer keeps protesting ("Unkown software-owner"). But this one, 3.5, is working on it.

[Mike]

And I start the program with setting the pointers after chaining.

The values in addresses 174 and 175 are only valid immediately after LOAD! If you in-between edit the program and re-start it, indiscriminate copying of 174/175 to 45/46 will reference the old values, possibly truncating the program - with exactly the effects we see here.

The idiom "POKE45,PEEK(174):POKE46,PEEK(175):CLR" really should be taken with a grain of salt. Actually, it assumes no further editing, much less saving of the program in the BASIC editor takes place.

You really should use the other method I highlighted in the other thread, printing the LOAD command on screen and filling the keyboard buffer to execute that line in direct mode. This variant of the LOAD command is guaranteed to set 45/46 correctly on load. However, as a first measure you need to rebuild versions of your program files that actually have a correct EOP marker and are of the correct length.