Advanced search  


2019.06.07 fixed NChat for the "Curve" theme, will eventually move it to its own page and add it to the default theme as well. Other plugins are next. see post in the Meta board for details

Pages: 1 [2] 3 4 ... 10
 on: February 07, 2020, 09:30:51 pm 
Started by rayarachelian - Last post by berskyboy
Testing, I was not able to reply to another post, I had tried on my iPhone.  Trying this on my iMac.

 on: February 05, 2020, 07:51:35 am 
Started by rayarachelian - Last post by rayarachelian
Take a look at - the VSROM is U6C (371-0072) second chip from the upper left - the serial number bit is on D7, so it's decimal value is 128, so it's the MSB in that ROM. You can keep all the other bits the same. There is a specific format to the serial number and it includes a checksum that you can see in the boot ROM source code, but there's a direct correlation between what's written to every other byte of 0240-0280 where the boot ROM saves the SN and AppleNetID to, and bit 7 of that VSROM.

 on: February 04, 2020, 09:26:53 am 
Started by rayarachelian - Last post by jamesdenton
Followup with the second diff.

 on: February 04, 2020, 09:26:22 am 
Started by rayarachelian - Last post by jamesdenton
Nice find, Ray!

I took a look at three different ROMs - the VintageMicros Master ROM that ships with the X/ProFile and the ROM in my machine. I also found a random 341-0229-A ROM online.

You can see in these screenshots that the changed bytes are not consistent between the three ROMs. So, it may be hard(er) to pinpoint what needs to be modified. Curious to see where this goes!

 on: February 03, 2020, 08:17:38 pm 
Started by rayarachelian - Last post by Lisa2
Yes this is great, I might try printing one myself.

I don't get why the creator when to all the trouble to simulate the LOS when he could have used LisaEm and ran the real code.....

 on: February 02, 2020, 05:46:47 pm 
Started by rayarachelian - Last post by rayarachelian
Found this today: and in the description it has a link to the STL files, incase you have a 3D printer and would like to build your own:
As a bonus, here's a Mac version from Adafruit: and (but there's more parts needed as listed in the video description).

 on: February 02, 2020, 11:14:28 am 
Started by rayarachelian - Last post by rayarachelian
Quite by accident, I found a serial number string that bypasses the serialization process, this might be a useful find, or perhaps it won't actually be viable, not sure.

Code: [Select]
When you first copy a tool from the floppy to the profile, such as LisaList (tee hee!) it will still warn you that it will need to serialize it. However it will write the magic serial number of zero, which means it's unserialized! Best yet, neither LOS, nor the boot ROM see this as an error condition! And I was able to initiate a print!

