Print

[rayarachelian]

(Alliteration for the win!)
I've added a new disk tool uniplus-set-profile-size to https://github.com/rayarachelian/lisafsh-tool-libdc42.git
This is as of yet untested. Basically the uniplus kernel (/unix) hardcodes sizes for ProFiles to 10MB. The partition table is such that it will work with both 5MB and 10MB profiles. But if you've got a fancy pants new Aphid, X/ProFile, or IDE:File, which can do larger drives, 10MB, while historically correct, is a bit, um, limiting.

This will let you hack up the boot-a-hacked.dc42 disk image (installer) /unix kernel (which then gets copied to the install media) and will allow you to pick much larger drivers. This is totally untested, so, I don't know if it will work out of the box, or if it will need modifications to the install scripts or whatever.

Unlike Priam Datatowers, for some unfathomable reason, Corvus, and ProFile drives are not queried for disk size, though there's nothing technically impossible about this. (And yes, LOS and Xenix also do the same kind of dumb thing here too.) So one side effect of changing the partition table sizes for these drives in the kernel like this is that if you decide to add a 2nd drive, to say a 2x parallel port card, you'll might find it will need to be the same size. (I'm not sure if this is just for new drives or if you can attach a pre-existing 5MB UniPlus drive and just mount it as is, but it's true at the block level - if not at the file system level.)

This was a side-side-side quest, hence the lack of testing, as my goal here was to disassemble to profile driver for LisaEm and insert HLE take over points.
Yes, I know uniplus source exists, I've been using them, however machine code is not the same as C code, so I needed to first make a Rosetta stone between pro.c and machine code so I know where to take over with native code. (see the files board for this Rosetta stone.)

If this tool is useful, great, if not, I'll delete it from the next release. Enjoy.
Eventually it may be possible to patch /unix and add extra code to read from block 0x00ffffff and populate this table automagically, but today's not that day. Why not? Because Unixy a.out/COFF non-elf files have text and data sections and I'm not sure I can add stuff at the end of the data section and still have it be executable properly. And if they're not I wouldn't easily be able to move the data section stuff without making some horrific changes all over the place.
And no, the UniPlus kernel source isn't compilable as is, some header and module files are missing. (And the binary implies that there are differences from the source code anyway not explainable by #ifdef defines.)

I'll likely eventually do something similar for LOS and Xenix to remove their 10MB ProFile limits as well.Luckily MacWorks doesn't have this stupid problem.

The tool is somewhat dd like in it's options, and somewhat fdisk like in its operation. If you don't know what dd and fdisk mean, don't use this tool. Oh, and do expect bugs and all sorts of weird things to happen.

[stepleton]

Well, this has nerd-sniped me pretty well this evening.

UniPlus is installing now on a 256M volume on my Cameo/Aphid right now. I don't know if it will work yet.

The hurdles so far have involved:
- Getting lisafsh-tool and friends to build without wanting the wxworld installed
- Specifying the right number of blocks for 256M*
- Editing the root filesystem disk image by hand so that the UniPlus ./install script makes a filesystem with 519472 blocks**
- One failure so far. It might be because I tried using a 4800-block swap partition. I'm trying a 2400-block partition now.

The symptom of the failure is that the kernel boots but the system hangs after it prints "2 serial ports". In my experience, this is a sign of it not finding something it needs on the filesystem --- the same problem crops up during installation when you don't use the modified root floppy image with "undeleted files" from this page.

