Author Topic: nDoom - 8bpp bug, sleep mode bug [SOLVED]  (Read 8775 times)

0 Members and 1 Guest are viewing this topic.

Offline Mrakoplaz

  • LV3 Member (Next: 100)
  • ***
  • Posts: 46
  • Rating: +130/-2
  • Prussian Minister of War
    • View Profile
nDoom - 8bpp bug, sleep mode bug [SOLVED]
« on: January 24, 2011, 03:25:17 pm »
As those who have been watching the progress of nDoom might have noticed, I've been fighting a bug that triggers a crash/restart (depending on the exact release) upon exit ever since the start of the project.
Before, I thought that it made sense, since I still had unfreed memory lying about when the program finished, and files that weren't getting closed. Today, however, I fixed up all those points, but the crash still remains; It is giving me a different error, but the end effect is the same.

Now, although I've got experience in computer programming generally, as well as in assembly specifically, I am quite a newbie when it comes to C, and so I wish to ask anyone skilled in this language - aside from unfreed memory and files not closed, could there be other causes for a crash that happens after the main() function returns? Or is it more probable that I've missed a free() somewhere? And could some 7 random bytes of unallocated memory somewhere really cause the calculator to restart (consistently, every single time the program exits)?
The Doom source I've based my project on uses some quite ugly hacks, so even outlandish suggestions are welcome, since one of those hacks might be triggering an extremely rare bug somewhere (note: although it uses some interesting hacks, it doesn't use any ASM() statements).

Furthermore, while the errors the emulator gives are extremely useful whilst coding in Assembly, am I correct in thinking that they're absolutely useless when coding in C, as the compiler abstracts most of the register/memory accesses away from the programmer?

Finally, could anyone explain what decides whether the Nspire just freezes, or also reboots, after a program crash? I've seen both, and there doesn't appear to have been much of a pattern.
« Last Edit: February 04, 2011, 02:08:49 pm by Mrakoplaz »

Offline Mrakoplaz

  • LV3 Member (Next: 100)
  • ***
  • Posts: 46
  • Rating: +130/-2
  • Prussian Minister of War
    • View Profile
Re: nDOOM - Fixing the crash on exit - Progress!
« Reply #1 on: January 31, 2011, 03:14:44 pm »
Great news! I've managed to narrow the bug down... to a most unexpected location.
The following lines of code, all from i_video.c, stop the crash-on-exit if commented out:

Code: (I_ShutdownGraphics(), line 114) [Select]
memset(SCREEN_BASE_ADDRESS, 0xFF, 320*240);
Code: (I_Flip(), line 131) [Select]
memcpy (SCREEN_BASE_ADDRESS + SCREENOFFSET, screens[0], SCREENWIDTH*SCREENHEIGHT);
Code: (I_InitGraphics(), line 197) [Select]
memset(SCREEN_BASE_ADDRESS, 0x00, 320*240);

As you can see, they all copy data into the LCD screen buffer. I can't exactly leave them commented, because then you can't see anything ;D
What's stranger still is that at the start of the program, I call memcpy() to the screen base address five times (for the initial loading screen), and that works just perfectly. Obviously, something happens between those two events that screws up the LCD controller, somehow, initially leading to a crash when the OS interrupts are re-enabled after nDoom exits (it must be something with the interrupts, because if I call TCT_Local_Control_Interrupts(0), I don't get the crash on exit, but right away once the first of the lines above gets called).

Now, I am puzzled even more than I was before, but at least I'm slowly moving in on the source of this crash...

Attaching the source code so that persons smarter than me are able to investigate.

Offline Silver Shadow

  • Beta Tester
  • LV8 Addict (Next: 1000)
  • ********
  • Posts: 817
  • Rating: +27/-7
    • View Profile
Re: nDOOM - Fixing the crash on exit
« Reply #2 on: January 31, 2011, 03:20:57 pm »
Can somehow your program and/or WAD file be overwriting a crucial part in memory responsible for displaying stuff on the LCD?
Former Coder of Tomorrow


Offline apcalc

  • The Game
  • CoT Emeritus
  • LV10 31337 u53r (Next: 2000)
  • *
  • Posts: 1393
  • Rating: +120/-2
  • VGhlIEdhbWUh (Base 64 :))
    • View Profile
Re: nDOOM - Fixing the crash on exit
« Reply #3 on: January 31, 2011, 03:23:23 pm »
This might be it! :

