Doesn't run correctly on nSpire CX, screen glitched

[reasv]

I have an nSpire CX -AB with the new screen and this emulator running in compatibility mode still lags significantly even with overclock.

So I tried to compile it myself to get it to run without compat-mode, but it it doesn't work. Whether I use the version I compiled myself or your release at #1 , while it doesn't start in compatibility mode, it's glitched and only part of the screen is occupied by the program, it also "flickers" a bit. When I try starting a game, the part of the screen occupied by the emulator becomes white and then it freezes forcing me to reset.

[Vogtinator]

• nspire-z80 (currently open issue, works on W but timing issue on AB)

I haven't heard of that and it's interesting - do you have a link?

Oh look, it's back to the first speed (the unplayable one) again. I'd say about 30 seconds per frame

I didn't expect it to be that bad - that can only happen if the caches are disabled completely or if the msleep function decides to be a sleep function instead.

Here's a build of gpsp which doesn't use any hardware timing (no msleep, no wait for vblank) in games: gpsp_launcher.zip

[fghsgh]

I haven't heard of that and it's interesting - do you have a link?

https://github.com/pbfy0/nspire-z80

I will try your new version later, currently I'm not at a computer to put it on the calc.

[fghsgh]

Here's a build of gpsp which doesn't use any hardware timing (no msleep, no wait for vblank) in games: gpsp_launcher.zip

While the previous version was sometimes slow (2x) but mostly playable once I figured out the reboot trick (just very rarely "very slow"), this one is sometimes slow and mostly very slow (the 30 seconds per frame slow). This is weird. I didn't believe it myself, but I can message you a video if you don't believe me.

I think I'll be reverting to the previous version for now. I also saw a glitch where it showed only the bottom right quarter of the screen, scaled to the full screen (in slowest graphics mode). Fastest graphics is just as slow as slowest though.

Maybe try to use only hardware timing? Just thinking that if disabling hardware timing makes it worse, then maybe enabling it will make it better?

Also, I turned off frameskip and the frames got faster. Still more than 5 seconds per frame though.

[Vogtinator]

Ok, so it's neither the framebuffer arera buffer/cache nor timer related.

Are other applications using lcd_blit also affected (try some of the ndless samples and crafti (which doesn't do any timing at all, so it's raw CPU and memory speed))?

[Vogtinator]

Maybe it's the input scanning (keypad and touchpad) - if you see the same slowdown with crafti I'll upload a version without any input support and a frame limit instead.

[fghsgh]

Are other applications using lcd_blit also affected (try some of the ndless samples and crafti (which doesn't do any timing at all, so it's raw CPU and memory speed))?

The ndless samples run in compatibility mode, but particles seems to be just as slow. I think it's skipping frames but I don't know how it's supposed to look. Crafti has been running well once I updated it to the HW-W version, but the problem there was mainly just compatibility mode slowing things down.

Actually, now I look at it, the particles program seems to have a very similar problem.

Maybe it's the input scanning (keypad and touchpad) - if you see the same slowdown with crafti I'll upload a version without any input support and a frame limit instead.

No. Even when gpsp is running, the gpsp menu (the blue screen thing) is very responsive. You just have to keep the menu key pressed for several seconds before the key is scanned and then it opens the menu quickly. That wouldn't be the case otherwise. Crafti is doing fine. ntxt is also running well in compatibility mode.

Just as a side note, it's normal the games take a long time to load, right? (when you select them in the menu, before the game starts, it stays on that blue screen for some time before opening the game)

[Vogtinator]

The ndless samples run in compatibility mode

That's weird - most use lcd_blit by now, like the most interesting one, link.tns.

Crafti has been running well once I updated it to the HW-W version, but the problem there was mainly just compatibility mode slowing things down.

So not a generic caching issue then - at this point crafti and gpsp should do the same stuff, reading input, doing calculations and calling lcd_blit without any waiting in between. gpsp is slightly more complex as it JIT's code for emulation, but I don't think that the culprit is there (otherwise it would rather crash than work slowly).

