Print

[D.Finni]

tried monitor last night and it immediately crashed so either the MMU changes broke it, or it's a broken image. Will retest this again when I've got the MMU working again.

I used the Monitor 12.3 image that's a 400K floppy. None of the Twiggy Monitors would boot. Got a hang with an hourglass cursor.

[rayarachelian]

I used the Monitor 12.3 image that's a 400K floppy. None of the Twiggy Monitors would boot. Got a hang with an hourglass cursor.

Ok thanks, will retry. i was using that same one so must be the MMU changes that's breaking it.

So there's a bit of a puzzle I'm trying to solve with the MMU. The docs on the surface seem pretty forward, but they're not when it comes to the stack. I wrote a small test program that fills RAM with the same value as the address, and then I set MMU segment 125 to be a stack segment of length 32. And this should be mapped from the top. So segment 125 maps to the range 0x00fa000000-0x00fbffffff.

For normal RAM segments the space is allocated to the start, that is fa000000. But if it's a stack, it starts at 0x00fbffff and grows downward by SLR pages. each 512 bytes.

So the goal here is to get LisaEm in service mode to match what this code does on a real Lisa and then retry UniPlus and see if it gets any further.
The bug there for those who missed it was that there's a memory fill routine that because of the incorrect stack mmu segment setting overwrites it's return address, which then winds up executing from address 0. After looking at it, I saw that this was because two MMU segments pointed to the same physical space, and realized LisaEm's stack segment implementation is incorrect.

The mmu test code looks like this incase anyone's curious. It just fills memory, sets segment 125, and goes back to the boot ROM, which throws an error, likely I should have cleared D0, but the error is good because then I can hit Apple-S to go to service mode and poke around memory:

So I put this on a CF card and fed it to the floppy emu, and booted off it, and then went in service mode to poke around memory. I then modified that 720 and 600 and reran it, and no matter what I do, I always get the same window of memory that works. Changing the SOR from 600 to 400 or 500 works and I see a different set of values there. But any other addresses outside that single page cause a bus error which means the size value in SLR isn't honored at all.

Code: [Select]

00020000 Starting Address
Assembler used: ASy68K Assembler v5.15.04
Created On: Thu Nov 19 21:37:07 2020


00000000                             1  ;------------------------------------------------------------------------------------
00000000                             2  ; mmu-stack tester - tiny program to fill most of Lisa RAM with it's own address
00000000                             3  ; and then set mmu segment 125 so we can see the physical addresses and test
00000000                             4  ; access via Service Mode.
00000000                             5  ;------------------------------------------------------------------------------------
00000000                             6 
00000000                             7 
00020000                             8    ORG     $20000     ; starting address note spaces at start
00020000                             9 
00020000                            10  START:
00020000  203C 00020080             11    MOVE.L #$20080,D0  ; start ~0x40 bytes after this code.
00020006                            12  FILL:
00020006  2040                      13    MOVE.L D0,A0
00020008  2080                      14    MOVE.L D0,(A0)
0002000A  5880                      15    ADDQ.L #$04,D0
0002000C  B0B8 0110                 16    CMP.L ($110),D0   ; fill RAM until screenbase
00020010  6FF4                      17    BLE FILL
00020012                            18    ;--------------------------------------------------------------------------------------------------------------------------------
00020012                            19    ; uniplus sets mmu like this:
00020012                            20    ;
00020012                            21    ;    mmu[1][122].slr:0c00,sor:0000  00f40000-00f5ffff::-->(00000000)  type::unused:0c00
00020012                            22    ;    mmu[1][123].slr:0c00,sor:0000  00f60000-00f7ffff::-->(00000000)  type::unused:0c00
00020012                            23    ;    mmu[1][124].slr:0c00,sor:0000  00f80000-00f9ffff::-->(00000000)  type::unused:0c00 v- so is this a bug somewhere else?
00020012                            24    ;    mmu[1][125].slr:07fc,sor:05dd  00fa0000-00fbffff::-->(0003ba00)  type::rw_mem:07fc <- this is normal RAM, not stack!!!
00020012                            25    ;    mmu[1][126].slr:0900,sor:0000  00fc0000-00fdffff::-->(00000000)  type::io_spc:0900
00020012                            26    ;    mmu[1][127].slr:0f00,sor:0000  00fe0000-00ffffff::-->(00000000)  type::siospc:0f00
00020012                            27    ;
00020012                            28    ;   2x of 7d (125)=0xfa => 0x00faxxxx == sor:00fa8008 slr:00fa8000
00020012                            29    ;   400=rostack, 500=romem, 600=rwstack, 700=rwmem, 900=iospace, c00=bad page, 0f00=sio/rom
00020012                            30    ;--------------------------------------------------------------------------------------------------------------------------------
00020012  247C 00FA8008             31    MOVEA.L #$00fa8008,A2       ;MMUSADRB,A2    ;SET MMU BASE REG PTR - use fa here as fc will cause crashing in ROM  - fa8008 is SOR
00020018  267C 00FA8000             32    MOVEA.L #$00fa8000,A3       ;MMUSADRL,A3    ;SET LIMIT REG PTR                                                    - fa8000 is SLR
0002001E  303C 0300                 33    MOVE.W  #$0300,D0           ;SET BASE VALUE should be 300*200=60000
00020022  323C 0600                 34    MOVE.W  #$0600,D1           ;MEMLMT,D1      ;SET to stack, only 32 pages.
00020026  287C 00FE0084             35    MOVE.L  #$00fe0084,A4       ;return value is monitor entry
0002002C  4EF9 00FE008C             36    JMP      $00fe008C          ;WRTMMU and return to A4
00020032                            37 
00020032                            38    END START                   ;need spaces before end keyword for it to work.

