Yet another SEDORIC update.

[Ray030471]

SEDORIC is such a powerful and extensive piece of software that it is understandable that we would find a few anomalies.

I have just discovered such an anomaly with the TKEN command.

When used with a null string variable, the TKEN command will incorrectly copy a byte from somewhere in memory to another place.

Set HIMEM to #97FF and run the following short BASIC program

100 A$ = "12345" + "ABC"
110 B$ = ""
120 TKEN B$

BASIC will correctly record A$ as being a string of length 8 bytes and with a start address of #97F7.
However, BASIC will record B$ as being a string of length 0 bytes and also with a 'start address' of #97F7.

Next, TKEN will firstly copy a byte from #97F7 ('start address' of B$) to #35 (input buffer) but then overwrite the byte at #35 with zero before copying the byte at address #134 to #98F6, ie #FF bytes further on from the 'start address' of B$.

This will not cause any adverse effect in many cases but it is worth knowing about it.

I have come up with a solution which involves a simple patch, using NIBBLE, at sector level on the disk (based on 17 sectors per track).

On track 00, sector 0E, from byte 31, enter 20 38 D2 4C 74 D2
On track 02, sector 07, from byte A0, enter 20 31 CD AA F0 3A

The first part (from address #CD31 in SEDORIC) overwrites what I believe to be irrelevant data but please inform me if you know otherwise.
The second part overwrites some of the TKEN code from address #E8A0.

Thankfully, UNTKEN does already check for a null input string.

[Symoon]

I have just discovered such an anomaly with the TKEN command.

Do you plan, at some point, releasing something like Sedoric 3.1, or 4.1, or whatever, with your patches?