TI99/4a OS versions

[wolhess]

23 hours ago, senior_falcon said:

Let's follow that up with another test. Save this program as LOAD

10 CALL INIT::CALL LOAD(-31787,0)

See if that tames this beast.

@senior_falcon 

 

Hi Harry, for my problem this did the trick! I run the program above as LOAD and then I run XB 2.9 on my F18a console. I get the normal XB prompt. I can EDIT, LIST, SAVE, OLD in a normal way.

 

You are awesome, I put the line in my LOAD for the XB program I want to run and now I can work completely normal.

 

Thank You very much!

[senior_falcon]

Here is a question for the hardware guys.

When you first turn on a TI99, what is the memory state. Is everything set to zero, or is it indeterminate, with possible values other than zero.

In particular, videofx is seeing a value of >0F at >83D5. As far as I know, nothing in XB or the console ever writes to that memory location. Is it possible that a normal powerup could lead to that value being there.

Edited June 20, 2022 by senior_falcon

[+mizapf]

I remember that the 32K RAM card is initially set to FF00 (or 00FF?), i.e. FF and 00 alternating. This was the reason why some programs (like TurboPasc'99) stopped working once I replaced the card with the internal 16bit 32K RAM (which starts with 0000 at all positions). I could prove that by initializing the card with that pattern in MAME.

 

Normally, all memory cells should be empty at the start; maybe it is an effect of the DRAM architecture that every second byte is FF initially.

 

Since there is no memory initialization, so the memory cells keep their power-on value, you should be able to prove that with a CALL PEEK(-10000,A,B):: PRINT A;B in Extended Basic.

[Tursi]

It is an artifact of the DRAM, yeah. There's no initialization code and nothing in the hardware forces a fixed value. RAM usually comes up with 0 bits or 1 bits. It's not clear to me why the 32k card provides such a repeatable pattern of both, but it does seem to! But you can't count on it.

 

[senior_falcon]

15 hours ago, Tursi said:

It is an artifact of the DRAM, yeah. There's no initialization code and nothing in the hardware forces a fixed value. RAM usually comes up with 0 bits or 1 bits. It's not clear to me why the 32k card provides such a repeatable pattern of both, but it does seem to! But you can't count on it.

 

It looks like it is totally unpredictable. My console at home starts up with a value of 244 or F4 in >83D5.

I will just reset it to zero and that should fix any problems with G.E.M.

[Tursi]

3 hours ago, senior_falcon said:

It looks like it is totally unpredictable. My console at home starts up with a value of 244 or F4 in >83D5.

I will just reset it to zero and that should fix any problems with G.E.M.

Yes. You can't count on power on values anyway. It's a home computer, nothing says you're the first app to run since powerup.

 

[apersson850]

On the other hand, you should never count on the content of memory you haven't set up under your own control.

[+OLD CS1]

1 hour ago, apersson850 said:

On the other hand, you should never count on the content of memory you haven't set up under your own control.

Says the guy who never tried to claim memory used by a network card driver to sniff information

[apersson850]

Rather "says the guy who tries to make robust software, which will work under all conditions".

[+mizapf]

I once wondered whether (in PC systems) memory page frames could reveal secret information when they are exchanged during memory paging. Imagine that one process A uses a memory page P to store name and password, the page being mounted in a page frame F. Another process B claims a new page, page P gets paged out to the hard drive, and the new page Q is mounted in the page frame F again. Then B could be able to read the memory contents of A with name/password.

 

I later saw that this is actually considered; the kernel zeros out the newly allocated page.

[Tursi]

On 6/21/2022 at 4:30 PM, apersson850 said:

On the other hand, you should never count on the content of memory you haven't set up under your own control.

That's the same hand.

 

[Tursi]

19 hours ago, mizapf said:

I once wondered whether (in PC systems) memory page frames could reveal secret information when they are exchanged during memory paging. Imagine that one process A uses a memory page P to store name and password, the page being mounted in a page frame F. Another process B claims a new page, page P gets paged out to the hard drive, and the new page Q is mounted in the page frame F again. Then B could be able to read the memory contents of A with name/password.

 

I later saw that this is actually considered; the kernel zeros out the newly allocated page.

Yep, but not until the exploits that took advantage of it.

 

[RXB]

On 6/21/2022 at 2:51 PM, Tursi said:

Yes. You can't count on power on values anyway. It's a home computer, nothing says you're the first app to run since powerup.

 

Recently Tursi showed me a problem with >833C that if not zero would affect the GPL DSR in REA switching to RXB or back and would lock up.

I had to put DCLR @>833C on boot of RXB and REA to stop this lock up of GPL DSR as it created a locked up STACK.

[atrax27407]

New update?