Print

[pablo_marx]

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

[pablo_marx]

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:



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



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?

[pablo_marx]

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.

[TorZidan]

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.

[pablo_marx]

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.

[pablo_marx]

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.

[jamesdenton]

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.

[pablo_marx]

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. 

[TorZidan]

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.

[sigma7]

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.

[pablo_marx]

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.

[Lisa2]

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.

[sigma7]

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

[stepleton]

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

[TorZidan]

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