pbos.info

Greetings, Pinfreaks.
I have two things.. progress on an IDE, and some hardware details that Tim asked for..

None of this work is of much use unless the eager Pinfreak out there can make changes and such.. and the existing work is all done under a compiler, via a Microchip RealICE emulator. So that is not something that the average fellow would want to do. So the key is a PC based development environment. This would allow the enthusiast to edit projects, download them, and debug them. I am in the midst of writing this editor (IDE.. integrated development environment). So far, I have chosen the uber simple INI file format, which I retitle the .PBP format, or Pin Ball Project. Details on the machine info, lamps, switches, solenoids, variables, and of course thread info are all stored here. The IDE will now open a project file (Firepower, of course), and the project view displays a tree with the major categories on it. Double click on a tree item, and a window pops up with that info there. I am working on these windows now. Eventually, there will be a compiler that takes user code and packs it into my own Pinball Command Language, which I have decided is a bit too much for folks to follow. The language will begin to resemble somewhat simple BASIC. So then the IDE will download the code to the pinball machine, and the user can start, stop, reset, and get key debug info on the operation. Whew.. I have a long ways to go.

So on to more hardware details.. the current proto board is built around a PIC24 part, which is a 16 bit microcontroller. Sad to say, but the days of a processor with external address bus and EPROMS are a distant past. Most microcontrollers have a ton of memory ( I have 256K of flash and 32K of ram in this one), and piles of peripherals built in. And why not.. this 16 bit lightning fast part is less expensive than an obsolete 6800 that Jameco might or might not have.
This board then has level translation chips (3.3V to 5V), and a 40 pin ribbon cable that is pinned out to represent a 6800 processor. I remove the original 6802 processor, and plug in my ribbon cable. That allows my microcontroller to take total control of the MPU board.
I then have code that generates the proper address/data/control signals, and take control of the board. I just ignore the EPROMS and SRAM. I control the 6821 PIA's, as they are all of the access to the hardware. I also generate an Eclock, since this will create the blanking signal, without which you will be hard pressed to make anything work. There is a 1mS pulse coming from the board as well, which was used in the original system to generate an interrupt.. but I think that I am generating my own timer interrupt.
I am also using a bit of the flash memory for non-volatile values (no more batteries!!). The only down side is that when a value is updated, the processor stops execution for some tens of milliseconds, and you can see a slight flicker in the scanning of the displays.

For more info on PBOS (pinball operating system) or PCL (pinball command language) please see previous posts.

Also, I am beggin for comments and ideas. Please email me at ceddy(at)nb.net.
Thanks,
Chris~

This week, I released the 10 page manual describing the Pinball Command Language, and am getting some great feedback from folks. The goal is to get some feedback on missing features, and also to see if folks like the idea of making rules in the format presented. If you want a copy of the manual, just email me at ceddy(at)nb.net.

There is one thing that is predictable when using pointers in C.. if you aren't careful, you will spend all day looking for mistakes. So after doing that a few times, I went to the trouble of adding some bounds checking. For instance, when a test wants to jump forwards or backwards in a thread, the code now checks to see if you have gone past the end or before the beginning of the thread. It will go to a place where, in the future, a record will be made of the error details. The code also looks for an attempt to use more threads than space is allotted for.. shew, was that a mess when I exceeded the end.

I continue to refine the rules of the game.. the targets 1-6 work fine, the standups behind the rubbers work, the spinner at least sounds and scores. Also, I fixed the lane change.. it goes in the right direction now!

To be done in the next few days..
Proper sounds when starting more than one player, proper sounds and scores when rolling over FIRE rollovers, and at least flashing and sounding (and clearing) FIRE POWER when you get it. Also, when a ball starts, the player lamp flashes, and is sposed to go sloid when you score. That is not yet done.

To be done this month..
I must start on the PC code and transfer software to edit and load a project into the machine.. or I will never be able to get anyone in on this fun.. So the plan is to get started. The only way that I know is to use Borland C++ for windows, so that is the plan. A project will consist of project revision info, machine details, target hardware details(remember, there can be more than one fellow making hardware), tag names for all objects on the playfield, and threads of course. I plan to make a thread tabe of contents to allow easier management of them. The current Firepower has over 60 threads so far. I will allow for the future inclusion of sound files and graphics files.. as that day will surely come.

Then on to the Ohio show! I will have a notebook by the machine for folks to sign into and add comments, leave emails, and such.
I will be the fellow with a laptop connected to Firepower.
Chris~

