Print

[stepleton]

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

[stepleton]

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.

[stepleton]

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

[AlexTheCat123]

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.

[stepleton]

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.

[stepleton]

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.

[stepleton]

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!

[TorZidan]

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.


 

[TorZidan]

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