PreOs - Page 1

Will PreOS .70 work with the ti 89 titanium?

PpHd is still working on Titanium support. It should be compatible.

Yes, an alpha release of Preos 0.70 works on titanium. Still some bugs.

Yes, it is true.

FYI, Kevin Kofler tried to make a kernel working on TI-89Titanium it's called Iceberg.
You can use it, until PpHd release the last PreOs.

Why "tried"? I'm not aware of any problems with it...

Just try ON+ESC in an AMS dialog, or try to run SMA.

Well, I'll look into those issues. (They are not show-stoppers though, they're just hot resets and one game not working...) But it would have been nice if you had reported them by yourself...
Speaking of reporting issues: are you aware of my changes to support the current ttstart-titanium in the latest Iceberg? (I actually save the screen as opposed to redrawing it.)

I haven't reported them to you since my research are not finished.
I am aware of what you did to support ttstart-titanium but as I have said before, ttstart doesn't support Kernel Programs, and this is juste one more bug in ttstart, not in the kernel.

It's not a bug, it's a requirement. We are looking into lifting this though (Lionel likes using HSR which does more or less the same as PreOs, and I'll try using the method used in TitaniK for ttstart). But still, for the moment, the Iceberg patch was the most sensible thing to do IMHO.

It IS a bug.

No, it is not a bug, it is a limitation imposed by TI's execution protection. But as I said, a better solution is in the works.

The crash protection issue is a typical case of a program being too robust. The call to:
jsr ($0).l ; Reset PortRestore / SetCurrentClip / ScreenClear() / FontSetSys + Some flags
points to an invalid address (the hack to get it doesn't work with AMS 3), which makes it crash itself. The resulting crash is then intercepted again, and the recursive crash protection handles the crash. However, that way, some initialization code is skipped, which causes it to mess up.

	move.l	12+6(a1),(a0)		; Read the 2nd function.
	move.l	12+6+6(a1),6(a0)	; Read the 3rd function.

has to be replaced with:

	move.l	22(a1),(a0)		; Read the 2nd function.
	move.l	28(a1),6(a0)	; Read the 3rd function.

on AMS 3.

I'll leave it to you to select the correct values at runtime, I'll just hardcode the AMS 3 values in Iceberg.

But it still doesn't work when I fix that.

I just wasn't calling the correct functions. (I was calling the 1st and 2nd instead of 2nd and 3rd.) This fixes the issue:

	move.l	28(a1),(a0)		; Read the 2nd function. 
	move.l	34(a1),6(a0)	; Read the 3rd function.

Now I'll look into the SMA issue.

kernel::ExtractFromPack fails. Tracing further.

kernel::LibsExec fails. Tracing further.
Well, duh... It fails because I didn't send the decompressing library. This definitely needs an error message!

Now I am getting to the actual error. There is a Protected Memory Violation and I don't understand what is triggering it... Are you sure this happens on a real Titanium as well?

Oh, now I see what's triggering it: you must not use the alpha-lock hack (Heap+constant) you are using! That's an AMS 1 only hack, and you will write to random data on AMS 2 that way. You can be glad that Iceberg caught that one. This is an SMA or genlib bug, please fix the offending code.

(I checked and found no such code in genlib, so this must be an SMA bug.)

>The crash protection issue is a typical case of a program being too robust.
Yes

>This definitely needs an error message!
Yes

>you must not use the alpha-lock hack (Heap+constant) you are using!
Yes

Well, since SMA is certainly not the only buggy program trying to write to MaxHandles+$24+$11, I have added a workaround to the RAM_CALL relocation code:

;Catch the alpha-lock hack and have the program write its crap to a harmless LCD address instead...
				moveq.l	#-$16+$24+$11,d0
				tst.b	d7
				beq.s	\reloc
					add.w	#$fc,d0
\reloc
				tst.w	d2			; Test bit 15 (Word / Long Word flag)
				blt.s	\word
					cmp.w	#$11,d2		; is this Heap?
					bne.s	\noalpha1
					move.w	#$fc,d4
					cmp.l	0(a5,d3.l),d0
					bne.s	\noalpha1
					move.w	#$4c00+29-(-$16+$24+$11),d4
\noalpha1
					add.l	d4,0(a5,d3.l)	; Reloc a Long Word : add d4.l to the address
					bra.s	\loopRAM
\word					cmp.w	#$11,d2		; is this Heap?
					bne.s	\noalpha2
					move.w	#$fc,d4
					cmp.w	0(a5,d3.l),d0
					bne.s	\noalpha2
					move.w	#$4c00+29-(-$16+$24+$11),d4
\noalpha2
					add.w	d4,0(a5,d3.l)	; Reloc a word : add d4.w to the address
					bra.s	\loopRAM
\loopRAMend	dbra	d5,fonctionRAM				; Continue for all the imported ramcalls

Note that my code doesn't try to actually enable alpha-lock. (Alpha-lock sucks anyway. )

Warning: Don't use this hack as is, it is currently broken for unrelocation (I need to negate d4 in that case). I think I'll sleep over it to decide whether to fix the hack or to revert it.

Kevin> How do you do your tests ? Do you own a TI-89 Titanium ?

Ask ExtendeD...

I decided to release Iceberg 0.94 with the fix for the anticrash problem only.

There is also a second problem with SMA: the loading of the monster file. There is an adda.l $40000,an for h220xTSR compatibility. This needs to be conditionalized on the hardware version in some way.

And GhostBuster doesn't fix that ?

Sure, but running GhostBuster on an archive-pack-compressed program is not a trivial task (you have to zunpack("sma") before, and even before that, to rename the compressed pack to a different name so you can unpack the file with the same name), and if we already fix the first problem, we can also fix the second one.

I have patched SMA (with PpHd's permission) pending an official update from PpHd: http://p080.ezboard.com/ftichessteamhqfrm10.showMessageRange?topicID=137.topic&start=36&stop=36.

Next problem: fonts. There are no longer all 3 fonts in the boot code, only the medium one, so programs using the old definitions for font_small and font_large (and there are lots of them ) break. We need to find an acceptable solution quickly. (And I realize we have different schedules. I'm trying to release things quickly so the Titanium users don't have to wait for programs to work on their calculator (and have chosen to base Iceberg on a known stable, but old and not completely bugfree, codebase to save time: PreOs 0.67), whereas PpHd wants to take his time to prepare a stable and as bugfree as possible PreOs 0.70 release.)

Yes, another problem to solve.

A straight forward hack to detect 0x800 and 0xe00 offsets won't work because of this <SARCASM>very clever</SARCASM> code in Solar: movea.l #font_medium,%a3; move.w #7,%d7; tst.b %d2; bne.w +16; move.w #9,%d7; adda.w #0xe00,%a3; bra.w +20; cmpi.b #2,%d2; bne.w +12; move.w #5,%d7; adda.w #0x801,%a3; .... You can see from very far that this was written by an incompetent programmer (move.w #7,%d7, bne.w +16 etc. WTF... I even found a loop of move.b #0,(%a0)+. ), so these hacks are hardly a surprise, but still, why he didn't use the documented macros (which would be way easier to detect) is beyond me, especially given how the rest of the code is very far from being optimal anyway.