No errors detected
No warnings generated


SYMBOL TABLE INFORMATION
Symbol-name         Value
-------------------------
FILL                20006
START               20000

When I went to try this on another Lisa that has the "H" ROM, to eliminate whether this is an issue with the "F" ROM not honoring SLR properly, unfortunately either the display on my floppyemu died, or the entire floppy emu died. Grrrr. So now, worst case, I'll have to either enter these bytes by hand on the keyboard or make a physical floppy... Or I can use the 2nd floppy emu that I got for a Mac SE instead...

Funnily enough I do have a few of the nokia LCD screens that it uses because when I got the floppy emu, it came with a dead display so I ordered a few of them, but I'll have to go solder the header pins on another... Meh....  This is the exact reason I wrote this emulator - because I got tired of dealing with failing Lisa hardware and irony of ironies, the floppy emu I got so I don't have to deal with failing floppies also failed...

Limiting the stack to a single page and trying UniPlus with LisaEm now causes a different crash on an undocumented opcode - similar but different to the last time, which I'll investigate further as well. Hmmm, come to think of it, I should check that opcode on a real Lisa to see if it also causes a crash - maybe that's actually not supposed to crash. Wouldn't that be quite the find!

Somewhat in parallel I'm working on the xon/off (software flow control) SCC handling and mouse issues in LOS. I haven't yet attempted to fix the contrast issue.

Edit 2020.11.12 8pm:

I manually typed in the above (now slightly cleaned up code) into my H-ROM 2/10 and got exactly the same results. I confirmed that it only allocates a single 512 byte page of stack and no more. It's not the F-ROM vs H-ROM, either the above code is wrong, or the Lisa MMU can only allocate a single 1 page stack for a segment. Edit: this was caused by an error in the tester code.

Tried that illegal 4e7a opcode that UniPlus tries to execute and got an error 48 (Illegal Instruction), so not quite sure what it's for, but throwing an illegal instruction trap is the right thing to do.



Edit 2020.11.19: so going over this code again, it turns out I've swapped the pointers to SLR and SOR, and that's what it wasn't working properly. I've modified the tester code, and optimized it a bit, and tried it again, and got proper results that match what the HWG's say. However, trying the same in LisaEm resulted in physical memory underflows, which are errors in emulation, which I'll fix. So this exposed a pretty huge bug.

The good news is that it allocates the right number of pages at the right virtual addresses. The bad news is that the physical location of the RAM is wrong.

The weird thing, the SLR that was used by UniPlus is incorrect, it's 7xx, which is not a stack segment, but rather a normal RAM segment, even though it was used as a stack. So that will require a lot more investigating, That could be on purpose or caused by some other issue elsewhere, will find out after I fix this.

[rayarachelian]

