Commander X16

kelli217 wrote: ↑Mon Aug 21, 2023 9:58 pm You may need to update your system to R44.

It was a sort of 'stealth' update, in that it seems to have escaped many people's notice and was not officially announced as loudly as some other releases have been.

Where can I find a feature update list for R44 ?
and If I want to Flash my Hardware........... just ROM.BIN or are other files required.

I figured out the problem....RTFM!

yock1960 wrote: ↑Mon Aug 21, 2023 9:15 pm HIRAM 0.7.0 version crashes R43 emulator....on my system anyway. Version 0.6.0 worked fine.

Hi.

The config file for the HI RAM build was faulty, and made it impossible to load the program with LOAD ,8,1.

I fixed that, and uploaded a new version. Hopefully that works better.

ahenry3068 wrote: ↑Mon Aug 21, 2023 11:19 pm Where can I find a feature update list for R44 ?
and If I want to Flash my Hardware... just ROM.BIN or are other files required.

https://github.com/X16Community/x16-emu ... es/tag/r44

I believe that the rom.bin should be sufficient. I don't think there's a new VERA bitstream (yet) and I think the SMC firmware from R43 is fine. Cunningham's Law states that if I'm wrong about any of that, I will be corrected in short order.

I appreciate that Kelli. Just upgraded to the R44 Emulator in Linux. (Yet to do on Windows.).

One of the team on DISCORD said they are going to Post a Video on doing a ROM flash on
Hardware. I like a few of the feature upgrades and I'm going to do it eventually. I'm
always nervous when I flash a BIOS. Even if all the hardware and software is flawless
a power outage can still F. U. So I'm going to wait for another couple days or weeks
before I take the plunge.

What does X16 Edit use as a line terminator when saving files ?

CR,LF
CR
or just LF

background for others:
CR = \r = carriage return = 0x0D
LF = \n = line feed (or new line) = 0x0A

At least as of the ROM version R45:

When I created a document on a Windows system with notepad, it had 0D 0A (from a hex viewer). X16EDIT added some smarts when opening a file, to look for those line endings and try to handle either kind consistently.

But it looks like on saving, it is only doing the CR (\r, 0D) fashion. When I opened and saved the above said file back out, it only contained the CR (\r 0D) endings. [whether I used the same filename or a different save-as filename]

Same for when using X16EDIT on system to make a new file, it only had CR line endings.

Maybe the editor needs to become smarter

Currently, it uses CR in PETSCII mode and LR in ISO mode when saving a file.

It could of course remember what was used in a file that was opened. And also let the user actively select line break encoding. It shouldn’t be too hard.

I really think you ought to make it use what it initially reads. If using INPUT# and LINPUT# from BASIC they expect the CR. They mostly work with Windows Text files except the $0A ends up as part of the INPUT String. If you take out the CR's then you end up getting a String to Long Error as the INPUT or LINPUT command continues on down the file looking for the $0D

(and yes I know the LINPUT terminator can be changed, but the default is stil $0D)

I'd just like to pop in to say VS Code has issue #35797 open, a feature request for supporting files with CR line endings (in addition to CRLF and LF which are already supported). The issue was opened in 2017 and as of 2023, VS Code still doesn't support it. I doubt VS Code is alone in this, so the X16 may permanently be a second-class citizen when it comes to text encoding cross-compatibility.

In other words, we may have to accept a reality where CR is the X16's native line ending, but with nobody ever respecting it.