Join us on Discord!
You can help CodeWalrus stay online by donating here.

Heavy Metal on TI-92 Plus

Started by utz, April 05, 2016, 08:29:18 AM

Previous topic - Next topic

0 Members and 2 Guests are viewing this topic.

utz

I'm afraid at this point even Lionel can't help me... that bit of code by itself can't be causing the problem, as in effect it does nothing at all. I'm sure the problem must be elsewhere. I mainly needed to vent my frustration, so thanks for the consolidating words @DJ Omnimaga.

I've got a hunch about what's going on by now. My guess is that those stack-based size optimizations that Lionel proposed need some modification, because in their current form they will mess up the registers when an interrupt triggers between those 2-step instructions. But that I will investigate... tomorrow, maybe.
  • Calculators owned: TI-82, TI-83, TI-83+, TI-85, TI-86, TI-92+, Sharp PC-1403

Lionel Debroux

#16
Most of the size optimizations I proposed are stack-based, yeah. But if the mere fact of switching to e.g. move.l xxx.w,xxx.w fixes the crash, then that would be a sign that your code is really unsafe, and you're just papering over the real issue.
To prevent reentrance from the same interrupt, the whole critical section of code should be executed from within the interrupt handler, i.e. before the RTE. Which means you wouldn't need to play games with the return address, either.

[EDIT: fixed typo]
Member of the TI-Chess Team.
Co-maintainer of GCC4TI (GCC4TI online documentation), TIEmu and TILP.
Co-admin of TI-Planet.

utz

Yeah, you're right. And those optimizations were not the problem, after all. Also I agree, not fiddeling with the return addresses would be nice, but I don't see how to do it without a major (unacceptable) increase in step-to-step transition noise.

So what was the problem? Well, I didn't realize that after running the timer detection loop, AUTO_INT_5 would fire immediately (ie. during TRAP #1). Which of course causes trouble when the AUTO_INT_5 vector has been modified  :banghead:

Aaaaanyway... before I package a new release, would one of you be so kind to test the TI-89 build? (upload both attached files and boot with "qed68()")
Also, updated source is available at https://github.com/utz82/qed68 for further examination.
  • Calculators owned: TI-82, TI-83, TI-83+, TI-85, TI-86, TI-92+, Sharp PC-1403

Lionel Debroux

#18
I haven't tested your program, but I can see other optimizations:
* the branches in the rdch area should be short (smaller);
* bclr #0,($60000E); bclr #1,($60000E) should be replaced by a single and (smaller, faster).
* bra \nx[1234] should be short (smaller): unconditional branches are 10 cycles, whether they're short or word;
* in rdseq, movea.l (seqpntr),a0 should be PC-relative (smaller). This one doesn't seem to be part of an area with carefully crafted timings;

For maintainability, you should have used appropriately named macros, instead of open-coding so many
* or.l d0,d0
* move.l (a7),-(a7); addq.l #4,a7
* move.l 1(a<n>),a<n> immediately followed by bra \nx(<n-1>) (I have noticed the occasional move in-between, for timing purposes).
* cmp.b (a<n>),d0 immediately followed by beq \resetsmp<n-1>;
* the 4 5-instruction sequences at the beginning of every core* subroutine, unless writing to the link port requires otherwise;
* the 6-instruction sequence at every \nx4 label, only core2[234] seem to be different due to writing to the link port.

A pessimization: disabling vector table protection only for short periods of time, when you're actually modifying its contents, instead of disabling it for the whole duration of your program :)
Member of the TI-Chess Team.
Co-maintainer of GCC4TI (GCC4TI online documentation), TIEmu and TILP.
Co-admin of TI-Planet.

utz

#19
Thanks Lionel, I'll look into these.

Branches are auto-optimized via the .tpr, so they should always be short. But I can add the .s to make the code more portable. Forgot about re-enabling vector table protection, will take care of that.

I very much dislike macros. I do see why others find them convenient, but for me, they decrease readability of the code too much.  So since I'm the one who has to maintain this code, I prefer to keep the text bloat, sorry.

Edit: Changes done, latest test build for TI-89 attached.
  • Calculators owned: TI-82, TI-83, TI-83+, TI-85, TI-86, TI-92+, Sharp PC-1403

Dream of Omnimaga

I'll give this a try on a calculator later if I can find my adapter and some batteries. :)
  • Calculators owned: TI-82 Advanced Edition Python TI-84+ TI-84+CSE TI-84+CE TI-84+CEP TI-86 TI-89T cfx-9940GT fx-7400G+ fx 1.0+ fx-9750G+ fx-9860G fx-CG10 HP 49g+ HP 39g+ HP 39gs (bricked) HP 39gII HP Prime G1 HP Prime G2 Sharp EL-9600C
  • Consoles, mobile devices and vintage computers owned: Huawei P30 Lite, Moto G 5G, Nintendo 64 (broken), Playstation, Wii U

Powered by EzPortal