I think you (or someone who knows coreboot) would have to tell me that. Right now, the /ramdisk file tells the OS loader to load the boot medium into memory and tell the kernel that it's there. Then the kernel recognizes it as the boot disk.qmastery wrote: ↑Fri Sep 03, 2021 9:41 pm 1) Is there a way for Visopsys to detect that we're running as a RAMdisk, or - alternatively - to try booting as a RAMdisk if a regular boot didn't work? Asking because my friend Mike is going to add Visopsys into ./csb_patcher.sh script which - among the other things - lets the coreboot'ers to easily get various floppy-based OS, - and it will be wonderful if we could use a fresh Visopsys floppy as-is without repackaging it by ourselves
If there was some coreboot 'hook' that could the loader could detect...
It's pretty easy to create that /ramdisk file in a script (assuming sudo/root privileges). Something like:
Code: Select all
mkdir ./tmp
mount -o loop /path/to/visopsys*floppy.img ./tmp
touch ./tmp/ramdisk
umount ./tmp
rmdir ./tmp
I have seen that sort of thing before with PS2 mice -- bytes or partial 'packets' go missing, and it's out of sync. There is a byte you can sync it to, but when I tried it, it only made things slightly less glitchy, and a lot of the mouse movement got 'lost'. If I still had a mouse that was doing that, I could give it another shot. Instead of throwing out-of-sync bytes away, construct packets with the data I do have, and infer the rest. Something like that.qmastery wrote: ↑Fri Sep 03, 2021 9:41 pm 2) On some unlucky boots, an internal touchpad of a laptop might freeze at Visopsys very soon after boot. This is probably seen at Linux as:but Linux survives this problem and a touchpad continues to work. Interesting if Visopsys could detect it and try to fix by i.e. re-initializing this input deviceCode: Select all
psmouse serio1: Touchpad at isa0060/serio1/input0 lost sync at byte 6 psmouse serio1: Touchpad at isa0060/serio1/input0 - driver resynced.