General Category > LisaList2
LisaEm 1.2.7-RC4 support bug reports
Al Kossow:
> if there's any way to pitch in, just name it!
getting the Pascal Workshop tools running standalone under Linux would be nice, as has been done for MPW but it isn't a trivial undertaking.
rayarachelian:
--- Quote from: Al Kossow on June 12, 2020, 04:23:55 pm ---
> Is the source debugger a part of LOS or are you adding it to LisaEm itself? If it's for LisaEm itself, would you release that also?
It would be for LisaEm, and I'd be releasing it.
The intent is to have a symbolic debugger that knows about LisaOS segmentation so you could see how the system works.
--- End quote ---
Fantastic! I look forward to it.
In terms of the CPU bug, I think I have a possible starting point. I didn't test some of the lesser used addressing modes with MOVE, and I remember having to change a few when I ported the CPU core from Generator over to LisaEm because it didn't support some at all. So those weren't tested at all. I did have some disassembly errors in some of these as well for some opcodes that were working, but disassembled incorrectly, so it's a fuzzy area where there may be more errors.
But, I think instead of creating giant tables in memory, they can be tested by using LEA, stuff like offset off PC, and such. They're possibly used as indices into tables, such as the menu list inside the Desktop menu, I suspect it's returning just the first one instead of adding an index or multiplying properly and so the same item shows up 8x instead of 8 different ones. Possibly such an opcode is used in the SANE lib on lookup tables, and certainly they'd be used to deference a specific file in a directory.
I don't think I can do the same for BRAnch/jmp/jsr, but if the addressing modes are good for LEA they should be good there too.
Going to see if I can fire up the good ole NeXT slab to test this theory. Will take weeks to test properly, but if that's what it is, it should be solvable.
I don't think they're all broken, I think they're broken under certain edge cases or else a lot more of the emulator would be broken.
--- Code: ---|Addressing Mode|Mode|Register
|-----------------------------
| (d16,PC) |111 | 010
|-----------------------------
| (d8,PC,Xi) |111 | 011
|-----------------------------
| (bd,PC,Xi) |111 | 011
|-----------------------------
|([bd,PC,Xi],od)|111 | 011
|-----------------------------
|([bd,PC],Xi,od)|111 | 011
--- End code ---
I'm making a ton of assumptions as I write this and I might be chasing my own tail, but if they pass, and the bug isn't found at least it would indicate that I should have a lot more confidence in those addressing modes. So at least it's a starting hypothesis to test.
rayarachelian:
--- Quote from: Al Kossow on June 12, 2020, 04:26:33 pm ---> if there's any way to pitch in, just name it!
getting the Pascal Workshop tools running standalone under Linux would be nice, as has been done for MPW but it isn't a trivial undertaking.
--- End quote ---
Here's another thing I've been thinking of, I want to build a Lisa interface app, not a full tool with stationary, but something more akin to the clock or the settings panel that can sit in the background and wait for commands from the host side of LisaEm. (Think Virtual Box Guest Additions, or VMWare tools)
Al, and Tom, if you'd like to help this to move forward, here's what I propose:
What I'd need it to do is to sit in a loop and accept commands that do the following things:
1. fetch the current directory listing with full attributes for all files and details and send it over to the host side of LisaEm. (i.e. directory at a specific location)
2. open a file handle and either read the whole file over to LisaEm or write a new entire file sent by LisaEm to the file system. (It can be a block level protocol where it does one block at a time and has some handshaking to say block sent, ok, get next block, etc. now close the file handle and go back to the idle loop)
3. enumerate devices such as inserted floppies or change directories. (i.e. one floppy inserted, what's it's volume name, 3 profiles, what are their paths)
4. optional - send the Lisa Clipboard over to LisaEm, or the other way.
5. optional - launch some other process/app
I can use the F-Line HLE (High Level Emulation) interface that I already have for ROMless mode to do this, so basically if this were ran on a real Lisa it would cause it crash with an F-Line exception, but on LisaEm it would work, but perhaps we can do something else with the NOP opcode in some weird pattern, like maybe:
--- Code: ---NOP
NOP
NOP
JMP (PC+2)
JMP (PC+2)
NOP
NOP
NOP
--- End code ---
which would do nothing on a real Lisa, but I could detect that stream of opcodes in LisaEm and use it as an interface.
It would need to use some embedded assembly so I can put values directly in either A or D registers to pass back and forward. I'd need it to send me a pointer to a block for some operations, and then I could read/write the data in the block on the LisaEm side. I pinged David T. Craig about this a few years ago and he shared how to write embedded assembly in pascal, so it's pretty doable, but I just didn't spend cycles on this.
Might be a bit more complicated for LPW, but if that could run in the background in LPW it could be used to allow us to control the compiler/linker and use an external IDE like VSCode/codium, etc. with some scripting. I've wanted to make LisaEm scriptable for a very long time now, so this would be a great excuse for that. (So I can easily add stuff like send a set of keystrokes or move the mouse to a specific location, or detect a button and click it, etc. sort of like QuickKeys.)
So if both of these things are done we can then add some git hooks or just have a make file that initiates a bunch of actions in LisaEm to press certain keys or move some files around which could invoke the compiler or linker, etc. as the end result, but you'd be editing in a comfy modern editor which LisaEm running in the background.
If I can get some help on this, I can finish off 1.2.7 in parallel and start implementing some of these features (which I was planning for 2.0 anyway) now which can help Al.
License wise it would need to be compatible with the GPL so I can include it.
Al Kossow:
if you want to look at a core other than generator, the one in MAME has been pretty thouroughly tested.
there also is a 68k instruction test suite out there.
stepleton:
--- Quote from: rayarachelian on June 12, 2020, 05:35:21 pm ---Here's another thing I've been thinking of, I want to build a Lisa interface app, not a full tool with stationary, but something more akin to the clock or the settings panel that can sit in the background and wait for commands from the host side of LisaEm. (Think Virtual Box Guest Additions, or VMWare tools)
...
License wise it would need to be compatible with the GPL so I can include it.
--- End quote ---
This is probably a bit more than I can chew at the moment (and the Linux-hosted Workshop is way out of my league, alas), but what's described here sounds like it may be able to use parts from this old project: https://github.com/stepleton-xx/lisabbs. The license is public domain, so you can do whatever you like with it. There's no inline assembly code, but there is non-inlined assembly that someone could use as a pattern.
BTW, if your NeXT isn't working, if Al's resources aren't appropriate, and if you can't use the Previous emulator to do what you need (which would be a roundabout way of comparing two 68k emulators), I have several NeXTs of my own. Conceivably I could establish a way for you to log into one of these machines remotely if you don't need the GUI.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version