Print

[rayarachelian]

brew install SDL2

brew install SDL2_image

brew install SDL2_ttf

I'm unsure why SDL2 would be required. wxWidgets only relies on SDL for sound, and then only on GTK systems. It might be that I installed SDL2 on the mac VM on which that specific beta release was built on, and then the wxWidgets I compiled there saw it and started using it, but it should work without SDL2 being installed on macos, assuming you compile wxWidgets yourself using the build-wx3.1.4-modern-macos.sh script inside the scripts directory, and then have added your path to it, and then built LisaEm yourself using build.sh

I would advise you to build RC3a (or unstable) yourself instead if you're going to go through that much effort.

[rayarachelian]

So it thinks this is a 4 byte opcode, but really it's a two byte opcode that's actually just a short branch to itself.

Code: [Select]

00020000  60FE                       2  START: bra.s START

So this is on purpose, for whatever reason. It could just be the idle loop of the kernel when it doesn't yet have any spawned processes to exec (i.e. init), however there is a bug in Generator - at least in the disassembly side where it doesn't properly disassemble this opcode.

Turns out this is pebkac on my part. Thanks to James Denton, who pointed me at http://www.bitsavers.org/pdf/unisoft/UniPlus+_System_V_Installation_Instructions.html

I needed to type in "copy" on the boot disk, and not hit enter. What's happening is that hitting enter boots the unix kernel off the disk, but this disk doesn't contain a file system, so when it tries to do fork/exece of '/etc/init' - there's no / directory, let alone a /etc directory and so exece fails with ENODIR and drops in this loop.

The loop can be found in the kernel source code in v1.5/sys/main.c. This is a tiny tiny, but valid assembly code uniplus program which just calls exece to run /etc/init. but apparently this needs to exist as a process in memory, before it can run fork/exec, (actually this is special as it's started via a different call: newproc(0) not actually fork.)

Weirdly, in UniPlus programs can start at address 0 - normally used for the trap table - but since this runs in user mode, it's fine. (This is something which the Generator disassembler doesn't like one bit! But it does emulate it properly as far as I can tell.)

This guy first sets up the stack pointer, then argc/argv, and environment variables, then calls trap #0 with 59 (exece) which tries to replace this process with init, and then fails, so it falls through and gets stuck in that "bra ." loop, but D0 is set to ENODIR - and that's what I saw happening at address 2/00000020 previously.

Fun stuff, and got a quick bit of "Ah Ha!" about how unix starts up. I had no idea it would create a fake stub program before loading init into memory, but I guess exec can't do that unless one exists as there's probably no "load this binary" function in the kernel, and so it can only use the exec class of syscalls. So it does that as a hack.

Code: [Select]

36 /*
 37  * Icode is the bootstrap program used to exec init.
 38  */
 39 short icode[] = {
 40                                 /*       .=USTART               */
 41         0x2E7C, HIGH, LOW+0x100,/*       movl   #USTART+0x100,sp*/
 42         0x227C, HIGH, LOW+0x26, /*       movl   #envp,a1        */
 43         0x223C, HIGH, LOW+0x22, /*       movl   #argp,d1        */
 44         0x207C, HIGH, LOW+0x2A, /*       movl   #name,a0        */
 45         0x42A7,                 /*       clrl   sp@-            */
 46         0x303C, 0x3B,           /*       movw   #59.,d0   exece */
 47         0x4E40,                 /*       trap   #0              */
 48         0x60FE,                 /*       bra    .               */
 49         HIGH,   LOW+0x2A,       /* argp: .long  name            */
 50         0,      0,              /* envp: .long  0               */
 51         0x2F65, 0x7463, 0x2F69, /* name: .asciz "/etc/init"     */
 52         0x6E69, 0x7400
 53 };
 54 int szicode = sizeof(icode);
 55

I'm in the process of adding patches for the profile handshaking code in v1.5/stand on the boot-a disk  (or boot blocks on ProFile/Widget media) to make the copy command work. Will report back after that.

Also, I've added HLE ProFile acceleration for the Boot ROM itself, which the boot code will use (it's now failing on attempts to write to the ProFile, so there, I need to patch the handshaking.) Hopefully this will help speed up anything that uses the Boot ROM call.

This was basically a freebie since I had code for it already in romless, but until now if you use the Boot ROM, it would do the full ProFile handshaking/byte for byte transfer under emulation. So now the entire JSR to that ROM routine happens in native code, so that should speed up almost all OS booting.

[rayarachelian]

