New Emulator release: R42 "Cambridge"

[Daedalus]

Ah. That sounds like it would be it. I am using hostfs (Honestly, I have no reason to use the SD card image, as just using hostfs for development is fast and super easy.) I had no idea there even WAS an "overwrite" code, and would have never even considered trying to research it.

So, All I have to do is put the magic overwrite sequence in front of the filename? So... "test.spr" becomes "@:test.spr"? I'll try that tomorrow when I get to my office. If that doesn't work, I'll package up the code and a .PRG and send it in.

Wait... OPEN returns error codes? Good to know! Now that I know that, I'll see if I can find a reference... Nope, All I can find is BASIC stuff, and I doubt if that helps me. But now I know, and knowing is half the battle.

I never used a Commodore computer, I was a "TRS-80" user back in the day, and that thing was nigh impossible to program in assembly language, I tried... even bought the ED-TASM program, but it never worked right, it refused to load the output back from the cassette tape, and I couldn't afford the Expansion Module and the Floppy drives. Computers in the 80's really sucked. Heh.

Anyway, if someone knows these arcane file details and could add them to the KERNAL docs in the Git repo, that would really help those of us trying to program this thing in assembly language with no documentation at all. If it wasn't for Matt Heffernan making a video series on it, I don't know where I would be.

Edited to add:
Yeah! That was it. Simply adding "@:" to the beginning of the filename prior to saving the file worked great. Also, I note that there are suddenly a LOT more doc pages on the github, with lots of great Commodore DOS data. Awesome! THANKS!

[TomXP411]

We plan to fully flesh out the PRG to remove dependencies on Commodore's materials, but that's a huge job to do in our spare time. =)

In the meantime, basically any Commodore 64 programming guide will really help. Obviously skip the stuff about hardware (like writing to the screen or reading the joystick and keyboard) and focus on the KERNAL calls and how they work.

I also like this KERNAL API reference, and I keep it open when working in assembly:

https://www.pagetable.com/c64ref/kernal/

[MooingLemur]

grml wrote:
> This is not a new issue, it's no different from R41. It runs fine on a new
> Ubuntu installation though.
>
> Or maybe look into AppImages (which would also require to be build on an
> older system) for self-contained binary packages.

I have new builds posted at https://github.com/X16Community/x16-emu ... es/tag/r42

Except for a deprecated 18.04 which GitHub planned to remove in December but pushed it out to April, GitHub's runner options are Ubuntu 20.04 and 22.04. I've changed the workflow to use 20.04 instead of latest. I don't know if it'll make a difference here, but I'm hoping to find out.

I suppose we do have options if this doesn't help things, such as building in an older chroot. This build stuff has been a real rabbit hole today :)

[grml]

It's now in the same state as R41 for me:

[code]
$ ./x16emu
./x16emu: /lib/x86_64-linux-gnu/libm.so.6: version `GLIBC_2.29' not found (required by ./x16emu)
[/code]

Debian seems to be a little slow with their glibc, idk.

No more 2.34 dependencies, so it will work on more systems than before.

(Why the hell doesn't BBCode work in this topic?)

[popey]

desertfish wrote:
> Here's the github issue for tracking these requests
> https://github.com/X16Community/x16-emulator/issues/34

As requested, I've updated the snap* to the latest release R42. It should work on most distributions including Debian. It works on the Pi and there's even an s390x build if someone has some monster IBM kit to run it on - which might be fun :D.

https://snapcraft.io/x16emu

It's currently got users on Ubuntu 22.04, 20.04, 18.04, 16.04 and 22.10 as well as Manjaro, Raspbian 10 & 11, Debian 10 & 11, Zorin, Pop OS 22.04, Zorin and Mint 20.3 and 18.3.

* hate about to snaps can go to /dev/null please

[mobluse]

I think that some of the new commands should have been shorter e.g. "P" or "" instead of "PSG", "I" instead of "I2C". When it comes to I2CPOKE the shortest abbreviation when in lower case mode is "ir", ("r" is "shifted" "2", i.e. add 32 to ascii code for "2") but that doesn't work. "i2C" works, but is longer. The digits in a command or function makes the shortest abbreviation not work. Also, there are a bit many FM and PSG commands. Could they not be fewer? NOTE sounds like a special case of CHORD, and then one maybe could have just CHORD or NOTE.

R42 was just put out without any prereleases and from a new repository that most didn't know about. It was impossible for most to discuss these new commands and functions before they were a fact.

New commands and functions in R42 with reverse case shortest abbreviations:
1020 Fm:REM FMINIT
1030 FMn:REM FMNOTE
1040 FMd:REM FMDRUM
1050 FMINs:REM FMINST
1060 FMv:REM FMVIB
1070 FMf:REM FMFREQ
1080 FMVo:REM FMVOL
1090 FMp:REM FMPAN
1100 FMPl:REM FMPLAY
1110 FMc:REM FMCHORD
1120 FMPo:REM FMPOKE
1130 PSg:REM PSGINIT
1140 PSGn:REM PSGNOTE
1150 PSGv:REM PSGVOL
1160 PSGw:REM PSGWAV
1170 PSGf:REM PSGFREQ
1180 PSGp:REM PSGPAN
1190 PSGPl:REM PSGPLAY
1200 PSGc:REM PSGCHORD
1210 REb:REM REBOOT
1220 POw:REM POWEROFF
1230 IR:REM I2CPOKE
1240 Sl:REM SLEEP
1250 Bs:REM BSAVE
1330 I2CPe:REM I2CPEEK

[TomXP411]

R42 was just put out without any prereleases and from a new repository that most didn't know about. It was impossible for most to discuss these new commands and functions before they were a fact.

There was a lot of talk about this, along with dozens of pre-release builds. In fact, GitHub runs a build every time code is checked in.

The thing, the talk was on Discord. It seems the forums are becoming mostly a place to store files and do long-form discussion, where the really active conversation is on the Discord.

[TomXP411]

Edited to add:
Yeah! That was it. Simply adding "@:" to the beginning of the filename prior to saving the file worked great. Also, I note that there are suddenly a LOT more doc pages on the github, with lots of great Commodore DOS data. Awesome! THANKS!

You're welcome. We tried to make sure that the most frequently asked questions made their way in there. I should probably add this to the SAVE, BSAVE, and OPEN commands' documentation, too.