Search

Showing Posts Tagged Pinball, Bally -35 OS,
but not Project
(Click any tag to remove it)
+ - Blog Post+ - Pinball+ - Game+ - Released+ - Archive+ - P1+ - Pinball+ - Stock Car+ - Arduino+ - Electronics+ - Project+ - Bally -35 OS+ - Abandoned+ - Read Only+ - System 3-6 OS+ - Repairs


Custom Bally OS, Pt 2: Let's Blink a Light

With I/O figured out, I theoretically know everything necessary to start writing code, so I want to start with the simplest possible thing: getting an infinite loop to run in pinMAME. The CPU (Motorola 6800) is fairly basic, it only needs to know one thing to run code: where to start. You do this by putting the address of your starting code at the highest location available in memory, so I wrote a quick assembly file:

.orq $1800 ; start of U6
main:
    jmp main

.orq $1FFF-1 ; two bytes before end of U6
    .dw main ; address of main

It doesn't get much simpler! And besides from a classic off-by-one error (I did $1FFF-2 instead of -1), it worked on the first (heh) try. Loading this up in PinMAME I was able to open the debugger and see it dutifully running around its tiny loop, forever.

My next step, then, is to initialize the PIAs. With this helpful guide I'm able to transfer my notes from part 1 into some shorthand instructions on how the PIAs will need to be initially configured:

U10
Bank A:
control: |self test irq|n/u|1|1|!blanking 0|D|0|1|
direction: out (1)
data: 11110000 
    - bits 0-3 go to display latches, start low
    - bits 4-7 go to display data, start high (1111 = blank)
Bank B:
control: |zero crossing irq|n/u|1|1|lamp strobe 1|D|1|1|
direction: in (0)

U11
Bank A:
control: |display irq|n/u|1|1|led 0|D|0|1|
direction: out (1)
data: 00000000 
    - bit 0: credit display latch, start low
    - but 1: not used
    - bits 2-7: digits 1 thru 100k, start low
Bank B:
control: |n/u|n/u|1|1|solenoid0|D|0|0|
direction: out (1)
data: 10011111
    - bits 0-3: number of solenoid to fire, use 1111 to fire none
    - bits 4-8: continuous solenoid data (turn flippers off, coin lockout on)

Configuring the PIAs is a bit of a pain as they have three bytes of memory internally (the control byte, the direction byte, and the data byte) per bank, but you can only access two at a time. Therefore, one bit (2) of the control byte chooses which (direction or data) the other byte goes to. Fully configuring a PIA involves first initializing the control byte so that you can access the direction byte, then initializing the direction byte (read or write), then changing the control byte to let you access the data byte so you can actually do some I/O:

    ldaA    00110001b   ; irq state | n/u | CA2 output | ...mode | CA2 value 0 = blank displays | enable direction register | irq on | ...self test ->low
    staA    u10AControl
    ldaA    11111111b   ; all outputs
    staA    u10A        
    ldaA    00000100b   ; toggle DDRA (3rd) bit to write to ports
    oraA    >u10AControl
    staA    u10AControl
    ldaA    11110000b   ; blanking means any outputs here will affect displays
    staA    u10A        ; 0-3 set all display latches low, 4-7 blank disp data

Finally, I can use the PIA to start controlling the LED, toggling it on and off repeatedly:

inc     counter
ifeq    ; counter = 0, it wrapped around from 255
    ldaA    00001000b   ; led bit
    bitA    >u11AControl
    ifne    ; led on?
        ; turn led off
        ldaA    11110111b   
        andA    >u11AControl
        staA    u11AControl
    else
        ; turn led on
        oraA    >u11AControl    
        staA    u11AControl
    endif
endif   

and it works! At least in PinMAME. I don't have any Bally/Stern machines on hand and configured correctly to easily test it in game right now, but that's alright. PinMAME isn't perfect but you can at least get most of the logic ironed out when it's easily debuggable before throwing it on the black box of a real machine.

The code for all this is available on my github, if you want to check it out

Posted Tuesday, April 03, 2018
at 02:46 PM


Tags: Blog Post, Pinball, Bally -35 OS,

