Omnimaga
Calculator Community => Discontinued => Major Community Projects => KnightOS => Topic started by: SirCmpwn on January 12, 2011, 04:56:02 pm
-
Hello,
I'm having some issues with KnightOS. As of right now, it runs fine on the TI-83+ (SE). However, on the TI-84+ (SE), it crashes. I believe this to be caused by improper USB interrupt handling. KnightOS runs without incident if interrupts are turned on, but as soon as interrupts (and multitasking) are turned on, it will crash. Here is my USB interrupt code:
HandleUSBEvents:
ld a, (ModelID)
cp 2 ; Models 2 and up have USB.
jp c, ResumeInterrupt ; Leave if we don't have the hardware (also tested with NC)
in a, (55h) ; Read USB status
bit 0, a
jr z, UnknownUSBEvent
bit 2, a
jr z, USBLineInterrupt
bit 4, a
jp z, USBProtocolInterrupt
jp ResumeInterrupt
UnknownUSBEvent:
xor a
out (5Bh), a ; Unknown event, WikiTI claims you should zero port 5B to acknowledge
jp ResumeInterrupt
USBLineInterrupt:
in a, (56h)
ld c, a
cpl ; xor 0FFh
ld b, a
in a, (57h)
ld d, a
and b
out (57h), a
ld a, d
out (57h), a ; Ack the interrupt without doing anything special
jp ResumeInterrupt
USBProtocolInterrupt:
in a, (86h)
ld c, a
in a, (84h)
ld b, a
in a, (85h)
in a, (83h)
in a, (82h) ; Just ack and leave, and hope that it doesn't get angry
jp ResumeInterrupt
However, if you don't notice anything wrong with this, it may not be the problem. Also suspect is the code that sets up the memory mappings on boot:
ld a, 1 ; Set flash page 1 in bank 1.
out (6), a
in a, (2) ;get calc version
rlca ;Roll bit 7 into carry.
ld a, 41h ; Set ram page 1 in bank 2.
jr nc, LowerModel ; C vs NC?
HigherModel:
out (5),a
ld a,81h
out (7),a
jr Return
LowerModel:
out (6), a
out (7),a
Return:
retI'd put my money on USB interrupts, but that's just me. You are now looking at the only model-dependent code in the whole OS, so this is pretty much where the problem has to lie. Is there any hardware I may not have initialized properly, or something I may have left out that is required on the TI-84+ (SE)?
-
Could it be that you are putting RAM page 1 into both $8000-$BFFF and $C000-$FFFF? You'd probably want to put RAM page 0 in $C000-$FFFF to have the same mapping as TI-83+
-
Ah, that could present an issue. I want an executable page in both, though, is that possible? Compatibility with calculators missing RAM is vital.
-
Paging the single extra RAM page in as page 3 rather than page 2 would allow you to execute stuff on it. :)
-
Yeah, you can put an odd-numbered page in (usually people use 3, but that's due to Omnicalc using pages 4-7, which you don't have to worry about for KOS)
-
I'm sorry, but I have some trouble with these ports. Could someone amend the code above to do that? Thanks!
-
If I understand correctly you just need to ld a with $83 rather than $81
-
Alright, I'll give it a shot.
-
No, that's the $8000-$BFFF region. What you need to do is output 3 to port 5 instead of $40
Edit:
Instead of $41, I meant >_>
-
On which model?
-
For the "higher models"
However, you made an optimization of reusing a which means you'll have to ld a another time
-
Right, I did. I'm about to test it.
-
Good luck Sir! Hope it works! :D
-
Me too. I've been trying to fix this issue for weeks now.
EDIT
I tried it to no avail. The new code:
; Initializes the kfs driver
FSInit:
ld a, 1 ; Set flash page 1 in bank 1.
out (6), a
in a, (2) ;get calc version
rlca ;Roll bit 7 into carry.
ld a, 41h ; Set ram page 1 in bank 2.
jr nc, LowerModel ; C vs NC?
HigherModel:
ld a, 3
out (5),a
ld a,81h
out (7),a
jr Return
LowerModel:
out (6), a
out (7),a
Return:
ret
It still doesn't work :( Another strange behavior is that when it turns off, it doesn't come back. It just says "waiting, please install OS now."
EDIT: I found the problem. It was pretty stupid. You notice that the second group of code on my first post appears to be called? It is. You probably shouldn't muck about with memory while the stack needs preserving. It runs fine on all hardware now.
-
For the record, this part of the code doesn't make sense:
ld a, (ModelID)
cp 2 ; Models 2 and up have USB.
jp c, ResumeInterrupt ; Leave if we don't have the hardware (also tested with NC)
This code doesn't make sense in my brain. Say the ModelID is 4. cp 2 would set the carry flag, right? So jp c would jump back for all the models with USB and try and run on those without it.
For that protocol interrupt, if it wants to send you some data over the control pipe, it might not like you ignoring it. For now, I think you might be able to just stall the ports and that will prevent it from connecting at all, but it should keep the driver working.
-
All USB interrupts are disabled at the moment. As for the ModelID, I can look into fixing that.
-
I think I remember a while ago we had a version of this that worked, but somehow it was lost. I can't remember what it was that was different though. (FSInit btw)
-
Glad it works! All i have is an 84+ :)
-
Seems, I doubt that it ever worked properly, it was probably just luck that the last bank didn't change during early testing.
-
For the record, this part of the code doesn't make sense:
ld a, (ModelID)
cp 2 ; Models 2 and up have USB.
jp c, ResumeInterrupt ; Leave if we don't have the hardware (also tested with NC)
This code doesn't make sense in my brain. Say the ModelID is 4. cp 2 would set the carry flag, right? So jp c would jump back for all the models with USB and try and run on those without it.
For that protocol interrupt, if it wants to send you some data over the control pipe, it might not like you ignoring it. For now, I think you might be able to just stall the ports and that will prevent it from connecting at all, but it should keep the driver working.
No, 4 minus 2 does not carry. (Technically the highest model number is 3 though, I think)
-
For the record, this part of the code doesn't make sense:
ld a, (ModelID)
cp 2 ; Models 2 and up have USB.
jp c, ResumeInterrupt ; Leave if we don't have the hardware (also tested with NC)
This code doesn't make sense in my brain. Say the ModelID is 4. cp 2 would set the carry flag, right? So jp c would jump back for all the models with USB and try and run on those without it.
For that protocol interrupt, if it wants to send you some data over the control pipe, it might not like you ignoring it. For now, I think you might be able to just stall the ports and that will prevent it from connecting at all, but it should keep the driver working.
No, 4 minus 2 does not carry. (Technically the highest model number is 3 though, I think)
Okay, then what is it, p? z would be equal, and I'm pretty sure m is negative. I guess you could just use S.
-
I double checked this. C is set on greater than or equal to for a CP instruction. And the model IDs are set at boot time, and are as follows:
0: TI-83+
1: TI-83+ SE
2: TI-84+
3: TI-84+ SE
This doesn't really matter though, because I will eventually change the way the interrupt detects the model. It's way too unsecure when a program can simply change a single number and completely screw up a TI-83+ (SE) or disable USB access on a TI-84+ (SE).
-
Sorry to hear about compatibility issues with the 84+. I hope you can resolve it without too much hassle. X.x
-
Yeah, the compatability was fixed, as I mentioned in an earlier post. My Ti-84+ BE is currently running KnightOS.
-
Oh it does now? Nice! I didn't have time to read all posts due to being busy and for some reasons this board alone seems to get new posts every minute or so sometimes.
-
I double checked this. C is set on greater than or equal to for a CP instruction. And the model IDs are set at boot time, and are as follows:
0: TI-83+
1: TI-83+ SE
2: TI-84+
3: TI-84+ SE
This doesn't really matter though, because I will eventually change the way the interrupt detects the model. It's way too unsecure when a program can simply change a single number and completely screw up a TI-83+ (SE) or disable USB access on a TI-84+ (SE).
yeah, but how are you going to make it more secure? Maybe have a section that only KOS can edit.
Speaking of which, will KOS mess with the certificate at all? I'm not doubting your coding skills, I'm just really afraid that my calculator would be bricked.
-
KOS will never have the certificate page swapped in, ever.
Also, I'll make it more secure by just running the same hardware test I use to set that byte at boot-time from in the interrupt.
-
KOS will never have the certificate page swapped in, ever.
Also, I'll make it more secure by just running the same hardware test I use to set that byte at boot-time from in the interrupt.
sweet. I was thinking cryptography next. j/k Also, with wikiTI down, I can't test all this stuff, but I have a pretty good idea how USB works atm.
-
Yay!
Really glad you figured it out x.x I think it was something like what you did that solved it last time.
graphmastur, what do you mean WikiTI is down? It's been up for me.
-
Yay!
Really glad you figured it out x.x I think it was something like what you did that solved it last time.
graphmastur, what do you mean WikiTI is down? It's been up for me.
It was down for a while, but is now back up.
-
BrandonW website was hit by a DDoS attack. It's all fixed since a few days now.
-
What's a DDoS attack?
-
Distributed Denial of Service. Its when a large number of computers send thousands of html requests to a web server in order to bring it down.
-
Stupid Black hats......
I blame TI :P
-
HOLY NECROPOST BATMAN! O.O
But seriously I doubt it's TI, I am sure it's a group of PS3 fans who got angry because BrandonW didn't make PS3jb compatible with every existing firmwares or because BrandonW refused to answer a question that was already answered in the FAQ
-
Lol, that's a nice way of showing thanks. Why they can't handle installing an older firmware, I'll never understand. They did it with the PSP just fine.