GEM window open problem

[exxosuk]

id=wind_create(&hfef,0,wind_y,639,wind_height)
junk=wind_open(id,0,wind_y,639,wind_height)
vr_recfl 0,wind_y,638,wind_y+wind_height-1
junk=wind_close(id)
junk=wind_delete(id)

 

I have the above code to open up a GEM window and then close it again (as part of a Gembench test routine) however I noticed on the Falcon the routine crashes always on 15 windows. But there is only ever 1 window open at a time as each time it opens, its closed again and deleted.

The problem does not show up on a STFM, it works on all 20 windows perfectly. In fact I've ran 200 window test on the STFM. So not sure why the Falcon does not like it ? AFAIK its the "wind_open" line where it locks up at. If I REM it out, the test runs all 20 loops. Though its not creating the window anyway.

 

[Justin Payne]

So, I know this is a test but are you testing to make sure your getting non-zeros back from some of those calls? It might be erroring out for some reason.

Also, it looks like what you're doing is correct but that 15 limit seemed interesting and it appears that some of the TOS's had 16 as the limit. Of course, dev count at 0 so is it really 16 where it's actually failing?

Also, are you running this code on real machines or on emulators?

I wanted to spend more time on this but I had some stuff I had to do but I'll look into it further tonight and respond unless you get an answer.

[Justin Payne]

I think I might have figured it out. Try wind_set() prior to opening the window.

http://toshyp.atari.org/en/008009.html#wind_create

 

I also found this snippet of code that seems to say you have to get the windows size before creating it. I'm guessing this is because you don't want to create a window larger than the current screen resolution.

http://www.atari-forum.com/viewtopic.php?t=20155

Edited December 23, 2015 by Justin Payne

[exxosuk]

I think the problem is some bug somewhere else. If I run the exact same code as a loop on its own, it works fine. When its in the main program, it doesn't. That does not make any sense unless it was doing multithreading in the app, but AFAIK Hisoft basic cant do that So no idea, how can the same loop work and yet not work. I've tried messing around with compiler options, the amount of RAM which is allocated, nothing works. I can't get the error code as it locks up on the window call itself and I have to reboot to unfreeze it.

 

Its for Gembench 6 which I am re-coding for the ground up, so as the code works on its own, its not much of a issue. Just another screwy problem in the thing which is why I gave up trying to make changes to it

[Justin Payne]

This is Hisoft basic? Not C? No wonder one of those lines didn't make sense.

No, the 68000 and 68030 weren't capable of multi-threading so you can rule that out.

 

I'm not familiar with Hisoft's Basic but it appears you can compile it. What about running it through a debugger. I would suspect that it would allow you to view a lot more of what is going on under the hood.

I feel like you're overwriting a piece of memory but I'm going to assume that language takes care of memory allocation...and even still, if you're killing each window, that doesn't make sense unless you were freeing it up.

 

It's like I have a lot of ideas but nothing concrete for you to try...and that's driving me nuts.

 

There are others here smarter than me (at least from a coding standpoint). Hopefully you have this publish on a code repository of some sort and possible allow others to check it out. GitHub is free and is pretty easy to use.

Edited December 23, 2015 by Justin Payne

[+poobah]

No, the 68000 and 68030 weren't capable of multi-threading so you can rule that out.

 

There's nothing about the 68k that would prevent multi-threading.

[Justin Payne]

Hmmmm. Well, I'm no CS graduate so I'm just going to speak from what I know but I guess that would be up to the OS to schedule threads and then language of choice to have libraries to support it. I know that MagiC supports multitasking but scheduling multiple threads, setting thread priority, and locking I don't think was ever made available in any OS for the Atari.

In any case, this is definitely a conversation I'd love to have but probably not in this thread (Rimshot. ) but thanks for calling that out. It gives me a chance to make sure I know what I'm talking about and are sometimes interview questions that a good dev should probably know. Threading always drove me nuts.

[exxosuk]

It is hisoft basic I am using. The code is probably not exactly set out as expected for those calls. I'm new to GEM and Hisoft. So not got many clues about it. I know there is a debugger in Hisoft but for some reason it won't run the full program in the editor (some programs do) and only other option is MONST but I have no clue about assembly.

 

The route works in my new app anyway, so its not much of a big deal. Just annoying as its yet another "bug" which has no answer to.

[Justin Payne]

Yea, debuggers will mostly work on compiled code so you're going to have to be able to muddle through Assembly. I guess I get spoiled with Java. You're mostly interested in seeing what exceptions are being thrown, the stack, and the registers state. It's not that difficult but maybe that's cuz I can read the stuff. Still, it's not always a walk in the park.

Still, if you put the code in a repository and post what file/line number it's failing in, you might get someone to take a look at it.

 

Good luck.