Omnimaga
Calculator Community => TI Calculators => Calculator C => Topic started by: Mrakoplaz 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.
-
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:
memset(SCREEN_BASE_ADDRESS, 0xFF, 320*240);
memcpy (SCREEN_BASE_ADDRESS + SCREENOFFSET, screens[0], SCREENWIDTH*SCREENHEIGHT);
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.
-
Can somehow your program and/or WAD file be overwriting a crucial part in memory responsible for displaying stuff on the LCD?
-
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! :)
-
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...
-
Yayyy glad you got it fixed :D
-
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.
-
Sounds excellent :D Also, this means that we are also going to get more resolution?
-
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.
-
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.
-
Good luck with the bug Mraklopaz!
-
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 :)
-
Gotcha, thats what i meant :] Awesome!
-
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).
-
Great to see all these bugs being squashed!
-
Glad to hear the bugs were fixed! :D
-
Is reading from the SDRAM as fast as reading from the internal SRAM (where the default screen location is mapped), BTW ?
-
It should be faster if it's on a cached area (which most of SDRAM is). You have to be careful with putting the screen buffer on a cached area though, because the LCD controller reads directly from memory. If the cached data isn't flushed to the memory, those parts of the screen won't update.
-
Yeah, when going back to the flat, I was thinking about caching getting in the way...
DMA by the LCD controller steals some bandwidth, but they make it possible to switch screens more efficiently than bus snoop. The TI-68k platform has had both kinds of LCD controllers over time: DMA first (HW1, before 1999), bus snoop later (HW2+, from 1999).
-
Yeah, I remember all grayscale games stopped working when HW2 came out then in ticalc news there was speculation about if GS was even possible at all on HW2 calcs.
-
I wish I still had my old TI-89 from 1998.
-
Those were the best, even if they ran at 10 MHz instead of 12. I wish TI didn't keep changing the hardware in their calcs over time, it causes programs to stop working completely from an hardware to another. X.x
That said on HW1 you had to make sure to update to the latest OS, though, because almost nothing works under OS 1.xx.