I think I should just point out that bcalls aren't as slow as what people think. Yes, if you are using bcall(_multAbyE) inside a djnz loop, then you are wasting some time. But the time wasted is relative.

The whole bcall process takes about 1000 t-states. In 6.5MHz mode, that's .00015 sec. If you do 100 bcalls, that's only .01 sec.

In this case, since you are making a basic library, there's no reason why you shouldn't use bcalls. The bcalls aren't slow compared to basic. However, floating point numbers vs. HL makes a big difference. If you don't need decimals, then HL is definitely the way to go.

The boot code has two purposes. 1) To receive OS's, 2) To prepare the calculator hardware to run the operating system.

Receiving OS's is one of the boot codes two purposes. Whenever you see the OS percentage screen, that is the boot code. The boot code also makes it appearance in "Waiting... Please send operating system now." However, even if the boot code couldn't receive OS's for whatever reason, this really isn't too bad as there are ways to glitch it.


But the primary purpose of the boot code is to prepare the calculator hardware for an OS and then jump to the OS to let it start executing. Whenever power is cut from the calculator, all of the hardware stuff dies. Then, when power returns, execution starts at the boot code. The boot code sets up all of the calculator hardware, checks to make sure that an OS is installed, and then jump to the OS. But the key thing here is that the boot code is run first no matter what. If you pull a battery, the next thing that is going to run is the boot code. (Unless the calculator is turned off, then you have like 5 secs to put it back in.) So if the boot code is missing, the calculator will crash as soon as a battery is inserted. And when it crashes, guess where it goes. The boot code. This would be an endless loop, and the end of your calculator.

Well that's nice. Can't wait to see this on the other 83+ calcs. And that would allow for custom boot code?

This won't work on 83+'s because on those, TI most likely locked the boot code the proper way with the flash chip itself. Here is the only reason that it actually works on an 84+: (new paragraph so people can quote me )

On the 84+, for whatever reason, TI decided not to hardware write protect the boot code sectors. The flash chip supports this feature, but TI didn't do it. So TI just programs the boot sectors and puts the flash chip in the calculator. That was mistake number one, but here comes mistake number two. Next, probably in order to save money, TI decided to make the circuit boards of the 84+ and 84+SE exactly the same, the only difference of course is the flash chip. So, to make sure that the boot sectors can't be overwritten, TI had to come up with a way to block different sectors on the flash chip for each model even though the hardware was exactly the same. Their solution was to make a port on the calculator that protects different flash pages based on its value. And finally, since the boot codes were programmed differently on the flash chips, TI put in code to set this port to different values based on the size of the flash chip. This way, as long as no one touches that port, the calculator will look like the boot code is write protected. However, we discovered what this port was and removed their boot code protection.

After writing this, I feel like this would work on the 83+SE also.

(Now, after all of that, if you know a bit of assembly, I'm sure you can figure out how to do it.)

Well, I've talked to brandonW about this. We really don't want to use this to make the pocket able to accept other OS's. The problem comes from how dangerous this is. In the end, it really is just like any flash mod, but the thing is, if something goes wrong while the boot code is all FF's, instant, permanent brick. Unless you can wire up the flash chip and reprogram it, your calculator is done. It will execute one instruction and end.

If we did make a boot code modder, of course it would be extremely safe. It would check batteries all over the place and probably would be stepped through instruction by instruction several times. But, boot code 1.03 will probably be coming to america soon which means it will become more widespread. And if we release this as the only way to install other OS's, over time, there will probably be about 5 people using it every day. If just 1 person is an idiot and tricks their calculator into running it with low batteries, they will brick their calculator and we will be in a huge mess online.

Besides, we don't even need to do this. BrandonW and I have come up with different ways to beat the boot code, and my program to do it is already done. With two exploits, we should be covered for a long time unless TI looks through their boot code for errors, which they won't.

Edit:
    Now that I think about it, NOPing out some checks in the boot code wouldn't really be that dangerous. (I've already NOPed stuff in my boot code.) So I guess a mod like this could be a possibility, but only if we need to do it.

Maybe have MODE quit instead of CLEAR?

Better.


Update! Now, the program won't quit until you have released all the keys. This is to prevent 83+'s from entering the no-archive boot. If you've already installed it in your certificate, this is the exact same program, so you really don't need to download it.

Put some spaces in . The about screen will display up to 48 characters, so use them.

I was wrong about the OS transferablility. You can't send 83+ OS's to the 84+, but aside from ethical reasons, there's no reason you can't put 2.55MP on your 83+.

Edit:
    I'm not sure there's even enough space to do that. Someone needs to try it.

I haven't said whether it's possible or not, because honestly I don't know. It should be possible.

Here's the process I'll have to go through.
1. Find those menus' cxCurApp values. (This is their ID values)
2. Figure out where they store the current varType.
3. Figure out where they store the current program
4. Figure out how to redraw the menus
5. Figure out how to search alphabetically for stuff
6. Add in special cases for those cxCurApp values in my hook routine
7. Write the hook routine

Now, 1 and 6 are simple. If I'm lucky, 2, 3 and 4 will be the same as the program menus. 5 I know how to do as long as I can do 2. And 7, I think this is like my 30th hook or something, so I've got some experience in the matter.