mos6507's Blog - Chimera API

[RSS Bot]

In recent discussions with Delicon we started to revisit the Chimera API I found the hotspot memory map we came up with to be somewhat lacking. Really the big problem is there are too many things for Chimera to do and not enough addresses in the last page of ROM(RAM) to hold them. The most efficient way to handle things is via an instruction language. The VCS would push a stream of bytes into an instruction hotspot. Either the length of the instruction would be encoded in the message, in which case Chimera would know when to start executing, or there would be a secondary hotspot to tell Chimera to parse the message and go. There would also be one or more status and output hotspots so the VCS would know when the function has been completed or pick up the results (if any).

 

I haven't really thought too much about the structure of this language and would welcome some brainstorming.

 

This is about as far as I've gone:

 

The first byte could represent the ID of the function. 256 possible functions are probably more than adequate. These would be like "slots". Most functions would be built into the firmware and never change. The rest would be "slots" that you can allocate in your game. The game loads up a portion of ARM memory and registers it as a slot. The end result would be similar to doing USR calls in BASIC. You're pushing the function name and parameters onto a virtual stack.

 

For instance, let's say you wanted to plot a point on a queue-based bitmap. The ID for a plot command might be $10.

LDA #$10; plot function
STA CHIMERA_INSTRUCTION
LDA #19; X coordinate
STA CHIMERA_INSTRUCTION
LDA #100; Y coordinate
STA CHIMERA_INSTRUCTION

STA CHIMERA_EXECUTE; strobe execute hotspot

 

At this point, the code can continue on in in true parallel with the ARM. However, if you want to tell the ARM to do anything new, you should first wait for the last function to finish:

 

.execution_wait
LDA CHIMERA_EXECUTE_STATUS
BNE .execution_wait

 

It's a pretty common-sensical way to do it, I think. By using magic writes, the amount of time required to tell the ARM what to do won't be that oppressive.

 

Another way of sharing memory would be to preallocate part of SRAM "game state" as shared between the ARM and the VCS. Instead of copying data back and forth, the ARM function(s) and the VCS can just look to that area. That would be either hardcoded or set through some global variable someplace, or on each function call (ala passing a parameter by reference). So let's say you wanted to task the ARM with the responsibility of populating queues related to sprite multiplexing. The X/Y and animation frame information for each sprite could be laid out in VCS memory according to a strict structure. The VCS modifies the part it's responsible for, then just tells the ARM to process the rest. The ARM then outputs strips of register values for the kernel, whatever is required to scan out the two sprites for that particular frame with a minimal amount of flicker.

 

I really don't know much about coprocessors communications so maybe those who have had experience with them could weigh in here.

 

http://www.atariage.com/forums/index.php?a...;showentry=3916