This doesn't matter very much for LisaEm for obvious reasons, but I wonder what would happen if someone were to burn a VSROM with serial # zero, and tried it on a real Lisa. Anyone have the ability to do that? I've no idea what effect this will have on AppleNet, but then again, I don't think that matters much. I'd imagine that perhaps the Lisa devs had such a serial #ed Lisa when they built the tools so they could create the initial copies of the tools disks, or perhaps they didn't, and used LPW instead, but anyway...
I was able to start a print from a document created from a LisaList stationary, however, I have more bugs to fix in LisaEm as GTK crashed after the print dialog came up and I selected output to PDF file, (and worse yet, it looks like I still have memory issues to fix.)
(Printing doesn't work if you have a mismatched serial number between your installed tools and the Lisa VSROM.)

Code: [Select]
src/host/wxui/lisaem_wx.cpp:OnMouseMove:5375:Mouse actual xh,yh: (255,303)  translated x,y: (110,127) display:(145,128)+(720,500)| 10:51:12.4 671191316
src/host/wxui/lisaem_wx.cpp:iw_check_finish_job:7871:No activity on printer #5 - flushing page| 10:51:15.5 791314010
src/host/wxui/lisaem_wx.cpp:iw_check_finish_job:7871:No activity on printer #5 - flushing page| 10:51:15.5 791314010
cpu68k.c:get_ipct:799:There are no free ipcts, but ipcts_free is non zero! 1| 10:51:36.9 835665452
cpu68k.c:get_ipct:799:There are no free ipcts, but ipcts_free is non zero! 1| 10:51:36.9 835665452

(lisaem:12134): Gtk-CRITICAL **: 10:51:42.763: gtk_print_context_create_pango_context: assertion 'GTK_IS_PRINT_CONTEXT (context)' failed

(lisaem:12134): Gtk-CRITICAL **: 10:51:42.764: gtk_print_context_create_pango_layout: assertion 'GTK_IS_PRINT_CONTEXT (context)' failed

(lisaem:12134): Gtk-CRITICAL **: 10:51:42.764: gtk_print_context_get_cairo_context: assertion 'GTK_IS_PRINT_CONTEXT (context)' failed

(lisaem:12134): Gtk-CRITICAL **: 10:51:42.764: gtk_print_context_get_page_setup: assertion 'GTK_IS_PRINT_CONTEXT (context)' failed
Segmentation fault (core dumped)

 The blue screenshot attached to this post is from vbindiff, a visual text mode diff, the white hightlight is where the serial number will get written to by LOS according to David T. Craig's Lisa tool deserialization papers. See the two hex dumps in here:
As you can see LOS write zeros for the serial number, which means the tools are NOT serialized. There are changes made to the disk image, but those are date time stamps, which are normal behavior.
Obviously this is kinda useless as LisaEm itself deserializes tools internally, and you could use lisafsh-tool to do so yourself, and certainly deserialized images already exist on lisa tosec, and other places. But it's still fun to think about.
If it turns out that this works, perhaps we could burn a bunch of VSROMs with this magic serial number and never have to bother with deserialization again on actual Lisas!

 on: February 02, 2020, 11:10:22 am 
Started by stepleton - Last post by stepleton
Thanks, Ray!

At your suggestion I've updated the mouse position info in the boot ROM scratch area, and things are working just fine now.

My "ISR" routines are just polling the VIA at this point, which will probably be A-OK for this application.

Incidentally, there really was some Unicode in my original post, where I was trying to describe the places where different kinds of mouse location updates would occur---I was describing a place on the screen where some non-ASCII characters were situated. Your text filtering trick turned these into the string "M-CM-6M-CM-7M-CM-8", which is good old printable ASCII.

Also: your explanation makes it easier to understand why certain screen locations caused different kinds of increments---it was all about LisaEm trying to drive the mouse from its last known location in the ROM scratch area---the place where I clicked to tell the boot ROM to boot from the floppy drive. This also explains why nothing happens until I moved the mouse, since up until that point, both LisaEm and the boot ROM had the same idea about where the mouse should be. It's only when I move the mouse that they can start having disagreements.

Well, I reckon that's all for this round. Till next time, and thanks!

 on: February 01, 2020, 12:34:02 pm 
Started by stepleton - Last post by rayarachelian
What LisaEm does is to detect what OS is running, and then peeks into the memory addresses where the mouse vector is. It can in most things recognize when the mouse is off, but not always. It can do this detection for the boot ROM, LOS/LPW, a few LisaTest  versions, and some MacWorks versions. It decides what OS is running by looking at a few IRQ vector addresses as these seem to be the same for a given OS each time. i.e. LOS 3.x always has the same location for the mouse coordinates and it always has the same values in those IRQ vector addresses. I manually obtained these addresses by tracing the OS as it booted up and disassembling the interrupt service routines for VIA1.

Then, the code in seek_mouse attempts takes mouse events off the mouse queue and attempts to match what the running OS inside the Lisa thinks is the mouse coordinates to where the last mouse event happened. There's a bunch of optimizations and other stuff in there to get rid of jiggling and acceleration, but basically, it will send mouse movement events that attempt to get the OS's coordiantes of the mouse to match the same location of the host machine mouse relative to the Lisa display.
That patch I sent you last night fixed a bug that was in LisaEm for a very long time, it stupidly didn't realize that the mouse coordinates in the running emulated OS matched the relative mouse location in the host system and so it kept sending mouse deltas of 0,0.
There are other ways of doing mouse emulation, but this is the best way. Another way is to make the host mouse invisible, center it, and then send the deltas of the movement and then recenter it again, but this captures the mouse and is annoying to the user. This is for example what VirtualBox and VMware do when you don't have their addons/extensions installed in the guest OS, and then you need to hit some special key combination to release the focus away from the VM.

Looking at the two videos, and thank you for this, what's going on there is that since you don't have an actual mouse on the display, LisaEm tries to seek forever and will never get satisfied as the mouse inside the "running os" will never reach the coordinates of the host mouse in the display. I'm assuming it thinks running OS is still the boot ROM unless you've changed them.
If you haven't changed and don't plan to change the interrupt service routines, then you should update the mouse movement in the same memory location that the boot ROM uses. If you've changed them, you'll need to implement actual mouse routines in your code so they'll be satisfied.
The relevant code is at these locations:If you uncomment the ALERT_LOG statements in check_running_lisaos, and launch LisaEm from the command line, you'll see what LisaEm thinks the running OS is.If it still thinks it's in the boot ROM, adding some mouse handling code that updates the x,y words at locations 0486, and  0488 will allow seek_mouse to complete and then it will stop sending events.
If you did update one or more of the the ISR vector addresses that LisaEm checks for, just add another block of code that's similar to the others in lines 310-361 with your OS, whatever you want to call it, and the locations of where you keep your mouse coordinates. You'll also need to add code that handles the mouse updates, it doesn't have to display a mouse cursor or handle it, but it does have to update those coordinates.
You can also turn the mouse off by telling the COPS to do so, and I think that will prevent LisaEm from attempting to send mouse delta updates, or you can write a long of 0xffffffff to address 490 - but I think that only works with the boot ROM, so it might not be as good a way to go (and  I didn't implement this for other guest OS's).
Hope this helps, and thank you for helping me fix this old seek-forever-bug.  ;D

 on: February 01, 2020, 11:49:12 am 
Started by stepleton - Last post by rayarachelian
Tom emailed me this reply, he was unable to post due to a db UTF error, these are his words, not mine. :) When I copied this message from my email client and pasted it directly in, I got the same exact db error, but the UFT chars are invisible.