Some more progress, I've added patches for the uniplus loader (aka standalone boot), so the :copy command now works, however there's some issue with the floppy after it ejects the disk, where it doesn't recognize the floppy drive anymore after the disk is ejected. This happens in both the standalone boot loader, as well as the kernel, once it comes up.

Likely this is some very tight timing CPU loop that falls out of sync. Meh. I wonder if the UniSoft driver guys though that the Lisa would never get a faster CPU, or newer versions of the ProFile which might react faster.
However, restarting and booting off boot-a-hacked, the next step :sunix worked, but then locked up at address 2/0000020 again, later after asking for which hard drive to install on and complaining about swap vs RAM. Likely this is the same NODIRENT error due to some access issue with the floppy drive.

I've found a really weird bit of behavior in the loader (the v1.5/stand pro.c file) where after it sends the 6 command bytes to the ProFile for a block write, it fails to flip the !CMD line, but goes into the prochk function which loops forever waiting for BSY to change. This caused the LisaEm profile driver to fall out of sync with the code in the loader.

I wonder if on a real ProFile, the ProFile flips BSY some time after the 6 command bytes are passed *without* first seeing !CMD flip in real life. This may be an issue for @stepleton and the Cameo/Aphid. Or not. I don't recall seeing this behavior in the /unix kernel.

Next I have to figure out the issues with the sony.c driver, and also whether /sunix is a separate kernel or a hard link to /unix on the boot disk. (Because if there's more than one and has drivers in different locations in RAM, I'll also need to patch it as well.) and obviously will need to figure out if mkfs has some disk size limit in it, and whether the install script passes a specific size to mkfs and patch that as well with the size of the profile.
Actually looking at this screenshot again, I see sunix has v1.1 on it and 1983 as the date, while before when I was booting unix, it says v1.4 and 1985. So for sure there are two different kernels at play here as well as the standalone loader.
Likely this is the reason patching the v1.4 kernel for a different sized profile did not work - because that doesn't patch the sunix v1.1 kernel.

[stepleton]

FWIW: Cameo/Aphid doesn't seem to have any problems to speak of with UniPlus. Works fine for me if you use standard hard drive sizes.

[rayarachelian]

I think I found a situation where the BSY transition (BSY is tied to CA1 on the parallel port VIAs, where CA2 is used for handshaking), was not sending IRQs. Still working on this bit, however, it doesn't seem to affect LOS at all.

As an aside was looking to add HLE ProFile read/write support and seeing that LOS is doing some sort of XOR checksum on both reads and writes. Not sure if this is related to the document checksum protection/password thing, but it's interesting anyway. The strange bit is that it doesn't seem to do a whole sector in one shot, or even all the tags together in one shot, but rather in chunks. For example, for tags it does 2-3 tags at a time and I see several repeated calls to this code for a single sector.

I'm unsure about this chunking thing I'm seeing, but, it is what it is.

This read routine does 8x reads per pass (looks like manual loop unrolling) and in between it's doing an EOR to D1 (I removed the register and other outputs to clean it up a bit):
(A2) is the read from the IRA port on the VIA.

It may well be that this checksum is written to the tags. But it's different from other checksums that we see for example in the Boot ROM code, where it would also mix in some shifts to deal with single bit errors, so not as robust. Likely this code was written by someone else who wasn't aware of the code in the Boot ROM.

Code: [Select]


1 102470 1/00c08a88 (0 0/0/0) : 1012                       : ..       :  239 : MOVE.B     (A2),D0  SRC:clk:00000000038eb7ad +8 clks
102472 src/lisa/io_board/via6522.c:lisa_rb_Oxd800_par_via2:1806:reading from register 1 (I/ORA    )| 14:50:38.6 59684781

102476 src/lisa/io_board/via6522.c:via2_ira:572:profile.c:READ 00 from ProFile, pc24:00c08a88  tag:profile state:10| 14:50:38.6 59684781
102482 1/00c08a8a (0 0/0/0) : b101                       : ..       : 1278 : EOR.B      D0,D1  SRC:clk:00000000038eb7b5 +4 clks
102486 1/00c08a8c (0 0/0/0) : 10c0                       : ..       :  225 : MOVE.B     D0,(A0)+  SRC:clk:00000000038eb7b9 +8 clks
102487 src/lisa/cpu_board/memory.c:dmem68k_store_byte:486::::::WRITE BYTE 00 ' ' to @1/00ad5700 using 17-ram| 14:50:38.6 59684793

