Omnimaga
Calculator Community => TI Calculators => ASM => Topic started by: SirCmpwn on March 24, 2011, 08:59:55 pm
-
What does the z80 do when it crashes?
-
What do you mean exactly by "crash"?
-
Is this like a joke?
-
Not at all. It's not in Randomness ;)
-
What does the z80 do when it crashes?
It depends on how it crashes. I would say it just resets to start at $4000 on page 7F, just like booting. TIOS may have a flag somewhere that gets set every time the OS starts, and if RAM is cleared, the flag is automatically reset, indicating to TIOS that RAM was reset.
-
Ahh. Oops. But now I'm curious, what DOES happen? RAM clear? Calc turns off? Do you just remove the batteries for 15 minutes?
-
Ahh. Oops. But now I'm curious, what DOES happen? RAM clear? Calc turns off? Do you just remove the batteries for 15 minutes?
You usually don't have to keep batteries out, that's only for rare cases.
-
Ahh. Oops. But now I'm curious, what DOES happen? RAM clear? Calc turns off? Do you just remove the batteries for 15 minutes?
You usually don't have to keep batteries out, that's only for rare cases.
Good. Las time my HP-50g crashed, the ON/CANCEL button stopped working, which means I couldn't turn it off without removing the batteries, and unless they were out for 15 minutes, the button stayed stuck.
-
Actually in that case it might be a freeze. When the calculator crashes, the user sees it eventually turn OFF, kinda, then when truning it ON again it says RAM Cleared. Some bad ASM code could cause the calc to freeze like you described and never get to the reset code (or whatever it is), so a battery pull is required.
-
Yeah, for example, don't run di and then halt in z80. That's a freeze that you would have to remove A battery for, to reset it.
-
There's this tutorial that someone wrote on how to deal with crashes. I can't remember where it is, but it was really sophisticated, and went into everything from running out of batteries to using Calcsys. Could someone please post that link?
-
I think he's more interested in what the calc does than how to fix it ;)
-
Yeah he really wants to know what technical stuff does the calc do, such as what ASM code is executed and how the hardware operates.
-
Yeah he really wants to know what technical stuff does the calc do, such as what ASM code is executed and how the hardware operates.
Okay, cool. I couldn't really tell.
-
Here's what I learned from that crash tutorial:
- When the RAM clears (probably because a certain address reads zero), the calculator runs the boot certificate code, which is a bit of code that all calculators have, and cannot be modified. This code tells it to boot the OS. (If you hold down DEL while replacing the battery, it will not boot the OS and will instead accept a new one from link transfer)
- When the OS boots, it goes through your archive and looks for archived variables, putting them into the VAT for access later. (If you hold down CLEAR while replacing the battery, it will skip this step, and it will appear as if there are no variables in archive)
- Once it has gone through your archive, it initializes all of the RAM variables and shows you the RAM Cleared screen.
I don't know much more (much less the super techincal details of all of this) but I know that some people do know. One such person is Benjamin Moody, the person who made The Impossible Game and TI-Boy SE. His app, zStart, can run on RAM clear, which means that all of your defaults are automatically restored after a crash. It works because part of the OS is modified to call that code.
-
When something goes wrong, such as execution on a restricted page, what actually happens?
-
When something goes wrong, such as execution on a restricted page, what actually happens?
I'm not exactly sure. My best guess would be that it simply jumps to $4000 on page 7F. You could try it, I highly doubt it will brick your calc.
-
I'm just curious, for error handling in KnightOS. I'm pretty sure that is what happens.
-
Well, to my knowledge, your code starts executing at $0000 or $0056 (after the boot code jumps to it)
-
There's this tutorial that someone wrote on how to deal with crashes. I can't remember where it is, but it was really sophisticated, and went into everything from running out of batteries to using Calcsys. Could someone please post that link?
That was ClrHome methinks
Now I'm starting to get curious as well...
I'm kind of speculating here, but I'll guess the OS detects something wrong, goes "uh oh", resets the RAM, sets some flag to say "RAM cleared" on reboot and to finish turns off the calc.
idk really tho :P
-
The OS typically doesn't detect something. It literally crashes. ;)
Any unclean start-up will cause the RAM reset sequence.
-
I don't know much more (much less the super techincal details of all of this) but I know that some people do know. One such person is Benjamin Moody, the person who made The Impossible Game and TI-Boy SE. His app, zStart, can run on RAM clear, which means that all of your defaults are automatically restored after a crash. It works because part of the OS is modified to call that code.
Actually, thepenguin77, aka Brian Coventry made the Impossible Game and zStart.
FloppusMaximus, aka Benjamin Moody made Mimas.
And calc84maniac, aka Brendan Fletcher made TI-Boy SE
-
Now the question is why so many people who are insane at Assembly, including Ben Ryves and those previously mentioned, all have names starting with the letter "B."
-
In an asm program the OS is only present when you run a bcall or an interrupt is toggled. When you try to execute code from a bad page, a hardware exception is enabled that resets the cpu. I believe there is a pin on the z80 that triggers a reset when it is set by an external device.
-
Now the question is why so many people who are insane at Assembly, including Ben Ryves and those previously mentioned, all have names starting with the letter "B."
/me was smart and names his calculator bert (No seriously, it's in sharpie on the tape)
-
What happens during a crash? The CPU executes instructions that don't make sense. For example, it places garbage on the stack, jumps into the middle of a routine, and then tries to return. The top entry on the stack is garbage, so it jumps to a random location in memory. If the location is in the 0C000h+ range, the hardware simply resets the CPU. If the top location is 0000h, it reboots. Often, the CPU will start executing data as code, placing the CPU into a random state. It might start overwriting RAM with garbage. Either way, the CPU eventually finds its way into the 0C000h range and resets, or hits the reboot code itself. If the CPU doesn't, you might get a freeze.
-
So the actual crash itself is just hardware, then? The hardware causes a reset when PC is C000h (unless it is in the other memory map mode)?
-
Now the question is why so many people who are insane at Assembly, including Ben Ryves and those previously mentioned, all have names starting with the letter "B."
And Brandon Wilson ... what the? O.o
What happens during a crash? The CPU executes instructions that don't make sense. For example, it places garbage on the stack, jumps into the middle of a routine, and then tries to return. The top entry on the stack is garbage, so it jumps to a random location in memory. If the location is in the 0C000h+ range, the hardware simply resets the CPU. If the top location is 0000h, it reboots. Often, the CPU will start executing data as code, placing the CPU into a random state. It might start overwriting RAM with garbage. Either way, the CPU eventually finds its way into the 0C000h range and resets, or hits the reboot code itself. If the CPU doesn't, you might get a freeze.
Ohh, so that's why it has the $C000+ protection? All crashes must find their way into the fourth bank, or the calc freezes? I guess the 8811-byte limit does have some use after all.
There's this tutorial that someone wrote on how to deal with crashes. I can't remember where it is, but it was really sophisticated, and went into everything from running out of batteries to using Calcsys. Could someone please post that link?
That was ClrHome methinks
I don't think it's too useful for this topic, but in case anyone's wondering, it's here (http://clrhome.co.cc/tutorials/crash/) (or here (http://www.revsoft.org/phpBB3/viewtopic.php?p=21573#p21573) or here (http://ourl.ca/8664/161736) or here (http://www.cemetech.net/forum/viewtopic.php?p=132118#132118) ;D).
-
Naw, the $C000+ limit is for money-sucking purposes. It used to cost money to make apps, and that was the only way to execute more code.
-
Naw, the $C000+ limit is for money-sucking purposes. It used to cost money to make apps, and that was the only way to execute more code.
Lol, funny. I still like the idea about having a flag that gets reset when a ram clear happens to test for ram clears. Although two things:
1) Should this be moved to KOS, or left here as it's not necessarily KOS related.
2) Does this happen if you jump to C000h+?
-
This should stay in this subforum, and I'm still unsure of what actually *happens* when you go past $C000
-
This should stay in this subforum, and I'm still unsure of what actually *happens* when you go past $C000
Well, I just tested it, by jumping into C000, and it immediately crashed, without executing anything. Or so far as I can tell, it did.
-
Sir, I would say that it must go to the boot code. My reasoning for this is that if no OS is present, jumping to 0000 will just cause a rst 38h which will loop into oblivion. The way to test would be to write a jump at 0000 and at 0053 and see which one gets on crashing.
-
How does the calculator even detect that code is running in the "illegal" area? The only explanation that I can think of is that the last two bits on the address bus (the ones that must be on if code above C000 is being executed) are wired into a trigger that causes the processor to jump to the boot code. In other words, the detection is in the hardware itself.
-
How does the calculator even detect that code is running in the "illegal" area? The only explanation that I can think of is that the last two bits on the address bus (the ones that must be on if code above C000 is being executed) are wired into a trigger that causes the processor to jump to the boot code. In other words, the detection is in the hardware itself.
Most likely it is. Remember that we are talking about all of this being in the processor. So the processor knows immediately if the pc is C000h or above.
-
How does the calculator even detect that code is running in the "illegal" area? The only explanation that I can think of is that the last two bits on the address bus (the ones that must be on if code above C000 is being executed) are wired into a trigger that causes the processor to jump to the boot code. In other words, the detection is in the hardware itself.
Most likely it is. Remember that we are talking about all of this being in the processor. So the processor knows immediately if the pc is C000h or above.
Which probably explains why the Z80 processor is actually TI's modified version.
-
How does the calculator even detect that code is running in the "illegal" area? The only explanation that I can think of is that the last two bits on the address bus (the ones that must be on if code above C000 is being executed) are wired into a trigger that causes the processor to jump to the boot code. In other words, the detection is in the hardware itself.
Most likely it is. Remember that we are talking about all of this being in the processor. So the processor knows immediately if the pc is C000h or above.
Which probably explains why the Z80 processor is actually TI's modified version.
Probably.
-
How does the calculator even detect that code is running in the "illegal" area? The only explanation that I can think of is that the last two bits on the address bus (the ones that must be on if code above C000 is being executed) are wired into a trigger that causes the processor to jump to the boot code. In other words, the detection is in the hardware itself.
Most likely it is. Remember that we are talking about all of this being in the processor. So the processor knows immediately if the pc is C000h or above.
Which probably explains why the Z80 processor is actually TI's modified version.
The detection may actually be done outside of the Z80. The memory controller could detect multiple consecutive accesses (which indicates instruction fetches) to a particular memory range and do almost anything it wants at that point.
-
If I had to make a guess, I say it deals with a specific peripheral (meaning a port) that is connected to the hardware and reads PC. That is why there are two memory mapping modes (one allowing execution beyond BFFF).
-
The protection is associated with "physical" memory locations, not with Z80 addresses; it works the same way regardless of the memory mapping ports. If you try (say, on an 83+ SE) writing 80h to port 6 and then jumping to 4000h, that will crash; conversely, writing 1 to port 5 and then jumping to C000h will not crash (assuming there's some valid code there. :P)
As for how it's implemented, it's presumably part of the "glue" circuit that connects the CPU to the memory and other hardware devices; this circuit is part of the ASIC used in newer calculators, but in older calculators, it's a separate gate-array chip. This chip can be thought of as the equivalent of the northbridge and southbridge chips on a PC motherboard.
-
So basically, it's the page, and not where it's mapped to, right?
-
Right. (Technically speaking, in some weird modes, it does depend on the mapping, but you don't need to worry about that, because nobody will ever use those modes.)
-
The idea of checking outside the CPU is actually not a bad guess. I do know that the Apple //e from 1980 used memory locations to reference hardware processes (e.g. you would preform "LoaD Accumulator $C030" to tweak the internal speaker). So, $C000 and beyond could be linked to a reset loop.
-
The >0C000h protection was to prevent people from stealing applications, a point which became void after TI released the freeware keys, and doubly void after Flop did that thing he no longer talks about. Sometimes, crashes don't make their way into the protected zone, and you have to pull a battery.
I'm not sure about how the calculator implements the protection. I tried the following program with Mimas:
BCALL NewLine
LD HL, sStart
BCALL PutS
DI
LD A, $C9 ; ret
LD ($FF80), A
LD ($8000), SP
LD SP,$8080
LD HL,retPoint
PUSH HL
JP $FF80
retPoint:
LD SP,($8000)
LD HL,sEnd
BCALL PutS
EI
RET
sStart:
DB "Start!",0
sEnd:
DB " ... End!",0This should only fetch a single byte from the forbidden zone, but it crashes anyway. So I guess it's not the multiple-access thing.
-
and it's obviously not the pc being in $C000. Maybe it just checks if that higher nibble is C, and crashes if it is.
-
How does the calculator even detect that code is running in the "illegal" area? The only explanation that I can think of is that the last two bits on the address bus (the ones that must be on if code above C000 is being executed) are wired into a trigger that causes the processor to jump to the boot code. In other words, the detection is in the hardware itself.
Most likely it is. Remember that we are talking about all of this being in the processor. So the processor knows immediately if the pc is C000h or above.
The original TI-83+ just had a stock Z84C00 processor. The detection there must have been done by outside hardware, probably checking the address and the M1 signal (which is active only on instruction fetches).
-
Ahh, I didn't know that the Z80 has a signal that's only active on instruction fetch. That would certainly make detecting where the PC is much easier.
-
Ahh. Oops. But now I'm curious, what DOES happen? RAM clear? Calc turns off? Do you just remove the batteries for 15 minutes?
You usually don't have to keep batteries out, that's only for rare cases.
That sometimes happens to me