A screen buffer is equal to SCREEN_WIDTH*SCREEN_HEIGTH/2, so this would be 320*240/2, not 320*240

Try using the constant "SCREEN_BYTES_SIZE" for the third argument of memcpy! :)


Offline Mrakoplaz

  • LV3 Member (Next: 100)
  • ***
  • Posts: 46
  • Rating: +130/-2
  • Prussian Minister of War
    • View Profile
Re: nDOOM - Fixing the crash on exit
« Reply #4 on: January 31, 2011, 03:26:17 pm »
Silver Shadow, I don't think memory's getting overwritten here... it seems to crash independently of whether the wad file is loaded or not.

This might be it! :
A screen buffer is equal to SCREEN_WIDTH*SCREEN_HEIGTH/2, so this would be 320*240/2, not 320*240
Try using the constant "SCREEN_BYTES_SIZE" for the third argument of memcpy! :)

The screen buffer's that size only if you're in 4bpp mode... I'm using 8bpp (so I don't have to bother with nibble->byte conversion), where the screen buffer is indeed 320*240 (hence using SCREEN_BYTES_SIZE gives you only half the screen in this mode).
I wonder if I've screwed up while setting the display mode...

EDIT: Yup, I seem to have screwed up. Removing the writes to 0xC000001C (LCD configuration), and changing third argument of memcpy() to SCREEN_BYTES_SIZE removes all crashing. I'll see if I can fix this bug before sleeptime...
« Last Edit: January 31, 2011, 03:34:20 pm by Mrakoplaz »

Offline Builderboy

  • Physics Guru
  • CoT Emeritus
  • LV13 Extreme Addict (Next: 9001)
  • *
  • Posts: 5673
  • Rating: +613/-9
  • Would you kindly?
    • View Profile
Re: nDOOM - Fixing the crash on exit
« Reply #5 on: January 31, 2011, 03:53:41 pm »
Yayyy glad you got it fixed :D

Offline Mrakoplaz

  • LV3 Member (Next: 100)
  • ***
  • Posts: 46
  • Rating: +130/-2
  • Prussian Minister of War
    • View Profile
Re: nDOOM - Fixing the crash on exit
« Reply #6 on: January 31, 2011, 04:17:04 pm »
Well, it's not quite fixed yet, I've had that argument in there for a reason... right now, only the top half of the screen is displayed. However, no crashing, and I'm working on getting fullscreen back.
Also, I've figured out a problem with my palette settings - apparently, it's bits 1-4 that determine the screen brightness, not 0-3... that means I was only using 8 colours out of 16, which I think would explain the low contrast.
Depending on how long it takes to fix this bug, I should have a bugfix release out either tomorrow or Wednesday.

Offline Builderboy

  • Physics Guru
  • CoT Emeritus
  • LV13 Extreme Addict (Next: 9001)
  • *
  • Posts: 5673
  • Rating: +613/-9
  • Would you kindly?
    • View Profile
Re: nDOOM - Fixing the crash on exit
« Reply #7 on: January 31, 2011, 04:27:02 pm »
Sounds excellent :D Also, this means that we are also going to get more resolution?

Offline calc84maniac

  • eZ80 Guru
  • Coder Of Tomorrow
  • LV11 Super Veteran (Next: 3000)
  • ***********
  • Posts: 2912
  • Rating: +471/-17
    • View Profile
    • TI-Boy CE
Re: nDOOM - Fixing the crash on exit
« Reply #8 on: January 31, 2011, 06:12:36 pm »
Are you using the normal SCREEN_BASE_ADDRESS for the buffer? Because I don't think there are 320*240 bytes there allocated for screen data alone. You're probably overwriting other data used by the OS.
"Most people ask, 'What does a thing do?' Hackers ask, 'What can I make it do?'" - Pablos Holman

Offline critor

  • Editor
  • LV11 Super Veteran (Next: 3000)
  • ***********
  • Posts: 2079
  • Rating: +439/-13
    • View Profile
    • TI-Planet
Re: nDOOM - Fixing the crash on exit
« Reply #9 on: January 31, 2011, 06:33:56 pm »
This might be it! :
A screen buffer is equal to SCREEN_WIDTH*SCREEN_HEIGTH/2, so this would be 320*240/2, not 320*240
Try using the constant "SCREEN_BYTES_SIZE" for the third argument of memcpy! :)