It just dawned on me that there is no link anywhere as to how to reach me, if you want. Please send all emails to ceddy(at)nb.net. Replace the (at) with the real thing, of course.
I am trying to arrange to be at the Ohio show March 20/21, where you can have a look at the running Firepower.
Thanks,
Chris~

Greetings pinball fans!
Over the last few days, I have added some more of the key game play details.
I trashed the old way of storing scores.. basically I used to keep one long variable, and would constantly break it up into separate digits to display them. So I switched to a separate 8 bit variable (in an array) to store each digit.. code deals with the rollover. So if tens gets to 10, I clear that to 0 and ripple an increment up to 100's, and so forth. That way, the code just mashes the nibbles together (4 bits is a nibble) and preps them for the interrupt to spew them out.
Next, as I studied the original game operation, it was clear that a switch event might queue up 5 increments of 10 points.. such as the standups behind the rubbers. So I have an array that holds a 'rack' of score increments, so that events can rack up onto the rack, and a separate thread can dole out the increments one at a time. This is key, as there is a sound for each increment, and a short delay before the next one.
I wrote code to keep track of the bonus for the game/ball. I also wrote the thread that splits up the value amongst the 1-20 lamps on the playfield, which was one of the hardest threads of the game yet. I have not yet written the thread that rolls the bonus onto the score at the end of a ball.
So then I started on some of the finer details. I made the 1-6 targets function much more like the original ones, with flashing when not earned, and fast flash and sounds when earned the first time, and a score increment when the target has already been earned. I also made a thread that acknowledges a 1-3 or 4-6 to earn your shield, and then 1-6 to clear the targets, but no ball lock stuff yet. I light up the shield, and if earned, I kick the ball save when the ball rolls out in the outlane. It kicks back very well.. I now suspect that the reason that my Firepower never kicked back very strongly and consistently was that the original processor and code could not get there fast enough.
I did the rubber standup targets, as mentioned above, and also the rollovers in front of the ball locks. I also did the two return lanes, and the out lanes, at least the unlit score routine. When lit, other things happen, and I have not gotten to that yet.
Much to do.. thanks for checking in!
Chris~

Interesting..I discovered that when the right slingshot kicker solenoid is engaged, there is enough electrical interference to make the switch matrix think that the switch is closed, and thus keep the solenoid engaged.. yikes, I had to put a delay in there so that the kicker would back off long enough for the switch to 'unclose'.
So I had my head deep in bugs dealing with thread execution, arithmetic comparisons, off by one bugs, and the like. Lots of code means lots of polishing. But as of today, I can coin up 1 to 4 players, and play a five ball game, and the game cycles back to attract. It is 5 only because there is no way yet to enter function codes and modify them. That will come. And so, the game is fully playable. Flippers, bumpers, slings, FIRE targets, POWER targets, 1-6 targets, 2x-5x bonus keeper.. Don't get me wrong.. there is a lot missing. The score of 0 displays, but no score increments work. Many of the targets work, but do not flash and make sound like they ought. And most of the more complex rules, multiball and the like, are not there. None of the function code values other than how many balls are being used.
But I can play a game on it!!
Chris~

Greetings..
Well, this is my third entry to the blog. The work of 3 days ago had a lot of the code running the game rules in C code.. as it is written, it can run both threads and C code at the same time. But the big idea is that there is no game specific C code at all! I have most of the code moved over to the threads method, which involved adding new commands as they were needed. Most of the new commands deal with moving data into and out of an 'accumulator' and decisions such as equal to zero, greater than or equal to, and so forth. I hope to have the game back into 'primitive play' mode in another day.

And a problem arises.. the non-volatile variables are stored as a block which is shuttled into the processor's own flash memory when a change is sensed. So for instance, when you coin up, and the credits change, the code wants to store away the non-volatiles. Since it takes about 50mS to do so, and the processor halts briefly, the multiplexing displays blink! It is not a crisis, but noticeable. And I suspect that there will be a crowd out there that will stand up and shout foul.. "it is not the same as the original!". So I am considering adding a small external flash chip that will hold the non-volatiles, instead of keeping it in the processor.

Once the basic operations are all in threads, and the game is playable again, the next step is to add to the threads the details of flashing and sounds. Right now, when I hit target 1, it just lights. The proper way is to blink it three times, throw a sound code out, and then after a delay, go back to background. (or something to that effect). If I represent these accurately, nobody will be able to tell the difference between the original and the new version!

Onward to the next phase.
Chris~

