LisaList2
General Category => LisaList2 => Topic started by: stepleton on May 09, 2020, 08:46:18 pm
-
This is a long-shot question: does anyone know anything about the hard drive format used by the Monitor?
(For those not aware: the Monitor is the internal-only* operating system and development environment that Apple used when creating the Lisa OS and applications that it released to the public. The Monitor is a bit like a cross between the Pascal Workshop and the UCSD p-System (https://en.wikipedia.org/wiki/UCSD_Pascal), perhaps being closer to the p-System. There are a few Monitor floppy disk images on Bitsavers, as well as some user documentation. There is also a source listing that may answer my question, but I haven't examined it too closely yet.)
Without documentation about Monitor internals (that I'm aware of), you might not expect to have much to go on when making guesses about how the filesystem is organised. As it turns out, though, the floppy images use the same filesystem as the p-System. If you extract all of the sector data from a disk image and place it in a single file, you can read it just fine with utilities from this project (http://ucsd-psystem-fs.sourceforge.net/). The disks make no use of sector tags (except to mark sector 0 as bootable). Additionally, the affordances of the Monitor file manager and hints from the user documentation suggest that a hard drive would also use a p-System-like filesystem.
With that in mind, I have tried using the filesystem utilities linked above to make a fresh 5 megabyte p-System filesystem image, then giving that image some blank sector tags and loading it into my ProFile emulator. This does change the behaviour of the Monitor version I tried it with---it seems to make it crash more! (More than it did with a hard drive image with BLU on it.) There are many possible reasons for this behaviour, but it may be because the Monitor is trying to read the filesystem and is getting some unexpected data (zeroes, in fact) back instead---that is, my formatting is incorrect.
There are many additional diagnostic and trial-and-error things to attempt to figure out what's going on, but I thought I'd ask just in case---does anyone just happen to know how the Monitor filesystem was arranged on ProFiles? If so, I'd love to hear about it...
* Internal-only: technically LisaTest was an externally-released Monitor disk, but it booted straightaway into the LisaTest GUI and didn't let you use the p-System-like user environment.
-
I've never seen monitor installed on a profile, so that's pretty cool. I'd ask to try to figure out what the maximum sector number it searched for was? This may help figure out what the internal limits are. i.e. is it 16 bits, 12 bits? some other thing?
How is to booting? Did you find a bootloader for Profiles for Monitor or did you use your own? If you used your own, how does monitor know where it's file system starts and the boot loader end?
This might also help: http://ucsd-psystem-fs.sourceforge.net/ucsd-psystem-fs-1.22.pdf but it's way too modern, and it does mention interleave, so not sure if the one from 77 of whatever the Lisa used would have it too.
This might help: http://bitsavers.org/pdf/apple/lisa/pascal_monitor/Monitor_11_Listing_Sep82.pdf
Not to be a one trick pony and say that this is a nail, but I'd approach this by enabling tracelog in LisaEm like so: `./build.sh --with-debug --with-tracelog` - with 1.2.6 I'd enable the define that turns on tracelog on start, on 1.2.7, I'd add `--with-debug-on-start` and then boot monitor from a profile as you've set it up. The tracelog it would generate would produce many gigs of output but it would contain everything Monitor did and tried to do, but failed.
Next I'd ask if it's smart enough to do some sort of interleave on the hard drive, but I'd guess it likely wouldn't.
-
So in http://bitsavers.org/pdf/apple/lisa/pascal_monitor/Monitor_11_Listing_Sep82.pdf on page 21 at address 0B12 there's a mention of cluster size and another comment saying #$100 (256) is the start of the volume table.
On page 23 there are comments about profiles with and without headers, not sure what the difference is. page25 has mentions of corvus and pipin and "cable disk" - interesting.
Bingo! page 29 at 110C there is an 9:1 interleave table. Likely that's what you need to make this work
I wonder what this Marksman interface was (page 32-33), there's mention of a 4 port PIA (Parallel Interface?)
At 2924 on page 63 we see the 1st block is 0000 and the last is 7fff. So that gives you the max size of the disk to 32768 blocks or 16384K or 16MB, but don't know how clusters work here so that would change the size to much larger.
At page 90 3C42 mentions macsbug (which is also on the mac - but the mac in macsbug does not stand for macintosh, rather it comes from motorola as a 68000 debugger). Warms my heart to see it mentioned here. Good times. :)
-
Thanks for the insights!
I think I wasn't clear in my initial post---I'm not booting from a ProFile, or even accessing a ProFile successfully at all. I'm still starting Monitor from Twiggies, and then trying to get it to do anything with the ProFile besides fail to access it. I'd like to have a bootable Monitor ProFile someday, but am not even certain how possible this might be. On the other hand, it may not be too hard, and you might even get my bootloader to do it with some tweaks...
Anyway, your thoughts inspired me to spend several hours this afternoon poring over the listing and experimenting.
1. The first thing I tried is just filling every block on the disk image with an empty p-System disk catalog. Forget interleaving---if it reads anything on the disk, it's going to find that the disk is formatted and has no files on it. Sadly, no joy. The system seems to carry on as if no drive were plugged in---well, except for randomly crashing into MacsBug with an unserviced level 5 interrupt all the time. Not sure why it does this.
2. Now, looking at PDSKRD in the monitor listing ($121C on), it seems like there's a simple disk block checksum mechanism at work during reads. If the read is configured to use disk headers, then the checksum is computed over the entire 532-byte block; otherwise it only does a checksum of the 512 data bytes (and then ignores them; statements $12B8 and $12BC). I think you can bypass the checksum check in "header mode", though, if the seventh byte of the header is positive (statements $12BE and $12C2). So I tried filling every byte of every header with the obviously positive byte $21. Still didn't work.
3. Although LisaEm would surely have been effective for peeking behind the scenes, I decided to investigate the Monitor's disk activity with my hard drive emulator---it's easy to do, since it's a tiny Linux computer, and you can just log in and watch the log messages scroll by. On boot (and when you attempt to mount a ProFile in the System Manager as well), the Monitor attempts to access blocks $000003 and $000007, which, if I've reversed the interleave scheme correctly, means that the Monitor was asking for blocks 7 and then 11... but only if we were in header mode! (Statements $11F0 and $11F4; in "non-header mode", it looks like you don't interleave.
Unfortunately none of these blocks make sense to me. On floppies, block 3 is the second block of the file directory., block 7 is the second block of the first file on the disk, and block 11 is the sixth block of the first file (assuming it extends that far). I'm not sure---maybe the filesystem layout is different in hard drives?
I guess the main thing to figure out then is why it tries to access these blocks. I still haven't been able to pinpoint the spot in the code where it does this. Hmm...
-
Well, an update---it turns out that I was silly and missed something important. You can initialise a ProFile in the Monitor after all---just use the Z(ero command in the S(ysMgr. Reads and writes to the ProFile work just fine after that.
There is however an additional problem, which is that if you restart the computer (and boot the Monitor from a Twiggy again), the Monitor will now hang at some point midway through the startup process. Fortunately the Monitor has installed MacsBug prior to the freeze. I've started to use it to investigate the hangs, but have some ways to go. It seems that the Monitor is trying to report an I/O error of some kind and is waiting for the user to acknowledge this by typing the space bar, but no message appears on the screen and pressing the space bar does nothing. It's possible that this communication is actually going to somewhere besides the screen, though I haven't had any success yet from listening in on the serial ports.
The freezing occurs only when an initialised ProFile is attached to the parallel port---if you have an uninitialised ProFile ready, then it will still boot. This freezing behaviour occurs even when the ProFile has an Office System 1.0 filesystem installed (instead of a Monitor filesystem---I'm not sure how similar these filesystems are---or if whether might be the same). It doesn't seem to matter whether you're using a genuine ProFile or an emulator, though I haven't tried initialising my real ProFile (I don't want to blow away my Office System install on that disk right now).
Other notes:
After reading Monitor documentation on Bitsavers, I haven't seen any evidence that you could install and boot the Monitor off of a ProFile. There's discussion of using the ProFile as a working drive, but nothing about how to install a bootloader or anything like that that I can recall. It's possible that Apple folk just always booted the Monitor off of floppies or from the connected Apple machine (the documentation often discusses having an additional "Apple" of some kind as part of your workstation).
I've determined that the unserviced Level 5 interrupts that I had mentioned upthread were probably being raised by my AppleNet card. Removing the AppleNet card seems to have got rid of these.
-
Well, an update---it turns out that I was silly and missed something important. You can initialise a ProFile in the Monitor after all---just use the Z(ero command in the S(ysMgr. Reads and writes to the ProFile work just fine after that.
Do you recall what the ProFile showed up as in the Devices list? I am using Monitor 12.3 on a Lisa2, and all I get are DRIVE1 and DRIVE2, with DRIVE2 being the 'working' device. Any attempt to communicate with DRIVE1 just hangs the system. That said, there does not appear to be a way to unmount the 'working' floppy device to load additional resources. Access to a ProFile would be handy here.
I assume the guide you're referring to is this? http://www.bitsavers.org/pdf/apple/lisa/pascal_monitor/The_Pascal_Development_System_Manual_Feb82.pdf
Page 57 mentions using a ProFile, but not booting from one. But, it does mention 'Transfer all of the files on the female boot diskette (to the profile)', so I dunno.
Anyway, I can't see my ProFile to even Zero it out.
-
I'm afraid I don't remember much that's useful here --- I guess I just let this project fall by the wayside! I have a distant memory rattling around in my head that you have to mark the drive as being attached to the system somehow (something like mounting in Unix), but I really can't recall anything useful. Sorry about that!
-
Rereading, I do remember copying the system files to the ProFile at one point with high hopes that it might do something to enable booting from the hard drive, but it didn't work in my experiments.
I'd forgotten about the odd gendered terminology that the documentation uses: there's the word "male" for little-endian (and hence the 6502-powered Apple II is "male") and "female" for big-endian, which, well, "Lisa" I guess. It was important to talk about these things because you could apparently have Monitor setups where a Lisa and II could be connected together. It sounds like you would use the II to get the ball rolling, which I suspect was a more common thing to do as the Lisa hardware was still under development.
PDF page 4 also drops unhelpful hints:
To boot from a diskette based Apple II, first power up the Apple II with the male boot diskette in drive #4:. Insert the female boot in drive #5: and power up the Lisa. The female boot volume can also reside on a hard disk. SYSTEM.STARTUP on the male boot volume automatically executes MONBOOT, the program that starts up the Monitor on the Lisa. If you type space during the boot process, MONBOOT is not executed. If you type 'D' during the boot process, the debugging version of the Monitor is booted.
It still sounds to me like disks on the Lisa side are just used for data storage here and not booting.
-
I have a distant memory rattling around in my head that you have to mark the drive as being attached to the system somehow (something like mounting in Unix), but I really can't recall anything useful
...
It still sounds to me like disks on the Lisa side are just used for data storage here and not booting.
That's OK with me, as long as I can change the working device to the ProFile vs floppy. I need to play around with it and see where that attachment point happens. Thanks for the tip!
-
I am using Monitor 12.3 on a Lisa2, and all I get are DRIVE1 and DRIVE2, with DRIVE2 being the 'working' device. Any attempt to communicate with DRIVE1 just hangs the system.
Is it possible that since 12.3 is a point release, and seems to be the only one for Sony drives, that DRIVE1/DRIVE2 refers to the old Twiggies and that 12.3 was a quick and dirty hack to add Sony compatibility? I seem to remember some piece of software somewhere that still refers to the Sony drive as the "lower floppy" which is where the second Twiggy drive was in the Lisa 1.
-
This is a long-shot question: does anyone know anything about the hard drive format used by the Monitor?
The Monitor file system, at least on the floppy disks, is the UCSD P-System, same as on the Apple II Pascal system, except it's big-endian. I documented the format and wrote an interpreter for it just a few months ago.
-
Oh interesting! As I was trying to format a ProFile for the Monitor, one of the things I did (or at least I think I did it) was to create a disk image in Apple II Pascal in an emulator and see if that image would work when transferred directly to a ProFile emulator. The endianity issue could be one reason it didn't go anywhere :)
Have you put any of your work online? But maybe more importantly --- is there something that would suggest to you that the format would allow you to boot from the disk? For example, one clue might be that the first few blocks are not used, making room for a bootloader.
-
*bump* yes pls, give us a pointer to this. Not committing to anything, but perhaps I could add support for this fs in lisafsh-tool, or something else eventually.
-
I attached two useful text files to this post. The first is an except from Apple's Monitor documentation, from a PDF on Bitsavers. It explicitly says "After the Monitor is installed [on the ProFile], you will still boot with the Monitor Boot disk."
So there's your answer from the horse's mouth regarding booting from a hard disk.
The second text file is the Apple Pascal 5.25" disk format for Apple II. You can also find a description of Apple Pascal disk format in the Call-APPLE publication called "All About Apple Pascal." It's documented in a few other sources too.
Like I said earlier, Lisa Monitor's format is exactly the same (so far as I know) as Apple II Pascal, except that word-length values are in big-endian order.
As far as code, I think that you could take DiscImageChef's (https://github.com/aaru-dps/Aaru/tree/master/Aaru.Filesystems) Pascal FS module and modify it. Within the Apple II community, you should also find one or two projects which can read Apple II Pascal formatted disks.
-
Oh, and by the way, last November I added Monitor format to my Vault archive site so you can click through and browse the contents of Lisa Monitor disks. And you can link directly to files within the disks. The URLs will never change.
This is neat. Take a look at some examples:
https://macgui.com/spyglass/r/7e8a7a533c8dfb56
https://macgui.com/spyglass/r/c65d7e778b0d2b79
https://macgui.com/spyglass/r/0f87d6f7c1cb821d
LisaTest is a Monitor-format disk. The feature is called "look inside with Spyglass" in the Downloads section of my site.
-
That file browser is nice. Looking through one of the files reminds me of another problem I've had with the Monitor disk images on Bitsavers: not being able to run Editor.obj. The error message mentions something about a font file, if memory serves. It's been a while...
Like everything Monitor, this feels fixable with some hacking. Even the fact of not being able to boot off the hard drive feels negotiable. The format document you've provided says "Blocks 0 and 1 are the boot blocks", and that ought to be plenty to fit a bootloader that can read the simple filesystem. We have source code for Monitor 11.6, and this might provide hints that would indicate what other changes should be made to the Monitor "kernel" itself (I don't think it calls itself that) so that it's happy to start on a hard disk.
A good reason to do this would be to make a convenient standalone Monitor drive image that can boot the Smalltalk environment that you find on one of the Bitsavers disks. Right now you need a Lisa 1 to run it --- the Monitor in one of the drives and the Smalltalk disk in the other. It's nice if you're patient. (For anyone who feels like trying this: Smalltalk won't run under the version 12 Monitors; I've always run it under 11.6.)
Speaking of bitsavers --- that useful second document you found made me head back to http://bitsavers.org/pdf/apple/lisa/pascal_monitor/ to see where you'd extracted that text from. I came up short! Do you have a link to the original somewhere? I probably have just not done a good enough job of scanning the PDFs, but I'm curious to know if there are Monitor docs in a different directory that I may have missed.
-
Speaking of bitsavers --- that useful second document you found made me head back to http://bitsavers.org/pdf/apple/lisa/pascal_monitor/ to see where you'd extracted that text from. I came up short! Do you have a link to the original somewhere? I probably have just not done a good enough job of scanning the PDFs, but I'm curious to know if there are Monitor docs in a different directory that I may have missed.
I may have misspoken the source. It's from Apple Macintosh developer documentation. It's from the early version of Inside Macintosh, distributed to developers in fall 1983 or spring 1984. It just tells you how to set up Monitor to use for developing Macintosh applications.
-
That file browser is nice. Looking through one of the files reminds me of another problem I've had with the Monitor disk images on Bitsavers: not being able to run Editor.obj. The error message mentions something about a font file, if memory serves. It's been a while...
Just ran across it here: http://www.bitsavers.org/pdf/apple/lisa/pascal_monitor/The_Pascal_Development_System_Manual_Feb82.pdf page 62:
The Pascal Development System Manual THE EDITOR File needed:
EDITOR.OBJ
LISA:EDITOR.FONT
LISA:EDITOR.MENUS
LISA:SYSTEM.FONT
And on page: 64
CUSTOMIZING THE EDITOR
The editor uses whatever font it finds in the file LISA:EDITOR.FONT to display the folder contents. The suggested fonts are:
TITLE12R12S.F 20 lines x 82 chars
SARA8.F 26 lines x 83 chars
TlLEX.F 32 lines x 82 chars (default)
TlLE7R15S.F 32 lines x 94 chars
TlLE5R18S.F 37 lines x 132 chars
-
Here's another little tidbit I came across today:
The Filer will create a volume with a large directory, capable of storing 786 file names, so long as the volume size is greater than 2048 blocks (1 MB).
Also, I have a possible reason why the Monitor did not automatically boot from the ProFile. It's because the Lisa developers also had Lisa OS installed in another partition on the ProFile, and they wanted LOS to boot from it instead of Monitor. And they did not yet have a way to pick which OS to boot from the ProFile.
-
Also wondering, how did one transfer files from Monitor to LOS? Did LOS 1.x understand the Monitor file system or vice versa?
-
That file browser is nice. Looking through one of the files reminds me of another problem I've had with the Monitor disk images on Bitsavers: not being able to run Editor.obj. The error message mentions something about a font file, if memory serves. It's been a while...
I've attached a 400k disk image for a Monitor 12.3 system (based on monitor_12.3_copysony.dc42) with a working setup for The Mouse Editor (cobbled together from lisav.dc42, root1.dc42, root2.dc42). You'll want to use the File menu, Open or Tear Off Stationary, and use one of: MEMO, MACROS, PAPER. I'll detail soon how this disk image was made.
(https://i.imgur.com/KkZvG0j.png)
(https://i.imgur.com/QAzl9HS.png)
(https://i.imgur.com/bv3Pxco.png)
(https://i.imgur.com/3EToKUn.png)
-
Nice! Looking forward to reading about how you did this one.
-
I've attached two more 400k disk images that I find more technically impressive than the above, but as they only contain a barebones Monitor environment neither is particularly useful on their own. Both of these originated from Monitor 11 Twiggy disks. The boot sector and MON.LOADER were replaced with those from monitor_12.3_copysony. The TWGDRVR7.OBJ was replaced with a patched SNYDRVR7.OBJ, and BOOTFILES.DATA modified to search for SNYDRVR7.obj instead of TWGDRVR7.obj.
The patches to the Sony driver were fairly minimal, and guided by diffing a Twiggy driver from a Monitor 12 disk against one on a Monitor 11 disk. One of the patches had to deal with interrupts (Monitor 12 seems to use TRAP $D to deal with them, and on Monitor 11 that trap just enters a level 7 interrupt / LisaBug). The other two patches deal with what is presumably the disk buffers provided by the Monitor.
lk026_mon11.1 (Sony).dc42:
(https://i.imgur.com/UVpWrJI.png)
lk025_mon11.8 (Sony).dc42
(https://i.imgur.com/cDIFOWQ.png)
-
Excellent. Let me propose a challenge for you --- obviously it's up to you to decide if you want to give it a go!
Given that you have 11.8 working on a Lisa 2 (or is it 11.6 despite what the disk image is called --- see your screenshot!), see if you can run Smalltalk on a Lisa 2 with instructions matching the ones found here:
https://lisalist2.com/index.php/topic,195.msg1492.html#msg1492
The Smalltalk Twiggy disk contains the interpreter and a file containing the Smalltalk virtual environment. This file is large, and the Smalltalk interpreter simply loads it sequentially from the disk into RAM. You will need at least an 800k disk to hold the information, and even that may not be enough. Therefore there could be these challenges:
- Can the monitor work with 800k disks?
(Accessing those disks is not radically different to accessing 400k disks, but even so)
- Does the Smalltalk interpreter talk to the disk in its own way?
(In which case that disk I/O code would need to be patched)
- Is 800k too small? Twiggies hold 871k.
(If it is, maybe the image is partially empty and can be trimmed to fit)
(Or maybe you can compress the image and replace the loading code Smalltalk uses)
(OR, maybe you can put the image and the interpreter onto a ProFile?)
If you accept the challenge, and if it would help, and if the computer feels like playing along (no reason to assume it wouldn't), I'm happy to do whatever you need on my Lisa 1 to help you investigate the problem.
Thanks for this awesome work!
-
Oh trust me, we are on the same page here – it is my current goal.
(https://i.imgur.com/fd3yqfQ.png)
-
Wow, this is really awesome! It would be so cool to get Smalltalk working on the Lisa 2.
-
The Monitor's Sony bootblock and mon.loader already understood 800KB disks. And after a little bit of time spent understanding the interleaving format, I've been able to produce 800KB disks that work fine in lisaem. As I haven't owned a Lisa in 25 years, I haven't been able to test this on hardware.
I've attached a copy of lk026_mon11.1.dc42 but converted to Sony 800KB format. I've executed a number of programs on the disk and all seem to work fine, which makes me reasonably confident in all of this. I'd much appreciate if somebody could test this on a Lisa with an 800KB drive.
I'm still working on Smalltalk: A minimal Monitor environment and the four Smalltalk files (bci.symbols, bci.obj, smalltalk.obj, image) fit on an 800KB disk with a little wiggle room. When executing Smalltalk, it loads into memory fine (verified by dumping the memory in lisaem), but its presently complaining about loader error 5 (SetSP at wrong place after physical link). I'm still working on figuring this out.
dumphex.obj:
(https://i.imgur.com/4PkKyRv.png)
compiler.obj:
(https://i.imgur.com/2urVsxV.png)
code.obj:
(https://i.imgur.com/arZWno1.png)
dumpobj.obj:
(https://i.imgur.com/trXDHxX.png)
(https://i.imgur.com/eeCI26K.png)
codesize.obj:
(https://i.imgur.com/DEqBN1m.png)
(https://i.imgur.com/2kZeyzK.png)
-
Seems to work fine on my 2/10: https://photos.app.goo.gl/ps23jWErTxW4Jh8LA
In my limited experience, regular 400k Lisas can handle 800k images served by a Floppy Emu. I don't know how you used the Monitor programs to make some of your busier screenshots, but I think I can run all of the programs you were running. Attempting to run the Editor fails with "I/O Error 1 type: <space> to continue", but I'm guessing this is because files are missing. The lack of a file called EDITOR.OBJ is probably a clue :)
Good luck with Smalltalk!
-
I have Smalltalk running in lisaem. The issue was that the Monitor's config.data that was being used was for a 1MB system and lisaem was setup for a 1.5MB system. Changing lisaem to be a 1MB system
resultingresulted in it working. Conceivably I could've swapped out the config.data with the config1.5.data on the lk025_mon11.8 disk.
However once the Smalltalk system launches, I can't move the mouse. It would be nice to know if it works the same or not on hardware (e.g. to track down whether or not its an emulator issue).
(https://i.imgur.com/T1SyExb.png)
(https://i.imgur.com/C3pggs8.png)
-
And for what its worth, here are a few more Twiggy Monitor disks converted to 800K Sony. lk025_mon11.8 was too large to fit, so one file was excluded: dumpobj.obj. The other Twiggy disks all fit within 800K.
-
It works just fine. Excellent job!
https://photos.app.goo.gl/RwpePrKyERYM4Fn97
I'm not surprised that the mouse works on real hardware. LisaEm includes special handling for different Lisa operating systems and environments, if I'm not mistaken. It's something I had to take into account when writing my Lisa IO code a while ago --- although I didn't do a lot of work to understand it; I think Ray just told me what to try to get it to work.
https://github.com/stepleton/lisa_io/blob/master/lisa_console_kbmouse.x68#L145
I'm excited that many more people will now have a chance to try out Lisa Smalltalk!
-
As you made such quick work of that: do you think you could get the Monitor to boot off of a ProFile? :D
-
That is the next and final goal for me. I believe it is possible, and possibly quite easy. The MacWorks XL with hard disk support is still based on Monitor, it installs a boot block to the Profile and a loader that can handle a Monitor filesystem. And for added bonus, the original sources are on bitsavers (the Hard_Disk_Install_Feb86.pdf file in /pdf/apple/lisa/macworks/)
-
I've long been confused why in lisaem, installing MacWorks XL to the Profile does not result in a bootable setup - you still have to use a floppy. This is even noted in LisaEm_Users_Guide_1.2.5.pdf – attempting to boot from the Profile after installation results in an error 75 (from the ROM).
So I spent the better part of the day looking into this... I copied over the first 8 blocks from the image to a new empty image, set the AA AA... boot tags, and immediately got an error 23.
(https://i.imgur.com/8GUONux.png)
This is an interesting error, as it comes from the bootsector (the first block copied). It indicates there was some sort of disk reading error. In this case, because I had failed to set the checksum tag for the sectors. I corrected that and it immediately goes back to error 75. Error 75 is interesting as its originating from the ROM, and implies an error occurred after passing control off to the bootsector.
EBOOT .EQU 75 ;general boot failure error code
I captured a trace in lisaem of the boot process, and prior to it going back into the ROM I could see it executing from 0x20a00: This is where the secondary stage bootloader gets loaded from the bootsector. Clearly the bootsector has done its job, it loaded in the subsequent blocks from disk and jumped over to them. But the instructions in 0x20a00 don't match what are on disk. It turns out the first sector was just read in 8 times in a row.
Looking at the trace logs confirmed this, the Profile was only sending back data from the first sector. Clearly the read command's block number wasn't being parsed correctly. It seems to boil down to these two instructions in the bootsector:
COPYSIX MOVE.B (A1), NHS(A0) ; NHS = 0x78 = PORTA2
MOVE.B (A1)+, ORA(A0) ; ORA = 0x08 = ORA2
Consulting the boot rom sources:
ORA2 .EQU $8 ;PORT A OUTPUT REG
PORTA2 .EQU $78 ;PORT A WITH NO HANDSHAKE
So it seems to be writing the same profile command data twice to port A (once with a handshake, and once without). This seems to confuse lisaem:
src/storage/profile.c:ProfileLoop:991:Wrote CMD 00 into ProFile Data block index:4| 20:52:31.7 52544879
src/storage/profile.c:ProfileLoop:992:Wrote MSB 00 into ProFile Data block index:5| 20:52:31.7 52544895
src/storage/profile.c:ProfileLoop:993:Wrote mid 00 into ProFile Data block index:6| 20:52:31.7 52544941
src/storage/profile.c:ProfileLoop:994:Wrote LSB 00 into ProFile Data block index:7| 20:52:31.7 52544987
src/storage/profile.c:ProfileLoop:995:Wrote RTRY 03 into ProFile Data block index:8| 20:52:31.7 52545017
src/storage/profile.c:ProfileLoop:996:Wrote SPAR 03 into ProFile Data block index:9| 20:52:31.7 52545033
src/storage/profile.c:ProfileLoop:998:Wrote ? ? ? ? 0a into ProFile Data block index:10| 20:52:31.7 52545063
src/storage/profile.c:ProfileLoop:998:Wrote ? ? ? ? 0a into ProFile Data block index:11| 20:52:31.7 52545079
src/storage/profile.c:ProfileLoop:998:Wrote ? ? ? ? 04 into ProFile Data block index:12| 20:52:31.7 52545109
src/storage/profile.c:ProfileLoop:998:Wrote ? ? ? ? 04 into ProFile Data block index:13| 20:52:31.7 52545125
Can clearly see 03, 0a and 04 duplicated – the 00s are as well, but those are less clear. 04 should be the threshold, 0a should be the retry count, 03 should be the block number.
The two writes to the VIA are getting duplicated on lisaem's profile side of things, resulting it in never seeing the block number where it expects.
NOP'ing out the first of the two moves (the second being more important for its incrementing of a1) results in MacWorks XL booting directly from the Profile image in lisaem. I've attached a disk image containing that NOP patch for others to verify.
With this issue finally understood, I can get back to the important work of making a Profile bootable Monitor system.
-
Regarding the no-mouse in LisaEm when booted into Monitor:
Here is a clue in glue for you:
https://github.com/arcanebyte/lisaem/blob/master/src/lisa/motherboard/glue.c#L378
-
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):
(https://i.imgur.com/sIDNfkp.png)
Which in turn allowed me to F)ile, vM)gr to inspect the drive:
(https://i.imgur.com/UMJ1CTk.png)
And with the drive having just been zero'ed, to create a new volume on the drive:
(https://i.imgur.com/IIy1we4.png)
And of course, inspect that before shutting things down:
(https://i.imgur.com/O5yxYNS.png)
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.
(https://i.imgur.com/0qied5C.png)
And pop back into F)ile, vM)gr, and L(ist the volumes on that drive.
(https://i.imgur.com/noO57To.png)
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.
-
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.
-
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.
(https://i.imgur.com/IMXp9pT.png)
-
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.
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.
-
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.
(https://i.imgur.com/AYiuNGL.png)
The 2 is always discarded by the loader (via subi.b #0x20, (a0)):
(https://i.imgur.com/Os5k52w.png)
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.
(https://i.imgur.com/Vm54KaD.png)
-
Still hoping to try these images later this evening UK time... the main thing I will have to do is remember to myself the utility packed with LisaEm that can convert .dc42 hard drive images to the raw concatenated sectors that Cameo/Aphid and ESProFile use. Will report once I give them a try...
-
I just copied both of the ProFile images over to an ESProFile and I can confirm that they both work on actual hardware on a Lisa 2/10. It's really neat to run the Smalltalk examples on a Lisa!
The only issue that I've encountered is that the mouse editor won't load and gives an error on the Smalltalk image, but everything else seems to be perfectly fine.
The exact error is:
Error #9 on file LISA:FM.MN.HEUR
InitWm called FMInit and got errNum = 9
Fatal Error 2 type: <space> to continue
So it seems that something's not quite right with some font-related stuff.
-
I just copied both of the ProFile images over to an ESProFile and I can confirm that they both work on actual hardware on a Lisa 2/10. It's really neat to run the Smalltalk examples on a Lisa!
Thats great to hear!! Thank you for testing!
The only issue that I've encountered is that the mouse editor won't load and gives an error on the Smalltalk image, but everything else seems to be perfectly fine.
The exact error is:
Error #9 on file LISA:FM.MN.HEUR
InitWm called FMInit and got errNum = 9
Fatal Error 2 type: <space> to continue
So it seems that something's not quite right with some font-related stuff.
The Smalltalk images I made are fairly minimal right now, pretty much just the bare-bones necessities from the Monitor 11.8 image with the four files from the t004 Smalltalk image copied over. So I think this is expected right now. Now that we know the images work on hardware, I'll start working on the two final images, reasonably "complete" environments for both Monitor 11 and Monitor 12 (assembler, compiler, editor, smalltalk, etc).
-
I keep failing to try this out myself --- it feels like there keeps being one extra thing that I have to do every evening. I'm glad that Alex has provided a report instead! There's no way I'm going to miss out on the fun for good, though... Alex has covered the 2/10 but I would like to see if the ProFile images will run at all on a Lisa 1. (I will not try to use the Twiggy drives.) Probably next week, but I encourage anyone else to try and beat me to the punch!
-
I've attached a zip file containing dc42 and raw images for a test of the "universal" Monitor profile image, based (yet again) on monitor_12.3_copysony. The filesystem contains both Twiggy (from lk017_mon12.2_1) and Sony drivers. The bootfiles.data is set to conditionally load Twiggy based on the ROM's SysType reporting 0, and to conditionally load Sony when the ROM's SysType is not 0.
I've verified this works by combing through a trace in lisaem, as well as specifying an invalid filename. I set it to try and load ZNYDRVR7.OBJ, and when I set the condition to Lisa2, I get an error during boot:
(https://i.imgur.com/iRyqr29.png)
And when I set the condition to Lisa1, the error goes away (indicating it didn't try to load it because it failed the SysType test).
Additionally I copied over some screen printing logic from the floppy's MON.LOADER to display the bootfiles that get loaded. With The Sony driver set to load for Lisa 2 and the Twiggy driver set to load for Lisa 1:
(https://i.imgur.com/Y0ByYTA.png)
And with the flags inverted so Sony gets loaded on Lisa 1, and Twiggy on Lisa 2:
(https://i.imgur.com/mpk3DwQ.png)
The patch introduces a branch (60 00 08 2C) before the CLR.W -(A7) and deletes the SUB.B #$20, (A0):
(https://i.imgur.com/u1Ec7DD.png)
The remainder of the patch goes at the end of the loader (beneath the font table), and with the caveat that I have not written 68000 assembly in 30 years, goes like this:
START ORG #0x21414
00 dc.b 0x00
00 dc.b 0x00
00 dc.b 0x00
04 10 00 20 subi.b #0x20, (a0) ; remove 0x20 from the byte,
; as the original code did.
18 10 move.b (a0), d4 ; load the byte into a reg
E8 0C lsr.b #0x4, d4 ; shift off the lower 4 bits (the string length).
; the result (just the upper 4 bits) will be
; 0(universal), 1(lisa1), 2(lisa2)
B8 3C 00 00 cmp.b #0x0, d4 ; is this a universal file?
67 00 F7 C8 beq.w loc_20bea ; yes, so continue reading it
not_universal:
1A 38 02 AF move.b 0x2af, d5 ; Load in the ROM’s SYSTYPE variable
B8 3C 00 01 cmp.b #0x1, d4 ; Is this file only for Lisa 1?
66 10 bne.b loc_2143 ; No, jump to Lisa 2 test
lisa1_test:
04 10 00 10 subi.b #0x10, (a0) ; Remove Lisa 1 marker from the byte
BA 3C 00 00 cmp.b #0x0, d5 ; Is SYSTYPE == 0 (Lisa 1)?
66 00 F7 FA bne.w loc_20c32 ; No, so advance to the next file in bootfiles.data
60 00 F7 AE bra.w loc_20bea ; The file wants a Lisa 1 and we are on a Lisa 1
; So allow the normal file read to continue
lisa2_test:
04 10 00 20 subi.b #0x20, (a0) ; Remove Lisa 2 marker from the byte
BA 3C 00 00 cmp.b #0x0, d5 ; Is SYSTYPE == 0 (Lisa 1)?
67 00 F7 EA beq.w loc_20c32 ; Yes, but we want a Lisa 2 for this file, so
; advance to the next file in bootfiles.data
60 00 F7 9E bra.w loc_20bea ; The file wants a Lisa 2 and we are on a Lisa 2
; So allow the normal file read to continue
-
My interest in all of this Monitor stuff, besides getting Smalltalk usable on more systems, was to be able to run some of the old tooling. With everything working reasonably well so far, I decided to try something I've wondered about for a while...
Some time ago, Al announced the recovery and posting of some old Monitor sources to bitsavers. So I cobbled together a Monitor 12 image with the assembler and necessary files, and gave it a whirl – and the sources compiled without any error. I've tried replacing the monitor.obj of a v11 disk with the output from this build, but that hasn't worked (I guess these Monitor sources *are* that old). But it is neat to be able to assemble this for the first time in who knows how long, it seems plausible that it could be made to work, and the listing file matches the same format as the Monitor 11 sources scan on bitsavers, so this may make it easier to transcribe the sources in that PDF.
One thing I learned is that it is vital to set the pretty listing option – otherwise the listing will have some placeholders in it (forward references that it doesn't immediately know how to resolve).
I've attached a zip containing the assembler output files (the listing, object and symbols file), as well as two 5MB Profile images (raw and dc42) and an 800KB image. While I've been successful running the assembler in lisaem with both floppy and Profile images, the output files are only correct when ran from the Profile image. On the 800KB, it looks like random bits of memory were written instead of what should've been, and on subsequent launches of lisaem it complains about invalid checksums in the dc42 file. Hopefully these are lisaem issues with 800KB disk handling. If somebody would like to try the floppy image on hardware, afterwards you could probably search the dc42 file in a hex editor for FILE:monitor.TEXT, or use the Python script from https://github.com/d235j/lisa-utilities, or send me the file.
(Also I realize I should stop posting images and provide the tooling I use to make these... I do plan on cleaning them up and getting them into a useful state for others. Presently its hodgepodge of a C executable, an ObjC executable, and four python scripts...)
For those that would like to play along at home, from the Monitor prompt type A to enter the Assembler, type ? to enter the options, type +p to turn on pretty, press return to exit the options, type monitor for the input file, and type oldmon for the next three options (listing, output and symbols). While you could type anything for those last three options, I'd advise against leaving the defaults as it'd overwrite the image's built in monitor.obj and monitor.symbols, leaving you with an image that will no longer boot properly.
I would also warn that the process is rather slow at 5MHz - certainly enough time to go make some tea...
(https://i.imgur.com/TWVA8df.png)
-
I had wanted to try out ASM6502.OBJ, and figured the ROM88 sources on bitsavers would be a good test. Unfortunately embedding the files as-is into a disk image did not work - despite having the correct file kinds, extensions, etc most of the Monitor tools refused to believe they were text files. So clearly I need to understand what all of the null bytes and other control characters in the existing image's text files actually mean to Monitor, so that regular text files can easily be transferred over.
As it was late in the evening and I had no desire to embark on that, I thought an easier solution would be to use the Terminal emulator app, and then use lisaem's serial shell or telnetd to paste the contents in.
Using the first disk image I posted in this thread, I added root3's TERM.OBJ, and lisav's TERM.MENUS.TEXT and the emulator is functional:
(https://i.imgur.com/aFYHhX3.png)
However when I use the connector menu to switch to serial port B and type a character into lisaem's adapter, there is an endless slew of Xmit Interrupt condition 61 errors and then lisaem crashes. So we may have another one for the lisaem issue list...
(https://i.imgur.com/dZIYYrg.png)
As always, I've attached a disk image – this time 800KB since the image still has The Mouse Editor – in case anybody wants to test it out on hardware. Additionally the image contains lk018_mon12.2_2's LISATALK.OBJ since it seemed like that could be used to send/receive files – although it may only work with another LISATALK or the MACTALK.RSRC on that disk?
(https://i.imgur.com/c7onn36.png)
-
I was also able to transfer the "REV H BOOT SOURCE" files into an image, and get them to assemble. The resulting binary's md5 matches the rev H ROMs that have been dumped.
1- I had to remove the .ABSOLUTE directive, as this upset both Monitor's and Workshop's assembler.
2- The output from Monitor was in a monitor object file format, so there were a few bytes that had to be removed: the first 56 bytes of the file (which have the module name, entry point, and code block entries), the last 8 bytes (the end block entry). Then the final 2 bytes were 0000 and needed to be replaced with the checksum to match. The rev h disk images on bitsavers have an executable file that looks like it computes the checksum and embeds it there.
I'm holding off on providing yet another disk image – my hope is that this and the Monitor sources and IO rom sources could all be part of the everything and the kitchen sink image.
-
pablo_marx@, I am having troubles using the Profile images you posted here in LisaEm. I think the issue also exists on a fresh Workshop 3 installation:
Lisa boots fine and displays the command line, but as soon as I type a key on the menu line, Lisa starts repeating it indefinitely , which causes the whole menu line to blink; this is futile: I cannot run any command when the menu line is blinking, and I cannot get it to stop blinking.
How did you overcome this problem? Which LisaEm version are you using?
I am running LisaEm from the latest codebase, on Ubuntu 24, with H roms, 1 MB of ram.
-
How did you overcome this problem? Which LisaEm version are you using?
I am running LisaEm from the latest codebase, on Ubuntu 24, with H roms, 1 MB of ram.
I haven't seen this issue, so I haven't done anything to overcome it. I primarily use LisaEm version 1.2.7-RC4_2022.04.01 on arm64 macOS, but when deep-diving into issues (like the Profile VIA double writes) I use a debug build of lisaem on x86_64 Debian 12.10 machine. The build for that is pointing at Ray's github repo and is based on commit a3ee183cd3a5d65d3780eefbe75df4f98bca08c6. I've been able to type just fine into that (I have it assembling the old monitor sources as I compose this).
Configuration wise, both are using H boot roms, A8 I/O ROMs, US keyboard, nothing in any of the slots. macOS machine has the Lisa RAM set to 1.5MB and the Linux machine has it set to 1.0MB. macOS keeps forgetting the SunRem double sided floppy setting, whereas Linux does remember that setting.
I can try to build from the arcanebyte repo later tonight to see if your issue reproduces for me there.
-
Using the same x86_64 Debian 12 machine, I checked out lisaem from arcanebyte's repo, commit 61d55b3c837be3c04a89f8e95bfa2852094dfe66, and built lisaem (another debug build FWIW). I have had no keyboard issues with the Smalltalk or Old Monitor Sources Profile images. I've been able to launch Smalltalk and assemble the monitor sources (both requiring some amount of typing). So I'm afraid I haven't a clue what @TorZidan's issue may be.
-
Using the same x86_64 Debian 12 machine, I checked out lisaem from arcanebyte's repo, commit 61d55b3c837be3c04a89f8e95bfa2852094dfe66, and built lisaem (another debug build FWIW). I have had no keyboard issues with the Smalltalk or Old Monitor Sources Profile images. I've been able to launch Smalltalk and assemble the monitor sources (both requiring some amount of typing). So I'm afraid I haven't a clue what @TorZidan's issue may be.
Do you happen to know which version of wxWidgets was installed? I'm not sure we've updated the Linux build script lately, so maybe the issue is 3.2.7 or similar.
-
On my initial Linux build with Ray's repo, I let lisaem build and install wx-widgets, so it appears to be v3.1.5-gtk. I'd be hard pressed to guess why wx-widgets would only affect the keyboard with these Monitor disks... I've also tried each keyboard locale and each IO ROM (but not every combination of them) and haven't had any keyboard issues.
-
Thank you, pablo_marx@, for the clues!
I built and run LisaEm version 1.2.7-RC4_2022.04.01, and I still had the repeating keys issue.
So I started digging into the preferences and menu items, and I finally figured it out: In the "Key" menu, somehow I have chosen "Raw Keyboard".
Changing it to "ASCII Keyboard" fixed it!
I have no idea what are these different keyboard options, but am glad that this case is closed.
-
tried each IO ROM
For IRL hardware, the I/O Board ROM is used exclusively by the Floppy Disk Controller's 6504... the 68000 can't even access it.
So the IO ROM version shouldn't have any affect on COPS/KeyBoard/Parallel/Serial/Sound etc.
I'd suppose that if you find one of these things is affected by the IO ROM version in the emulator, that might merit a bug report.
The exception is that the PRAM is in fact the 6504's RAM that also can be accessed by the 68000, so there is the potential for the I/O Board ROM to interfere with access to, or alter the PRAM.
-
tried each IO ROM
For IRL hardware, the I/O Board ROM is used exclusively by the Floppy Disk Controller's 6504... the 68000 can't even access it.
So the IO ROM version shouldn't have any affect on COPS/KeyBoard/Parallel/Serial/Sound etc.
The 68000 can certainly make inquiries of it, as it displays the I/O ROM version in the top right during boot/diagnostics. So it seemed feasible, but certainly very unlikely, given the error report that some piece of code could be checking the version and altering behavior based on the value (e.g. enabling some quirks mode code path when dealing with the COP), resulting in the behavior described.
(https://i.imgur.com/KZVdhKM.png)
-
tried each IO ROM
For IRL hardware, the I/O Board ROM is used exclusively by the Floppy Disk Controller's 6504... the 68000 can't even access it.
So the IO ROM version shouldn't have any affect on COPS/KeyBoard/Parallel/Serial/Sound etc.
The 68000 can certainly make inquiries of it, as it displays the I/O ROM version in the top right during boot/diagnostics.
NO, this is not correct, the 68000 cannot access the IO ROM directly as James said. What happens is that the IO ROM version is written into the shared RAM by the 6504, and the 68000 reads that. Try it, If you were to remove the 6504 from your IO board and POST the system IO ROM displayed will be gibberish.
-
the IO ROM version shouldn't have any affect on COPS/KeyBoard/Parallel/Serial/Sound etc.
... some piece of code could be checking the version and altering behavior
Fair enough... the 68k may certainly behave differently due to what the 6504 communicates (and thus influenced by the IO ROM)... but ordinarily it does not (with a couple of exceptions*).
The intent of my post was to avoid someone having the impression that eg. if their keyboard didn't work IRL (In a Real Lisa™) then the IO ROM might be a likely suspect. The IO ROM doesn't directly control operation of the I/O Board beyond the FDC.
* some exceptions being:
- The "Startup From" menu will show two floppy drives for A8, and one floppy drive for 88 -- further edit... I'm thinking this is more complicated... maybe two floppies appearing requires earlier revision CPU ROMs too?
- Xenix assumes the parallel port hard drive is 5MB or 10MB depending on A8/88
- The hard disk icon in the Startup From menu and environments such as MacWorks changes between a ProFile and a Widget
- The clock speed of the 6522 VIAs is different (approx. 500KHz vs 1.25 MHz), 88 indicating the 2/10 I/O Board designated as having "fast timers" per the source code comments, requiring different time constants.
edit: exceptions
-
However when I use the connector menu to switch to serial port B and type a character into lisaem's adapter, there is an endless slew of Xmit Interrupt condition 61 errors and then lisaem crashes. So we may have another one for the lisaem issue list...
Finally getting around to trying out some of these images. For starters, this experiment with TERM.OBJ was successful in sending data in both directions on both serial ports.
https://photos.app.goo.gl/LVvA6mp1T7WfsjR68
-
[The "Startup From" menu will show two floppy drives for A8, and one floppy drive for 88 -- further edit... I'm thinking this is more complicated... maybe two floppies appearing requires earlier revision CPU ROMs too
We are quite off topic, but I want to put this to bed:
I tried quite a lot of combinations of cpu and i/o roms in LisaEm. Here is how it works:
For "H" and "3A" cpu roms: The CPU rom checks the I/O rom version, and, based on that, shows different icons on the startup screen. It will show two floppy drives (and a ProFile) only if the I/O rom is "40".
All earlier cpu roms (I tried B,C and D) always show two floppy drives on the screen (and a ProFile), regardless of the I/O rom version; so it seems that they predate the Lisa 2 and XL.
-
I've tried the Monitor ProFile images on my Lisas (Lisa 1, Lisa 2/10, both with 1 MiB of RAM) and am not getting very far: immediately after trying to boot from the drive image, it gooses the screen contrast in one direction or another (probably sending it uninitialised data from RAM), beeps, and then sends the machine into a boot ROM boot failure dialogue (or at least it seems to do that when the screen is still visible).
I've tried serving the images from a Cameo/Aphid or an ESProFile with the same outcome. In both cases I am booting from the I/O board's own parallel port.
Alex, how are you minting your hard drive images? I'm using dc42_to_rraw (note two r's) from LisaEm at HEAD and applying it to the .dc42 ProFile images that pablo_marx has shared.
I expect you must be doing something to make your own images, since pablo_marx's raw hard drive images have interleaved sectors and are not bootable when served by an ESProFile or a Cameo/Aphid: you can tell since the third word of the image isn't $aaaa. I can produce exact duplicates of these files by applying dc42_to_raw (note one r) to the .dc42 files.
One last thought: Alex, you seem like someone who might have 2 MiB RAM fitted in your Lisa, and I know these images require a specific amount of RAM...
-
I've attached a zip containing the assembler output files (the listing, object and symbols file), as well as two 5MB Profile images (raw and dc42) and an 800KB image. While I've been successful running the assembler in lisaem with both floppy and Profile images, the output files are only correct when ran from the Profile image. On the 800KB, it looks like random bits of memory were written instead of what should've been, and on subsequent launches of lisaem it complains about invalid checksums in the dc42 file. Hopefully these are lisaem issues with 800KB disk handling. If somebody would like to try the floppy image on hardware, afterwards you could probably search the dc42 file in a hex editor for FILE:monitor.TEXT, or use the Python script from https://github.com/d235j/lisa-utilities, or send me the file.
I attempted this build with the 800K image served to my Lisa 2/10 by a Floppy Emu. Historically I haven't had problems reading 800K disk images on my 2/10 even though it is in a stock 400K configuration; I can't recall now if I've done much writing, though.
You weren't kidding about that cup-of-tea thing: the build process takes a couple of hours!
Unfortunately it was early in the "assembley"'s "pass one" that the whole show was brought to a halt by a disk error. By then it was quite late at night (I had actually dozed in bed for a bit), so I didn't have the wits to take a photo exactly of what it said.
-
On second thought, I'm not certain how dependable the 800K disk result is. It's been a very long time since I've updated the firmware on my Floppy Emu and it's possible that there are some old bugs there.
I just tried using BLU to read a whole 800k disk into RAM and then write it to a new disk image. Both operations appear to have completed successfully, but then a failure was encountered when I tried to verify the newly written image with the image in RAM. I will see about upgrading the RAM and then try again if I still have time.
UPDATE I retract the retraction :-) it seems that at some point I had actually updated the Floppy Emu to the latest version. Is anyone aware of poor experiences when working with 800k disk images on a machine with the stock (400k) ROM? Sunrem must have issued a patched ROM for a reason, I suppose...
-
Alex, how are you minting your hard drive images? I'm using dc42_to_rraw (note two r's) from LisaEm at HEAD and applying it to the .dc42 ProFile images that pablo_marx has shared.
I expect you must be doing something to make your own images, since pablo_marx's raw hard drive images have interleaved sectors and are not bootable when served by an ESProFile or a Cameo/Aphid: you can tell since the third word of the image isn't $aaaa. I can produce exact duplicates of these files by applying dc42_to_raw (note one r) to the .dc42 files.
One last thought: Alex, you seem like someone who might have 2 MiB RAM fitted in your Lisa, and I know these images require a specific amount of RAM...
Yeah, I used dc42-to-rraw as well. It's been a few days, so don't quote me on this, but I believe I used either the -i or -d option to interleave or deinterleave the image.
I do indeed have 2MB of RAM in my Lisa, so I guess RAM size could play a role too. We know these images also work with 1.5MB because of LisaEm, but I'm not sure if anyone's gotten it to work on anything less than that.
-
The -d flag for dc42_to_rraw appears to have done the trick!
The Smalltalk ProFile image boots on my Lisa 1 and Lisa 2/10 both: https://photos.app.goo.gl/Koh6G3KLBQNxJmqf7
It's great how quickly Smalltalk loads, but I'm afraid that speed prepares you for a let-down when you actually try using the system! A speed demon it is not.
All functionality appears to be present in any case, except for at least one thing. I accidentally selected "snapshot" from the "yellow button" menu, which ought to dump the current VM memory image to disk. Either it froze completely or it just takes ages, much longer than the several minutes I gave it.
-
I'm now giving the "universal" image a go. Things are promising at the start: the Lisa 1 announces as it boots that it's loading TWGDRVR7.OBJ while the 2/10 says it's loading SNYDRVR7.OBJ. Now to see if I can mount some disks...
On the Lisa 1: yes, we can read Twiggies!
On the Lisa 2: yes, we can read 3.5" disks!
At least well enough to do directory listings, which may not be so demanding. I tried to run Smalltalk off a Universal twiggy and it did not work, but we expect this from Monitor 12 (Smalltalk prefers 11). (Smalltalk is an excellent way to exercise a read from an entire Twiggy as that's how large the VM image is.)
(Does anyone know how to get the Monitor on a Lisa 2 to eject a floppy disk?)
pablo_marx, are there any real hardware experiments that I've forgotten to run? Sorry it took me so long! Excellent work.
-
Finally, I can confirm that the monitor assembly that failed for me on the floppy disk appears to work just fine when carried out on the ProFile. Not only that, it is much, much faster, taking perhaps five or ten minutes (cup-of-tea time) instead of the hours I found when doing the same on the floppy.
Thanks once again for this amazing progress with the Monitor!
-
Does anyone know how to mimic the SmallTalk mouse buttons in LisaEm running on e.g Linux PC?
Years ago,
stepleton@ figured it out IRL (in real Lisa):
https://lisalist2.com/index.php?topic=195.0
"Once loaded, it is helpful to know that this Smalltalk was designed for computers with three-button mice. The buttons were identified by colour. The "red button" is your ordinary Lisa mouse button. The "yellow button" is the Apple key and the "blue button" is either option key."
I tried the "Windows", "Alt" and "Ctrl" keys on my keyboard, but no luck.
-
I've long been confused why in lisaem, installing MacWorks XL to the Profile does not result in a bootable setup - you still have to use a floppy. This is even noted in LisaEm_Users_Guide_1.2.5.pdf – attempting to boot from the Profile after installation results in an error 75 (from the ROM).
The two writes to the VIA are getting duplicated on lisaem's profile side of things, resulting it in never seeing the block number where it expects.
After this excellent analysis of the bug, I took interest in it and fixed it in LisaEm:
https://github.com/arcanebyte/lisaem/pull/31
It has been merged into the master branch.
Some more regression testing is needed to confirm that I haven't broken anything...
It seems that Ray had written some code to ignore these duplicate writes, but the code was in the wrong place, and incomplete...