2 102491 1/00c08a8e (0 0/0/0) : 1012                       : ..       :  239 : MOVE.B     (A2),D0  SRC:clk:00000000038eb7c1 +8 clks   2nd read
102494 src/storage/profile.c:ProfileLoop:777:ProFile access at PC:1/00c08a8e event:1 read IRA state:10 SEND_DATA_AND_TAGS_STATE idxr,idxw: 529,4 bsy:0 cmd:0 rrw:0| 14:50:38.6 59684801

102503 1/00c08a90 (0 0/0/0) : b101                       : ..       : 1278 : EOR.B      D0,D1  SRC:clk:00000000038eb7c9 +4 clks
102507 1/00c08a92 (0 0/0/0) : 10c0                       : ..       :  225 : MOVE.B     D0,(A0)+  SRC:clk:00000000038eb7cd +8 clks

3 102512 1/00c08a94 (0 0/0/0) : 1012                       : ..       :  239 : MOVE.B     (A2),D0  SRC:clk:00000000038eb7d5 +8 clks
102524 1/00c08a96 (0 0/0/0) : b101                       : ..       : 1278 : EOR.B      D0,D1  SRC:clk:00000000038eb7dd +4 clks
102528 1/00c08a98 (0 0/0/0) : 10c0                       : ..       :  225 : MOVE.B     D0,(A0)+  SRC:clk:00000000038eb7e1 +8 clks

4 102533 1/00c08a9a (0 0/0/0) : 1012                       : ..       :  239 : MOVE.B     (A2),D0  SRC:clk:00000000038eb7e9 +8 clks
102545 1/00c08a9c (0 0/0/0) : b101                       : ..       : 1278 : EOR.B      D0,D1  SRC:clk:00000000038eb7f1 +4 clks
102549 1/00c08a9e (0 0/0/0) : 10c0                       : ..       :  225 : MOVE.B     D0,(A0)+  SRC:clk:00000000038eb7f5 +8 clks

5 102554 1/00c08aa0 (0 0/0/0) : 1012                       : ..       :  239 : MOVE.B     (A2),D0  SRC:clk:00000000038eb7fd +8 clks
102557 src/storage/profile.c:ProfileLoop:777:ProFile access at PC:1/00c08aa0 event:1 read IRA state:10 SEND_DATA_AND_TAGS_STATE idxr,idxw: 532,4 bsy:0 cmd:0 rrw:0| 14:50:38.6 59684861
102566 1/00c08aa2 (0 0/0/0) : b101                       : ..       : 1278 : EOR.B      D0,D1  SRC:clk:00000000038eb805 +4 clks
102570 1/00c08aa4 (0 0/0/0) : 10c0                       : ..       :  225 : MOVE.B     D0,(A0)+  SRC:clk:00000000038eb809 +8 clks

6 102575 1/00c08aa6 (0 0/0/0) : 1012                       : ..       :  239 : MOVE.B     (A2),D0  SRC:clk:00000000038eb811 +8 clks
102587 1/00c08aa8 (0 0/0/0) : b101                       : ..       : 1278 : EOR.B      D0,D1  SRC:clk:00000000038eb819 +4 clks
102591 1/00c08aaa (0 0/0/0) : 10c0                       : ..       :  225 : MOVE.B     D0,(A0)+  SRC:clk:00000000038eb81d +8 clks

7 102596 1/00c08aac (0 0/0/0) : 1012                       : ..       :  239 : MOVE.B     (A2),D0  SRC:clk:00000000038eb825 +8 clks
102599 src/storage/profile.c:ProfileLoop:777:ProFile access at PC:1/00c08aac event:1 read IRA state:10 SEND_DATA_AND_TAGS_STATE idxr,idxw: 534,4 bsy:0 cmd:0 rrw:0| 14:50:38.6 59684901

102608 1/00c08aae (0 0/0/0) : b101                       : ..       : 1278 : EOR.B      D0,D1  SRC:clk:00000000038eb82d +4 clks
102612 1/00c08ab0 (0 0/0/0) : 10c0                       : ..       :  225 : MOVE.B     D0,(A0)+  SRC:clk:00000000038eb831 +8 clks

8 102617 1/00c08ab2 (0 0/0/0) : 1012                       : ..       :  239 : MOVE.B     (A2),D0  SRC:clk:00000000038eb839 +8 clks
102629 1/00c08ab4 (0 0/0/0) : b101                       : ..       : 1278 : EOR.B      D0,D1  SRC:clk:00000000038eb841 +4 clks
102633 1/00c08ab6 (0 0/0/0) : 10c0                       : ..       :  225 : MOVE.B     D0,(A0)+  SRC:clk:00000000038eb845 +8 clks

