[removed]

[parrotgeek1]

I know.
I perfectly understand that's it's going to be hard (and hazardous) to develop a boot loader without an emulator.

To begin with, are you using nspire_emu or firebird ?

nspire_emu, because read breakpoints STILL don't work in 64-bit firebird.
I suppose since the exploit works well I could switch to firebird.

[parrotgeek1]

I don't think it'll work on nspire_emu anyway - something is not implemented if I remember well. Boot1 dumpers don't work on nspire_emu for example.

Maybe it'll work on firebird, but I'm not sure.
It should work on a real calculator.

It works on firebird.

But, when you try to use the read_nand function, boot1 (3.0.0.99) crashes.
@Lionel Debroux

Also I just realized something really dumb I never thought of:

All of the boot1 functions are at different addresses on boot1 4.0 lol

[critor]

Yes. If we want a new boot loader working on both HW-W+ and HW<W, we'll have to make it check the Boot1 version.

[parrotgeek1]

Yes. If we want a new boot loader working on both HW-W+ and HW<W, we'll have to make it check the Boot1 version.

and write 2 different screen.c files, one that displays everything sideways. ugh

I wonder if Excale or Vogtinator would help with the nand stuff?

[critor]

Let's just make everything use set_pixel(), with 2 cases in set_pixel().

[Lionel Debroux]

Lack of testing on real calculators is a bit worrisome

[parrotgeek1]

Lack of testing on real calculators is a bit worrisome

are you saying the exploit doesn't work on real hardware? The makes me think you're hinting at that

[Lionel Debroux]

The fact that exploits work on emulators - especially older ones, as you're running mainly nspire_emu for the reason you described above - does in no way warrant that said exploits work on real hardware (let alone that they don't cause issues), indeed...
Heck, even the fact that an exploit doesn't work on an emulator doesn't imply that it doesn't work on real hardware (though clearly, such as situation is unlikely, provided the emulator is accurate enough).

It's been about 16 years since I became aware of emulator glitches (in addition to missing features) on the TI-68k series. Non-existent bits in SR, garbage in - garbage out on the nbcd instruction, and even a simple instruction sequence which produces a different result when run on an emulator which doesn't emulate the 68000's embryonic pipeline - the trio was used as anti-VTI measures (and thereby a weak protection against reverse-engineering by script kiddies) in HW3Patch. TIEmu has none of these three bugs, so HW3Patch works properly, and in the abandoned JS TI-68k emulator, I worked around the third check.

[parrotgeek1]

I would use firebird more if it let me launch it from the command line with a boot1/boot2 instead of having to create a new flash image in the GUI every single time. It's really tedious

[critor]

Same thing here.
I rarely use firebird, because I'm always dealing with different flash images.