Actually, now I look at it, the particles program seems to have a very similar problem.

The particle program is not very efficient and with a lot of particles severe slowdowns are expected. If you have just one or two, it should run smoothly though.

No. Even when gpsp is running, the gpsp menu (the blue screen thing) is very responsive. You just have to keep the menu key pressed for several seconds before the key is scanned and then it opens the menu quickly. That wouldn't be the case otherwise. Crafti is doing fine. ntxt is also running well in compatibility mode.

Too bad, would've been easier to investigate.

Just as a side note, it's normal the games take a long time to load, right? (when you select them in the menu, before the game starts, it stays on that blue screen for some time before opening the game)

Yes, the flash and filesystem layers are incredibly slow so loading times ~10s are not unusual.

[fghsgh]

The particle program is not very efficient and with a lot of particles severe slowdowns are expected. If you have just one or two, it should run smoothly though.

The thing is that it only ever shows 0, 2 or 3 particles (never 1, and trying to get more resets to 0). Never anything else. And keeping the key pressed for 5 seconds before it reacts (same time as the framerate and also the same as the menu button in gpsp "very slow" mode) doesn't seem very normal to me.

The ndless samples run in compatibility mode

That's weird - most use lcd_blit by now, like the most interesting one, link.tns.

Well, after I tried some of them, which were all in compatibility mode and didn't work, I gave up and probably never tried link. Also, this was quite a long time ago. Maybe you're talking about a newer version.

