Print

[stepleton]

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!

[stepleton]

As you made such quick work of that: do you think you could get the Monitor to boot off of a ProFile? 

[pablo_marx]

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/)

[pablo_marx]

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.



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.

[TorZidan]

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

[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]

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. 

[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.

[stepleton]

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

[AlexTheCat123]

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.

[pablo_marx]

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).

[stepleton]

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!

[pablo_marx]

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:



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:



And with the flags inverted so Sony gets loaded on Lisa 1, and Twiggy on Lisa 2:



The patch introduces a branch (60 00 08 2C) before the CLR.W -(A7) and deletes the SUB.B #$20, (A0):



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