Print

[stepleton]

Hi folks,

This might just be a question for Ray, but it might also be a question for anyone with knowledge of Lisa internals.

First, I've definitely found a behaviour difference between my 2/10 and LisaEm (1.2.6.2, to be fair). I think this one might be easy to fix for someone knowledgeable. But it also may not matter, because it could be that I'm doing something wrong in the first place, at least as far as Lisa programming is concerned.

I'm trying to code up a little library for bare-metal mouse and keyboard I/O, in service of another project. It's pretty basic for the moment. For the purposes of this post, you can imagine that it boots straight off of a floppy and jumps straight into the following:

Code: [Select]

    ; Define VIA addresses
kKbVia      EQU  $FCDD81
kKbViaIfr   EQU  $1A
kKbViaOra   EQU  $02

  ...

WaitForCops:
    LEA.L   kKbVia,A1
.wb MOVE.B  kKbViaIfr(A1),D0
    BTST    #1,D0
    BEQ.S   .wb
    MOVE.B  kKbViaOra(A1),D0
    RTS

Now on the Lisa, WaitForCops works as expected: type some keys, move the mouse, and you get bytes; otherwise you don't (or maybe you get zero bytes---my program doesn't display those). Either way, something I can work with.

In LisaEm 1.2.6.2, WaitForCops works as expected until the first time I move the mouse. Then it continually streams what looks like the last mouse byte it had streamed previously (again, maybe there are zeros I'm not seeing). You can type more, or move the mouse more, and see those codes blip up occasionally in the bytes, but the old mouse bytes just won't stop---they just keep coming and coming.

I don't know that this matters all that much---it's obviously not something that bothers the operating systems or even Service Mode. Does anyone know if they're doing something I'm not (e.g. some kind of initialisation step)?

I did notice this line in LisaEm's cops.cc and wondered if it might be related, but thought it might not be because it always resets the mouse motion data to 0, 0, and my bytes aren't changing.

Anyhow, thanks for any thoughts!

[rayarachelian]

Now on the Lisa, WaitForCops works as expected: type some keys, move the mouse, and you get bytes; otherwise you don't (or maybe you get zero bytes---my program doesn't display those). Either way, something I can work with.