* (I can't use the convenience "256M" syntax that uniplus-set-profile-size allows, since Aphid uses the number of blocks for a 256M disk that's specified in the X/ProFile manual: 0x7FFF0 blocks. I don't think this will be the same as the number of blocks that "256M" implies. I need 524272 blocks)

** The install script has hard-coded numbers for 5M and 10M drives. As for 519472, this is a relic --- it should actually be 521872, but the number is slightly smaller thanks to sticking with the value that was right for a 4800-block swap partition.

[stepleton]

Closer but still no cigar. It was going so well, too --- with a 2400-block swap partition, it booted normally and started installing the full distribution off of floppies. Unfortunately, at unlucky floppy #13 it decided it was out of disk space. Here's a picture of the accident scene:

https://photos.app.goo.gl/VvNkovKs6sdKDtWg6

It's possible that 256M is just too big for UniPlus or its filesystem. A smaller size may be worth trying.

[rayarachelian]

Well, this has nerd-sniped me pretty well this evening.

Glad to hear I made someone happy!

UniPlus is installing now on a 256M volume on my Cameo/Aphid right now. I don't know if it will work yet.

The hurdles so far have involved:
- Getting lisafsh-tool and friends to build without wanting the wxworld installed

Oh, thanks for letting me know. I thought I fixed this, it should ignore it and use the get-uintX-types.c to create machine.h without requiring wxWidgets, but I think maybe the build script library in bashbuild still has that requirement since it shares it with the rest of LisaEm. I think deleting  post-wx-config.fn for the standalone lisafsh-tool distro should be the thing to do, but I've not tested that. I'll give it a shot.

- Specifying the right number of blocks for 256M*
- Editing the root filesystem disk image by hand so that the UniPlus ./install script makes a filesystem with 519472 blocks**
- One failure so far. It might be because I tried using a 4800-block swap partition. I'm trying a 2400-block partition now.

The symptom of the failure is that the kernel boots but the system hangs after it prints "2 serial ports". In my experience, this is a sign of it not finding something it needs on the filesystem --- the same problem crops up during installation when you don't use the modified root floppy image with "undeleted files" from this page.

* (I can't use the convenience "256M" syntax that uniplus-set-profile-size allows, since Aphid uses the number of blocks for a 256M disk that's specified in the X/ProFile manual: 0x7FFF0 blocks. I don't think this will be the same as the number of blocks that "256M" implies. I need 524272 blocks)

** The install script has hard-coded numbers for 5M and 10M drives. As for 519472, this is a relic --- it should actually be 521872, but the number is slightly smaller thanks to sticking with the value that was right for a 4800-block swap partition.

Funny, I'm at the same state with UniPlus after adding some hacks to ignore the profile errors. Hangs right after it shows 2 serial ports.

I've seen this before as well. I suppose we'll need to figure out the install script and modify it to match whatever is set in the kernel.

The convenience sizes can be changed in the code, no worries there.

In the UniPlus source code, these are the swap sizes I see. I expect the exact size isn't important on SD/TF/CF media, but rather on a physical drive, it's set to be the exact size as several cylinders to prevent slowdowns. (The size is of course memory size related.)

Code: [Select]

./include/sys/swapsz.h:#define  PRNSWAP 2400            /* swap size for ProFile */
./include/sys/swapsz.h:#define  CVNSWAP 3959            /* swap size for Corvus */
./include/sys/swapsz.h:#define  PMNSWAP 4000            /* swap size for Priam */

The hard part will be figuring out what will let it work.

There's also questions about mkfs and if it has any inherent limits. I don't see source code for mkfs. So maybe if 256M doesn't work, maybe try less. For sure, it supports Priam so that 80MB or 79MB  may be a good size to try first and see if it can be made to work, then maybe try 128M, and so on.

Many thanks for giving it a whirl. It frees up cycles for me to try to get uniplus to work on LisaEm.
About the disk 13 failure, most likely mkfs hasn't made the requested disk size and was left with something smaller. It too may need modifications.
Did any time this error show on the screen? If not that's good news it means the kernel isn't blocking the writes to blocks above 10MB.

    p->pd_err ="invalid blkno";[/size][/font]

[compu_85]

Sweet! Looking forward to trying this out!

FWIW, when I was running 2 Widgets on a 2/10 with Xenix, I could format the Widget attached to a parallel port card to 10m, but anything beyond the 5mb boundary went into nowhereland.

-J

[rayarachelian]

Sweet! Looking forward to trying this out!

FWIW, when I was running 2 Widgets on a 2/10 with Xenix, I could format the Widget attached to a parallel port card to 10m, but anything beyond the 5mb boundary went into nowhereland.

Yeah, not sure about Xenix, haven't disassembled it yet, however what uniplus does is a partition trick. the partition table has entries for both 5MB and 10MB drives and somehow the installer knows the size of the media and decides which partitions to use for root and swap. But if you use a corvus drive, it allocates the entire space to just root and swap.

Weird logic.

[rayarachelian]

I think I know why the above failed. I only patched /unix (v1.4) on the boot floppy, however, there's another kernel on the floppy called /sunix that's v1.1 - and this guy is what runs the install script.

see: https://lisalist2.com/index.php/topic,52.msg1234.html#msg1234

[rayarachelian]

So yeah, when I wrote this code I hadn't realized that "sunix" was a separate kernel (v1.1 vs v1.4) and as such it has it's own partition table that's identical. I didn't catch it the first time around because it's split across two different sectors. It should be available on the next push to unstable and separately libdc42, but likely it will need updates to the script that runs mkfs as well.

I've also added patches to LisaEm when a profile larger than 10MBs is used to modify the partition table in RAM. There's a slight issue here - since the partition table isn't stored anywhere, if you create a larger volume on an Aphid, X/ProFile, IDE::File and patch uniplus, the same parameters must be passed to LisaEm exactly for patching the image. I don't yet have a mechanism to do that, so was just making assumptions about the partition table, but I'll have to think up a mechanism for properly dealing with this.

i.e. if you install on real hardware, then use BLU to transfer to LisaEm (and convert to dc42). Likely the best way to go is to detect a patch and not to patch it when it's already patched. Obviously in this case if you have extra volumes, they all must be the same as as the large volume, or to be safe, just have a single large drive.

Many thanks for @compu_85 who provided a BLU image of a UniPlus install to play with, and also to jamesdenton for walking me through some of the details of how uniplus formats the ProFile and its setup script.

Don't yet have either v1.1 or v1.4 kernels booting all the way up, but I suspect it's around the BSY transitions not properly signalling interrupts. It's possible that Xenix is affected the same way.

I did add an option to fake 800k drives and both v1.1 and v1.4 report MicroDiskette with 2 heads. I also patched the keyboard ID cops code to only report to the Boot ROM, I don't see any ill effects from this in LOS so I'll leave it.