LisaList2
General Category => LisaList2 => Topic started by: bmwcyclist on April 13, 2025, 10:10:07 am
-
Is there a way to mount two .image volumes formatted for use by the ESProfile so that files, System Folders, etc. can be copied easily between them?
CiderPress does not appear to recognize the volumes.
Could a second ESProfile be used in a 2/10?
-
Could a second ESProfile be used in a 2/10?
You can definitely have two (or up to seven) connected if you have enough parallel ports. I'm not aware if something like Selector on 2-7 would be possible, since that's only brought up on the boot disk. Though, I suspect someone with some programming skills can probably write a Mac program to select a drive image on the others?
-
You should be able to boot from each drive in turn, S(elect the desired image from the Selector, and then quit the Selector and move onto the next drive until you've selected images for all of them. I had to do that recently when I ran out of space and had to transfer all my LOS compilation stuff from a 16MB to a 32MB Workshop volume!
-
You can definitely have two (or up to seven) connected if you have enough parallel ports. The trick will be using something like Selector on 2-7 wouldn't be possible, since that's only brought up on the boot disk. Though, I suspect someone with some programming skills can probably write a Mac program to select a drive image on the others?
So I can just get an external ESProfile, attach it to a rear port and it will mount a second volume?
If so that is exactly what I need.
Who has an external ESProfile to sell? :)
-
You should be able to boot from each drive in turn, S(elect the desired image from the Selector, and then quit the Selector and move onto the next drive until you've selected images for all of them. I had to do that recently when I ran out of space and had to transfer all my LOS compilation stuff from a 16MB to a 32MB Workshop volume!
I am not sure I follow. How does that allow me to have two volumes mounted to the desktop at the same time to copy between volumes(images) with only one ESProfile?
-
I am not sure I follow. How does that allow me to have two volumes mounted to the desktop at the same time to copy between volumes(images) with only one ESProfile?
Oh sorry, I didn't know you wanted to do all this with just one ESProFile unit! Unfortunately that's not really possible; you've got to have one ESProFile for each drive that you want to have mounted. Sorry for misunderstanding!
-
Oh sorry, I didn't know you wanted to do all this with just one ESProFile unit! Unfortunately that's not really possible; you've got to have one ESProFile for each drive that you want to have mounted. Sorry for misunderstanding!
All good!
Some off-topic questions: I was looking up ESProfile stuff on your GitHub, and you did an eclectic car project. Was it a full-size car?
-
You should be able to boot from each drive in turn, S(elect the desired image from the Selector, and then quit the Selector and move onto the next drive until you've selected images for all of them. I had to do that recently when I ran out of space and had to transfer all my LOS compilation stuff from a 16MB to a 32MB Workshop volume!
Ahh, yes, good call on this process. Hadn't thought of that!
-
Some off-topic questions: I was looking up ESProfile stuff on your GitHub, and you did an eclectic car project. Was it a full-size car?
Oh yeah, I forgot I had that thing on there! No, it's not an actual car that I converted to be electric or anything (I don't have that level of mechanical skill), but it's a small 6ft x 3ft ish thing that I made in high school and would ride around my neighborhood. I bolted a deck chair to the top for myself, and there was room for a passenger on the back if they wanted to stand up and hold on to the back of the chair, which is definitely pretty dangerous but actually worked really well. It was powered off 10s (so 36V) lithium ion batteries and could get about 1 hour of driving on a charge with the batteries that I had, so not too bad at all!
-
You should be able to boot from each drive in turn, S(elect the desired image from the Selector, and then quit the Selector and move onto the next drive until you've selected images for all of them. I had to do that recently when I ran out of space and had to transfer all my LOS compilation stuff from a 16MB to a 32MB Workshop volume!
Note that the Selector has some untested scripting capability (https://github.com/stepleton/cameo/blob/master/aphid/selector/MANUAL.md#scripting) that may be able to automate some coordinated set-up of multiple ESProFile or Cameo/Aphid hard drive emulators.
Meanwhile, what's this about a 32 MB Workshop volume? I had assumed that it could only be 5 or 10 MB if it wasn't a Priam drive...
-
Meanwhile, what's this about a 32 MB Workshop volume? I had assumed that it could only be 5 or 10 MB if it wasn't a Priam drive...
It doesn't work in stock LOS/Workshop, but you can do it if you patch the ProFile driver properly. I'm planning on revealing all of my progress with compiling LOS during a presentation at VCF Southwest in June (hopefully I'll be done by then), so I'll probably wait and share the details then, but it sure comes in handy for fitting all that source code on a single volume!
And interestingly enough, you can actually use up to a 16MB ProFile (or really closer to 15MB if you exclude the tag bytes) without the patch! Just make an image of 30,000 blocks or smaller, and it'll work fine.
-
Fair enough I guess, but I find this kind of proprietary "I've got a secret" posture... fairly motivating. I might try to find out how to patch the ProFile driver, and if I work it out between now and June, I might spill the beans.
Don't worry too much, it's not long till VCF SW and I'm busy.
-
I totally understand; I find the whole "secret" thing really motivating myself! And as you can probably tell from everything that's freely available on my GitHub, I don't normally like doing things this way where I keep everything a secret. It's just that this is a pretty massive project, and I think it would be a lot more exciting to reveal it all at once at an event like this than to reveal it piece by piece along the way. And besides, I'm not even done yet! But rest assured that I'll be sharing all the details and files that I possibly can once that date comes around so that everyone else can replicate things! I hope that all makes sense.
-
Please tell me this secret doesn't involve writing a Monitor/Workshop executable emulator that intercepts "syscalls"/traps in order to map them to standard POSIX functions, allowing the old tooling to be ran from a modern command line with full access to the local filesystem (ala https://github.com/ksherlock/mpw, https://github.com/eschaton/MINIXCompat, etc).
-
Please tell me this secret doesn't involve writing a Monitor/Workshop executable emulator that intercepts "syscalls"/traps in order to map them to standard POSIX functions, allowing the old tooling to be ran from a modern command line with full access to the local filesystem (ala https://github.com/ksherlock/mpw (https://github.com/ksherlock/mpw), https://github.com/eschaton/MINIXCompat (https://github.com/eschaton/MINIXCompat), etc).
No, it doesn't; even though it's painfully slow, I made a rule for myself that I have to do everything on original hardware without any modern emulators or other techniques (aside from a hard drive emulator) to help me along.
-
It's just that this is a pretty massive project, and I think it would be a lot more exciting to reveal it all at once at an event like this than to reveal it piece by piece along the way.
I have to say that I'm unmoved. Filesystem discoveries are of such basic utility to Lisa enthusiasts that big-presentation glory for one particular project (however famous) doesn't really justify keeping the secret in my book, at least not for a patch that I expect amounts to changing a single-digit number of bytes. (It will be interesting to know if that hypothesis is correct!) Other people may have other projects they want to accomplish on their machines, and in my own opinion it's better for everyone if they don't have to wait for such a fundamental enhancement.
I assume that patching the ProFile driver is a relatively small part of your efforts. If that's correct, and if wanting to "be there first" is part of your motivation, I wouldn't overestimate the number of people with the will and the patience to try and accomplish the "hard part", which is to build the Office System and its tools. Who knows, but I would expect that a lot of people have other designs on their free time between now and June.
But let's say that you did get scooped because someone else gets their hands on a big ProFile: the worst-case scenario! Maybe they will get some story-of-the-day fame on hackaday and hacker news or something. You're still the one who's going to show all your work to an excited crowd at VCF; you'll be filmed and people are going to be able to ask you questions and talk to you in person. You know the deep lore and the technical details, and your care to share your knowledge (eventually :) ) suggests to me that your work will wind up as the primary reference for how to do it.
You were not the first person to make a ProFile emulator, but ESProFile is now celebrated as one of the best and most accessible options out there, and rightly so. I expect the same outcome for your current project even if you aren't the first across the line. (Although I suspect you will be regardless.)
Big ProFile Technique is your discovery and so the knowledge is yours to do with as you wish, for now. But I may get a wild hair someday and try to figure it out for myself, and if I do, I will remain tempted to tell everyone how to do it. I'm still pretty busy, though. Maybe it's this evening that I'll finally get time to test those Monitor ProFile images...
-
...ESProFile is now celebrated as one of the best and most accessible options out there...
ESProFile "one of the best" What? Says who? It's works and it's CHEAP. Does cheap automatically make is the best? I don't agree.
-
ESProFile "one of the best" What? Says who? It's works and it's CHEAP. Does cheap automatically make is the best? I don't agree.
Oh dear, I don't intend to start a debate on two fronts!
Saying "one of" the best is a great hedge, first of all --- I didn't say "THE best". But it all depends on what a buyer is optimising for. If you're on a budget and you like a menu for choosing a disk image, then I do think ESProFile is a great choice, and I'm really glad it exists. Meanwhile, if you're looking for something that has years and years of track record and good support, then X/ProFile is a top pick. If you like an electronics project that's also been around for a while, IDEFile is a lot of fun.
I'll tell you what isn't one of the best options under just about any circumstance: my own gizmo, since they don't make the SBC I use any longer. Too bad! Plus the selection of the bidirectional level adapter ICs I used in my design was poor and led to reliability problems on the internal connector of 2/10s. It was well-documented, at least! Another not-best option is a semi-abandoned Raspberry Pi gumstick project you can find on GitHub, and same for a thing I once saw on an Italian website that purports to use a PC parallel port to emulate a ProFile (which sounds interesting but awkward these days). I would love to link to these last two projects but Google these days is not helping me track them down like it used to.
Still, that's three choices that don't count as "one of the best", which you can revise to "top 50%" of six options I mentioned if preferable. Says who? Says me :) I'm glad there are several fine emulators to choose from.
-
I have to say that I'm unmoved. Filesystem discoveries are of such basic utility to Lisa enthusiasts that big-presentation glory for one particular project (however famous) doesn't really justify keeping the secret in my book, at least not for a patch that I expect amounts to changing a single-digit number of bytes. (It will be interesting to know if that hypothesis is correct!) Other people may have other projects they want to accomplish on their machines, and in my own opinion it's better for everyone if they don't have to wait for such a fundamental enhancement.
I assume that patching the ProFile driver is a relatively small part of your efforts. If that's correct, and if wanting to "be there first" is part of your motivation, I wouldn't overestimate the number of people with the will and the patience to try and accomplish the "hard part", which is to build the Office System and its tools. Who knows, but I would expect that a lot of people have other designs on their free time between now and June.
But let's say that you did get scooped because someone else gets their hands on a big ProFile: the worst-case scenario! Maybe they will get some story-of-the-day fame on hackaday and hacker news or something. You're still the one who's going to show all your work to an excited crowd at VCF; you'll be filmed and people are going to be able to ask you questions and talk to you in person. You know the deep lore and the technical details, and your care to share your knowledge (eventually :) ) suggests to me that your work will wind up as the primary reference for how to do it.
You were not the first person to make a ProFile emulator, but ESProFile is now celebrated as one of the best and most accessible options out there, and rightly so. I expect the same outcome for your current project even if you aren't the first across the line. (Although I suspect you will be regardless.)
Big ProFile Technique is your discovery and so the knowledge is yours to do with as you wish, for now. But I may get a wild hair someday and try to figure it out for myself, and if I do, I will remain tempted to tell everyone how to do it. I'm still pretty busy, though. Maybe it's this evening that I'll finally get time to test those Monitor ProFile images...
I see your point, and I think you've convinced me!
To be clear, I wasn't trying to keep it a secret to be "first" or anything. Besides, if anyone had wanted to compile bits of LOS before this, they could've split it up across multiple disks and done it piece by piece without any sort of patch whatsoever. Heck, that's what I was doing originally myself!
Of course, I would be delusional to claim that it wouldn't be a bit disappointing for someone else to come out of nowhere and finish first after all of this work, but that isn't the primary motivation for me, and it's really just more about the excitement factor of revealing it all at once. But if it's this important to people to have the patch, then it seems like it's probably the right thing to do.
My friend @warmech is going to come on here and be the one to actually share the details because he's the one who actually found the bytes that need to be changed in the disk image itself, and so he should get most of the credit here. It's only two bytes, and after I found the bytes that needed to be changed in the Pascal source, I originally didn't even bother searching through the disk image because I figured that those bytes would show up so many times that it would be impossible to find the right occurrance. But luckily he tried it anyway and now we have this patch! A big thanks to Will; he's been very supportive ever since I started of this project, and it's always nice to share the latest successes with him and bounce ideas off him!
ESProFile "one of the best" What? Says who? It's works and it's CHEAP. Does cheap automatically make is the best? I don't agree.
This is something that is totally a matter of opinion. Some people are going to think that ESProFile is the best (or one of the best) emulators out there. Others are going to thing that X/ProFile or Cameo/Aphid or IDEFile is the best emulator. So I don't really think that this is something to argue about, given that it's very opinion-based. Different emulators have have their own unique pros and cons that are each going to matter more or less to different people.
I'll tell you what isn't one of the best options under just about any circumstance: my own gizmo, since they don't make the SBC I use any longer. Too bad! Plus the selection of the bidirectional level adapter ICs I used in my design was poor and led to reliability problems on the internal connector of 2/10s. It was well-documented, at least! Another not-best option is a semi-abandoned Raspberry Pi gumstick project you can find on GitHub, and same for a thing I once saw on an Italian website that purports to use a PC parallel port to emulate a ProFile (which sounds interesting but awkward these days). I would love to link to these last two projects but Google these days is not helping me track them down like it used to.
Another one to add to this list (in my opinion) is my old ArduinoFile emulator. It's really flaky with the 2/10 and parallel cards, and you might as well give up if you have an XLerator. Plus, the board design is ugly and a bit weird to assemble, and its diagnostic mode leaves a lot to be desired. Nobody should be building these anymore now that ESProFile is a thing!
I personally agree with Tom about the pros and cons of each emulator. ESProFile and Cameo/Aphid (with the PocketBeagle caveat for Cameo/Aphid) are great for people who want a really inexpensive emulator that allows you to select which disk image you want your Lisa to boot from at power-on. IDEFile is good for anyone who wants a fun "hardcore DIY" solution that uses parts that feel more period-accurate to the Lisa. And X/ProFile is good for anyone who wants something that's guaranteed to "just work" with customer support if anything goes wrong.
-
Howdy all.
When Alex and I were trying to figure out large(er)-scale storage options to get the LOS source on to a Lisa proper, he'd mentioned that you could flub with the block count on a ProFile image to get it higher than 10MB. I don't even remember what prompted me to go fishing through the LOS source for the ProFile drivers, but I cracked them open and it hit me like a ton of bricks. From "LISA_OS\OS\source-PROFILE.TEXT.unix.txt":
38 : (*Drive types*)
39 : T_Profile = 0;
40 : T_Seagate = 1;
41 : T_Widget = 2;
... [For context, T_Profile is a 5MB model and T_Seagate is the 10MB model] ...
283: if (discsize <= 9728) or (discsize > 30000)
284: then drivetype:= T_Profile (* set drivetype to profile *)
Anything that returns a max block count of less than 9729 or more than 30000 the Lisa treats as a 5MB Profile. There's some Widget vs Seagate logic a few more lines down but, ultimately, if it's not a T_Profile then it's a T_Seagate - fair enough. Since 30000 is an integer and this is Pascal, I reasoned that there had to just be a word in the compiled Profile driver somewhere that contained 30000. Sure enough, in LOS 3.0's first installer disk at address 0x1C7A6: $7530. Surely it couldn't be that easy... could it?
Since I don't actually have a working Lisa at my disposal at the moment, I rang up Alex and had him try a patched version (we ended up trying $FFFF ultimately) on a disk image on his ESProFile. Without any fanfare and after a loooooooooooooong wait, we were staring straight down the barrel of a 32MB ProFile in LOS. After the fact, Alex also found that this works for the first Workshop installer disk: 0x81A6 is where you want to patch.
[EDIT - There are notes in the ProFile ASM driver (I believe it was the ASM file...) that indicate that this could be expanded even further with some slightly more extensive tweaks to the driver. I haven't had any time to pry further, but the possibility allegedly exists.]
It's a relatively tiny contribution to an otherwise much, much larger project but the implications are - quite literally - huge. I'm happy to have figured it out, but it helps that it was just that simple, lol. ;D On the much more important flipside, Alex has been grinding away at all of this for some time now and I think the outcome will be a huge boon to the Lisa community. He deserves a ton of kudos for the progress he's made with the LOS source and I can't wait for y'all to see the outcome.
On another note, I second the idea that each of these emulators has their strong suits and each one occupies a slice of "best-hood". The X/ProFile does exactly what it needs to and has a rock-solid reputation; it might not be the cheapest option, but it's a damned fine product that meets about every expectation you could lob at it without fail. The ESProFile, on the other hand, is a happy blend of accessible, inexpensive, and functional; it's cheap (but not "cheap"), it's an open design, and - as Tom pointed out - it runs Selector, which is just too damned convenient not to use.
-
Thanks all for humouring my morning crankiness... this may be a simple change, but it's a really exciting new capability for the community! And it may mark a new phase in the life of Lisa OS --- how long has it been since there was a patch of any kind that added novel functionality to system? This is the first one I can remember: to me at least, LOS and the Workshop have basically been fixed in amber for as long as I've been familiar with Lisa.
I have to admit that Alex's choice of 30,000 felt like too much of a coincidence with that line in `source-PROFILE.TEXT.unix.txt`, which I had cracked open after his first message. I was minded to scan floppy images for someplace where the words $2700 (9728) and $7530 were near neighbours next --- in one of those somedays I keep waiting to come around.
And that's another exciting thing: this may be the first time that having the source code to hand has enabled a functional change to the OS, which in a way validates all the effort that Al Kossow put in to making the it available. It sounds like it's just the first of what could be many thanks to the work that's underway now.
Good luck, Alex! I can't wait to see what you've got to show us in just a few weeks!
-
Just to be clear...
Am I correct that there is no Macintosh or window software available to Mount an ESProfile image for easy maintenance and manipulation?
-
Not really, so far as I'm aware, but I don't have a lot of experience with MacWorks images, so things may be a bit easier there.
An ESProFile image is a "raw" sector-by-sector representation of what's on an Apple parallel port hard disk like a ProFile or a Widget. We have these kinds of raw images for other, modern applications --- they're often called .iso files, a term that originally referred to CD and DVD images but that I think has become more generic. Sometimes you can mount .iso files on modern OSs, but they tend to be ones that store images of drives that were created by more modern operating systems.
The challenges of treating an ESProFile like a modern disk image are these ones that I can think of:
- ProFiles and Widgets use odd sector sizes: 532 bytes, which is not a power of 2. This is unusual for modern hard disks, and I would expect that most modern software that deals with disk images may have difficulty dealing with this.
- The filesystems used by various versions of the Lisa OS were not used anywhere else, and no software or operating system that mounts disk images (yet) recognises it. It would be a fun project to use FUSE (https://en.wikipedia.org/wiki/Filesystem_in_Userspace) to give this capability to modern Unix OSs, as some have done for reading earlier MacOS media on modern MacOS (https://apple.stackexchange.com/questions/389186/reading-hfs-standard-and-mfs-on-catalina). Apple even once shipped an example of using FUSE to read old MFS volumes, but don't do this any longer. Anyway, nothing like this exists for LisaOS volumes right now.
- Let's say you want to read a MacWorks disk image. Again I'm not so familiar with MacWorks, but some (all?) MacWorks installations incorporate the Lisa Monitor OS's filesystem, so they are probably not easily readable as ordinary Macintosh volumes.
So the short answer is "not really", I think. For Lisa OS, the closest thing I can think of is Aaru (https://github.com/aaru-dps/Aaru) made by long-ago LisaList person claunia (not seen for a while!) which at least supports read-only access to the files on some hard drive image formats. I am not sure whether raw sector-by-sector dumps are among them given ProFile/Widget's weird sector size.
-
[ mis quote]
is there any software available to Mount [a hard disk used by a Lisa]
[ / mis quote]
When a SCSI drive is used by MW+/II, it remains in the same format as a MacPlus would use it, so could be moved to an older Mac with SCSI and mounted (assuming compatible drivers and so on).
As such, I think that the hard disk image on eg. BlueSCSI media might be mountable using some kind of software.
... but that's limited to images of SCSI drives, and not applicable to parallel port drive images.
-
Am I correct that there is no Macintosh or window software available to Mount an ESProfile image for easy maintenance and manipulation?
Yeah, Tom is right in terms of directly mounting and manipulating the image. The only thing you can really do to mess with an image from a modern computer is to convert it to a dc42 image using the tools included with LisaEm, and then boot LisaEm from your new dc42 file to mess with it however you need to. Then convert it back to a raw image to put back onto your ESProFile's SD card. But depending on what you're trying to do, this might be more trouble than it's worth!