General Category > LisaList2
Monitor format for ProFiles
pablo_marx:
TL;DR - I've attached a 5MB Profile disk image which, in lisaem, successfully boots into Monitor 12.3.
To work around Profile/Monitor quirks in lisaem, in addition to the NOP mentioned in an above post, I had to apply many of those within MONITOR.OBJ itself to be able to successfully talk to the Profile from within the Monitor environment. This patched MONITOR.OBJ allowed me to use S(ysmgr to Z(ero the Profile drive (&3):
Which in turn allowed me to F)ile, vM)gr to inspect the drive:
And with the drive having just been zero'ed, to create a new volume on the drive:
And of course, inspect that before shutting things down:
From here I was able to compare the layout of the disk image with the MacWorks XL profile image I posted earlier, and everything lined up the way it should. So I cobbled together the bootsector, bootloader, volume headers, and embedded a ~ 5MB volume containing the contents of monitor_12.3_copysony.
lisaem successfully booted the drive. From there we can pop into S)ysmgr and look at the M)ount table and see the drive I named PROFILE is mounted, and is set as the working drive.
And pop back into F)ile, vM)gr, and L(ist the volumes on that drive.
As always, it would be nice to see if this works on Lisa hardware or not. If it does not work, I presume its due to those NOPs in the Profile drivers and I can make an image without them. And then once its verified working on hardware, I will try to cobble together an image containing all Monitor 11 things, and another containing all Monitor 12 things.
stepleton:
I won't be able to give it a look for several hours and maybe not until tomorrow, but someone else may beat me to the punch!
In the meantime, I hope you're keeping track of all the LisaEm issues you've discovered! If I remember them correctly, they're:
- Mouse behaviour while running Smalltalk (but the mouse works fine in the Monitor editor?).
- Duplicated writes to the VIA when trying to talk to the ProFile.
I feel like these issues might be fairly easy to correct for someone who knows the LisaEm code.
I wonder if it's possible to make "universal" Monitor ProFile image: an installation that would use the Twiggy driver on Lisa 1s and the Sony driver on Lisa 2s.
pablo_marx:
I've attached another 5MB Profile image that boots into a Monitor 11 setup with Smalltalk available. Just something to add to the hardware test queue.
The mouse seemed to work fine with editor in Monitor 12. However with the editor in Monitor 11, the mouse would jump ~ 100px per movement and then just vanish from the screen. I've just now seen the hourglass move when loading Smalltalk, this time diagonally about 100px to the bottom and right.
Another issue that I encountered, admittedly minor, is that lisaem intentionally crashes when a number of things try to reboot the Lisa. This was a minor nuisance when trying to debug the patches to the Sony driver in Lisabug, and wanting to reboot the system to get it back into a good state.
pablo_marx:
--- Quote from: stepleton on April 08, 2025, 04:04:53 am ---I wonder if it's possible to make "universal" Monitor ProFile image: an installation that would use the Twiggy driver on Lisa 1s and the Sony driver on Lisa 2s.
--- End quote ---
I suspect so. There is enough space left over in the secondary loader for some added code. Could modify BOOTFILES.DATA to include both TWGDRVR7 and SNYDRVR7, change the loader to check the filename as they're read out of that file, and if it is one of those two files then check the hardware type. If there is a mismatch then don't read the file in.
pablo_marx:
Something that would be even simpler / smaller... the entries in bootfiles.data are all 16 bytes long, with the first byte containing the file name's string length in the lower four bits, and 2 in the upper four bits.
The 2 is always discarded by the loader (via subi.b #0x20, (a0)):
Could make use of that discarded 4 bits to indicate machine type. The current value of 2 would indicate all types, 3 indicates Lisa 1, 4 indicates Lisa 2.
The loader also looks at some low memory variables the ROM populated, e.g. LOMEM/MINMEM and HIMEM/MAXMEM. So it shouldn't be a problem to consult SYSTYPE to determine the type.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version