P2 RAM not cleared on new program load?

potatohead · 2013-03-24 20:31

I just noticed this.

For some reason, I was thinking the P2 would initialize it's RAM when accepting a new program. That doesn't appear to be happening. If this is documented, I missed it clearly.

Right now, I have the texture sample modified to take values from the HUB, and I'm using an instance of the monitor to modify those for some quick, interactive testing. The values are at $2000, which is my typical place to drop them right now. On program load, they are defined in the COG memory as normal, but on the first frame the reads from the HUB insure they never get used.

When I F10 from Pnut.exe while P2 is running, those values persist. When there is a break in the power, they come up zeroes. I just spent some time trying to figure out why something wasn't working, when it was actually working!

'Fetch new texture values from HUB

        setindb    #pixu_
                
        reps  #6, #1    
        setptra base  'which is $2000

        rdlong    INDB++, PTRA++

Rayman · 2013-03-25 05:55

That's actually convienient for this testing, right?
I have to think the real chip wouldn't be like this though.
Seems like that would be a security problem...

Heater. · 2013-03-25 06:23

Interesting.

Normally I would not expect RAM in my machines to be cleared on reset/reload and I would expect RAM to be full of junk at power up.

Seems the Prop I does clear RAM on reset, I have never checked, so the question is who is clearing the RAM?

My bet is is that it's not done by hardware but by the loader or the Spin interpreter when it starts up.

Given that the Prop II has no Spin interpreter on board it would be down to the loader.

For fast boot speed one would not want to be clearing RAM so perhaps Chip left it out on purpose.

ctwardell · 2013-03-25 06:34

Heater. wrote: »

Given that the Prop II has no Sin interpreter on board...

Uh oh, the P2 can't tell right from wrong...

C.W.

Heater. · 2013-03-25 06:56

Ooops, fixed that.

potatohead · 2013-03-25 07:44

Yes, it's handy now that I know about it. @Heater, yes best practice is to assume RAM is garbage and code from there. In practice with the FPGA, at power on RAM is 0, and apparently, unchanged on new program load. Well, as far as I know. Really, I was just working with some longs at $2000 when I saw this behavior. Sent a program in that should not have worked until proper values were populated. Was just lazy and curious at the same time, so I didn't initialize anything. The COG just starts with the graphics code, reading from that RAM right away with no setup. The first thing the program does is fire off a monitor on pins 3 & 5 for interactive access to those values. It works consistently. Power cycle = 0, new program without power cycle = whatever values were there before.

I'll have to put a couple of big pictures in there to see if it's true for the whole RAM area. I suspect it is.

As for the real chip, that's my question too.

cgracey · 2013-03-25 10:25

Here is the last part of the booter program:

'
'
' If loader authenticates, run it
'
		reps	#8,@:cmp		'verify loader hmac signature (z=1 on entry)
		setcog	#0			'ready to relaunch cog0 with loader/shutdown/monitor

		rdlong	data,ptra[-$10]		'get loader hmac signature long
		rdlong	bits,ptra++		'get proper hmac signature long
:cmp	if_z	cmp	data,bits	wz	'compare, z=1 if authenticated

	if_z	coginit	loader_pgm,loader_ptr	'if loader authenticated, relaunch cog0 with loader
'
'
' Authentication failed, hide fuses and clear memory
'
		reps	#$20000/16,#1		'ready to clear all memory
		cogid	monitor_pgm	nr	'hide fuses (set bit 10)
		wrquad	ptra++			'clear 16 bytes at a time (quad=0)
'
'
' If key <> 0, shut down - else, start monitor
'
		or	fuses+0,fuses+1	wz	'check if 128-bit key = 0
	if_z	or	fuses+2,fuses+3	wz

	if_nz	mov	monitor_pgm,#$008	'if key <> 0, set shutdown (overwrites fuse data in cog regs)

		coginit	monitor_pgm,monitor_ptr	'relaunch cog0 with shutdown or monitor

Here is what it does, in order:

- If the loader authenticated, run it.

- If authentication failed, hide the fuses and clear the memory.

- If the key is not 0, shut down (with memory cleared); else, run the monitor.

Rayman · 2013-03-25 11:49

interesting.... looks like the clearing of RAM is something that we'll have to keep in mind then...
I guess means that the emulator is behaving the same way as the real silicon will...

potatohead · 2013-03-25 12:20

I did read through the booter. And it made sense. I somehow thought there was a reset on new program load. Probably me confusing P1. (And it is awesome to have that to read Chip)

So the cool thing is we can now have big data in upper RAM and only upload program code deltas! Short cycles. And if we want to "hot swap" a cog or some data, do it via monitor. Honestly, this all has a very Apple 2 kind of feel to it. It was common to BLOAD various bits and pieces to work with, writing out a finished product or data set when work is done. Nice to know we have those options now.

I have not yet looked at the external RAM... Is it likely to work in a similar way, or would the need to refresh get in the way?

P2 RAM not cleared on new program load?

Comments