Doesn't run correctly on nSpire CX, screen glitched #3
Comments
|
Same issue here with AB hw rev, also, games run incredibly slow (I have to keep MENU pressed for like 2 seconds before gpsp finds out) and I don't have patience to let games get past the loading screens so I don't know how slow it is exactly. |
|
Looking at the source code, i'm a bit puzzled why it would do this. And i see that Vogt added a RGB555 screen mode and skipped some steps. (presumably in an attempt to make it faster?) Please give my build a try and also update your ndless_resources.tns file to the latest version. |
|
I will try it later as I don't have time now. I thought it had something to do with the screen being rotated but not updating the dimensions (320x240 becomes 240x320 but the software keeps sending 320x240, so the first 320 gets cut to 240 and the second 240 causes the right strip to remain). I think my ndless_resources is up-to-date as other programs and games work just fine (both compatibility mode and not). |
|
Even after updating ndless, it's not working. Only a square is rendered, the home screen flickers, and games run VERY slowly, like, unplayable slowly. It looks like only a white screen is shown when the game starts, but after pressing F for 4 seconds it changed, so that proves it's still running. Holding MENU for about the same time brings you back to the menu, from where you can then exit. Also, I had a problem with my calc freezing between two starting-screen-banner-display things, but I think that is an issue with the ROM of the game. I have an actual cartridge of the game that's doing that and it works on my DS Lite. I think I'm not allowed to upload the ROM here, so I'm not doing that. |
|
Sounds like the RGB555 mode is still broken then :/ |
|
Thanks. |
|
@fghsgh I discovered why Gpsp wouldn't work and i managed to make it work without any modifications ! Remove your ndless_resources.tns file and replace it with the file below (after decompressing it of course). Reboot your calculator & reinstall Ndless again. Try my version of gpsp again and it should work ! |
|
Hmm, upstream is ahead by 20 commits, though, including one that fixes/improves the lcd compat mode, in r2012 |
|
@adriweb I did not notice that :P But since he submitted the fix for it, then using his fork is still good. |
|
The ndless.me download just redirects to the latest github release, though. which is the r2012 containing that "(r2012) lcd_compat mode: Save some memory and support transparency" commit... |
|
@adriweb Yeah, it still links to the older version. He added RGB555 but it wasn't working properly for me. Only after compiling it from source did i fix the issue. |
|
Weird - I don't know how that can be, since the file I get in the release is from November 2017, from the commit date :P |
|
Probably a GCC bug then... I'm not lying, you can try it yourself 👁️ |
|
lol woops. @Vogtinator any input about this? |
|
This GPSP fork has If for some reason it still starts, it would not display anything as lcd_blit wouldn't know what to do with RGB555. This means it's probably a regression introduced by ndless-nspire/Ndless@e71c0e7 - which would mean that the OS does weird stuff with that buffer. That would need to be investigated. Can you confirm that it still works with ndless master with that commit reverted? |
|
Well i tried it again by, again, downloading ndless from ndless.me again and it still works with my precompiled gpsp. I mean, it used not to work before on the emulator (same issue as him), what the hell ? Sadly, i don't have my Nspire anymore (will only get it in a few months...) so @fghsgh or @reasv , could you try it again with an updated ndless_resource.tns ? |
|
I have put the ndless_resources.tns @gameblabla sent on my calculator, restarted and re-installed ndless, but it still doesn't work. I have tried both the original version and the version @gameblabla sent above. Can someone send a newly compiled gpsp? |
|
@gameblabla I had the same - works fine in firebird but apparently not on real HW. @fghsgh or @reasv: Can you check whether the battery icon in the top right changes if you plug/unplug the charger? |
|
Do you mean in the os? Which screen of the os? Usually it changes. |
|
No, while gpsp is running and glitched. |
|
Sorry, I can't try it as my battery is fully charged and the battery icon doesn't even update in the OS. To drain battery, I'm letting it count from 1 to 999999 (which prevents sleep) on full brightness and charging my phone with the USB-cable. It seems the counting will keep it busy for some time. EDIT: I got the battery down to 75% and the icon didn't even update in the OS... until I found out that the other end of the cable was not plugged in. Then, it still didn't work, because apparently it wasn't the same cable. After fixing that, it updated in the OS, but not in the program, neither turning on nor off. EDIT: Could the slow speed have something to do with the timer hardware being locked on newer calculators (like the test mode LED)? I though I heard something like that. That could mean interrupts run much slower. |
|
I’m not sure what you mean with the timer stuff in recent hw revs (where did you hear/read that?) but in any case, in the OS, when you plug your calc’s USB the icon should change to indicate that it’s charging (some lightning icon IIRC?) or at least connected, anyway something different. I doubt this has changed on the hardware side... |
|
It did change in the OS, not in the program. I can't find where I read that. On some forum probably, about the LED. It's not in my browser history as far as I can see. It was something like "maybe they have put a protection on it, just like you have to write to [memory mapped port address] to enable access to the first timer". |
|
Ok, that rules out that the OS is somehow interfering with the timing, that means that GPSP itself does it :-/ That also explains why it behaves differently in the emulator. I'll do some tests. |
|
GPSP does indeed modify the timings and changes from the OS-defined 320x320 (sic!) to 320x240. On a 240x320 LCD that won't work. I disabled lcd timing changes in this build, please give it a try: |
|
I've decided to jump into this as I have an nSpire CX CAS -AA model with 4.5.0.1180 installed. I used the ndless_resources.tns in ndless_res_new.zip provided by @gameblabla because the one provided in #1 crashes and reboots the system. The latest launcher above, from @Vogtinator , correctly fills up the screen with the menu. When I launch a ROM, such as Pokemon FireRed, it starts off as a white screen and SLOWLY starts to display the Gamefreak/Nintendo copyright information. |
|
Ok, so the display issue is fixed, but now it's apparently a performance issue? |
|
It's so slow that the original Alpha v0.11, released August 6,2012, is faster. |
|
Same for me as for @ThunderRemix. Can this be the same issue as this TI-84+ emulator? That issue is mainly about invalid ROMs but there is also something there about speed. |
|
Yes my 2nd sentence solves potential issues for future versions - my first one is true for the time being though :P |
|
Okay, so I'll install ndless 4.5 then. In the meantime, I found out this while running slower (the 2x one):
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. |
|
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. |
|
I'm still here too. The problem are the skills (I'm not very comfortable with the ndless API). |
|
Not sure if anyone is still working on this but here is my info: 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. |
Full. I never tried |
|
@Led1-ch good luck and I'm hoping for the best! Though it did work sometimes with ndless 4.4... |
|
Please try Ndless with a completely different approach of LCD compatibility from here: ndless-nspire/Ndless#202 (comment) With this, the applications should work much better. |
|
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. |
|
@fghsgh This approach of using |
|
@Vogtinator where can I find that? I suck at GitHub. |
|
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. |
https://www.ticalc.org/archives/files/fileinfo/449/44971.html
Nope, this repo is based on the tarball. The gbc4nspire sources were lost. |
|
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: |
|
Which HW revision is that calc? It's confirmed to work on HW-Y and below with insufficient data for others. |
|
AB, see above |
|
Ok, so for Z+ calcs it still needs some work. They probably switched the display model... |
|
...which could explain the first issue with the display only being 240x240. |
|
No, that was the display initialization code configuring the LCD controller to output 320x240px while drawing 240x320px. That's fixed in b7e972d |
|
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) |
|
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? |
|
@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.
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.
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. |
|
By calling a different function for sending commands over SPI, the issues on HW-AA+ should be fixed now, please try: ndless-nspire/Ndless#202 (comment) |
|
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. |
|
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. |
|
This now restores registers better, please try: ndless-nspire/Ndless#202 (comment) |
|
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. |
|
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. |
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.
The text was updated successfully, but these errors were encountered: