atari email archive

a collection of messages sent at Atari from 1983 to 1992.

Just when you thought it was safe...

(1 / 1)


	I have implemented a new set of coin routines, which has been
"alpha tested" on Hard Drivin and a few other games. Now the hard part-
making it the "official" set. If you don't give a rodent's posterior about
coin handling, stop now. Ok, for starters, here are the new options:

	Free play (yes/no)
	Discount for continue (yes/no)
	Bonus Threshold (number of coins needed for bonus: 2-9)
	Bonus Award (number of coins added each time threshold passed: 0-3)
	Game cost (1-8 coins)
	Right mech multiplier (aka value, 1-8)
	Left mech multiplier (aka value, 1-8)


	At present there are a few, uh, features that bear changing:

   *	The game program must "know" where the "discount" bit is stored
	and deal with it.

   *	The old kluge of clearing bc and bccnt "at the right time" is
	still needed.

   *	cn_credit still reports (credits * 12), although with game prices
	as high as 8, The multiplier _should_ be 840. On the other hand,
	the table of strings for normalized fractions would get out of
	hand...

   *	MAXCOINS is still 30 (up from 25) which could be a problem for
	operators using five-dollar-bill acceptors and wanting to give
	a bonus for a five, but allowing a $.25 continue...

   *	The usual problems of the hardware guys braiding the coin inputs
	and wanting software to unbraid them.

   *	The current (as I type) version apparently resets the options to
	defaults if a coin comes in before the mainline sets coin_modes
	to the value in the EEPROM. (Yes, I'll fix it, but it's part of
	the problem with the first "feature" above, and I didn't see it
	until I started composing this.)

   *	The current code (descended from System I) doesn't really deal
	with compilers/machines that have non-atomic add-to-memory.
	GreenHills (or Gnu CC) on a uni-processor 68k has no problem,
	but ASAPs or multi-68k games may lose coins once in a blue moon.

   *	For reasons having to do with System I (again) the current code
	declares its variables "extern" and lets "someone else" allocate
	them. This is almost never needed and never a real good idea.

   *	I'm sure I missed some.


	Anyway, I'd like to call a meeting of "Concerned Citizens" to
clean up this mess. Please let me know when you are available (presuming
you'd like to help out) Backward compatability to System I is not our
top priority, but experience has taught me not to make gratuitous changes.

					Mike
Message 1 of 1

Jun 01, 1990