#2144 ramlink image handling broken in 3.9 - fine in 3.8

[Erhan]

this ramlink image https://www.dropbox.com/scl/fi/1ojjiav1q8o19x3a03ebj/ramlink.zip?rlkey=vn5688lijf4mv2wz7p3h8igte&e=1&st=sthzsojw&dl=0 was working fine in vice 3.8, it's 8 mb image file, was working both with command line or from preferences GUI. 2.01 bios used.

it doesn't work in 3.9, causes force shutdown. even i enable ramlink at last step, shutdown happens with crt header error. with same 2.01 bios.

another bug for ramlink, vice 3.9 : (executed from console) preferences GUI, ramlink settings, after choosing bios and a blank 0 byte ram image for example, then adjusting ramlink size with + and -, some capacities give error in console window, some become invalid values. probably this causes above bug explained. 8 mb image becomes invalid.

[radius75]

I confirm. Starting RAMlink with 8MB size configuration causes the emulator to crash. With 16MB the emulator starts without a problem. The problem appears when something other than 16MB is set

--

Error - failed to set resource 'RAMLINKsize' to 15
Error - failed to set resource 'RAMLINKsize' to 14
Error - failed to set resource 'RAMLINKsize' to 11
Error - failed to set resource 'RAMLINKsize' to 10
VIC-II: VSP Bug: safe channels are: 13567. Emulation of memory corruption is disabled.
Main CPU: RESET.
VSync: Sync reset
Unit 8: RESET.
Error - no CRT header found.
CART: 'D:\Gry\_Commodore64\JiffyDOS-full\cmd ramlink-dos-v2.01.bin' is not a valid CRT file.
VIC-II: VSP Bug: safe channels are: 0123457. Emulation of memory corruption is disabled.
VIC-II: VSP Bug: safe channels are: 012345. Emulation of memory corruption is disabled.
VIC-II: VSP Bug: safe channels are: 0346. Emulation of memory corruption is disabled.
CART: attached 'D:\Gry\_Commodore64\JiffyDOS-full\cmd ramlink-dos-v2.01.bin' as ID 73.
Main CPU: RESET.
VSync: Sync reset
Unit 8: RESET.

[gpz]

What exactly do i have to do to reproduce this? :)

[radius75]

Run x64sc / default
select ram link dos 2.01
set 8MB
enable RAMlink

[Erhan]

of course, if you run x64sc (official 3.8 gtk vice) , from settings GUI, ramlink, select 2.01 bios and this ramlink.rl (8 mb) file and set capacity to 8 mb and enable ramlink. everything is fine. it's proper ramlink image with some games (compatible with ramlink, n0sdos) inside ramlink native partition.

[Querino]

https://sourceforge.net/p/vice-emu/code/45391/

maybe it helps. though i guess it was obvious.

[Roberto Muscedere]

No, there is a bug. It is a sign/comparison issue. Found it and I'm fixing it.
I had some new code in here that I thought was inactive, but somehow this compare got out.

[Roberto Muscedere]

Ok, I was wrong at that last comment. That is in regards to new code I'm developing.
It seems that the "-cartramlink {name}" switch is equivalent to "-ramlinkbios {name} -ramlink". If you use "-ramlinkbios" you must also include "-ramlink".
However, you are correct with the GUI settings for ramlink. Checking/unchecking "Enable RAMLink emulation" with any file selected for the BIOS causes an assertion:

CART: '/home/rmusced/vicesvn/rlsample/dummy' is not a valid CRT file.
x64: mainlock.c:164: mainlock_yield_begin: Assertion 'mainlock_is_vice_thread()' failed.

Even if I use a valid CRT file instead of the RAW binary, it still fails.

I've seen this error before, but I'm not sure what it is; something to do with the GUI which I'm not the maintainer on.

[compyx]

I suspect the UI code is altering a resource without obtaining the main lock, triggering the assertion. I'll have a look.

[Querino]

but VICE implodes by just starting with something like

