LisaList2

Advanced search  

News:

2022.06.03 added links to LisaList1 and LisaFAQ to the General Category

Pages: 1 2 [3] 4 5 ... 12   Go Down

Author Topic: LisaEm 1.2.7-RC4 support bug reports  (Read 53716 times)

Al Kossow

  • Sr. Member
  • ****
  • Karma: +34/-0
  • Offline Offline
  • Posts: 73
Re: LisaEm 1.2.7-RC1 support bug reports
« Reply #30 on: June 11, 2020, 01:56:40 pm »

should there be a separate thread for build problems?

it built, but running the LisaEm file fails to start

aek$ lldb ./LisaEm
(lldb) target create "./LisaEm"
2020-06-11 10:55:43.216 lldb[60281:1979433] Metadata.framework [Error]: couldn't get the client port
Current executable set to './LisaEm' (x86_64).
(lldb) run
Process 60751 launched: './LisaEm' (x86_64)
Process 60751 stopped
* thread #1: tid = 0x1e35e5, 0x00007fff91c9a09e libsystem_c.dylib`flockfile + 4, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x68)
    frame #0: 0x00007fff91c9a09e libsystem_c.dylib`flockfile + 4
libsystem_c.dylib`flockfile:
->  0x7fff91c9a09e <+4>:  movq   0x68(%rdi), %rdi
    0x7fff91c9a0a2 <+8>:  addq   $0x8, %rdi
    0x7fff91c9a0a6 <+12>: popq   %rbp
    0x7fff91c9a0a7 <+13>: jmp    0x7fff91ce344a            ; symbol stub for: pthread_mutex_lock
Logged

rayarachelian

  • Administrator
  • Hero Member
  • *****
  • Karma: +101/-0
  • Offline Offline
  • Posts: 772
  • writing the code,writing the code,writing the code
    • LisaEm
Re: LisaEm 1.2.7-RC1 support bug reports
« Reply #31 on: June 11, 2020, 06:01:41 pm »

should there be a separate thread for build problems?

it built, but running the LisaEm file fails to start

aek$ lldb ./LisaEm
(lldb) target create "./LisaEm"
2020-06-11 10:55:43.216 lldb[60281:1979433] Metadata.framework [Error]: couldn't get the client port
Current executable set to './LisaEm' (x86_64).
(lldb) run
Process 60751 launched: './LisaEm' (x86_64)
Process 60751 stopped
* thread #1: tid = 0x1e35e5, 0x00007fff91c9a09e libsystem_c.dylib`flockfile + 4, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x68)
    frame #0: 0x00007fff91c9a09e libsystem_c.dylib`flockfile + 4
libsystem_c.dylib`flockfile:
->  0x7fff91c9a09e <+4>:  movq   0x68(%rdi), %rdi
    0x7fff91c9a0a2 <+8>:  addq   $0x8, %rdi
    0x7fff91c9a0a6 <+12>: popq   %rbp
    0x7fff91c9a0a7 <+13>: jmp    0x7fff91ce344a            ; symbol stub for: pthread_mutex_lock


Please build it with --debug and then when this happens try to do run the list command and/or bt (backtrace) to see where it's crashing so we can find out more about what caused this crash.
Logged
You don't know what it's like, you don't have a clue, if you did you'd find yourselves doing the same thing, too, Writing the code, Writing the code

Al Kossow

  • Sr. Member
  • ****
  • Karma: +34/-0
  • Offline Offline
  • Posts: 73
Re: LisaEm 1.2.7-RC1 support bug reports
« Reply #32 on: June 11, 2020, 07:36:19 pm »

(lldb) bt
* thread #1: tid = 0x233677, 0x00007fff91c9a09e libsystem_c.dylib`flockfile + 4, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x68)
  * frame #0: 0x00007fff91c9a09e libsystem_c.dylib`flockfile + 4
    frame #1: 0x00007fff91ca3368 libsystem_c.dylib`vfprintf_l + 28
    frame #2: 0x00007fff91c9b885 libsystem_c.dylib`fprintf + 186
    frame #3: 0x000000010003330e LisaEm`LisaEmFrame::LoadImages() + 3118
    frame #4: 0x000000010004505d LisaEm`LisaEmFrame::LisaEmFrame(wxString const&) + 28445
    frame #5: 0x0000000100035484 LisaEm`LisaEmApp::OnInit() + 3396
    frame #6: 0x00000001001cbabd LisaEm`wxApp::CallOnInit() + 173
    frame #7: 0x000000010015c599 LisaEm`wxEntry(int&, wchar_t**) + 121
    frame #8: 0x000000010003415f LisaEm`main + 15
    frame #9: 0x00007fff938b35ad libdyld.dylib`start + 1
    frame #10: 0x00007fff938b35ad libdyld.dylib`start + 1


