So I've got a little question for you guys!
I find this project VERY interesting to see an hope to see it work!!!

BUT...

I would like to make my own pin with a pc-based OS and a flatscreen...
So my question is: how do you control the coils, switches, lamps etc? Do you use the existing powerboard or do you've made a costum powerboard or something like that?
Do you program this in VB or what else?

Any tips or hints?

Thanks,

Evert

Thats a massive undertaking. Your best bet would be to google rec.games.pinball and look for posts from nuggie. He is doing exactly what you described.

Now, we are planning on making an API available for the nucore system that will allow you to program your own modes using existing playfields or even create new games using new playfields.

About the I/O, we are interfacing the original pb2k I/O board. It's extremely well designed, very rugged, is easily fixed if it needs repair, and lowers the cost of nucore since we don't need to re-invent the wheel.

If this part ever becomes hard to find (only way would be if people put them in the trash) we'll definitely create a new driver board.

PS - VB is not the best choice for programming pinball, though you probably could do it.

Doesn't the PB2K I/O board simply plug into the PC parallel port? That's about the simplest possible interface, but it's just an 8 bit interface. Did you guys have to reverse engineer the protocol?

Kenbo wrote:Doesn't the PB2K I/O board simply plug into the PC parallel port? That's about the simplest possible interface, but it's just an 8 bit interface. Did you guys have to reverse engineer the protocol?

Yes the I/O via the pc parallel port is a very simple but effective design. Ironically enough I emulated the entire I/O board including decoding the protocols first since I never imagined the emulator would drive the actual machine in the beginning as technology was still too slow at the time.

Turns out, none of that is needed at all when you interface to the real machine since the 'actual hardware' handles the protocols automatically along with the original rom software written to interface it.

We've also discussed the future eventuality that someday parallel port hardware will be completely obsolete at which point we will create a USB->Parallel interface (if someone else hasn't already which I think they have actually) to handle communications to the board.

Port I/O doesn't get any simpler than a parallel port, but by protocols I meant addressing protocols. It's just an eight bit interface and it seems there needs to be a layer that specifies to the board whether you're reading or writing and which register to address or, if a totally polled interface, the order in which reads and writes occur. I'm just curious how simple or complex the logic is.

Kenbo wrote:Port I/O doesn't get any simpler than a parallel port, but by protocols I meant addressing protocols. It's just an eight bit interface and it seems there needs to be a layer that specifies to the board whether you're reading or writing and which register to address or, if a totally polled interface, the order in which reads and writes occur. I'm just curious how simple or complex the logic is.

Yes your correct, the designers of pb2k did a great job of addressing a lot of different I/O via a simple 8 bit port. It's really not that complicated at all, which is a testiment to their clever work. I don't have the details in front of me, but IIRC the pport has 3 registers, so they used 1 as the control port to tell the I/O board what data they wanted to address, 1 register as the data bus, and 1 register for something else, perhaps read or write selection, I don't recall now.

There's a webpage on the net somewhere that outlines most of it, but in fact has several mistakes, which cost me a few weeks of headaches till I realized it wasn't a bug in my code but rather simply incorrect info.

[edit]
Oh and I also recall that the I/O data protocol is done in a series of data byte sequences, like 5 or so, most of which are just toggling control bits with the real data byte sandwhiched in between. It's been a couple of years since I worked on that part though, so my memory is very hazy on it.