Jed;

	I got your request.  I do not understand why you need a Steel Talons
program to test on Multisync II.  It appears that Steel talons will never use
Multisync II.  If you would still like to have a Steel talons version as an
additional test of Multisync II, let me know today.  I found at least two
places where the CONTROL register at C00000B0 is written to.  Is this the
correct address for the GSP 34010?

						Ed

As per your memo of 7 November 1991, please confirm that Steel Talons will 
never use MultiSync II.

Finding DRAMs for the MSP is becoming a lot of work. Since Steel Talons is
the only game using the MSP I will just take it out. 


Jed

Will Multi-sync II be used in Steel Talons?
It's tough to predict the future. Here is some data and some conclusions
on Steel Talons:

1) Recent wisdom from Exec Committee: 
   "Standard Distribution channel  has done all it can; no more orders.
2) We have 175 Steel Talons in inventory.
3) We have 200, possibly 400 Steel Talons PCBs purchased in inventory.
4) We may build some Steel Talons uprights; no testing yet; may begin
    testing as early as 11/18/91.

I feel confident saying we will not build anymore sitdown Steel Talons. I
speculate that as many as 800 Steel Talons uprights may be released for
production in January 1992 (quantity is based on what they did with Road Riot
upright). Since we have an inventory of 200-400 Multi-syncs, it is likely we
will begin such a build with Multi-syncs; then once the ball is rolling that
way, it is likely that Mfg. will want to complete the build with Multi-syncs
and not switch to Multi-sync II. It's hard to ask Mfg. what they would do until
they have a time and quantity for the Upright Talons build and can try to
procure parts for more Multi-syncs. Given the weak state of the market, 
we may end up with a release of Upright Steel Talons that matches our
inventory of Multi-syncs, powersupplies, joysticks etc. In that case, we
would not use multi-sync II  on Upright Steel Talons at all.

In summary, the probability of using Multi-sync II on Steel Talons is small,
maybe 1 in 10. This would go up if Upright Steel Talons tests extremely
well, the market improves and  Mfg. has difficulty procuring Multi-sync parts. 

The reason for doing MultiSync II is that the 64Kx4 VRAMs and 64Kx4 DRAMs
are becoming increasingly difficult (like impossible) to get.

Don't plan on building more MultiSyncs.

This latest flurry of memos got started when I asked Logg for some programming
support so I could verify that one of the new circuits works with Steel Talons.

After my experience with Hitachi VRAMs I see no reason to believe that anything
works unless I see it.

Unless I am otherwise ordered, I am continuing to work on MultiSync II. It will
probably be needed for Street Driver. It will probably be the only hardware
available to the Training Group until they can do their own.

MultiSync II also has the built-in option to use EPROM, Flash EPROM, or RAM 
on-board. This makes possible a very fast download from a PC with a PCLINK
card. 

MultiSync II is not the next generation hardware. 


Jed

From:	KIM::ROTBERG      "Professor of Gonzo"  8-NOV-1991 09:15:01.69
To:	LOGG
CC:	
Subj:	Control in GSPCODE

Ed,

I did a cursory examination of the code, and there are 5 modules that
seem to set the CONTROL location.  These are BLITROUT.C, PICBLIT.C,
COL.ASM, GRCMDS.ASM, and DPOLY.ASM.  Ein most cases they either clear
a register and store it to CONTROL, or use the combination of some
#defines/EQUs to store an immediate value.  NONE of these seem to set
the low bit to anything other than zero.

I'm not exactly sure what this means, but I would be loathe to make
changes to these modules bindly.  It looks to me like we need to talk
with Max or find some other solution...

	- Ed -

Rick;

	I am going to make the assumption that we may need to use Multisync II.

	I have made the changes in the 68000 code for the new CAS/RAS mode but
there seem to be at least five places according to Ed Rotberg in the Max's GSP
code where he sets this register.  Can you get Max in to make these changes or
should we attempt to change the code ourselves?  If we do the latter, this will
be a case of if it doesn't work, we will be at a loss of how to debug it.  We
have a no tools to debug the 34010 code in the GSP!

Jed;

	We should have EPROMs for you on Monday.  We have no way of knowing
if we changed all the locations.  Ed Rotberg will bring them over.

	I will return on Tuesday.

ok.

Jed

Jed;

	I left the 6 EPROMs for Steel Talons Multisync on your desk.
Let me know if these work or not.

I have received EPROMs from Ed Logg that have the GSP produce CAS-Before-RAS
Refresh. 

The game runs but produces pixel errors on some screens. The pixel errors are
different from the ones produced by the Hitachi VRAMs and are on different 
screens.

The error count on a game that was run overnight was Zero in all categories. 

I have measured the signals coming from the GAL and they look very good.
I have tried a bipolar PAL but there was no difference. (PALs have a higher
noise immunity than GALs.)

Freezing the 68010 makes the pixel errors disappear. Since the 68010 tells the
GSP when to change buffers we may be looking at buffers that are out of order.

This board, with the GAL, when loaded with the original program, runs 
perfectly with no pixel errors. This leads me to believe that the problem
is not being caused by the new GAL circuit.

I believe the pixel errors may be due to an error introduced when the Eds were
changing GSP code.

It would be nice to have the GSP Code examined and corrected. If this is not
possible at this time, I will assume the problem is with the GSP code and
will proceed with the board. (I am running out of time to do this board.) 

Also, it turns out that all of the Game Code we have released has the 
GSP generate a refresh cycle every 5 us. It only needs to to produce one 
every 10 us. (Self-Test has it generate refresh every 10 us.)

This is set in the CONTROL Register, bits d3 and d4. They are both currently 
being set to zero, presumably by the instructions setting the other bits in 
the register that control other functions. d3 should be set to '1' and d4 
should be set to '0'. (d0 is LSB.)


Jed

	I have asked Ed Rotberg to add the 10us refresh rate by changing the
D3 bit to 1.  

	Ed and I do not believe our changes cause the pixel errors we see on
the screen.  Our changes would either kill the GSP/RAM if it failed.  Since
the pixel errors occured on Multisync I with different RAMs, and the GSP has
known bugs, and we did not create or modify any original GSP code, we believe
Applied Research should correct the GSP code.

	It is my opinion that the errors we see are due to a RAM/circuit 
failure.

	Since we have been promised support for the Multisync hardware and
firmware, it seems strange to ask us to examine and correct the GSP code.  We
have been more than cooperative in changing the GSP code for the new RAMs when
it is the responsibility of Applied Research to do so.  We will gladly supply
you with the source code if you wish to do your own examination.