Interrupt problems
Page 1 of 1

Author:  MrSpock [ Thu Oct 17, 2013 10:26 am ]
Post subject:  Interrupt problems


I have some programs that combine mouse using IRQs and graphics and they worked fine some months ago. Now, they start running very slow and then they hang the computer as soon as the mouse interrupt is generated.

I don't think this is an easy68k problem. I suspect this has to do with the OS change in the computer. When everything was running, I used XP (32 bit machine). Now, the OS is Windows 8 (64 bit).

So... do you know if there is some problem related to Windows 8 or 64bit machines?

Thanks in advance

Author:  profkelly [ Fri Oct 18, 2013 8:12 pm ]
Post subject:  Re: Interrupt problems

All of the computers I use are running Windows 7 64bit and EASy68K is working OK. I have tested it on Windows 8 32bit but not on the 64bit version.

Author:  MrSpock [ Wed Oct 23, 2013 10:37 am ]
Post subject:  Re: Interrupt problems

Since now, I tested easy68k both in real Windows machines and virtualized Windows under VirtualBox (Ubuntu and Mac). All these configurations worked perfectly.

A few days ago, a colleague executed easy68k on Windows 8 64 bits and he did not found any problem.

Actually, the machines that give me problems are running a remote Windows 8 64 bit virtualized under VMWare. So, the problem may be caused by the remote desktop, the VMWare or some combination of them. I don't know the details of this particular configuration. Maybe a colleague will sign in the forums and ask more "precise" questions ;-)

On the other hand, the problem seems to appear when using the mouse interrupt. I have an example code that combines graphics and mouse and it fully hangs the computer as soon as the mouse motion is detected. I'm not attaching this code because I think it is too long for a forum post.

The following example, which is much shorter, is aimed at printing the mouse position at the top-left corner of the screen. Under Windows 7 and VirtualBoxed XP it works perfectly, but using the remote-VMWare-thing the mouse coordinates are delayed. For example, if I stop moving the mouse, the coordinates keep moving a few seconds until they stop.

So, is there something special about the simulated interrupt management? Some buffer that may produce an overflow maybe? Do the simulated interrupts access the real ones in the Windows machine and require some special privilege?

   ORG   $1000
   move.l   #ISR_MOUSE_MOVE, ($64)   ; Associate ISR to level 1 interrupt. This is crucial: first put
               ; the ISR in the exceptions vector, then enable mouse interrupt.
               ; Otherwise, an error may happen if mouse moves before the ISR
               ; has been defined.
   move.w   #$0104, D1      ; Interrupt 1 when mouse moves
   move.b   #60, D0
   trap   #15         ; Enable interrupt

.LOOP:   bra   .LOOP         ; Just loop and do nothing. Mouse is interrupt-driven.

   MOVE.B   #9,D0
   TRAP   #15      ; halt simulator

*                           FUNCTIONS                      *

* Prints the specified values in the top-left of the screen
* as "X: 1234, Y: 1234". Each number is print to fill 4
* characters.
* Pre: D3.L: Number to show after the "X:"
*      D4.L: Number to show after the "Y:"
* Post: Numbers shown
* Modifies: A1, D0, D1, D2.
      eor.w   D1, D1
      move.b   #11, D0
      trap   #15      ; Put text cursor to 0,0
      lea   .STR_X, A1
      move.b   #14, D0
      trap   #15      ; Print "X: "
      move.l   D3, D1
      move.b   #4, D2
      move.b   #20, D0
      trap   #15      ; Print the first number
      lea   .STR_Y, A1
      move.b   #14, D0
      trap   #15      ; Print "Y: "
      move.l   D4, D1
      move.b   #4, D2
      move.b   #20, D0
      trap   #15      ; Print the second number
; Static data specific to this function      
.STR_X:      dc.b   'X: ',0
.STR_Y:      dc.b   ', Y: ',0
; No need to perform memory alignment after this line because
; these specific strings use 10 bytes and memory is aligned
; after them. Otherwise, explicit alignment must be performed.

*                              ISR                         *

* This ISR is called when a MOUSE MOVE event is produced.
* Pre: D3.L: Number to show after the "X:"
*      D4.L: Number to show after the "Y:"
* Post: Numbers shown
* Modifies: A1, D0, D1, D2.
      eor.b   D1, D1
      move.b   #61, D0
      trap   #15      ; Query mouse
      move.l   D1, D3
      andi.l   #$0000FFFF, D3   ; Put the X coordinate in D3.L
      move.l   D1, D4
      swap   D4
      andi.l   #$0000FFFF, D4   ; Put the Y coordinate in D4.L

* Variables and Strings

   END   START      ; last line of source

Thank you very much for your help!

Author:  profkelly [ Wed Oct 23, 2013 11:40 am ]
Post subject:  Re: Interrupt problems

This is an issue in VMware. A Google search returns many hits on slow mouse response.

There is nothing special in the EASy68K code that gets mouse input. It uses simple Window's messages.

Author:  MrSpock [ Wed Oct 23, 2013 12:27 pm ]
Post subject:  Re: Interrupt problems

Thanks again! I'll take a look and tell you in case I solve the problem.

Author:  MrSpock [ Tue Nov 05, 2013 11:57 am ]
Post subject:  Re: Interrupt problems

The system still hangs, so it is not a mouse problem. Actually, we think that VMWare is not the source of the problem.

We use easy68k in a set of computers that use a VDI (Virtual Desktop Interface) called VWorkspace, from Quest Software.

We performed some more tests involving graphics. The test program is something like that (of course, this is pseudocode, the actual program is M68000 assembler).

while (true) {
  draw_something(); // Draws some rectangles and circles.

Even if "draw_something()" draws always the same thing, this hangs the VDI client in the local machine. However, if I put some delay inside the loop using the TRAP #15 delay functionality, it works.

Of course, if the code works perfectly on any tested Windows configuration and only hangs using this VDI client, the problem is neither Windows nor easy68k. But I was wondering if this gives you any clue of what's happening.

I mean: when drawing something on screen, or when using the double buffer, does easy68k sets or resets something that may lead the VDI to this strange behavior?

Thanks in advance!

Author:  profkelly [ Tue Nov 05, 2013 1:56 pm ]
Post subject:  Re: Interrupt problems

I'm downloading a trial version of VWorkspace. I will try to set up a test system and duplicate the issue.

Author:  MrSpock [ Wed Nov 06, 2013 6:53 pm ]
Post subject:  Re: Interrupt problems

Thank you very much!

Author:  MrSpock [ Wed Nov 20, 2013 7:49 am ]
Post subject:  Re: Interrupt problems

We have found that although the client side problem is somehow specific of EASy68k (other tested applications don't have this behavior running on the remote desktop), there are some server side problems that also appear with other programs. Basically, the virtualization and remote desktop configuration we are using may be useful in typical office networks but it is not well suited for engineering and software development environments. But, of course, this has nothing to do with EASy68k.

So, we had no choice but to move EASy68k to non-virtualized computers. Of course, it would be nice if you found a solution for the VWorkspace part of the problem. However, due to the server-side problems (which are not specific of EASy68k) I don't think the IT people is going to allow us to execute EASy68k on the virtualized environment. Sorry for the inconveniences.

Anyway, I'd like to thank you for developing this exceptional tool to learn computer architecture and assembly programming.

Page 1 of 1 All times are UTC
Powered by phpBB® Forum Software © phpBB Group