Still fixing some more MMU related code, in the last week, I've written three alternate MMU handlers, two of them worked, the other did not, however with the new ones that worked, it broke LOS, so there's some more fixes to apply. One of the MMU handlers completely gets rid of the address ea caching and calculates the RAM address right off SOR on each access. The other uses math as before, but now has a lot of int32 casts around the addition code which seems to be making the big difference.

The ones that worked also fixed Monitor, after which I fixed the yellow contrast bug.

It also seems to be allowing MacWorks 3.0 to install to the hard drive. It didn't work on the first pass, but after I enabled tracelog to try to find the issue, it worked the 2nd time around - this might be some timing bug since TRACELOG slows it down to about 500KHz on my machine, but it did work and allow me to copy the System folder over to the hard drive. At least now I have a 5MB ProFile drive that has MacWorks installed on it for what it's worth.


You still have to boot off the boot floppy (just the same as with lisaem <=1.0) because it will throw error 75 when trying to boot off the hard drive. MacWorks XL 4.5 still throws a sad mac. (On a real Lisa, MacWorks 3.0 does self-boot off the hard drive without the boot floppy, so that's yet another bug somewhere, likely with ProFile/via emulation.)


One thing might be the serial number, not sure about this, but was using it with the magic-zero serial number on the first attempt and then switched to one of my Lisa's serial numbers - perhaps it cares, but not sure why it would, but I did see a message saying it read the serial number after it started booting.

One clue might is that all of a sudden after the new MMU fix, the vectors I use to detect the OS in glue.c have moved for MacWorks and Monitor.
Perhaps these new address changes have something to do with LOS failing. LOS now crashes by executing code that doesn't exist - that is it branches or JMPs or something to a region where no code has been loaded which causes the emulator to bail since there's no basic block for it to work on.

But obviously Monitor crashing on boot was a bug that got fixed so both somewhat closer, and further away. UniPlus behaves exactly the same as before, with a double trap panic, etc. however Xenix is now crashing in the same way that LOS crashes, so that's another clue that the MMU isn't quite there yet.

[rayarachelian]

I've fixed LOS from crashing, nothing else has changed/improved than MacWorks 3.0. Going back to the pty issues and mouse click-release issues.

[rayarachelian]

Managed to fix the pty code last nigh, xon/xoff worked well, the output isn't getting cut off anymore.
Serial port A is still broken, however, looking at it now.

[rayarachelian]

Didn't manage to fix serial port A, so disabled it instead. Added host serial port support (i.e. USB to serial adapters: /dev/ttyUSB0, or wired serial ports /dev/ttyS0 - names on macos and FreeBSD will vary.).

On Linux you might not have permissions to your USB serial port, so you either have to add yourself to the right group (dialout) and then logout and log back in, or use sudo chmod o+rw on /dev/ttyUSB0 (or whatever) as the device will be owned by root and you won't be able to open it.

The Serial code in LisaEm only connects at "power on" - if for example you choose Shell (PTY) and then type in exit, you won't be able to use that connection until you tell Lisa Office System to power off and then power back on. Perhaps in future releases I'll add a way to reconnect or even switch the backend device. But for now this will suffice as a lame, but somewhat acceptably usable thing.

I've not tested this on macos yet. I've mostly used POSIX methods of opening the pty and serial port, so in theory it should work, testing may reveal it will not. Will find out soon enough. 
This will be part of 1.2.7-RC4 release.

As you might have noticed, I've renamed some of the options, so PTY is now "Shell" as that's more human friendly, and the parameter would be either nothing, or something like /bin/bash or /bin/zsh.
For Serial, meaning host physial serial port, you'll need to figure out the device name. If it's a USB serial port, it will create a new character device in /dev with the time/date of the insertion, so you can use ls -Flatr /dev/tty* to find it, or perhaps the output of dmesg:

Code: [Select]


$ dmesg -T

...[Wed Dec  9 12:26:22 2020] keyspan_pda 1-1:1.0: Xircom / Entrega PGS - (prerenumeration) converter detected
[Wed Dec  9 12:26:22 2020] usb 1-1: USB disconnect, device number 6
[Wed Dec  9 12:26:22 2020] keyspan_pda 1-1:1.0: device disconnected
[Wed Dec  9 12:26:24 2020] usb 1-1: new full-speed USB device number 7 using xhci_hcd
[Wed Dec  9 12:26:24 2020] usb 1-1: New USB device found, idVendor=06cd, idProduct=0104, bcdDevice=ab.89
[Wed Dec  9 12:26:24 2020] usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[Wed Dec  9 12:26:24 2020] usb 1-1: Product: ACME USB serial widget
[Wed Dec  9 12:26:24 2020] usb 1-1: Manufacturer: ACME usb widgets
[Wed Dec  9 12:26:24 2020] usb 1-1: SerialNumber: 47
[Wed Dec  9 12:26:24 2020] keyspan_pda 1-1:1.0: Keyspan PDA converter detected
[Wed Dec  9 12:26:24 2020] usb 1-1: Keyspan PDA converter now attached to ttyUSB0  <<<--- here it is

$ ls -Flatr /dev/tty*

....

crw-rw-rw-   1 root dialout   188,   0 Dec  9 11:37 /dev/ttyUSB0 <<-- and here.

....


As you can see, the device is owned by root:dialout, so adding your user to the dialout group, followed by logging out and logging back in should get you access to the port, if not, or you don't feel like logging out, you can sudo chown it or sudo chmod it as needed.
The preferences string for the port I used is "/dev/ttyUSB0|9600,N,8,1" - the first part is the device name. This is absolutely required or you won't be able to use the port.

The | character is a separator to the parameters. If you omit it, LisaTerminal will be able to set the baud rate, number of bits, parity, and stop bits.
If you provide it, you can lock the port to the settings you've provided, and no matter what's set in Lisa Terminal the port will remain at that speed/settings.
You can also add ",hw" to enable hardware handshaking, or ",-hw" to disable it. ",xon" (as well as checking the Xon/Off checkbox will enable software handshaking on the Linux side of the port. ",-xon" will force disable software handshaking on the Linux side. Note that Lisa Terminal will still send ^S/^Q characters to signal xoff/xon through the port.

For LOS and LisaTerminal it's pretty much required to use Xon/Xoff software handshaking to prevent data loss, even though I've built in some code to detect LOS and slow down the serial port pacing, but since LisaTerminal lacks file transfers, there's not much disadvantage to enabling software handshaking.

Since Serial A is broken, it's now set to Nothing, and all the options are disabled. Sadly this will remain until I can get it to work such as LOS doesn't hang when Serial A is accessed. There's some bug in the z8530 code somewhere that prevents it from working properly.

Neither the PTY(Shell), nor the Serial port code will work on Windows. I'll eventually write Windows specific equivalent code to allow it to work there, but likely this won't be in 1.2.7.

Most likely I'll release 1.2.7 final before the end of this year, and then start on 2.0. I'll back fill some of the features into a 1.2.8 and possibly 1.2.9 - i.e. the widget emulation, and debugger features.

[D.Finni]

Since Serial A is broken, it's now set to Nothing, and all the options are disabled. Sadly this will remain until I can get it to work such as LOS doesn't hang when Serial A is accessed. There's some bug in the z8530 code somewhere that prevents it from working properly.

Isn't this the port whose baud rate is limited to 9600? Does that have something to do with the problem? Earlier this summer we discovered that one port can go up to 57600, but the other is limited to only 9600.


Also, have you committed to Github recently? I'm trying to checkout the latest source, but I don't see anything new.

[blusnowkitty]

There any way you could change the Double X/Triple Y display scaler to pull up a bypassable warning instead of a hard stop? Just a minor thing really that's kinda bothered me since one of my monitors is only 100 pixels short; let me play with it anyway darn it

[rayarachelian]

Isn't this the port whose baud rate is limited to 9600? Does that have something to do with the problem? Earlier this summer we discovered that one port can go up to 57600, but the other is limited to only 9600.

That's unrelated and has to do with the design of the I/O board and which clock is presented to which z8530 timing pin. That said, it is possible for Serial A on actual Lisas to go higher than 9600 with MacWorks (without the PFG), and it's possible to user Serial B for LocalTalk (230KBPs).

The weird thing is that early on, LisaEm passed the LisaTest of the serial ports where a cable that takes data from port A and sends it to port B and vice versa is used. So it's something in the way LOS uses it that the z8530 emulation isn't quite providing. I've tried older LisaEm's all the way down to 1.0 on macos x and they all lock up when LOS accesses Serial port A.

I'll have to retry LisaTest again to see if it still works or if it throws an error and see if I can get a clue of what's going wrong with port A.

Also, have you committed to Github recently? I'm trying to checkout the latest source, but I don't see anything new.

Nope. I only push to github when there's a release and things are stable. I'm working on adding yet another feature, so depending on how that goes the next one may be as early as next weekend, or much later.

[rayarachelian]

There any way you could change the Double X/Triple Y display scaler to pull up a bypassable warning instead of a hard stop? Just a minor thing really that's kinda bothered me since one of my monitors is only 100 pixels short; let me play with it anyway darn it

Eh, I suppose I could, but then you might get stuck in that mode without a way to function properly. 100 pixels would be enough to cut off the bottom of the screen where the icons get minimized to, or the top of the screen where the menu bar is, so do you think you'd enjoy scrolling up and down of almost every operation like that? It might be fun for about 5 minutes and then will be annoying.

edit: if a window shows up too high (or too large in Lisa), you could install https://www.spectacleapp.com/ on OS if you get stuck, but sadly this isn't being supported anymore. That said it seems to work all the way up to big sur.
Ubuntu seems to implement windows key + left|right to resize the window. I'd rather not disable these, but if you're hell bent on it you could disable those dialogs yourself.

[Al Kossow]

FYI, someone just mentioned SDL 2.0.14 has been released

[rayarachelian]

FYI, someone just mentioned SDL 2.0.14 has been released

LisaEm uses wxWidgets. SDL is only used to provide sound because of the sound class requires SDL:

from: https://docs.wxwidgets.org/3.0/classwx_sound.html

Code: [Select]

Currently this class is implemented on Windows and Unix (and uses either Open Sound System or Simple DirectMedia Layer).

I'll look at add the new SDL to new macos releases.

[rayarachelian]

Incase folks are curious, I'm adding the https://github.com/jeremysalwen/TerminalWx.git class to LisaEm, it will be used for various purposes including having a terminal that can be used with the emulated serial ports. Once I get it working with that, I'll also add xmodem and support for an actual serial port so  you could use LisaEm to directly talk to BLU so you can image your ProFile/Widget.

Once Xenix or UniPlus start up, it could also be used as an alternative console so you can do copy/paste, etc. and eventually for LPW.

But right this minute the goal is to add it as another endpoint for Serial B.

[rayarachelian]

I've implemented most of the TerminalWx (which is a vt100 terminal emulator window for wxWidgets) and have gotten it to compile, but the Edit Menu doesn't do much, I couldn't figure out how to enable drag select text on it.

However I was able to get text in/out of Serial B to the terminal window. Setting Serial B to "Terminal" will open a new window with the TerminalWx widget, and then whatever you type in it will show up in LisaTerminal, and vice versa. This could be useful in the future for interacting with the Lisa unixens.

Currently implementing file transfer protocols (upload/download text and xmodem.) The idea here is to attach this to a physical USB serial port, and then you could connect that to a physical Lisa and transfer disk images to/from BLU. I suppose we could build an xmodem command line for the unixens as well.

Once this works and is debugged, I'll release it as RC4 and within a few weeks after testing the 1.2.7 RELEASE. I intended to release this last year, but working in C++ is much slower.

Future plans after this are code freeze for 1.2.7 except bug fixes, which may trigger versions such as 1.2.7.1 1.2.7.2, as needed, etc. The left over stuff I intended for 1.2.7 such as Widget emulation and updates to libdc42, and possibly the debugger, will make it to 1.2.8, but once 1.2.7 is done.

Once 1.2.7 RELEASE is done, I'll be starting work on the 2.0 features, in parallel with 1.2.8, starting with revisiting the 1.3.0 CPU core (which I can test via automation now), then UI vs core separation. This is a much longer term project that could be a year or much more.

Most of the new serial port features (physical port access, shell, BLU interface) won't be available for Windows 10 in 1.2.7 since it has different ways of doing things than POSIX style systems, but I'll likely add them to 1.2.8.

At least that's the plan at the moment.

[compu_85]

.... Added host serial port support ...

Sweet! I'll have to try it with the daisy wheel and Imagewriter!

-J