Welcome! Glad to see someone else who's interested in 68k programming. I don't know how many 68k assembly programmers there even are, these days- I think most use C, don't they?

Is there a reason to use memcpy over memmove for this case? memmove is working at the moment- I used it because the documentation says it can deal with it when the source and destination overlap and memcpy can't.

But thanks for the help, everyone, it's working now.

This morning, I checked if Solar89 can properly handle two-byte tokens (by adding the Matrix tokens). Most of the time it works... but sometimes it doesn't, and I'm not sure how I can fix it.

Here's a situation that would cause a problem: trying to run a text file containing "[A]", or the matrix A token, through Solar89. Why? The hex code for this token is 5C00h.

The way Solar89 is programmed, each line of the text file is looked at individually, and then the hex code for the token is added to an unsigned character array (since unsigned char = 8 bits). So if the line contains the token ClrHome, the program will add the character E1h to the array, then add 3Fh to the array to finish it off. A two-byte token is handled by splitting the hex code into two characters and adding them both to the array. So for the token [C] (5C02h), the character 5Ch and then the character 02h.

The problem? For any token that has a byte of 00 (there aren't too many, but they include [A]), the \0 character is what will be added to that character array. And that seems to prevent me from adding anything else to the array. So if I'm trying to tokenize [A], no end-of-line character will be added, and anything after [A] on that line won't be added either.

But that's not the main problem. The main problem is that the code that saves the token array to a file does it by writing each individual character to the file, and it stops before it reaches \0. So even for a file only containing [A], I won't get 5Ch 00h 3Fh (3Fh being the hard return, the newline character), I'll just get 5Ch.

Fortunately, only a few tokens have a byte of 00h, and probably a lot of programs can be written without using them. But it would be nice to support them, but I'm not really sure how. Would I need to use something other than an unsigned character array? Or can I implement some workaround?

I like all of the changes- I'm glad the Members Only section was removed and the forums there merged with the other sections, as that's definitely streamlined the index. One thing, though- the Major Community Projects section still says this:

Some of the best non-RPG calculator projects from our users, all with their own sub-forum.

With the merge of the Major RPG projects, this text probably should be changed.

I have attached v0.1, an alpha and testing version, since everything seems to be working (even though there are only one-byte tokens supported at the moment).

If you use it on a real calculator, I highly recommend doing a backup and then installing a crash protection program (either PreOS or KerNO) if you don't use one already, simply because even though it seems to work perfectly, there's always the chance of a bug that I missed.

I have provided a demo that you can try tokenizing (the same program in the screenshot above). There's documentation on what exactly to do with all of the programs included (in the various readme files), and once you get everything setup I recommend trying the demo (since I know it should work).

I'd like people with a Voyage 200 or TI-92 Plus to try it on those calculators, to see if it works- I have versions provided for them but I obviously can't test them. You can also try testing other calculator models- the only one that definitely won't work is the 85 since BinPac8x makes strings, not program files for it. (And the 86 probably uses different token codes than the 82, 83, and 84+).

[Attachment removed- outdated version].

IIRC the format is exactly the same. You might not even have to rename them

Oh. Okay, well in that case, problem solved.

Yes, this sounds very nice.

Could you also use BrandonW's resign68k program to resign the 68k OS? That's what I used for GTC, and it says it works with AMS upgrades too.

Deleting entire folders is possible through the VAR-Link dialog, just select the folder with F4 before deleting it

...oh. I didn't know that, thanks.

I don't know precisely what can have screwed up your calculator. There's no write protection (only a silly execution protection that complicates launching other programs), so pretty much any memory overrun in an assembly program can have immediate or delayed consequences on the system's stability.

Wait, what about the boot code? Is that protected, like it is on z80 calcs?

So, in order to make sure everything was stable again (if memory somewhere had been overwritten) what would I need to do? Do a "system hard boot"  by removing a battery and using [ON] + [)] + [-] (a key combination which I found here on UTI when I went hunting through various tech support forums)? Delete the OS before sending a new one?