102639 1/00c08ab8 (0 0/0/0) : 51ca ffce                  : Q...     : 1031 : DBRA.W     #$c08a88,D2  SRC:clk:00000000038eb84d +10 clks


Edit: seeing the same kind of read + xor in MacWorks XL 3.0 as well. Since MacWorks is built on top of Monitor OS and Monitor OS was built before LOS, I suspect this is the original source of this behavior, and likely the XOR is used with one of the tags, perhaps as a way for the scavenger program to detect corrupted data.

[rayarachelian]

Eh, so 6 weeks forwards, 3 weeks back.

Had to roll back some of the profile HLE code. In my zeal to get UniPlus working, I hadn't noticed for quite a few days that I broke LOS from booting, and then had to do a lot of bisecting to figure out exactly where the bugs were, and roll them back. Pushed to unstable.

The new HLE (High Level Emulation) checkbox in preferences works for the Boot ROM phase of loading LOS (before the Welcome screen).

I'll also be adding LOS+MacWorks HLE support in the next few days/weeks. Will re start again on UniPlus, but I guess I'll have to keep testing against LOS.

[rayarachelian]

I've added HLE ProFile hard drive acceleration to both MacWorks XL 3.0 and LOS 3.1, both seem to be working.
Pushed to the unstable branch on github.

Next up, restarting on ProFile code tests of the BLU image of UniPlus that Jason sent my way, to get it to boot up all the way.

[rayarachelian]

So seeing some weird issues in both UniPlus and Xenix around the stack. In one case when booting off Xenix, IRQ#2 gets triggered from the COP, but rather than use an RTE to get out of the Interrupt Service Routine, the last thing that unwinds the stack is an RTS, this causes the value of 2100 to be loaded into the high word of the PC and 0001 into the low word of the PC - these come from the SR being pushed on the stack during the IRQ. RTE would have successfully restore the stack properly.

This happens after the kernel has started up and reported about most of the hardware, but before

So either Xenix isn't ready at this point to receive an IRQ from VIA1/COPS421, or the wrong value has been loaded into the IRQ vector.

Using the ROM HLE code works fine with LOS and MacWorks, but in UniPlus, instead of showing the boot loader ":" prompt, it throws error 75, but looking at the tracelog, I see another odd address error issue come up, similar to the one that happens in Xenix.

I've verified that MOVEM, LINK, UNLK opcodes and other mechanisms are working as expected. It's possible/likely there's some side effects from the HLE ProFile routine, but not sure yet. Maybe it's relying on some register values that are normally thrown away, or an IRQ happens when it's not expected (but in Xenix case above, the IRQ mask was 1 and the IRQ triggered was 2, so this indicates to the "hardware" that the OS is ready to receive an interrupt.

In the UniPlus, during the loader startup (standalone/ boot prompt) when HLE is enabled, I see the stack overwriting some code around 0060000, and ofc when that's executed, the emulator crashes. This doesn't happen with HLE turned off, so certainly something's up with A6/A7 which are used in stack frames. I suspect debugging this will be easier since I can turn tracelog on, record what happens, turn HLE on, repeat, and diff and see where it varies. Fixing whatever this is might help on the Xenix side too.

Obviously all this stuff works on a real physical Lisa, so it's something that's different in the emulator than in the hardware that's at fault, as usual. Most likely the symptoms are showing up way after the thing that's different happened, so it's hard to track down (for now.) It's probably some stupid unused register being used side effect, or an off-by-one, etc.

I'll probably timebox this to another week or two of debugging/exploring; if I make progress there, great, if not, I'll go back to the terminal window stuff, etc.

[rayarachelian]

UniPlus, during the loader startup (standalone/ boot prompt) when HLE is enabled, I see the stack overwriting some code around 0060000, and ofc when that's executed, the emulator crashes. This doesn't happen with HLE turned off, so certainly something's up with A6/A7 which are used in stack frames. I suspect debugging this will be easier since I can turn tracelog on, record what happens, turn HLE on, repeat, and diff and see where it varies.

The ROM Profile read function D1 is the sector number to read, looks like D1 is actually preserved by the ROM call if the sector is read successfully. UniPlus's loader uses the old value in D1 to load the next sector, LOS's does not, so instead it wound up reading the same sector over and over again, and of course this led to a later crash.
tl;dr don't rely on the comments in the source code. they're not always completely true.

One dumb bug fixed, 99+/-whatever more to go.

Code: [Select]