In LisaEm 1.2.6.2, WaitForCops works as expected until the first time I move the mouse. Then it continually streams what looks like the last mouse byte it had streamed previously (again, maybe there are zeros I'm not seeing). You can type more, or move the mouse more, and see those codes blip up occasionally in the bytes, but the old mouse bytes just won't stop---they just keep coming and coming.

Hi Tom!

Thanks for this, I'll test this out and see if I can fix this behavior!

That if statement is basically saying, if there's no keys in the queue to send, and the Lisa is reading from the VIA, then send a mouse movement. If there's no mouse movement recently, send code 0 which indicates mouse status, followed dx,dy, but in this case dx=0, dy=0, so you'd get 3 zero bytes. (mouse movements are additive to the dx,dy, so if you first move +1,+2 and a bit later, you move +1,+1, it will send +2,+3.)

Off the top of my head it should add mouse movement to the queue anyway, so this condition is when you'd use polled I/O without an interrupt service routine. I'm not sure what a real COPS will return in that case, but expected a null mouse movement wouldn't break anything.

But it should not repeat the same movement again.

So, as an aside, so what are you seeing returned on the real Lisa when there's no mouse movement and no keys pressed and you read from IRA, ignoring the IFR wait? I'll add that to that fn if you have seen it.

I think in this case the bug is that the IFR is being set and not cleared somehow, or something else is setting it again and again. Off the top of my head, I think I remember the VIA docs say that when IRA is read or written to, from it should clear that corresponding IFR bit.

So likely the bug isn't in that line but rather that the IFR bit isn't being cleared on the read. Which might be the case. The macro on line 1072 should be clearing that IRQ, but perhaps it isn't working as intended. https://github.com/rayarachelian/lisaem/blob/8ae6947342ed6035fe5f99ea65ab0631204ade2d/src/lisa/io_board/cops.c#L1072
I can understand that when you get the first zero, two more are sent as dx,dy, and this would trigger IFR again as the cops queuelen is now 2 after reading the 1st zero. But that should stop after reading that 3rd byte. So not sure why it's repeating beyond that. The bug might even be in irq.c and not in either via6522.c nor cops.c.I'd suspect this block: https://github.com/rayarachelian/lisaem/blob/8ae6947342ed6035fe5f99ea65ab0631204ade2d/src/lisa/cpu_board/irq.c#L809 or maybe here:https://github.com/rayarachelian/lisaem/blob/8ae6947342ed6035fe5f99ea65ab0631204ade2d/src/lib/libGenerator/generator/reg68k.c#L301
irq.c is a bit complex, it has a way to queue IRQs in the future, for things like the VIA timers, video retrace, and async disk requests.

I'll experiment in the current repo and see what I'll find and reply here again.

Please note that the source code you're looking at is actually 1.2.7 and not 1.2.6.2 but much of this code hasn't been touched for the 1.2.7 changes.

I'd do another push soon, but I've been stuck trying to sort out some issues with scaling and skinless modes for the last couple of weeks without much progress. (Basically the wx3.1.2 is reporting a screen size of 1920x1080 for my 4K display possibly because I've set GTK scaling to 200% and it's trying to do 4K scaling, but wx3.0.x returns 4K for the resolution!
Then on top of that the dc has it's own scaling via dc.SetUserScale, which I'm now using instead of the code from the last push. But now I'm having trouble calculating the sizes and locations of things and so both mouse and centering code is broken in OnPaint_skinless() for zoom sizes other than 50% ). Skinned modes work fairly well, but not for all scale sizes.

Edit, yup, confirmed, this is stuck forever flagging that it has mouse movement data as soon as the mouse is moved the first time and doesn't quiesce.:

Code: [Select]

src/lisa/io_board/cops.c:via1_ira:1061:IRA1 copsqueuelen:0, mousequeuelen:1 cops_mouse:81500 VIA1.IFR:00000000 VIA1.IER:00000082| 20:16:03.9 858443839
src/lisa/io_board/cops.c:via1_ira:1061:IRA1 copsqueuelen:2, mousequeuelen:1 cops_mouse:81500 VIA1.IFR:00000000 VIA1.IER:00000082| 20:16:03.9 858443973
src/lisa/io_board/cops.c:via1_ira:1061:IRA1 copsqueuelen:2, mousequeuelen:1 cops_mouse:81500 VIA1.IFR:00000000 VIA1.IER:00000082| 20:16:03.9 858443973
src/lisa/io_board/cops.c:via1_ira:1061:IRA1 copsqueuelen:1, mousequeuelen:1 cops_mouse:81500 VIA1.IFR:00000000 VIA1.IER:00000082| 20:16:03.9 858444105
src/lisa/io_board/cops.c:via1_ira:1061:IRA1 copsqueuelen:1, mousequeuelen:1 cops_mouse:81500 VIA1.IFR:00000000 VIA1.IER:00000082| 20:16:03.9 858444105
src/lisa/io_board/cops.c:via1_ira:1061:IRA1 copsqueuelen:0, mousequeuelen:1 cops_mouse:81500 VIA1.IFR:00000000 VIA1.IER:00000082| 20:16:03.9 858445857
src/lisa/io_board/cops.c:via1_ira:1061:IRA1 copsqueuelen:0, mousequeuelen:1 cops_mouse:81500 VIA1.IFR:00000000 VIA1.IER:00000082| 20:16:03.9 858445857
src/lisa/io_board/cops.c:via1_ira:1061:IRA1 copsqueuelen:2, mousequeuelen:1 cops_mouse:81500 VIA1.IFR:00000000 VIA1.IER:00000082| 20:16:03.9 858445991
s

Here's a workaround, add this line:

Code: [Select]

  if ( !(mouse_pending_x|mouse_pending_y) && mousequeuelen==1 && copsqueuelen==0) mousequeuelen=0;
here: https://github.com/rayarachelian/lisaem-1.2.x/blob/v1.2.6.2.1/lisa/cops.c#L1242  for 1.2.6.2
or here:
https://github.com/rayarachelian/lisaem/blob/master/src/lisa/io_board/cops.c#L1244 for 1.2.7

[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!
--Tom



Hi Ray, thanks for the reply!

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

Here's a video of what I'm seeing in LisaEm.
https://drive.google.com/open?id=1xindh38YWHwlyIzlBRl772EBU5HiR2Im

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 1.2.6.2 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:
https://drive.google.com/open?id=15bh9VmbkLHK5s5JjjWKMswQBp_fCbXy_
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...

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

• https://github.com/rayarachelian/lisaem-1.2.x/blob/master/lisa/glue.c#L270
• https://github.com/rayarachelian/lisaem-1.2.x/blob/master/lisa/glue.c#L295
• https://github.com/rayarachelian/lisaem-1.2.x/blob/4a32d33a79a408b4458a8dffb9222b9982cee27c/lisa/cops.c#L141

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. 

[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!