--

should everything be in the app bundle at that point?
Logged

rayarachelian

  • Administrator
  • Hero Member
  • *****
  • Karma: +101/-0
  • Offline Offline
  • Posts: 772
  • writing the code,writing the code,writing the code
    • LisaEm
Re: LisaEm 1.2.7-RC1 support bug reports
« Reply #33 on: June 11, 2020, 10:19:14 pm »

(lldb) bt
* thread #1: tid = 0x233677, 0x00007fff91c9a09e libsystem_c.dylib`flockfile + 4, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x68)
  * frame #0: 0x00007fff91c9a09e libsystem_c.dylib`flockfile + 4
    frame #1: 0x00007fff91ca3368 libsystem_c.dylib`vfprintf_l + 28
    frame #2: 0x00007fff91c9b885 libsystem_c.dylib`fprintf + 186
    frame #3: 0x000000010003330e LisaEm`LisaEmFrame::LoadImages() + 3118
    frame #4: 0x000000010004505d LisaEm`LisaEmFrame::LisaEmFrame(wxString const&) + 28445
    frame #5: 0x0000000100035484 LisaEm`LisaEmApp::OnInit() + 3396
    frame #6: 0x00000001001cbabd LisaEm`wxApp::CallOnInit() + 173
    frame #7: 0x000000010015c599 LisaEm`wxEntry(int&, wchar_t**) + 121
    frame #8: 0x000000010003415f LisaEm`main + 15
    frame #9: 0x00007fff938b35ad libdyld.dylib`start + 1
    frame #10: 0x00007fff938b35ad libdyld.dylib`start + 1


--

should everything be in the app bundle at that point?

Yes, the LisaEm.app folder structure should be created, the skins and the images it's trying to load should be inside it at this point, but weirdly it's dying on fprintf, so since debug is enabled, it's trying to call ALERT_LOG which is going to say it entered LoadImages, and then what image it's loading.

Not sure what caused the segfault there, likely something was NULL, possibly there's a failure to convert the wxString to a cstring in the string concat on pngfile:
 
Code: [Select]
 
    #define LOADBITMAP(XpngX,XresnameX)                                                                  \
    { pngfile=skindir + skin.XresnameX; if (!XpngX) XpngX    = new wxBitmap(pngfile, wxBITMAP_TYPE_PNG); \
      ALERT_LOG(0,"Opening %s filename",(const char *)pngfile);                                          \
      if (!XpngX->IsOk()) EXIT(0,0,"something went wrong with loading %s",(const char *)pngfile);        \
    }                                                                                                       
It's possible skindir isn't right, or the bundle hasn't been created properly by the build.

If you do frame return (I think) it will rise up in the stack frame one level, repeating this until you get to the LoadImages method might give you more info, and you can try list to see where exactly it went wrong.

Some other things to try - I'd see about deleting your LisaEm preferences - if you've got some from 1.2.6, they may cause issues.

Another thing is to check that you see a skins directory under LisaEm.app/resources and inside is another directory called default (for default) skin, and it has a config file with details about the skin, along with the pngs and wavs:

Code: [Select]
└── LisaEm.app
    └── Contents
        ├── MacOS
        └── Resources
            ├── resources -> .
            └── skins
                └── default

