problems with threaded uzem

[CunningFellow]

Howdy all,

The new version of Uz-Em crashes on the tempest-render-mode if I run from a command window under Win32(XP).

Other games run fine from either command-prompt or from double-clicking. Even using the new cool -V option.

However the crazy mode I am working on for tempest dies. It goes OK if I double-click the hex file. Just dies if I run from the command-prompt.

[lunatic]

Weird, Could you send me the hex/uze file that crashes the emulator, so I could debug uzem?

[CunningFellow]

The hex file (leena.hex) in this post

http://uzebox.org/forums/viewtopic.php? ... =50#p11711

I have SDL 1.2.15 and mingw 20130723

if I doubly click it it runs fine, if I open it from a command-prompt it shows the bit map, draws some coloured lines, corrupts the screen and crashes.

The same hex file runs OK from an earlier version of uzem I compiled myself.

[lunatic]

The hex file (leena.hex) in this post

http://uzebox.org/forums/viewtopic.php? ... =50#p11711

I have SDL 1.2.15 and mingw 20130723

if I doubly click it it runs fine, if I open it from a command-prompt it shows the bit map, draws some coloured lines, corrupts the screen and crashes.

The same hex file runs OK from an earlier version of uzem I compiled myself.

Hi,

Seems like your code is in a loop where it only updates PORTC. Never again PORTB (after the initial few lines).
Actually the only io that is done in this for-ever-loop is: OUT @PORTC,r23

But the emulator needs PORTB to be frequently updated, or it will hang.

Have you used any timers or features that other video modes does not use? (more specifically: that uzem does not have support for?)

Weird that it works in earlier versions of uzem though. And that you report that it has different behaviour if you start it from command line.. Hm

[CunningFellow]

The tempest mode uses Timer_OVF to end the render loop.

I modified UzEm to support the overflow interrupt a few months ago and then Uze/Alec did a neater version of this and committed it.

If the "H_Sync" call is never happening that means the overflow interrupt is not running. There SHOULD be 63 iterations of the "IJMP block" and then an overflow_interrupt to make a H_Sync.

The new threaded version DOES work as long as it is run directly from the GUI (double-click a HEX file). It is only if I at the CLI and I type

Code: Select all

uzem.exe leena.hex

Does it hang.

Would you like the source code to look at?

[lunatic]

The tempest mode uses Timer_OVF to end the render loop.

I modified UzEm to support the overflow interrupt a few months ago and then Uze/Alec did a neater version of this and committed it.

If the "H_Sync" call is never happening that means the overflow interrupt is not running. There SHOULD be 63 iterations of the "IJMP block" and then an overflow_interrupt to make a H_Sync.

The new threaded version DOES work as long as it is run directly from the GUI (double-click a HEX file). It is only if I at the CLI and I type

Code: Select all

uzem.exe leena.hex

Does it hang.

Would you like the source code to look at?

Maybe when you double-click the hex file, you run an older version of uzem? I can't really see a logical reason why double-clicking should have any difference from CLI.
You could send me the source, but I am not that awesome in ASM as you guys.

Do you or uze6666 have any experience in using the gdb support in uzem?

[CunningFellow]

I have searched my hard drive from explorer. There is only one "uzem.exe" on the drive.

I have made sure the file association for (dot)hex is pointing to "C:\uzem.exe"

The very very funny thing, and the reason why I am pretty sure it is thread related is this.

The bouncing lines in the Leena demo are not random. They always start exactly the same position and velocity. The garbled frozen screen you get when running from the CLI is 35 seconds into the pattern. This happens instantly. So it looks to me like the core code is running full pelt without rendering for a few milliseconds and getting 35 seconds into the pattern. Then it does one screen shot and freezes.

Unfortunately I am woeful with C and I have never had luck getting GDB to work with anything. If you can point me to an absolute idiots tutorial I will try though. I will also package up the ASM code later today but it is not at all easy to understand if your not already quite familiar with ASM.

[uze6666]

I haven't used the standalone gdb debugger, but if you're comfy with Eclipse checkout this wiki page: http://uzebox.org/wiki/index.php?title= ... er_Eclipse. It's quite a few steps, but afterwards it speeds up troubleshooting.

[CunningFellow]

should I just stick with WinAVR even though it is several years out of date, or should I update the GCC parts of it.

If so is it dangerous and can I break thing trying to update the GCC version.

[uze6666]

Good question. I'd stick with the current winavr since it works jut fine and upgrading bits and pieces may wreak havoc. Alternatively, AvrStudio 6 uses gcc, and is more up to date. However, I didn't installed it myself yet, so I don't know if it works with the Uzebox stuff. (no gdb support in this case?)