Stern Pinball Firmware
Lutgarda Briseno
So I was wondering how much do we know about how their developers work? What development platforms, tools do they use? Are they still writing stuff in assembler (probably not)? Is the length of time it takes a result of an aging platform, etc?
From a talk I saw at Pinburgh they switched away from assembly with the SAM system. It was interesting to learn that all of those old Bally/Williams DMD routines were written in assembler. I can't imagine.
What surprises me is that they don't seem to have a standard template. You would think they would have a base code that they build up from. But some games that have practically no status screens would suggest that they don't do this.
They may be able to start doing this now with the SAM system.. Anything written in assembly is basically impossible to templatize. I can't even imagine how they are doing that. I always assumed they had a custom compiler but.. wow. That says a *LOT* for the Stern devs, and clears up why some of the code updates take so damn long. 99% of developers couldn't hang, as they're used to being spoon fed with stuff like Visual Studio.
I'm definitely interested in this topic. If the community was interested you would need to find volunteers with a particular skill set - embedded software. Then you would first need to answer the question "Can enhancing/extending the code be done?" So what are the things that would need to be discovered in order to answer the question. Realistically, I don't think it can be done.
It's not just a question of knowing the language. In fact, programming language is almost not relevant. You would have to disassemble the code. Figure out if they were using an realtime operating system (RTOS) and which one. If they were not using an RTOS, how are they handling realtime events - interrupt driven, semaphores, etc. Of tremendous importance is what microprocessor is being used, what peripherals are on board, how are bits arranged (endian order). Yikes...so much to think about. Then, once the new code is written, you'd have to manually link it with existing code (something the normally compiler/linker does).
I think a new code base is more of a viable solution that enhancing existing code. I would love to be proven wrong! Even better would be if we could convince Stern to provide a plug-in or modular architecture that could be extended. That would be the path of least resistance.
Untrue. I reused a lot of routines when I was doing 6502 and 8086/8088 assembly. If you're organized it's completely possible to do. Programmers have just gotten a lot more lazy in the last 20-30 years with the high level languages that are in vogue now, and the executable sizes have ballooned with tons of redundant code. But, it is easier than assembly.
You're right, of course - but I guess I was trying to scale the complexity of what game code would need to do vs what my experience is, which was basically Visicalc (i.e. Excel computation), and it seemed just ridiculous to be able to get there. But my experience with assembly is pretty minimal
This has been going on for a long time. Assembly is more difficult to debug. Really wish we could get ahold of the original source code to old games. I have looked at doing work on games like BF, but reverse engineering a system like that is a huge investment before you even begin to code anything new.
Assembly is more difficult to debug if you don't have the source, but if you have the source and label well, I never found it much harder than C to debug, especially if you have an informative window into the registers and memory variables. If you DON'T have the source and just have a dump of the assembly code, it's a nightmare to work with. But I do love the positively anemic file sizes of well-written assembly code compared to the massive bloat of high level languages these days.
I talked with a friend about Stern code and exactly this on friday, that it would be really interesting with a documentary with cameras present and just see how they code and work. Not with the intent of bashing, but genuine interested since I am a programmer myself.
That's only after the low level code is written... then perhaps you could create a system that allowed people to script the rules in python. However, Python is not an appropriate language for embedded programming. Assembly, C or C++ are the typical languages. You're working at a much lower level. It is very likely that you'd be coding to specific memory addresses, using registers, etc. You need some knowledge of computer architecture and real time concepts such as interrupts, semaphores, mutexs, etc. You likely would need a Comp Sci or Comp Eng background. I'm not saying it's rocket science but it's not like programming in Visual Basic either.
Stern currently uses Sourcery CodeBench with the Atmel SAM9G platform(Spike) on Linux kernel 2.6.30. A moderate amount of the "base" code is shared between games (but is not limited to); lamp effects, base-language, coin door operation, coin meter, node board communications and diagnostics, node board switches, ticket/redemption, backbox lighting, slam tilt, start button, playfield tilt, generic tournament settings, active ball counter, ball save, display interactions..
There must be someone out there that actually knows how stern does this. I wouldn't think they have a very sophisticated development environment because if they did code updates would roll out in a more timely fashion. I know they have to focus on the most recent games but I think they could easily sell enough extra games if they had a better release schedule. Hiring an extra programmer would not be that expensive or that hard unless the development environment was just not what newer developers are interested in. (Kind of like the issues we had as mainframes started to die-off - couldn't get a new grad to touch it with a 10 foot pole).
Which makes the long spells between code updates and general launch condition of their code pretty inexcusable. That's a pretty plush development environment, with opportunities for substantial re-use of codebase if the projects are managed well.
Makes sense to do it that way but it also begs the question. Why the blue blazes does it take so long for them to update the code ?
We use a system at work where all the safeguards are taken up by subroutines and any new modes we add to a device simply have to correctly integrate with those sub routines to ensure that nothing catastrophic can go wrong. It is then a relatively straightforward process to debug the code for the new modes.
Sort of, but that doesn't interface directly to the driver board system. That just provides a mostly language-agnostic wrapper that you can interface to the P-ROC from higher levels while providing a single point of change for future P-ROC updates while leaving as much of the higher level frameworks untouched as possible (there are several now).. The real "real-time" stuff happens at the FPGA level within the P-ROC.
It takes so long because coding these things is not about how easy it is to type code into a studio environment. I'm not excusing the time they do actually take to get it out. But it's not the platform that's causing it. It's the seven things that go wrong whenever you change one other thing. It's the correct implementation of the result trees and score balancing. It's getting the mechanics to respond properly. It's about tweaking the timing. Etc, etc. The coding environment is a minor concern.
c80f0f1006