HELP!!! Rare Pinball machine using 6502 project

wrkey · Post by **wrkey** » Tue Mar 06, 2012 9:17 pm

Greetings,

I have an extremely rare Cocktail Pinball machine made by Valley in 1978. My machine is one of less than 20 that is known to still exist and one of 3 or less that acutally work. Getting my machine to work has been a long journey and I am very close to having a fully working machine. However.......

The code that was extracted from the ROM has been found to faulty either due to corruption over time or the extract process itself. It is also possible that there was a bug pre-existing in the code.

The Visual Pinball MAME group of programmers managed to dis-assemble the 6502 code and I have both the BIN file for the code and the TEXT assembler code.

I need someone who would be interested in looking at the code and helping to resolve the issues with in it. Besides myself there are several other owners of this machine who are looking for a viable code set and one we can load and use in our machine.

You can find out more information about this project through my personal webiste's projects page. Navigate to www.rustykey.com and then select projects and then Spectra IV. You can also see information on it by searching Spectra IV on Facebook where I have set up a page for it as well. I hope to update my personal page very soon with the latest information.

Any assistance in this effort will be greatly appreciated and you will receive accolades and credit on the various websites as we proclaim the fact our machines now function correctly and who all helps us get there.

If you are interested in helping, either leave a message here or send me an email. I am not sure of the restrictions on this website (just joined) but I will try to post the binary and text files along with the other informaiton I have this evening.

Thanks in advance for any help you can provide!!

Nightmaretony · Post by **Nightmaretony** » Tue Mar 06, 2012 9:46 pm

I will jump in as well. Am making a new 65C02 based computer for the Bally home pinballs which were based on the F8 processor.

throw me an email on here or at nightmaretony@yahoo. Will need to have a schematic to know how the board is based.

Thanks

Tony

Nightmaretony · Post by **Nightmaretony** » Tue Mar 06, 2012 9:47 pm

Nightmaretony wrote:

I will jump in as well. Am making a new 65C02 based computer for the Bally home pinballs which were based on the F8 processor.

throw me an email on here or at nightmaretony@yahoo. Will need to have a schematic to know how the board is based.

Thanks

Tony

Had just read your page, acid damage has been an issue with the Bally arcade 17 and 35s for melting board traces. It should not have messed with the code unless it also got onto the eprom pins.

Seperate driver boards, me always likes

Nightmaretony · Post by **Nightmaretony** » Tue Mar 06, 2012 11:34 pm

Some caveats though: pretty insanely busy with projects and cancer. Will need others along the way but will help out as I can along things....

We need as good a dump as possible, though.

wrkey · Post by **wrkey** » Wed Mar 07, 2012 2:37 am

THANKS TO ALL!!!!!

I knew that there was a community of folks who want to help others! Anytime devoted to this will be greatly appreciated!!!

Okay, so make it easier for those here on this forum and those from other areas of interest (Spectra IV owners) I put all the files I have on my website. Here's a link directly to the page with code links:

http://www.rustykey.com/projects/spectra/page3.html

That is the 3rd page (newest) of my repair page for the Spectra IV and the files you will want is at the bottom. There is a drawing of how the chip is laid out on the board, the binary code file, the de-assembled text file and a Informational txt file with all the information I've received on this code. Here's a link for the manual which includes schematics for those that want to see that.

http://mirror2.ipdb.org/files/2273/Vall ... tra_IV.pdf

Thanks again!!!!!!

TMorita · Post by **TMorita** » Wed Mar 07, 2012 8:41 pm

There are some hex bytes in that disassembly which are valid code, but which are not disassembled.

0FED: 00 00 00
0FF0: 00 00 A9 01 85 FF 4C 12 06 00 0F 0F 6F 08 81 0F

This is

BRK
BRK
BRK
BRK
LDA #$01
STA $FF
JMP $0612
...

Toshi

TMorita · Post by **TMorita** » Wed Mar 07, 2012 8:48 pm

Yoou mention:

These here are the two most notable odd accesses:

> 0DDA: B9 EB 0E lda $0EEB,y !!!
> 0DE0: B9 F2 0E lda $0EF2,y !!!

> They point right in the middle of executable code (see files).
> I tried to change the addresses to redirect them to the block
> starting a few bytes later ($0EFB and beyond), but that didn't
> change the faulty behaviour... :/'

You're misunderstanding the code.

The full code is:

0DCF: C0 10 cpy #$10
0DD1: B0 07 bcs $0DDA
0DD3: 8C 82 01 sty $0182
0DD6: A9 3C lda #$3C
0DD8: D0 09 bne $0DE3
0DDA: B9 EB 0E lda $0EEB,y
0DDD: 8D 82 01 sta $0182
0DE0: B9 F2 0E lda $0EF2,y

The first 16 entries of that table are never used because the code branches elsewhere if the index is less than 16. This can be done by:

TYA
SEC
SBC #$10
TAY
LDA $0EFB,Y

but the programmer just subtracted 16 from the table address instead and did this:

LDA $0EEB,Y

So there is nothing wrong with that piece of code IMHO.

Toshi

TMorita · Post by **TMorita** » Wed Mar 07, 2012 9:01 pm

If my memory is flaky and I have the BCS behavior reversed, then it could be that the original code was supposed to have a BCC opcode there instead of BCS.

Toshi

wrkey · Post by **wrkey** » Wed Mar 07, 2012 9:15 pm

First let me say thanks for the assistance thus far!

