Interrupts aren't required to get it to work if you do everything in a loop.

Just try to configure the UART slightly differently, the register offsets and what the various bits do is all explained within the PDF document.

You can't change th FIFO size, it's the hardware.

For the other questions, take a look at the PL011 manual: http://infocenter.arm.com/help/topic/com.arm.doc.ddi0183f/DDI0183.pdf

I'm not sure what I can do with remote debugging here...

I'd suggest you try some more ways to configure the PL010 UART, maybe try turning the FIFO off.
There's also still the possibility that there's something wrong on the sender's side.

Can you try without the exclamation mark in that line?

As I wrote: Untested

Ok, fixed.

Try this (untested):


char uart_getchar(void)
{
volatile unsigned *recv_buffer_reg = (unsigned*)0x90020000;
        volatile unsigned *fr = (unsigned*)0x90020018;
while(!(*fr & 0x10))
idle();
        return *recv_buffer_reg;
}


If this doesn't work, try replacing the idle call with just a semicolon for busy waiting.

Quote from: TurtleForGaming on January 20, 2018, 09:21:21 PM
I have posted this bug 

Right, whoops..

Quote
And I don't have an another module

Oscilloscope, pc with level shifters, a microcontroller kit?

Did you try a different receiver to rule out issues on the transceiving side?

Maybe try a higher delay like 1s and send 10 chars per line.

Also, I just remembered that there's a bug in the uart_getchar function which is not fixed yet, can you try the function  from https://tiplanet.org/forum/viewtopic.php?f=20&t=20611&p=222899&hilit=nspire+uart#p222899 instead?

Yes, but I doubt that that would help.
If you stil want to try that, refer to the ARM pl010 manual.

The FIFO is an internal buffer which the UART hardware stores data in. If data arrives faster than you read it out, it'll fill up and no new data can be processed.
Getting interrupt handling right is not trivial, it requires quite some trial-and-error. The easiest workaround is to decrease the baud rate or just make the transmitting side slower.
You could for instance add a delay of a few ms after you sent 32 B.

This might be the FIFO running out of space - try to delay the sending or receive it in a tight loop.

Preferably, you register an interrupt handler on available input and read the whole fifo immediately.

Looks impressive!

Now just textures, shadows, anti-aliasing and shaders are missing

Out of curiosity, did you try it on hardware as well? I noticed that there are some unexpected bottlenecks there, especially memory speed (simple blit is already much slower).

QuoteHowever, Ndless doesn't seem to provided any way to change the calculator's palette colors. Anyone know if this is possible?

Not with the public API, in fact ndless does not even know that SCR_320x240_8 is paletted. I didn't even want to add it, but did so as some programs that needed to be ported to HW-W used it, I had no choice...

I could add a new bool lcd_set_prop(enum type, union value) syscall for some more flexibility though and extend the definition of  SCR_320x240_8 to mean 8 bit with palette. This would of course require a yet unreleased version of ndless_resources.
What do you think?

For now you could hack around by writing to REAL_SCREEN_BASE_ADDRESS and specifying "--uses-lcd-blit=false --240x320-support=true" to genzehn.

x64 is IA-64, I highly doubt that anyone of you has an Itanium system anywhere
The term got popular when Microsoft used it incorrectly for AMD64 and Intel-64 compatible editons of Windows, but it's still wrong.

QuoteGood job. I wonder how is the speed?

I have no idea, I don't have a HW-W+ calc...

Hi everyone,

inspired by a post on reddit I finally got around to update gpSP-Nspire to be able to build with the newest Ndless SDK.
This has various advantages:

• Supports HW-W without any noticable issues (hopefully)
• No gpsp_resources required anymore, the launcher is now gpsp itself
• Builds again, so bugs can be fixed now more easily (not by me though )
• Built it with LTO enabled, so maybe a bit faster

No screenshot of any kind attached, as it would just look the exact same as the current version of gpSP-Nspire...

It requires a newer revision of ndless, which I haven't yet released formally, so that is also attached. Should work
fine on any OS version starting from 3.1.

Source code: https://github.com/Vogtinator/gpsp

Have fun!