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.

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.

Quote from: Compynerd255 on March 25, 2011, 07:01:24 pm

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.

Quote from: graphmastur on March 25, 2011, 08:13:08 pm

Quote from: Compynerd255 on March 25, 2011, 07:01:24 pm

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.

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. )

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.

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 >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.