This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
Messages - Vogtinator
Pages: 1 ... 25 26 [27] 28 29 ... 83
391
« on: June 28, 2014, 09:00:00 pm »
The non-cx hardware is entirely different, so you'd need to rewrite the asm code and the timer setup code in audio.c almost completely.
It shouldn't be too hard, though, as only the bit positions, register layout and clock speeds changed.
392
« on: June 27, 2014, 06:17:36 pm »
I have a theory:
The frame buffer contents mustn't be cached, as that may cause artifacts. So caching is disabled by the OS.
On GS calcs the screen buffer is in SRAM, so SRAM caching is disabled. But it's active on SDRAM writes and reads.
On CX calcs the screen buffer is somewhere in SDRAM, and the buffer set by the OS has caching disabled. So writes and reads will be slower.
What happens if you allocate two buffers for both calcs so the default one is never used?
393
« on: June 27, 2014, 06:02:15 pm »
I'm doing the same thing in nGL, but actually a third buffer, so the screen buffer is still usable after inversion.
So is the GS's SDRAM indeed that much slower?
394
« on: June 27, 2014, 05:55:28 pm »
You shouldn't be able to write to SRAM if you're in 16bpp mode and filling the screen.
SRAM is 0xA4000000 - 0xA4020000 = 128 KiB and 320*240*16b= 150KiB
395
« on: June 27, 2014, 05:39:53 pm »
I had to disable all IRQs and FIQs to get rid of the clock on screen, but TCT_Local_Control_Interrupts(0) should do the same.
But normally ndless itself does that already.
And matref, are you copying directly to SCREEN_BASE_ADDRESS? On GS calcs it's in SRAM and on CX in sdram because of it's size.
396
« on: June 27, 2014, 03:46:15 pm »
No, run the program on CX and not-CX.
397
« on: June 27, 2014, 02:58:38 pm »
Could you do something entirely without n2dlib, just directly memcpy one buffer into the other 500 times and compare that? Both LCDs in 16bpp mode of course.
398
« on: June 27, 2014, 08:09:52 am »
I've been working on nKaruga since quite some time now, and although it's reasonably fast on monochrome TI-Nspires, it's accurately twice as slow on color calcs, although it's the same code running and that the monochrome screen is being configured in 16-bits mode by the game. So you don't handle those different LCDs differently? Using the monochrome LCD in 16bpp mode like a color one looks awful.
399
« on: June 26, 2014, 01:04:36 pm »
An important question is where to start. First GUI, then "kernel"? I'd go for the first, as that could be tested with wine accurately. Greetings help a lot  Well, have some: Hi! Hi! Hi! Hi! Hello! Hello! Hello! Hello! Hello! Hello! Hey! Hey! Hey! 'sup? 'sup? 'sup? 'sup? 
400
« on: June 26, 2014, 10:31:23 am »
Does nspire_emu show the same symptoms?
401
« on: June 25, 2014, 05:19:40 pm »
I took a quick look and the source code: Is it really so slow that you had to use assembler for custom "incorrect" division  ? How much was the speedup? And if you want to make it as fast as possible without any source changes, I'd advise you to use the genzehn tool and the zehn format from my ndless fork and the same optimization options in the Makefile that I use in crafti (especially -flto, -mcpu, -Ofast). In crafti there isn't anything in assembler yet, pure C++ and it runs fast enough (I may change the asm thing, if your "incorrect" version makes a significant difference). But if you really want to dig into the "every cycle counts" I may point you to __builtin_prefetch or the "PLD"(preload) arm instruction. I didn't follow any of the steps and actually ran it, though, too much work to do for a game I'm not really a fan of, sorry.  It looks really awesome though 
402
« on: June 25, 2014, 02:24:32 pm »
Hmm. do __builtin_setjmp and __builtin_longjmp work? I tried it, it didn't make any difference, but I'd want to know whether they also call msvcrt.dll., probably 'cause I forgot copying nspire_emu.exe.. On http://sourceforge.net/p/mingw-w64/mailman/message/31232870 someone seems to have the same issue, even with MinGW 4.8.2, where the bug should have been fixed. It also happens only on 64-bit.. Could you try using the __builtins and -fno-omit-frame-pointer just in case and then look at the write to restart_after_exception (or not, if it works  )? Edit: You forgot emuprintf("Ndless not detected or too old. Debugging of applications not available!\n"); Edit2: Compiled, tested: WORKS!
403
« on: June 25, 2014, 11:51:22 am »
I get it as well, three times my screen's size O.o It also seems to happen for unusually big images. By the way. Given that we have two repos with similar content now, I think we should merge them into one and start working in one organization repo with some conventions like for example git-flow. Yup, I think the same. My changes are smaller: A message if ndless wasn't detected at gdb connection and prefixing emu output with "[nspire_emu]". It took me a while see it... I'm a noob with this code...
Now what? Have you reported to mingw? Any hotfix? Maybe it got corrupted somehow. Can you step through setjmp or look when 0x10/16 gets written into restart_after_exception[1]?
404
« on: June 25, 2014, 11:43:14 am »
They will also get picked up by the linker and there may be some "duplicate definition of symbol" errors.
Also, you wouldn't be able to use it in two seperate files, as the symbols in it would then cause the same issue.
If there aren't any symbols in it, it doesn't need to get compiled -> header file.
405
« on: June 25, 2014, 11:39:33 am »
To be honest, your source code is awful: - DON'T include .cpp files EVER!
- DON'T mix defines and variables. They need to be distinguishable, e.g. ALL-CAPS
- A while(1) with an if-chain and break statements? You know you can return at any point in a function?
- Don't do it like getlength, use floor(log10(score))+1
- Don't hardcode font drawing. Use an array.
- Use "enum class" instead of enum, otherwise the enum values will have the same scope as the enum itself
- Use initialization lists
- References instead of pointers
- Loop + array lookup in sell_cargo
- Why is money a pointer to a uint32_t?
- (u)int(8/16/32)_t doesn't have a fractional part. Multiplying it by 1.1 is the same as *1.
I'd advise you to read a good c++ book or online tutorials, but it'll take a while.
Pages: 1 ... 25 26 [27] 28 29 ... 83
|
Show Posts