Note that it's only random because the calculator does not contain any hardware to put a byte on the data bus when it generates an interrupt request. As such, the value will typically be approximately what was on the data bus immediately before the interrupt request, though this varies from calculator to calculator (hence the contradictory information in the 28 days guide - that will work on some calculators, but for safety assume the value is entirely random). Z80 systems that are designed with IM 2 in mind will have each interrupting device place an appropriate interrupt vector address on the data bus when interrupting.
Edit: Kerm beat me to it, evidently. It couldn't be used as an effective random number generator as there are still patterns to its randomness (and on some devices it may not be random at all). If you'd like to test the randomness of your calculator's hardware, please see
IM 2 randomness on MaxCoderz.
If the calculator know where its jumping to, then it must have a way of returning this value, correct? If you can trigger IM 2, then can't you get the address it has selected, forward from your choice of 'i', then subtract the true address from .dw 'i' , 00. Use the difference as your random seed.
Sorry about the double post, but this is newsworthy in this topic. I have just posted Unit 1 of the tutorial "the z80 Files" on Google Docs. The link is below. Anyone with the link can edit it, so please edit away. I actually would like it to be lengthened a bit. Comments can be left there as well, so as not to draw this topic (excuse the upcoming grammar-fail) off-topic.
https://docs.google.com/document/d/16kb_uChpEkaDiLcn2bz_FHQMGJtsLLa2MgvrZ9YX5Kk/edit
Why do you say that it should have a way of knowing where it came from? With a call, yes, but it does a jump to what it thinks is the IM2 handler address. I will try to get a chance to check out your draft later.
Kk. Sounds good. Please don't refrain from editing the hell out of it wherever it needs it.
What I was saying is...you know how the 'pc' register indicates the current executing address? Well, if the calculator is reading the IM2 handler address out of a randomized section of memory, it must somewhere catalog the address it's reading from, just like you need to return a pointer to something before you can read from it. Can't you fish out that address, subtract it from the two byte word consisting of high byte 'i' and low byte $00, and then have a random seed?
It pushes 'pc' onto the stack, loads the address from ('i' (concatenate) 'bus') directly into 'pc'. If it didn't do that, then one or more registers would get trashed every time an interrupt triggered.
What code would be used to activate "inverted text" for bcall vPutS? And I'm assuming that, since you are using iy + textFlags, iy must already point to the system flags. What do you load into it?
ACagliano wrote:
What code would be used to activate "inverted text" for bcall vPutS? And I'm assuming that, since you are using iy + textFlags, iy must already point to the system flags. What do you load into it?
You use the set and res instructions:
Code: set textInverse,(iy+textFlags)
...code to display text...
res textInverse,(iy+textFlags)
Ok, that makes sense. But, what do I load into IY ? Or is it already preset?
ACagliano wrote:
Ok, that makes sense. But, what do I load into IY ? Or is it already preset?
iy is set by the OS, and if you don't know what you're doing, you shouldn't touch it. If you have code that cannot enter the OS, since it doesn't use any bcalls and doesn't allow the TI-OS's interrupts to run, then it's safe to use iy, as long as you restore it before anything that could let the OS get control happens. A good rule of thumb for beginners is to just leave it be.
Ok. I had a feeling that IY was preset, but just wanted to be sure.
ACagliano wrote:
Ok. I had a feeling that IY was preset, but just wanted to be sure.
Definitely better to be safe than sorry. And for future reference, here's the equate that iy should stay equal to:
Code: flags EQU 89F0h
It's not really that complicated, just be sure to restore its value before quitting your program/using routines (bcalls) that make use of the flags. Really though it's pretty slow and you can generally just use ix if you want to use an index register for something (like for masked sprites, for example).
Chickendude, I have known the TI-OS interrupt to need iy on occasion, and if it has been switched, terrible things befall the calculator (well, a crash, but you know). Perhaps I just happened to do things that made the interrupt need to overreach, such as triggering silent linking or turning off.
Really? That's interesting to know. I've never had a problem using iy just like ix, though admittedly i've also never touched linking. I guess i very rarely use iy for anything other than storing my own flags and even when i do interrupts are generally either turned off or in mode 2 because i like to play with the shadow registers a lot.
EDIT: Also, speaking of interrupts, i was just thinking that if you aren't using interrupts (im 2) you could maybe use "i" to hold data, though i guess it wouldn't be much faster than a push/pop. I think ld a,i sets/resets the z flag accordingly, too, so maybe you could take advantage of that.
This is a program that install a small routine that runs prior to the system routine part of the time to screw with someone... Is it correct?
Code: ;; TI Calc Prank.wcodeproj
;; main.z80
;;
;; Created by Anthony Cagliano on 8/31/12
#include "ti83plus.inc"
#include "dcs7.inc"
CycleNum .equ saferam1
Start:
di
ld a,0
ld (CycleNum),a
ld a,$99
ld i,a
ld hl,$9900
ld de,$9901
ld bc,256
ld (hl),$7A
ldir
ld hl,InterruptCode
ld de,$7A7A
ld bc,InterruptCodeEnd-InterruptCode
ldir
ld de,saferam1
ld hl,texttodisp
ld bc,texttodispend-texttodisp
ldir
im 2
ei
InterruptCode:
ld a,(CycleNum)
cp 0
jr DelAll
cp 128
jr DispText
jp $0039
DelAll:
bcall(_ClrLCDFull)
jp $0039
DispText:
ld hl,saferam1+1
ld a,0
ld (curCol),a
ld (curRow),a
bcall(_PutS)
jp $0039
InterruptCodeEnd:
texttodisp:
.db "Moron",0
texttodispend:
.end
.END
I recommend you to test programs like this in TI flash debugger.
It looks fine to me
jammasterz wrote:
I recommend you to test programs like this in TI flash debugger.
It looks fine to me
You can also use PindurTI or jsTIfied, as both have very accurate interrupt emulation. Sadly, WabbitEmu's interrupt emulation is inaccurate.
Maybe they're good too, never tried them.
Also i hope you give your guy the opcode of setting the interrupt mode back to 1 so that he can revert the prank.
ACMBP:asm acagliano$ ./compile.sh prank
----------------------------------
Doors CS Assembler/Compiler
Version 2.0L
Written by Kerm Martian
http://www.Cemetech.net
----------------------------------
----- Assembling prank for the TI-83/84 Plus...
./compile.sh: line 9: tasm/zztemp.asm: No such file or directory
./compile.sh: line 15: tasm/zztemp.asm: No such file or directory
Cannot open assembly 'tasm/Brass.exe': No such file or directory.
----- There were errors.
What does this mean?