Since there's questions around iconv, and iconv is involved in UTF, I wonder if it would help you if I tarred up my wxWidgets dir from my install of macos x 10.11 to make things simpler? if so try this: https://lisaem.sunder.net/downloads/wx-widgets-macosx-10.11-elcap.tar.xz - it expects to be extracted to /usr/local from /

Also, when you compile with debug enabled, it will automatically run lisaem within lldb and set it to power on immediately.
I'd say also unset LD_LIBRARY_PATH and DYLD_LIBRARY_PATH before running build.sh.
Logged
You don't know what it's like, you don't have a clue, if you did you'd find yourselves doing the same thing, too, Writing the code, Writing the code

Al Kossow

  • Sr. Member
  • ****
  • Karma: +34/-0
  • Offline Offline
  • Posts: 73
Re: LisaEm 1.2.7-RC1 support bug reports
« Reply #34 on: June 12, 2020, 12:01:45 pm »

The issue is with my build of wx3.1.3

your wx3.1.3-cocoa-x86-macOS-10.11-clang-sdl works and builds with -liconv

also it creates LisaEm.app, with my build of the library, replacing -liconv with /usr/lib/libiconv.2.dylib it creates LisaEm

I will leave finding the root cause for what the mismatches in my building of the library for another day..
« Last Edit: June 12, 2020, 12:04:26 pm by Al Kossow »
Logged

rayarachelian

  • Administrator
  • Hero Member
  • *****
  • Karma: +101/-0
  • Offline Offline
  • Posts: 772
  • writing the code,writing the code,writing the code
    • LisaEm
Re: LisaEm 1.2.7-RC1 support bug reports
« Reply #35 on: June 12, 2020, 01:00:23 pm »

The issue is with my build of wx3.1.3
...
I will leave finding the root cause for what the mismatches in my building of the library for another day..

Yeah, I treat wxWidgets as yet another lib, and not part of LisaEm, though experience tells me wx usually needs a custom build, and OS shipped wxWidgets almost always don't work - the only exception I've seen so far is for the wx3.0 that ships with Ubuntu 19.10, but I prefer later releases as they've fixed some of their bugs and have better features.

I've had plenty of issues with wxWidgets, but for now I'm stuck with it until things get better with Qt - there's possible talk of forking it to get rid of the licensing issue, we'll see. see: https://www.phoronix.com/scan.php?page=news_item&px=More-Interest-Possible-Qt-Fork

There's not many other choices. SDL is fine for full screen games and emus, but terrible at UIs. I didn't like Qt in the past because what it created didn't look like a native app - not sure about newer ones. GTK might be a possibility - I've been told it's actually portable to Windows/macos x, but don't know that much about it.

I'm certainly not about to support 3 different GUI libraries and write native windows, cocoa and GTK UI's that would be a waste of time.

One of the (many) goals for 2.0 is to separate out the UI from the core so that alternative UIs can be used.

But for now I've got a lot of core features to fix and new ones to implement.
Logged
You don't know what it's like, you don't have a clue, if you did you'd find yourselves doing the same thing, too, Writing the code, Writing the code

Al Kossow

  • Sr. Member
  • ****
  • Karma: +34/-0
  • Offline Offline
  • Posts: 73
Re: LisaEm 1.2.7-RC1 support bug reports
« Reply #36 on: June 12, 2020, 01:13:44 pm »

Thanks for all of you efforts

Cross-platform GUI development is a nightmare

The whole point of building my own version of Lisaem is to try to get a development platform with a source debugger for the Lisa OS sources so that people could do something with them. It's been stalled for months becuase I had been waiting for your release to try gluing in a debugger, and the MAME Lisa emulation still doesn't get through self-test.

Logged

rayarachelian

  • Administrator
  • Hero Member
  • *****
  • Karma: +101/-0
  • Offline Offline
  • Posts: 772
  • writing the code,writing the code,writing the code
    • LisaEm
Re: LisaEm 1.2.7-RC1 support bug reports
« Reply #37 on: June 12, 2020, 01:38:38 pm »

