New Emulator release: R42 "Cambridge"

[TomXP411]

From: Earth, Galactic Sector ZZ9 Plural Z Alpha.
Subject: Emulator R42

The Commander X16 community has released emulator R42! This is a big release from the X16 Community development team, and boy, are we excited!

You get file system improvements (no need for SD Card image files now), new BASIC commands (sound, power, RESTORE and ASC() enhancements) and a host of other improvements.

Stop by and grab your copy of the emulator for galactic sized fun!

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

[grml]

If you want the Linux releases to be compatible with more than just a few new distributions, you should compile the binaries on an older system. The older, the better.

Otherwise, this happens (~2 year old Debian installation)
[code]
$ ./x16emu
./x16emu: /lib/x86_64-linux-gnu/libm.so.6: version `GLIBC_2.29' not found (required by ./x16emu)
./x16emu: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.33' not found (required by ./x16emu)
./x16emu: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.34' not found (required by ./x16emu)
[/code]

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.

[desertfish]

I'm not panicking!

[StephenHorn]

grml wrote:
> If you want the Linux releases to be compatible with more than just a few
> new distributions, you should compile the binaries on an older system. The
> older, the better.
>
> Otherwise, this happens (~2 year old Debian installation)
> [code]
> $ ./x16emu
> ./x16emu: /lib/x86_64-linux-gnu/libm.so.6: version `GLIBC_2.29' not found
> (required by ./x16emu)
> ./x16emu: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.33' not found
> (required by ./x16emu)
> ./x16emu: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.34' not found
> (required by ./x16emu)
> [/code]
>
> 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.

Interesting. This might not be "new", but in this case it happens to come from a new source of the problem: GitHub build artifacts. In the past, Michael rolled his own set of builds to post with an emulator update. This time around, we've directly used the results from GitHub's build pipeline. There may be a plus side, if we can setup build actions to use an older Linux distribution. Otherwise, we may instead have to look into improving the Makefile or otherwise better document the build process to make it easier for folks to roll their own Linux builds.

[waspentalive]

My Debian 11 is up to date with glibc of 2.31. When I attempt to run R42 I get error messages requesting 2.34

If you could provide a static version of x16emu that would go a long way to allowing more of us to run the emulator.

[mobluse]

I have a Raspberry Pi 4 Model B with most updated Debian GNU/Linux 11 (bullseye) aarch64 (i.e. the standard OS for this system). I think you should provide a binary also for this since it is a common computer even if it is difficult to buy right now. Normally I have compiled the emulator and ROM myself, but it would be easier if it was available as a binary. It doesn't have to be statically linked, but it should be runable if you install the required packages from the distribution using apt. Maybe the emulator for ARM64 could be included in the Linux package so that you don't need two Linux packages. Using R41 the emulator often runs at 100% with my CPU (Cortex-A72 (4) @ 1.800GHz) even when generating sound. I hope R42 also can run at 100%.

[desertfish]

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

[Daedalus]

R42 is unable to save files using the following sequence of KERNAL routines:

lda #1
ldx #8
ldy #1
jsr SETLFS
lda file_name_len
ldx #<file_bios_name
ldy #>file_bios_name
jsr SETNAM

jsr OPEN
ldx #1
jsr CHKOUT

Write file contents using CIOUT

lda #1
jsr CLOSE
rts

It works fine when I revert back to R41, so I'll just use that in the interim.

[TomXP411]

Please file an issue on the "Issues" tab on the Github page. We'll look into it.

[MooingLemur]

Daedalus wrote:
> R42 is unable to save files using the following sequence of KERNAL routines:
>
> lda #1
> ldx #8
> ldy #1
> jsr SETLFS
> lda file_name_len
> ldx #<file_bios_name
> ldy #>file_bios_name
> jsr SETNAM
>
> jsr OPEN
> ldx #1
> jsr CHKOUT
>
> Write file contents using CIOUT
>
> lda #1
> jsr CLOSE
> rts
>
> It works fine when I revert back to R41, so I'll just use that in the interim.

Is this using hostfs or an SD card image? If it's on hostfs, I suspect the problem is that the emulator now honors the CBM behavior of not allowing file overwrite by default. In order to overwrite, the overwrite flag should be specified by prepending "@:" in front of the filename, such as with "@:FILENAME"

If this isn't the problem, a fully working test case (assembled PRG, preferably) would be welcome. File I/O definitely works in R42 in this way, otherwise SAVE wouldn't work :)

After OPEN, ideally your code should be checking the command channel of DOS to ensure there hasn't been an error.