Open FerdinandoPH opened 1 year ago
pinging @Vogtinator just in case
Yeah, this looks like it's the usual HW-W-like LCD format mismatch. The issue with the CX II LCD in particular is that there's extra HW which performs rotation, so when writing to the existing framebuffer it's like a 320x240 one, but when changing to a different location it's actually 240x320... That unfortunately needs specific code to handle the is_cx2
case here.
Is this project maintained?
No (read the author profile bio...), a fork would be needed to update the code to use the latest SDK stuff
There is already an is_hww
clause in the lcd code that seems to rotate the framebuffer. How would an is-cx2
differ from this, and what would need to be done to implement it?
There is already an
is_hww
clause in the lcd code that seems to rotate the framebuffer. How would anis-cx2
differ from this, and what would need to be done to implement it?
IIRC it's almost the same. It might have to do an X/Y flip in addition to the 240x320 conversion, but I'm not entirely sure.
You could try
if(is_hww) {
return x * 240 + y;
} else if(is_cx2) {
return (319-x) * 240 + 239 - y;
} else {
return y * 320 + x;
}
@Vogtinator I've implemented such a check with https://github.com/unilock/nspire-z80/commit/01af73c098837b99aaf863cc36d7c7dc2a2ba5f3, but I'm still running into pretty much exactly the same issue as in the original post.
It seems the screen dimensions are referenced in a few other locations:
Unfortunately my knowledge of C isn't decent enough to know what exactly needs to be changed (nor is my ARM9 assembly, especially).
Try
static void n_set_84_pixel(int x, int y, uint8_t gray, uint8_t *buf){
for(int dx = 0; dx < 3; ++dx)
for(int dy = 0; dy < 3; ++dy)
buf[xy_to_fbo(C_XO + x + dx, C_YO + y + dy)] = gray;
}
Might be a bit slow, but should produce a usable picture.
@Vogtinator Done here: https://github.com/unilock/nspire-z80/commit/4ae848f0d45c373dde92073d2aa95801c711417a
Unfortunately, I still get more or less the same problem. The calculator also crashes and reboots a few seconds after starting the program (this isn't new; even the unmodified version of nspire-z80
did this on my CX2).
Maybe fb_setup(uint8_t *buf)
has to be updated for CX2 hardware as well?
That sounds like something else is wrong then
Maybe fb_setup(uint8_t *buf) has to be updated for CX2 hardware as well?
FWICT that just clears the screen and draws a border with an icon. It should still be usable if the border is corrupted.
Rom works fine on wabbitemu (it's a ti 84 se rom), but I open it on this emulator and this happens: I can exit pressing esc, but that's about it. I'm using a ti nspire cx ii cas with ndless 5.3![WhatsApp Image 2022-09-13 at 20 40 06](https://user-images.githubusercontent.com/29411787/189984393-fe71af1d-5a73-45b4-9f44-3a53e55ac4f7.jpeg)