As I dig in, it appears that some more commands are in line. There are many functions that have to make decisions, such as "if( (one==1) && (two==2) && (three==3) ) then light(five) else light (seven).
Since the threads commands to not allow one to write direct code, the plan is to implement a very simple processor in each thread. Each thread will have features such as an accumulator and flags such as zero, carry, overflow, and such. Then, one would do something like this..
THCMD_LINE_TAG, TEST_X3
; Test this players' multiplier value and set light X3 if needed..
THCMD_LOAD_ACC, PLAYER_DATA_BONUS_MULTIPLIER
THCMD_SUBTRACT_#, 3
THCMD_GOTO_IFGE (greater or equal to), LIGHT_X3
THCMD_SET_LAMP_OFF, BONUS_X3
THCMD_GOTO_LINE, TEST_X4
THCMD_LINE_TAG, LIGHT_X3
THCMD_SET_LAMP_ON, BONUS_X3
THCMD_LINE_TAG, TEST_X4

As you can see, it does resemble assembly a lot. The good news is that when you start with an existing game rule set, you will be able to see how it works, and cut and paste some changes.
So there will be commands to load values, perform simple math or logic on them, and make jumps based on the results. In the same vein, there will also be commands to perform logic on individual bit states.
The rub to writing this is the effort of converting flags such as C, Z, and V, to decisions such as GE, GT, EQ, NE, LT, and LE. I believe I have the plan worked out, and half written. Next task is to test it in a thread. I will write a thread to decide if all 6 targets have been made, and clear them if so (relies on logic IF's), and a thread that lights the bonus lights based on the player's bonus earned (relies on arithmetic IF's).

I will let you know the results!
Chris~

Greetings..
The quest here is to create a broad Pinball Operating System. The PBOS will interpret numerous threads, where such threads are built of codes that represent specific commands or operations. For example, { THCMD_WAIT_SW_CLOSE, SW_LEFT_EJECT_HOLE, }, will wait for a switch closure on the left eject hole. When the switch closes, the code moves to the next line.
An early list of commands:
                case THCMD_WAIT_SW_CLOSE:
                case THCMD_SET_LAMP_ON:
                case THCMD_SET_LAMP_OFF:
                case THCMD_SET_LAMP_FLASH:
                case THCMD_SELECT_SOL:
                case THCMD_SET_SOL_ON:
                case THCMD_SET_SOL_TIME:
                case THCMD_SET_SOL_OFF:
                case THCMD_SET_DELAY_mS:
                case THCMD_WAIT_DELAY_mS:
                case THCMD_SET_DELAY_SEC:
                case THCMD_WAIT_DELAY_SEC:
                case THCMD_SET_PL1_DISPLAY:
                case THCMD_SET_PL2_DISPLAY:
                case THCMD_SET_PL3_DISPLAY:
                case THCMD_SET_PL4_DISPLAY:
                case THCMD_SET_CREDITS_DISPLAY:
                case THCMD_SET_BALL_DISPLAY:
                case THCMD_PROCESS_COIN:
                case THCMD_GOTO_LINE:
                case THCMD_LINE_TAG:
                case THCMD_KILL_THREAD:
                case THCMD_KILL_THREAD_TYPE:
                case THCMD_SET_THREAD_TYPE:
                case THCMD_START_THREAD:
                case THCMD_KILL_THIS_THREAD:
                case THCMD_SET_FLAG:
                case THCMD_TEST_FLAG:
You can see that there are commands to manage switches, lamps, solenoids, displays, delays, and the like.

The ultimate goal of the project is:
To have a number of replacement boards available for a variety of machines
To allow the aficionado to modify/edit/add to the rules easily
To allow others to implement the PBOS on other hardware
To have a commercial quality electronic system available to short run production endevors.

As of this blog, I have built a daughter board that plugs into a 6800 socket, and written software to scan and operate the board (and associated driver board). I then created a linked task list executor, which uses the cooperative multitasking scheme, to allow the machine to execute multiple threads at once. This is an ideal method, as there are multiple separate things going on in a machine at the same time. One target may need to: post a score change, post a sound, set the players target flag, flash the bulb 4 times, and leave the bulb on. You can see that to do this all over the playfield would be difficult in one continuous program. Also, the threads can be started up and killed as needed. A thread that flashes game over during attract is not wanted during game play.

The existing daughter board is really for development only, and sharing with some beta testers. The next step is to flesh out a board for system 3/4/6/7 that replaces the driver board altogether. This will allow:
Eliminate the existing MPU board
Eliminate the dodgy connector strip that is the cause of failure
Eliminate the batteries for non-volatile memory
Eliminate the high wattage resistors that generate heat (they only did this so they could use regular transistors.. a darlington or MOSFET would have eliminated the high watt resistors).
Allow the addition of current monitoring to prevent latchup of the solenoids
Allow the addition of a serial port to show debugging information for developing