I was able to paste this text into vi, then do cat -v, copy the output of cat -v and paste it here and that worked. So whatever these UTF8 chars are that break are invisible, or perhaps they're UTF8 smartquotes, brackets, or something like that.

------------------------------- >8 cut here 8< ------------------------------
Hi Ray,

Thanks for your reply post on LisaList! I composed a reply just now, but LisaList is not letting me post it unfortunately, saying there's a database error. So, here's the same message over email for now... I'm happy to repost it publicly and may try to do it myself a little later.

Cheers and thanks for looking into all of this!

Hi Ray, thanks for the reply!

Unfortunately I don't think this change has made a difference for me, at least not in I've done a ./ clean and then a ./ --with-debug, and in the modified version I still see the problem.

Here's a video of what I'm seeing in LisaEm.

To explain---this program is a kind of "hello world" for my console I/O hacking. There's several seconds at the beginning where I'm loading the disk image, and then it gets started.

Ignore the Buzz Aldrin business---that's from what was on Wikipedia's front page that day, and is just there to test text display. The most interesting stuff is a tiny row of pixels at the top left corner, where I've copied two 16-bit mouse motion accumulators, one for dx and one for dy. (I forget which is which.) In LisaEm, once the mouse moves, they take off running and keep going. But one really weird thing is that the accumulator that goes changes depending on where the mouse is in the display window!

More nitty-gritty details about this strange phenomenon: This difference in accumulation seems to be a pretty reliable effect---I see it in LisaEm on Linux and on LisaEm 1.2.6 running under Wine. The pattern is hard to characterise, but roughly speaking: the first accumulator climbs alone when the mouse is on the left-hand side of the screen, the second one climbs alone when the mouse is on the right-hand side of the screen, and both climb together when the mouse occupies a narrow diagonal band going from roughly the word "FROM" in "STARTUP FROM", down and to the right through the letters "M-CM-6M-CM-7M-CM-8", and onward along the same line. (There are some additional behaviours near the top of the screen, and the positioning of these effects isn't always the same, but it always seems to be similar to this.)

Anyway, on the real Lisa, things work as normal:
although it's a little harder to see the bits in this video.

Very strange! I wish you good luck for the GUI debugging---unfortunately the Lisa is about the only graphical programming I do, and even then mainly by twiddling bits! I wish I could help. Thanks for taking a detour to investigate this mouse issue...

Pages: 1 [2] 3 4 ... 10