Serveral items here should be mentioned. In the informational text file that helps explain what has been discovered thus far, the gentleman that pulled the code initially stated that there were server code references that seemed odd. In an later email he explains how it appears that the programmer used a table of values that are 'combined' based on the switch activated to determine the address to 'jump to'. Thus the 'odd code' is explained.

For the machine itself, there are a couple of problems that I'll define here that may help in determining the code issues.

First problem is that when in multiplayer mode and either the 2nd or 3rd player is in process, anytime 1,000 points are scored (either all at once or cumulative) something odd happens. For player 2, the Tilt sound is activated but the game doesn't tilt and continues to play. For player 3, the 'Credit Won' sound is activated AND a credit is awarded (if it hasn't exceeded the credit limit yet) and continues to play.

Secondly, the machine tends to 'get lost' and freaks out. I really don't know how better to explain it. I am thinking it might have something to do with the rotational tilt switch but I can not be certain. Unfortunately, trying to recall exactly what happened when it 'freaks out' hasn't been possible. Right not the machine is 'locked up' and even after a power cycle the scores are all mixed up with numbers, it acts as if it's in the middle of a game and there's lots of sounds being made. I will try to work with it some this evening and see what I can figure out.

If you want to see what the game looks like and even play the game virutally including the 2nd and 3rd player errors, you can go to the Visual Pinball forum and acquire the VP system and the Spectra IV game file and load it on your machine. This system is worth having just for fun too!!!

Oh.. one other question. Would it help if someone went through and documented areas with in the code with comments such as - Switch testing here, Test Mode starts here, Score Increment here, Ball count decrimented here, etc.???

Thanks

Rusty

TMorita · Post by **TMorita** » Wed Mar 07, 2012 9:48 pm

wrkey wrote:

First let me say thanks for the assistance thus far!
...
Secondly, the machine tends to 'get lost' and freaks out. I really don't know how better to explain it. I am thinking it might have something to do with the rotational tilt switch but I can not be certain. Unfortunately, trying to recall exactly what happened when it 'freaks out' hasn't been possible. Right not the machine is 'locked up' and even after a power cycle the scores are all mixed up with numbers, it acts as if it's in the middle of a game and there's lots of sounds being made. I will try to work with it some this evening and see what I can figure out.
...
Rusty

Based on my limited experience with restoring old computers, this sounds like either the RAM is bad, or the address decoding of the RAM is bad.

You might try replacing the RAM, and checking if all the chips involved in decoding the address space to RAM are correct.

Toshi

Nightmaretony · Post by **Nightmaretony** » Wed Mar 07, 2012 10:58 pm

Based on battery acid melt, either trace rot or shorted together. Thsoe need to be taken care of before going further...

(the Bally pinballs were notorious for these...)

also, since the memory locations are known in the readme, can the code use the labels to show what routines are where? If no one else, I will take that on under the Kowalski

leeeeee · Post by **leeeeee** » Thu Mar 08, 2012 2:13 am

There are quite a few places where the index used to access a table doesn't start from zero. I've fixed that in my disassembly by using the label to the location of the table and subtracting the start offset from it in the code.

What would help is more information on things like which inputs are which to U18, U19, U20 and U21 and which outputs drive which solenoids.

The notes say that the displays mapped at the start of page zero are player 4 first but the manual says the status display is first.

The notes also say that the NVRAM is $80 to $FF but from the manual and the code it would seem to be $00 to $FF with it being used as shadow registers for the output latches in quite a few places.

There do seem to be some places where branch sense seems to be wrong, like after testing for A = $00 the following BEQ goes to code that clears a bit in A.

Still lots of code that's unknown though, at least to me.

Lee.

leeeeee · Post by **leeeeee** » Thu Mar 08, 2012 2:19 am

Quote:

There are some hex bytes in that disassembly which are valid code, but which are not disassembled.

I don't think there's any path to that code anyway.

Lee.

Nightmaretony · Post by **Nightmaretony** » Thu Mar 08, 2012 3:47 pm

The schematic is on his page, so that is an easy question to be answered

wrkey · Post by **wrkey** » Thu Mar 08, 2012 4:21 pm

Such great responces!!!! Thanks to all!

Okay, I'm sure you guys will laugh at me but here's my attempt at commenting the code. My thought process was to put in 'plain english' what I new (switch jump locations) and then start commenting the assembler code process and then maybe I could 'convert' the assembler code process into 'plain english' In other words have comments that says 'incremint score by 100' or 'incremint ball count by one' or 'tilt process is here' , etc.

I'm thinking that we have the code commented with the 'plain english' it would be make debugging much easier.

As for the tracing that are bad.. we have corrected and tested all the tracings on the board. Of course there could be some that we missed.

Most of the chips have been replaced on the CPU board.. at least those with visible corrosian creep.

I don't know if this info is helpful but here it is anyway. There are 3 boards that drive the machine, the CPU, a solenoid / sound board and a lighting board. When test mode works (which is 95%) of the time, all the solenoides, lights, display board and switches respond as they should. This is why I'm leaning towards a coding issue.

Also, the disassembled code is from the Visual Pinball application that reads chips and converts it to be used in the VP program. I have no idea if the de-asseblembed code is 100% accurate. However, they game does play better (with the same errors) on VP as it does in real life... so the VP conversion process seems to be accurate.

Anyway, here's my start on the commenting... I'd love to have critique and help on getting the comments to be more 'plain english'.

I miss the days of my Cobol programming!

Thanks again!