A Custom OS for Bally -17/-35 Pinball Machines, Pt 1

With my previous success programming a new rom/os for early williams pinball machines, I thought: why not do the same for their competitor, Bally? I've already got most of the code worked out, so it can't be that bad to adapt the I/O part to the other board, can it? They both use the same CPU, RAM, and IO chips as well. So today I dug into the schematics and started documenting what I'd need.

Memory Map

The first step for coding some basic I/O is to get the memory map:

Chip Address Purpose
U7 $00 128B of RAM
U10 $88 PIA (GPIO)
U11 $90 PIA (GPIO)
U8 $200 256 nibbles of RAM
U2 $1000 2KB Game ROM
U6 $1800 2KB OS ROM

What's notable here is how small it is. The Williams boards used 3 RAM chips instead of 2, 4 PIAs instead of 2, and 3 ROMs instead of 2 but, besides from an extra 128B of RAM (which I'll miss), the Bally boards have comparable capabilities to the Williams.

Williams took a very straightforward approach to their design: 16 solenoids? Well that will need 16 I/Os, so that's one PIA (each PIA has two banks of 8 I/O pins). An 8x8 switch matrix? Another 16 I/Os (and thus another PIA) obviously. This resulted in a system that was easy to program, but uses a ton of chips that can all go bad. Williams boards are notoriously unreliable, and reproductions aren't readily available.

Bally took the opposite approach here. 16 solenoids? That sounds like 4 bits of data. Why an 8x8 switch matrix when we probably won't need more than 5x8 switches? Lets use those other three bits for other unrelated things. We won't need to write to the lamp board and switch matrix at the same time, so lets connect both up to the same pins, and use another pin to select which one. And hey, the same logic works for the displays as well, right? Stuff like this allows Bally to make due with half the I/O lines, but I can imagine it'll be a pain to work with. Still, it worked out well, right? Bally boards are considered the most reliable and well designed of that era, they're easily repairable, and replacements are available with better, modern designs.

It took me a good few hours to decode the meanings of all the pins on the 2 PIA chips. Each has two banks (A and B) with eight lines each, and four extra lines (CA/B 1/2) with more limited functionality:

U10:
A0-4:  switch strobe ST0-4 (NH)
A5-7: dip switch 1-3 strobe (NH)
A0-3: lamp address
    selects lamps 0-14 for each of the four lamp chips
    all high (15) for no lamp
A4-7: lamp data
    low to enable any of the four lamp chips
A0-3: display 1-4 latch,  nored with CA2 J1-(20-24)
    bcd enabled when high
A4-7: display data
CA1: self test switch input (low = pressed)
CA2: nored with display latch: display blanking/enable (low -> high blanking)
    bcd blank when blanking high (signal low)
CB1: zero crossing input (NL)
CB2: dip switch 4 strobe (NH), lamp strobe 1 
    latches data for first lamp board on down signal
B0-7: switch return I0-I7

U11:
A0: display 5 (credit?) latch, nored with U10-CA2
A1: 'sound module address enable'? J1-7
A2-7: display digit enable #6-#1 (100k-1 or v.v?) J1-(6-1)
B0-3: solenoid/sound data A-D
    0-14 turns on that solenoid
    15 all solenoids off
    (only one solenoid can be on at a time!)
B4-7: 'continuous solenoid data' A4J4-(5-8) -> A3J4-[11,9,8,10]
    low=enable
    B4: A3J4-11: Cont 2 
    B5: A3J4- 9: Cont 4 coin door lock out
    B6: A3J4- 8: Cont 1 flipper disable (high=enable flippers?)
    B7: A3J4-10: Cont 3 
CA1: display interrupt input (NH)
CA2: LED (high turns on), lamp strobe 2
CB1: n/u?
CB2: solenoid (low) or sound (high) select

With this, I have a general idea of what my OS will need to do to run the peripherals, and most importantly, I know how to turn the diagnostic LED on the board on and off, which will be the simplest way of knowing whether my code is actually running. My next step will be to set up an entry point and toggle the LED via one of the PIAs

Posted Sunday, April 01, 2018
at 07:05 PM


Tags: Blog Post, Pinball, Bally -35 OS,