x64sc -default -ramlinkbios "C:\MSYS\CMD\CMD_RAMLink_DOSV202.crt" -ramlink -ramlinksize "8"

some sizes work, some don't. the same when changing in the GUI and do a reset.

[compyx]

I got this backtrace while enabling RAMLink (through the UI, after closing the dialog):

CART: attached '/home/compyx/Downloads/ramlink201.bin' as ID 73.
Main CPU: RESET.
VSync: Sync reset
Unit 8: RESET.
Process 60732 stopped

* thread #12, name = 'x64sc', stop reason = signal SIGSEGV: address not mapped to object (fault address: 0x555659b15d6f)
    frame #0: 0x0000555555687a68 x64sc`ramlink_io1_read [inlined] ramlink_io1_read(addr=<unavailable>) at ramlink.c:1372:17
   1369         return val;
   1370     } else if (rl_io1mode == 1) {
   1371         if (rl_cardbase != -1) {
-> 1372             val = rl_card[rl_cardbase | (addr & 0xff)];
   1373             IDBG((LOG, "RAMLINK: io1 r card[%06x] = %02x at 0x%04x", rl_cardbase |
   1374                 (addr & 0xff), val, reg_pc));
   1375         } else {
(lldb) q

I was playing around with the spin button that changes the RAM size. not sure what setting I was using.

[Roberto Muscedere]

Yes, there still is the size bug I referred to initially. I will submit the change soon.

[Roberto Muscedere]

Should be fixed in r45704.

[radius75]

Error - failed to set resource 'RAMLINKsize' to 6
Error - failed to set resource 'RAMLINKsize' to 7
Error - failed to set resource 'RAMLINKsize' to 10
Error - failed to set resource 'RAMLINKsize' to 11
Error - failed to set resource 'RAMLINKsize' to 14
Error - failed to set resource 'RAMLINKsize' to 15

The emulator no longer crashes.

--

And besides, I think I once checked in Vice how much free memory RL sees depending on the 0-16MB setting
And those were completely different values than I read now.

--

I found it. This is from two years ago.
https://sourceforge.net/p/vice-emu/bugs/1949/#24e2/b3db/2310/c453
Now (r45704) the number of free blocks is different. It increases evenly.

[Roberto Muscedere]

This is normal. The change made in ramlink between 3.8 and 3.9 was better emulation of how it physically interacts with memory (overlaps, wrap arounds, open-bus). Memory sizes of 6, 7, 10, 11, 14, and 15 aren't physically possible on a real ramlink so they aren't allowed now. The GUI is being adjusted to accommodate.
In regards to the crashing, I chose a datatype that I thought was consistent across all compilers and platforms, but it wasn't. You learn something new every day.

As for your blocks free table, some of the values don't make sense. Changing the size of any of the ram devices connected to ramlink requires a c64/c128 "reset" as well as purging any memory save files, or else weird things can happen. Ramlink wasn't designed for dynamic memory size adjustments.

There is an easier way to understand the blocks free on the default native partitions. Ramlink 2.01 looks for an REU or GEORAM, and then a ramcard. It will always put the system partition at the end of the ramcard if available, otherwise it will be at the end of the REU or GEORAM. So if you only have an REU or GEORAM, you will always loose 256 blocks. (It is actually 16 blocks, but since native partitions have to be in multiples of 256 blocks, you can't use the remaining 240 blocks of free space unless you use 1541/71/81 emulated partitions in some perfect combination.)
Native partitions have an overhead of 64 blocks for the boot sector, header, bam, and fixed directory entries.
So if you use just GEORAM/REU, your default native partition space will be "SIZE"-256-64 blocks, but if you have a ramcard installed, it will be "SIZE"-64 blocks. On the ramcard side, the system partition will always be placed there, so your native partition size will always be "SIZE"-256-64 blocks.

[radius75]

Ah... I was convinced that this is how it should be as I once noted and I thought that a real RAMlink would behave so strangely when dividing free space depending on the unusual size of installed memory 😆
I trusted emulation.

But I hope I should have my real RL soon.

Thank you for the comprehensive explanation.