HomeForumsWhat's newResources 
 
 
Ram cart + Slave cpu
ClaudioSH2 - Sep 27, 2004
  ClaudioSH2 Sep 27, 2004
I am starting to program in Saturn and wanted to know if it is possible with the use of the ram cartridge to dedicate it`s ram for slave cpu and master cpu to be with all the main ram so that slave cpu does not have to wait master cpu when both need to access the ram.

 antime Sep 28, 2004
Both CPUs access the outside world through the same system bus, so your scheme wouldn't help. If you're having bus contention issues switching one of the CPUs cache to RAM (partly or completely) is the way to go.

 Runik Sep 28, 2004
Don't forget that you can't use executable code in the RAM cart ...

 antime Sep 28, 2004
Correct me if I'm wrong, but I thought that was more a "shouldn't" (due to reliability issues) than "can't".

 Runik Sep 28, 2004
IIRC the doc clearly says that you mustn't do it.

There's nothing stated regarding what would happend if you try to do so ... but I never tried myself

 ExCyber Sep 28, 2004
I don't know where I saw this, but I'm pretty sure that prohibition is only there because it was seen as a potential security hole. That explains why it says not to do it even if you transfer the code back to internal RAM first. Still, you have to wonder why Sega prohibited developers from doing this when the BIOS itself runs code from a cartridge...

 Runik Sep 28, 2004

  
	
	

		
		

			Originally posted by ExCyber@Sep 28, 2004 @ 03:07 PM



 the BIOS itself runs code from a cartridge...


Are you sure about that ? I never noticed such a thing ...

 antime Sep 28, 2004
The security hole comment is only in the ROM cart document, I believe the prohibition on storing code in RAM carts is because they can be flaky and corrupt the code.

 ExCyber Sep 28, 2004

  
	
	

		
		

			Are you sure about that ? I never noticed such a thing ...


I notice it every time I turn on my Saturn with the Action Replay cart in it.


  
	
	

		
		

			The security hole comment is only in the ROM cart document, I believe the prohibition on storing code in RAM carts is because they can be flaky and corrupt the code.


That could be, but I think fundamentally any security issue is in the usage of the bus, not in what type of memory is expected to be attached to it, so I still think that's the more likely explanation. A corrupt data structure (e.g. a level map or a palette) could be about as much of a hazard to the gameplay experience as corrupt code, wouldn't allow an attacker to take over the system as easily. To be honest I don't see what it is particularly that they were afraid of, but I also don't see what could be a threat for ROM cart usage and not RAM cart usage - if you're assuming an attacker the game can't assume that a particular type of memory is connected in the first place.

 CyberWarriorX Sep 28, 2004

  
	
	

		
		

			Originally posted by ExCyber@Sep 27, 2004 @ 08:15 PM



I notice it every time I turn on my Saturn with the Action Replay cart in it.


I'm not sure about the other versions of the bios, but on the jap 1.01 the actual code starts at 0x00001A62. It basically does an ip check at 0x22000000 then if all is good, it executes the code pointed to by the ip.

Cyber Warrior X

 Runik Sep 28, 2004

  
	
	

		
		

			Originally posted by ExCyber@Sep 28, 2004 @ 06:15 PM



I notice it every time I turn on my Saturn with the Action Replay cart in it.


Oh, I see what you mean

This code is in the RAM cart, but it's not executed in it : it's copied to the saturn memory before being executed ...

I thought that this guy wanted to execute code in the RAM cart memory ...