Visopsys 0.91 - Return of the RAMdisk?

General discussion about Visopsys.
User avatar
Posts: 581
Joined: Tue Nov 16, 2010 7:20 pm

Re: Visopsys 0.91 - Return of the RAMdisk?

Post by andymc »

Hi Qmastery
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 ./ 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
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.

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
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:

Code: Select all

psmouse serio1: Touchpad at isa0060/serio1/input0 lost sync at byte 6
psmouse serio1: Touchpad at isa0060/serio1/input0 - driver resynced.
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 device
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.
Post Reply