The screen buffer's that size only if you're in 4bpp mode... I'm using 8bpp (so I don't have to bother with nibble->byte conversion), where the screen buffer is indeed 320*240 (hence using SCREEN_BYTES_SIZE gives you only half the screen in this mode).


The first mViewer beta was using 4bpp mode.
When I changed the source to use 16bpp mode, i experienced very frequent reboots on exit.

mViewer is now very stable.

How did I solve the problem?
- I'm allocating my own separate 16bpp screen buffer
- I'm changing the screen buffer base address (see HackSpire)
- I'm switching the mode from 4bpp to 16bpp

Of course, before exiting:
- I switch the mode from 16bpp to 4bpp
- I restore the original screen buffer address
- I'm freeing my now unused 16bpp screen buffer


Hope this can help you.


Now, some questions for you.

Do the wad file still have to be in the root document folder?
(with OSes 1.X, it's not easy storing things in that folder...)

With my basic Nspire ClickPad, and the wad file in the same folder as ndoom, I'm getting a reboot upon starting... no error message.
It happened both with Ndless 1.7 and Ndless 1.4.

Offline DJ Omnimaga

  • Clacualters are teh gr33t
  • CoT Emeritus
  • LV15 Omnimagician (Next: --)
  • *
  • Posts: 55941
  • Rating: +3154/-232
  • CodeWalrus founder & retired Omnimaga founder
    • View Profile
    • Dream of Omnimaga Music
Re: nDOOM - Fixing the crash on exit
« Reply #10 on: February 01, 2011, 12:34:41 am »
Good luck with the bug Mraklopaz!

Offline Mrakoplaz

  • LV3 Member (Next: 100)
  • ***
  • Posts: 46
  • Rating: +130/-2
  • Prussian Minister of War
    • View Profile
Re: nDOOM - Fixing the crash on exit
« Reply #11 on: February 01, 2011, 10:03:21 am »
Wohoo! It works! Thanks so much, people! I thought SCREEN_BASE_ADDRESS was some sort of hardware buffer in the LCD controller with sufficient memory already present there... no idea it was just mapped to a random location in the RAM.

However, now I am getting another big problem: There's no more crashing on exit, but if you go to sleep mode (with CTRL+ON), it refuses to wake up again. No idea if it's not waking up, or if it's just the screen that isn't turning back on. To fix this, you have to hard-reset the calculator.
Since the nspire_emu crashes if you attempt to engage sleep mode (Warning at PC=103755FC: Bad read_word: b00001bc), I can't really debug it.

To answer your question, Critor, it should now look in the current folder, not in the root. The bug you describe occurred often on earlier versions - have you tried with the latest release (e.g. the one attached below)? No error message is strange, though...

Builderboy, you don't get more resolution, but you get twice as many colours now (16, while before I was only using 8, since I was using bits 0-3 instead of 1-4), so the general result is a much better picture anyway :)

Offline Builderboy

  • Physics Guru
  • CoT Emeritus
  • LV13 Extreme Addict (Next: 9001)
  • *
  • Posts: 5673
  • Rating: +613/-9
  • Would you kindly?
    • View Profile
Re: nDOOM - Fixing the crash on exit
« Reply #12 on: February 01, 2011, 11:24:55 am »
Gotcha, thats what i meant :] Awesome!

Offline Mrakoplaz

  • LV3 Member (Next: 100)
  • ***
  • Posts: 46
  • Rating: +130/-2
  • Prussian Minister of War
    • View Profile
Re: nDOOM - Fixing the crash on exit
« Reply #13 on: February 04, 2011, 02:08:15 pm »
Wohoo, sleep mode bug fixed! See the main nDoom thread for download.

In case any future developer encounters a similar "calculator won't wake from sleep mode after running app" bug, I'll document it here:
If you want to use the Nspire's timers for your own things, and want to reconfigure them, you must store the values that were originally stored by the OS and which you're changing (for me, those at 0x900D0010 and 0x900D0014) to a variable somewhere, then restore them before you quit the application; Apparently, the OS uses those in sleep mode (not sure for what, but it does).

Offline fb39ca4

  • LV10 31337 u53r (Next: 2000)
  • **********
  • Posts: 1749
  • Rating: +60/-3
    • View Profile
Re: nDoom - 8bpp bug, sleep mode bug [SOLVED]
« Reply #14 on: February 04, 2011, 03:40:42 pm »
Great to see all these bugs being squashed!