0|                       ;-----------------------------------------------------------------------------
1F70|                       ;  First initialize and then ensure disk is attached by checking OCD line.
1F70|                       ;  Assumes ACR and IER registers of VIA set up by caller.  For boot, these
1F70|                       ;  are cleared by power-up reset.
1F70|                       ;  Register usage:
1F70|                       ;    D0 = scratch use           A0 = VIA address for parallel port interface
1F70|                       ;    D1 = block to read         A1 = address to save header
1F70|                       ;    D2 = timeout count         A2 = address to save data
1F70|                       ;    D3 = retry count           A3 = scratch
1F70|                       ;    D4 = threshold count       A4 = unused
1F70|                       ;  Returns:
1F70|                       ;    D0 = error code (0 = OK)
1F70|                       ;    D1 = error bytes (4) <--- not true, this returns the same D1 value (sector #) when there's no error.
                                     I was setting this to zero thinking error bytes are zero to signal no error along with D0.
1F70|                       ;    D2 - D7 and A1 - A6 are preserved
1F70|                       ;-----------------------------------------------------------------------------


[rayarachelian]

More work on MacWorks around allowing 4MB of RAM - there's now a preferences checkbox, but likely this should be kept off for now (at least in this version).

Added more code to the uniplus partition resizer.

Added a few more disk conversion tools, plus added options to turn on/off interleave5/deinterleave5 options for some of them.

Code: [Select]

raw-to-dc42 -d aphid.image           # convert a Cameo/Aphid image to LisaEm, likely
dc42-to-raw -i lisaem-profile.dc42  # copy a LisaEm image to Cameo/Aphid maybe.


[rayarachelian]

After much tweaking of the profile code, I managed to get UniPlus booting off a pre-installed image (this was converted from BLU to a dc42).
Most likely installing from scratch won't work yet because part of the install process uses another kernel, version 1.1 called "sunix" (see: http://www.bitsavers.org/pdf/unisoft/UniPlus+_System_V_Installation_Instructions.html ), versus the normal kernel called "unix" which is 1.4. So that's the next step, trying to get it working.
I'll push to "unstable" once I get the sunix step working.

[rayarachelian]

Just pushed to the unstable branch, this should fix a bunch of bugs, though it does introduce a few new ones.

It now builds for windows, but as @Neelix57 on github noted, on Windows, the conversion of wxString to CString does not properly work for UTF strings - this affects Profile disk paths. Tested by adding an omega character in the profile path and it failed to open. This works properly on macos.

If you're interested in playing with UniPlus you'll need to first install it on a real Lisa, download it to your computer using BLU and XModem, and then run blu-to-dc42 to convert it.

This not-quite-a-release includes several new tools including the video state ROM decoder.

Let me know if you'd like binaries.
https://github.com/rayarachelian/lisaem/tree/unstable

[D.Finni]

Nice work. I'll be sure to check it out!

[rayarachelian]

Just added package building functions in the bashbuild system for win10/NullSoft Installer System, Linux: deb/rpm/snapcraft, freebsd pkgng - these will be available the next time I push to unstable (probably in a week or so after more testing.) - these are only marginally tested, but they do produce installable packages.

I'll try to build a ports^* for it in FreeBSD as well, and maybe an OpenIndiana/Solaris package, but these are far lower priority - if you care about these, please let me know, if not I might put these on the back burner and go back to UniPlus sunix v1.1 (fixing the profile code) and then back to TerminalWx instead which are next to do. These are the last barriers to the 1.2.7 release +/- a few other minor features.

I probably will skip NetBSD/OpenBSD/Dragonfly BSD packages for now.

I took a look at HelloSystem and I really like it and want to use it on some of my machines, so I'd support it with a package and it's own LisaEm.app bundle, but I couldn't get it to install on a virtualbox hard drive - only seems to work as a live image, so this will also be skipped for now until a more mature release comes along. (Tried 0.50 and 0.60.)
^* Since FreeBSD doesn't install bash by default (and this is required by bashbuild), and I also prefer to use a custom, statically linked wxWidgets rather than the official one which is several versions older, I might just skip the ports dir for FreeBSD, will see how much of an uphill battle it is.There currently is a FreeBSD port for 1.2.6.2, however the maintainers switched it to regular borne shell, and rewrote-out the bash specific parts of the much older build script. That build script has evolved into its own package/library at https://github.com/rayarachelian/bashbuild )  Once all this package code is happy I'll update bashbuild with the new code as well.

[rayarachelian]

Just added classic Solaris packages as well as IPS ones to the bashbuild scripts, only took a single day of satisfying scripting on a Saturday

(or would that be better alliterated as csh'elling on a Caturday - but then again, it was bash after all?)