Disclaimer: This information is provided as is. There may be errors in this information. You may use this information only if you agree that Minimalist / Coinop.org, its employees, and noted authors will never be held responsible for any damage, injury, death, mayhem, etc. caused by errors in the information. When working with high voltage, never work alone and always follow safety precautions.

Document Title: [TronMap.html (html file)]

Memory map for Bally/Midway MCRII system (Tron)

I know of the following games that run on MCR/II systems: 
	TRON   (MCR/II)
	TWO TIGERS (MCR/II)
	SATAN'S HOLLOW (MCR/II)
	DOMINO MAN (MCR/II)
	WACKO (MCR/II)
	JOURNEY (MCR/II with MCR/III sprite board)
	
I've been told that these are MCR games, too:
	KICKMAN (MCR/I)
	SOLARFOX (MCR/I)
	
and I belive that there are others.

The game system (MCR/II) consists of three boards: 
    * the audio board (super sound I/O) - Z80 + 2 AY-3-8910
    * the cpu board - Z80 and background/tile generation 
    * the video board - TTL logic based sprite generation.
    
The memory map presented here was based on schematics
for TRON.

There are surprisingly few customs on the boards; most functionality
is implemented with TTL and CMOS logic.

Audio Board
-----------
    0000 - 0FFF 4K Audio Program ROM @ A7
    1000 - 1FFF 4K Audio Program ROM @ A8
    2000 - 2FFF 4K Audio Program ROM @ A9
    3000 - 3FFF 4K Audio Program ROM @ A10 (optional)
    4000 \
    5000  \ __ Not mapped
    6000  /
    7000 /
    8000 - 83FF Program RAM, 1K @ A6
    9000 - 9003 R/O 4 x 8bit register file (2x LS670 @ B9 / B11)
    A000 - A003 AY-3-8910 PSG @ F7
    B000 - B003 AY-3-8910 PSG @ F6
    C000 - write status back to main CPU (LS374 @ A5)
    D000 - Diag LED (bit 0)
    E000 - reset interrupt ??? 
    F000 - read audio config dipswitch

Cpu Board Memory Map
---------------------
    Cpu Board Memory Space
    ----------------------
    0000 - BFFF -- ROM -- Program roms.  different games
    		   have different numbers of roms. usually from 3 (0000-7FFF)
		   to 5 (0000-BFFF)
    C000 - C800 -- RAM -- program ram
    D000 - EFFF -- NOT MAPPED
    F000 - F7FF -- RAM -- foreground RAM; sprite "control" area; not sure of 
    		   the format of this area, yet. (haven't gotten that far ;-)
    F800 - FFFF -- RAM -- background RAM; controls display of background 
    		   graphics; format is alternating tile/attribute
    

    Cpu Board I/O Ports
    -------------------
    
    00 - R/O - IP0  \
    01 - R/O - IP1   + read control Input busses
    02 - R/O - IP2  / 
    03 - R/O - IP3  Read 8 bits of 10 pos Dip Switch on audio board
    04 - R/O - IP4  Read control input bus
    07 - R/O - IP5  Read audio status register
    
    00 - W/O - OP0  Write latch OP0 (coin meters, 2 led's and cocktail 'flip')
    04 - W/O - OP4  Write latch OP4
    
    1C - W/O - WIRAM0 - write audio latch 0
    1D - W/O - WIRAM0 - write audio latch 1
    1E - W/O - WIRAM0 - write audio latch 2
    1F - W/O - WIRAM0 - write audio latch 3
    
    E0 - W/O - clear watchdog timer.  This should be implemented (KEM does 
    	not) 'cause the MCR games use the 'tilt' button (which halts the
	game without clearing the watchdog) to exit from the diagnostic
	modes
    
    E8 - W/O - ???
    
    These are the ports of a Z80-CTC; it generates interrupts in mode 2.
    F0 - W/O 
    F1 - W/O 
    F3 - W/O 
    
System Notes:
-------------

    I don't know how the control input busses actually map to controls; 
    I have to study the TRON input board schematics to figure this part
    out; one of the "copy protection" things that Midway did was to make
    the control panels _very_ different from game to game (witness TRON,
    TWO-TIGERS, and TAPPER -- all three have very different, custom panels)
    
    The CPU runs in interrupt mode 2.  The z80-ctc at B3, HK3882 is 
    responsible for generating interrupts, and the vectors that go 
    along with them.
    
    There are 4 possible interrupt vectors (address are for TRON, 
    other games vary) each one corresponding to one of the interrupt
    vectors generated by the CTC.
    
    The CTC is programmed with a base vector, and bits 1:2 of a 
    generated interrupt indicate which timer channel is raising the 
    interrupt. (i.e.: vector #'s are: (binary) bbbb bcc0 where 'bbbb b' is
    the 5-bit vector number, 'cc' is the 2 bit channel number (0-3), and
    the lsb is always 0 (architecture of z80 demands this)).
    
    So, in the case of tron, with base vector set to 0x08,  the following
    interrupt vectors are possible: 0x08, 0x0A, 0x0C, and 0x0E.
    
    I/O Port E8:
    
    this port gets the following sequence of bytes written to it
    at system start:
    
	    02 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 00 01 05
	    
    with no intervening hardware writes or any other accesses for that 
    matter.  The values are written in a tight loop.  
    
    To the point that I've run the system (admitedly, not very far), the
    system does not write any further data to E8. (however, TWO TIGERS
    writes these values every interrupt)
    
Timer Usage
-----------
    The CTC chip is used differently by different games.  There are 4 
    timers provided;  each can be programmed for external triggering or
    internal count-down.   When used as a timer, the system clock is run
    through a divide by 16 or divide by 256 prescaler.  When used as a
    counter, there is not prescaling.
    
    In the MCR/II circuit, the CTC chip only has timer channel 3 wired up
    for external triggering (actually, 0 and 2 can be triggered from the
    debug connector, if the timers are programmed for counter operation.
    
    I think that the channel 0 trigger is wired up to VBLANK (it comes
    from the custom chip MMC05 at G11 on the CPU board). However, I have 
    to actually check a real MCR/II system to be sure.
    
    The other timers, if used in software, will be configured for timer
    operation; these timers are programmable, and count with the system
    clock.  The emulator assumes 4 clock cycles / instruction, and 
    so decrements the timers by 4*cpu_time_slice at the end of each main
    cpu timeslice.  underflow is handled by adding the timer-period value
    to the timer count instead of setting the count to the reset value.
    this way, undershoot and overshoot should balance out.
    
    The VBLANK interrupt wired to ch0 is 30Hz, not 60hz!