EDIT: I tried link from ndless 4.4 (my OS version) and it was running in compatibility mode, but smoothly. Colors was also responsive to the keypress to quit (I didn't have to keep pressing it for long and it just quit quickly).

[Vogtinator]

EDIT: I tried link from ndless 4.4 (my OS version) and it was running in compatibility mode, but smoothly. Colors was also responsive to the keypress to quit (I didn't have to keep pressing it for long and it just quit quickly).

You need to use the latest download - ndless 4.5 works fine on OS 4.4. If you use an outdated version there can be issues such as this.

[fghsgh]

Well, didn't know that. It's kind of confusing that the ndless version looks like the OS version.

[adriweb]

Ermm, to the contrary, it's done on purpose so that it's easy to know which one is for which OS, no need to keep track of different numbers then. But anyway yeah, use the latest available to avoid potential issues of bugs already fixed.

[fghsgh]

no need to keep track of different numbers then.

Well, if my OS is 4.4 and I should use version 4.5, it seems like two different numbers to me. Correct me if I'm wrong.

[adriweb]

That's the thing: use the Ndless version corresponding to your OS, it's as simple as that :P But if you want to continue to use Ndless, then don't update your calc's OS whenever a TI update gets out, since it won't be compatible. So... look at the latest ndless version, and install the OS that matches.

[Vogtinator]

That's the thing: use the Ndless version corresponding to your OS, it's as simple as that :P

Wrong - use the latest version of Ndless which supports your OS. Ndless 4.5 supports all OSs which there is an installer for back to 3.1.

[adriweb]

Yes my 2nd sentence solves potential issues for future versions - my first one is true for the time being though :P

[fghsgh]

Okay, so I'll install ndless 4.5 then.

In the meantime, I found out this while running slower (the 2x one):

• turning off frameskip doesn't slow it down, the frames are closer together (as it should)
• putting it into fast mode will make frameskip higher, and it runs faster, but not as fast as when it's not slowed down, fast mode has basically no effect in that case
• scaled/blended mode (graphics options) is just as fast as unscaled mode

I stopwatched the framerate in the very slow mode: 4.4 seconds. The larger numbers I was talking about before were with frameskip on. This is also the maximal time you'd have to keep a button pressed for before it is detected. It's also the same time for particles.

Updating ndless didn't fix the issue. And particles, link and colors are all still running in compatibility mode.

Okay, so I got particles running at a fluent speed just by restarting the program, but there are still some graphical glitches. When I tried to record it, it didn't work. It's back to being 4.4 seconds per frame. What is weird here is that particles doesn't slow down the actual particles, just the framerate. Gpsp also slows down the game.

Update: I didn't manage to open gpsp once with it running quickly since upgrading ndless. I'm going back to 4.4.

[BMWeasel]

I just remembered that this existed, 5 months later after finals =|. Either way I thought I would throw the few cents i had left over here. HW rev: AC OS ver: 4.5.0.1180 ndless ver: 4.5.0 So far with the latest version there is no compatibility issue prompt but the games run at 6fpm. the menu button needs to be held down to exit (I'm assuming its just waiting for the next frame[also running overclocked]) If anyone with the skills to work on this gets bored enough to try something I'm here now =P

[fghsgh]

I'm still here too. The problem are the skills (I'm not very comfortable with the ndless API).

[Led1-ch]

Not sure if anyone is still working on this but here is my info: HW rev: AD OS: 4.5.0.1180 ndless: 4.5.0 (compiled from source 2/26/2020)

So basically I tried every single variation of the gpsp posted in this thread and they were all horrendously slow. The only one that was slightly playable was the one where msleep was disabled and that was still very very slow. On the other hand, gpsp in compatibility mode works completely fine! It is a tad slow even with overclocking so real time games are difficult to play.

I am graduating soon and will have some free time so I'm considering writing a new emulator from scratch so it will be compatible with the new lcd api of ndless. @Vogtinator how much c++ support does ndless have or should I write it completely in c only.

[Vogtinator]

@Vogtinator how much c++ support does ndless have or should I write it completely in c only.

Full. I never tried std::filesystem though, that might be broken.

[fghsgh]

@Led1-ch good luck and I'm hoping for the best! Though it did work sometimes with ndless 4.4...

[Vogtinator]

Please try Ndless with a completely different approach of LCD compatibility from here: https://github.com/ndless-nspire/Ndless/pull/202#issuecomment-594753861

With this, the applications should work much better.

[fghsgh]

The LCD was already working quite decently, it must be some kind of timer that causes the issue. First time I ran this, it was slow, but not unbearably slow. I think I was maybe getting 2 fps (and the whole gameplay was slowed down, regardless of how much frameskip I set). However, the second time I ran it, it took 63 seconds (and I'm not exaggerating, I stopwatched it) between choosing "Return to game" and seeing the first frame of the game. Then, I had to keep menu pressed for multiple seconds before it would open the menu again. I had to wait out the 60 seconds another time and then I had to press left for another 48 or so before the character moved one frame.

Could you send a version that doesn't try to match the speed to a real GBA? I'm talking about doing what Crafti does and not caring about time too much.

[Vogtinator]

@fghsgh This approach of using lcd_blit is flawed by design and can't really work well, so just try the original gpsp builds instead.

[fghsgh]

@Vogtinator where can I find that? I suck at GitHub.

[Led1-ch]

I will try out the new ndless resoures in a few hours but the fact that msleep being disabled significantly speed up the lcd_blit emulator for me means that it's somehow detecting the fps wrong and sleeping too long. But even then I'm not really sure what the issue is. There's also a significant slow down when playing romhacks that do C script insertion instead of straight assembly hacking whereas on the original gpsp it's fine so I'm not sure what's going on there either. Maybe because the C scripts often include checks during the main game loop the nspire can't keep up?

@fghsgh you can find the original build on the ndless apps or on ti-planet. The source code is lost for it I think.

[Vogtinator]

@Vogtinator where can I find that? I suck at GitHub.

https://www.ticalc.org/archives/files/fileinfo/449/44971.html

@fghsgh you can find the original build on the ndless apps or on ti-planet. The source code is lost for it I think.

Nope, this repo is based on the tarball. The gbc4nspire sources were lost.

[fghsgh]

The speed at which that one runs is great. However, the ndless compatibility mode seems broken. It seems to be very stable but it is still unplayable because of the broken compatibility mode. Here is a picture of the Pokemon Firered startscreen:

[Vogtinator]

Which HW revision is that calc? It's confirmed to work on HW-Y and below with insufficient data for others.

[fghsgh]

AB, see above

[Vogtinator]

Ok, so for Z+ calcs it still needs some work. They probably switched the display model...

[fghsgh]

...which could explain the first issue with the display only being 240x240.

[Vogtinator]

No, that was the display initialization code configuring the LCD controller to output 320x240px while drawing 240x320px. That's fixed in https://github.com/Vogtinator/gpsp/commit/b7e972d8e52e8f4097b579618649c11082f4f9ae

[Led1-ch]

The original build is unstable after about 5 runs it forgets where the bios is for revision AD but the LCD display is fine. Like I said it's about half as slow as pre W revision (i compared to overclocked revision D from my friend)

[Led1-ch]

Okay so with the new resources and the original gpsp I get a screen similar to fghsgh. Lots of lines everywhere and also tilted the wrong way. With the lcd gpsp I get a black screen after using the menu and I ended up having to restart my calculator. Does this mean that revisions like AB and AD have the pre W dimensions just with an lcd display and that the slowdown on the original gpsp is simply due to the rendering speed and is that fixable? I noticed that the original gpsp was released in 2012 while the SDK graphics for ndless was released in 2013 maybe using that library will make it run faster?

[fghsgh]

@Vogtinator You left the IRC room, so I'm writing this here, as it's the only other way I have to contact you: I restarted the calculator (ctrl + on, on), and the inverting and on/off commands worked. Writing FFFFF caused a dark green, which inverted was magenta. I think this is due to the restart, not because of the I/O the program did. This has also happened on gpsp already. The rectangle was still messed up, though. The read bytes were 0x1ff, 0x01, 0x10a, 0x148.

[Vogtinator]

@Vogtinator You left the IRC room, so I'm writing this here, as it's the only other way I have to contact you:

Just write in IRC, I'll read it later.

I restarted the calculator (ctrl + on, on), and the inverting and on/off commands worked. Writing FFFFF caused a dark green, which inverted was magenta. I think this is due to the restart, not because of the I/O the program did.

Yes, that it works after "restarting" (which is actually just idle mode) can be explained by the OS using SPI to turn the display off and back on again. That the commands now worked means that the communication with the chip still works, just some initialization is missing. Question is now what has to be done, maybe setting CS differently, some GPIO pin or some other hidden clock configuration.

This has also happened on gpsp already. The rectangle was still messed up, though. The read bytes were 0x1ff, 0x01, 0x10a, 0x148.

When the test program works, the new lcd compatibility mode should work too. The test program doesn't set MADCTL anymore, so it's still 240x320.

[Vogtinator]

By calling a different function for sending commands over SPI, the issues on HW-AA+ should be fixed now, please try: https://github.com/ndless-nspire/Ndless/pull/202#issuecomment-594753861

[fghsgh]

It works! Runs very smoothly. It only freezes now when I press L to load a savestate. I left it on for 15 minutes, but it didn't respond to any keypresses and had to reset again. EDIT: maybe the savestate didn't work because of the downgrade. New savestates are working correctly.

[Led1-ch]

It works wonderfully for me (the original gpsp on compatibility mode). It runs much more closely to pre HW W speed! But there is a slight issue with a thin blue line on the left side of the home screen of the calculator.

[Vogtinator]

This now restores registers better, please try: https://github.com/ndless-nspire/Ndless/pull/202#issuecomment-594753861

[Led1-ch]

It works great! Thank you so much for these updates, everything is running smoothly. I also noticed that for some games turning off the music speeds up the game a lot.

[Vogtinator]

Let's just call this issue fixed then. I'm still hopeful that GPSP can be made to work natively on 240x320, but for now this is good enough.