GinDiamond wrote:
And, executing past address $c000 will do what?
The contents of your RAM go down in flames. Basically, it has exactly the same effect as taking all of the batteries out of your calculator and putting them back in again. So if execution ever wanders past $C000, your calc turns off and greets you with a nice little "RAM Cleared" message when it wakes up.
(BTW, this works by clearing the program counter to $0000 when it reaches the illegal values. $0000 is also the default value of the program counter when the calc recieves power, so TI understandably stuck the reset routine there, since that's what should happen when you get a new calc. This also means that jumping to $0000 or causing another program to do so will also reset your calc).
why would I want to reset my calc every time I run the program?
GinDiamond wrote:
why would I want to reset my calc every time I run the program?
The point is that it would take away the limit so it doesn't crash when execution goes past the limit.
Compynerd255 wrote:
(BTW, this works by clearing the program counter to $0000 when it reaches the illegal values. $0000 is also the default value of the program counter when the calc recieves power, so TI understandably stuck the reset routine there, since that's what should happen when you get a new calc. This also means that jumping to $0000 or causing another program to do so will also reset your calc).
To my vast confusion, jsTIfied only works properly when I reset the PC to $8000 on the TI-83+SE and the TI-84+/SE. $0000 only works on the TI-83+, and very strangely, 1.12 requires $0000, while 1.14 and higher can deal with $0000 or $8000.
Oh. So, going past adress $C000 will allow assembly programs bigger than 8,211 bytes or something?
GinDiamond wrote:
Oh. So, going past adress $C000 will allow assembly programs bigger than 8,211 bytes or something?
That's correct. Unfortunately, it would only work on peoples' calculators who had the particular fix.
Oh.
So, I'm getting into the circuitry thing.
I noticed that the schematic you linked me to showed the CPU separate from the RAM and the ROM. Could I switch out the CPU for a more powerful Zilog z80?
KermMartian wrote:
Compynerd255 wrote:
(BTW, this works by clearing the program counter to $0000 when it reaches the illegal values. $0000 is also the default value of the program counter when the calc recieves power, so TI understandably stuck the reset routine there, since that's what should happen when you get a new calc. This also means that jumping to $0000 or causing another program to do so will also reset your calc).
To my vast confusion, jsTIfied only works properly when I reset the PC to $8000 on the TI-83+SE and the TI-84+/SE. $0000 only works on the TI-83+, and very strangely, 1.12 requires $0000, while 1.14 and higher can deal with $0000 or $8000.
Well, if the RAM is actually filled with zeroes, the processor should just encounter nop after nop and eventually cycle back to $0000, which should only take 9 ms on a 15 MHz processor. Of course, I'm probably totally wrong, since this would involve execution going past $C000 again. And again. And again.
Compynerd255 wrote:
Well, if the RAM is actually filled with zeroes, the processor should just encounter nop after nop and eventually cycle back to $0000, which should only take 9 ms on a 15 MHz processor. Of course, I'm probably totally wrong, since this would involve execution going past $C000 again. And again. And again.
In essence, you've just entered an infinite loop, and you've frozen your calc?
Except that in most cases with how the z80 does memory banking $0000 is not in fact ram but rather ROM page 00h which contains the OS and why it cleanly resets when the PC is reset to $0000.
At least that is what is supposed to happen.
As I mentioned before, could I switch out the 5MHz processor for a faster one?
Switching it out wouldn't do anything as the processor itself is not what controls the clock speed but the clock signal being fed to the chip. You can overclock/reclock the processor by just replacing a few resistors iirc. That said some things in the OS are hard coded based on the clock speed, at least in some OS versions, and that will cause issues if you change the clock speed.
But, in theory, I could switch out the processor for a 200MHz one, and then change some resistors, and then hack up the OS a bit as needed, and then I've just earned a voided warranty?
GinDiamond wrote:
But, in theory, I could switch out the processor for a 200MHz one, and then change some resistors, and then hack up the OS a bit as needed, and then I've just earned a voided warranty?
I kinda doubt a pin compatible 200Mhz z80 exists and 200Mhz would cause even more issues. They had enough issues just bumping to 16Mhz for the SE and 84+/SE Calcs.
But what exactly does a processor mean if its 16MHz when you say the processor doesn't actually control the speed?
I think you'd face issues when interfacing with hardware, as the RAM and Flash memory aren't fast enough to keep up with the processor.
GinDiamond wrote:
But what exactly does a processor mean if its 16MHz when you say the processor doesn't actually control the speed?
The external hardware controls the speed. However, certain processors can only go so fast. The z80 in your calculator can only hit about 30MHz before it starts getting unstable because of gate propagation delays and skew. Faster processors are designed to actually be able to go that fast.
Basically, the general idea behind how fast a CPU will go rests on two factors. Gate design and the clock. The gate design will determine a soft limit as to how fast the core will go. Cheaper, bigger gates will usually open and close more slowly than small, expensive gates. So, if you try to open and close them too fast, the core becomes quite unstable and will start doing unexpected things. The other part is the clock. The most common implementation among low frequency devices is to just have a piezoelectric element that vibrates at a certain frequency when voltage is applied. Whenever a cycle completes, it sends a jolt of electricity in to the CPU circuit. On the z80, each jolt is called a 'T-State.' It will cause the gates to open and close, depending on the current instruction being fed in. Most operations require multiple T-States to completely change the gates in the CPU to where they need to be, so frequency is not always equal to operations per second.
I am relatively unfamiliar with the TI hardware, but I'm pretty sure that the entire clock regulation mechanism on the TI-84+(se) is totally internal to the ASIC. However, on the TI-83+, the voltage regulation to the clock is external, so you can muck about with it. Some people have gotten their 83+s to run faster than 84+SE models
Right. I figured about those oscillator timers.
So, the z80 processor it comes with can only handle so many commands at once, right? Can you create "virtual registers" to increase the amount of computing capacity?
Yes. Those "virtual registers" are called IX and IY, and RAM.