Thanks for all of you efforts

Cross-platform GUI development is a nightmare

The whole point of building my own version of Lisaem is to try to get a development platform with a source debugger for the Lisa OS sources so that people could do something with them. It's been stalled for months becuase I had been waiting for your release to try gluing in a debugger, and the MAME Lisa emulation still doesn't get through self-test.



One thing to be aware of, you're going to run into issues with the LPW linker throwing either bus/address errors or throwing "Bad intrin patch" - I've not been able to solve that, but suspect it's the same as the Desktop menu bug, or the scrollbars bug. :( I'm trying to finish off 1.2.7 by the end of June so I can work on resurrecting the 1.3.0 CPU core in order to fix this and get to the other 2.0 features after July.
It's either it's own bug, or some opcode that behaves differently between the 68000 and 68040 math/shift/bit ops, or possibly some address mode - I didn't test any complex addressing modes in the 68000 tester I build on the NeXT slab because I didn't have a good way to do that yet, but I think I have an idea of how to do that next.


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?

And many thanks for working on getting the Lisa sources released!
« Last Edit: June 12, 2020, 02:24:16 pm by rayarachelian »
Logged
You don't know what it's like, you don't have a clue, if you did you'd find yourselves doing the same thing, too, Writing the code, Writing the code

stepleton

  • Sr. Member
  • ****
  • Karma: +109/-0
  • Offline Offline
  • Posts: 384
Re: LisaEm 1.2.7-RC1 support bug reports
« Reply #38 on: June 12, 2020, 03:51:31 pm »

The whole point of building my own version of Lisaem is to try to get a development platform with a source debugger for the Lisa OS sources so that people could do something with them.

Hooray!

I can't think of what I could do to help this effort, but if there's any way to pitch in, just name it!
Logged

Al Kossow

  • Sr. Member
  • ****
  • Karma: +34/-0
  • Offline Offline
  • Posts: 73
Re: LisaEm 1.2.7-RC1 support bug reports
« Reply #39 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.

Logged

Al Kossow

  • Sr. Member
  • ****
  • Karma: +34/-0
  • Offline Offline
  • Posts: 73
Re: LisaEm 1.2.7-RC1 support bug reports
« Reply #40 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.

Logged

rayarachelian

  • Administrator
  • Hero Member
  • *****
  • Karma: +101/-0
  • Offline Offline
  • Posts: 772
  • writing the code,writing the code,writing the code
    • LisaEm
Re: LisaEm 1.2.7-RC1 support bug reports
« Reply #41 on: June 12, 2020, 05:22:56 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.


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: [Select]
|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   


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.
Logged
You don't know what it's like, you don't have a clue, if you did you'd find yourselves doing the same thing, too, Writing the code, Writing the code

rayarachelian

  • Administrator
  • Hero Member
  • *****
  • Karma: +101/-0
  • Offline Offline
  • Posts: 772
  • writing the code,writing the code,writing the code
    • LisaEm
Re: LisaEm 1.2.7-RC1 support bug reports
« Reply #42 on: June 12, 2020, 05:35:21 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.


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: [Select]
NOP
NOP
NOP
JMP (PC+2)
JMP (PC+2)
NOP
NOP
NOP

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.
« Last Edit: June 12, 2020, 05:43:24 pm by rayarachelian »
Logged
You don't know what it's like, you don't have a clue, if you did you'd find yourselves doing the same thing, too, Writing the code, Writing the code

Al Kossow

  • Sr. Member
  • ****
  • Karma: +34/-0
  • Offline Offline
  • Posts: 73
Re: LisaEm 1.2.7-RC1 support bug reports
« Reply #43 on: June 12, 2020, 06:20:29 pm »

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

stepleton

  • Sr. Member
  • ****
  • Karma: +109/-0
  • Offline Offline
  • Posts: 384
Re: LisaEm 1.2.7-RC1 support bug reports
« Reply #44 on: June 12, 2020, 09:26:55 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.

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.
Logged
Pages: 1 2 [3] 4 5 ... 12   Go Up