That is helpful Jan! Sorry to have so many questions...

Is there a FTDI chip in the black cable?
When you say 2 FTDIs you mean one in the cable and another on the little PCB adapter (HiLetgo FT232RL FTDI USB to TTL Serial Converter)?
Are you switching the RX and TX with the connecting wires in between?

Thanks

So what would be a good option to purchase for a DMD or an LCD that would fit a spike machine like KISS? What additional hardware is needed to control the display? Is there anyway to control the native DMD from the PC with an additional controller?

Thanks

Tim

Wow! I just came across this thread. Nice work I will certainly be keeping an eye on the progress of this. Well done

Spike2 comes with working ethernet?

So you're telling me that I can completely re-theme a Stern SPIKE machine with nothing more than two FTDIs and an SD card reader?

Thats awesome! #MacGuyverStyle

Thanks for the kind words jabdoa but you did the heavy lifting! I hope I get a chance to buy you a beer sometime.

Yes, my KISS Pro is flipping from my laptop code and running on the Mission Pinball Framework. Boring as hell to play so far but all of the coils are working and I can play a 3 ball game with crude scoring.

I've already started designing new modes on paper and my brain is buzzing with lots of cool ideas. I'm many months away from anything remotely resembling a complete game.

Mission Pinball is freaking amazing!

Which is awesome! So the big question, what are you going to have the cities do?

I'm really excited but keep in mind that I'm not starting from the current KISS code. I'm starting from the ground up. Just getting KISS Pro to basic flip was quite a bit of work; although Jan has made great progress for future SPIKE owners.

There are no inserts on the playfield for cities so is it worth pursuing the cities? Not sure yet. I'm planning on going a different direction than the current modes. Right now, it's just a proof of concept. And as a proof of concept, we now know it can be done on KISS and other Stern SPIKE systems! We'll just have to see how far we can take it with MPF. Mission Pinball is a very important tool for the pinball community and I can't thank them enough.

Great news! Is there updated documentation on this detailing what you guys have found? What's the SD card reader for? Or is this just so you can write the software to an SD card for use with the Stern CPU card?

Quick update. I've been working with MPF two months in my spare time. I'm still a long ways away from a complete game and solution (audio, LCD etc.) but what you can do with MPF is nothing short of amazing. Some days, it is very frustrating to solve problems with MPF but the guys that develop MPF (Jan, Brian, Gabe and Quinn) are super responsive and there is no doubt that anyone can built a commercial quality game using MPF.

Although I'm not ready to implement these things, my big concern for the future "complete solution" is what computer to place inside the cabinet (Raspberry Pi or PC) and what to use as a display. I think I'd like to put a color LCD in but if I could reuse the DMD, that would be the first option. And then what to do about audio. Again, I'd like to use the Stern hardware but so far that is not an option with MPF.

I'd eventually like to share this with other KISS owners but it has to be a complete solution that would work for everyone. Ultimately, if I could just plug in a Raspberry PI with the software loaded and it used the rest of the Stern hardware, that would be nirvana.

Jan, as a PC/FAST user, one thing I am struggling with is being able to power up and have the PC go straight into the game. I think a Pi would maybe be able to do this, but I am nowhere near capable of finding out. Either way, I think powerup/powerdown might be the only real hurdle an MPF machine has to get on location.

If you are a spike MFP user you probably had to assemble a FDTI to FTDI connection using duct tape and chicken wire. Well no more! I've found a company that makes and USB null modem cable. I took a chance and ordered one of these cables in hopes of having a clean, reliable cable.

http://www.ftdichip.com/Products/Cables/USBtoUSB.htm

Just got it in today. At first, no luck and I was worried that I had misspent $50. However, it was just selecting a different COM port than I had been using before. Changed the config setting to COM5 and it works! Looks like a standard USB cable but has an FDTI chip in both ends and the RX/TX connections are crossed in the middle.

Tim

That would be sweet to work with the DMD. How would sound work with the spike? Anyway to use the internal audio?

I'll add the FTDI cable to the documentation.

I 100% agree with the method of having the core code / framework running on a host controller and then just using a bridge to different hardware. This way you can keep the host environment the same and support endless amounts of hardware with a simple custom bridge. Absolutely the correct way of solving this problem! keeps all your options open! To develop the host to run on the actual hardware would be a complete nightmare (for every bit of hardware) and in most cases not even possible! (even though it is very cool it can actually run on the spike cpu it self)

Regards
Russell

Pros and cons of course. I do want to use a LCD and have other HW options but I would also like to share the fruits of my labor with other spike owners. Therefore it would be nice to make it easy for an owner to who Is unlikely to buy and install all components required to use my code. I'm kind of torn between making a one-off for myself and doing something that is easy for other KISS owners to use.

Reading the docs it could be as simple as just installing a cheap raspberry Pi?

I'd personally consider any audio solution that didn't include ducking to be so inferior as to be useless, it's a pretty essential aspect of basic sound design for a pin.

Yes I agree. I'm already using ducking extensively. MPF has a solid set of tools for mixing channels and ducking. Essential for a rock pin.

Very cool. I'll give it a try this weekend.

Thanks Jan!

Sorry for the noob question, but does the spike system use a standard RGB LED matrix display, or is it a stern specific display? (typical signals for RGB LED displays are R1, G1, B1, R2, G2, B2, A, B, C, D, Strobe, and clock). I bought a bunch of those displays for the kids for christmas and accidentally (hehe) ordered an extra that might find its way into a pinball machine at some point. I also know somebody has written some sort of MPF to that type of interface, but haven't really dug into it yet. (It is about 20 projects from the top of the pile). I have absolutely no idea how MPF interfaces with displays in reality. Thanks in advance for any info.

So is it a simple bit per pixel framebuffer, and then to get grayscale they oversample? So it is 128x32 resolution = 4096 bits of raw data per frame. Assuming 32 fps it is 128kbps. Stern says it is 16 shades of grayscale, so assuming you can correctly time it is 2 Mbps for the raw frames. If the Cortex M0 keeps the last framebuffer sent to it, and just replays it, it would take significantly less bandwidth. (It would be even better if they just encoded 4 bits of grayscale into the framebuffer, and then it would only take 16384 bits for a whole frame.) Of course, that would never be backwards compatible to the old DMDs that don't have a microprocessor on them which is probably the real case. Thanks for the info.

Now I understand. I drive my RGB LED panels using a raspberry pi zero, and end up using this project: https://github.com/hzeller/rpi-rgb-led-matrix. (Of course, that isn't for a pinball project, it is simply for panels that display pictures). With your bit rates and explanations, it made it much easier to understand how DMD displays are being driven underneath the covers.

Quick chime in that I put my GB next to my road kings p-roc project so I can start messing using the one CPU while I experiment! Thanks mpf!!!

IMG_20171123_110044 (resized).jpg

Does this work with the home edition Spike Jr boards?

They're the same node boards, just one less core-driver node than a Stern pro. Same Spike 2 CPU node.

Hey gang, so I'm finally trying this out on my GoTG Pro (v1.06, Spike 2). I am using a USB to USB Null Modem cable. I have a couple questions from the MPF docs page here: https://docs.missionpinball.org/en/latest/hardware/spike/mpf-spike-bridge.html

1. In step 3 ("Edit /etc/inittab") it says "Last line needs to be changed to enable login without a password: S0:2345:respawn:/sbin/getty 115200 ttyS0 -n -l /bin/sh" but there's not really anything like that in my inittab file. Here are the contents. Do I just add the above to the end of the file? And would I actually only add "USB0:2345:respawn:/sbin/getty 115200 ttyUSB0 -h -n -l /bin/sh" since I'm using the USB to USB null modem cable?
   
   # /etc/inittab: init(8) configuration.
   # $Id: inittab,v 1.91 2002/01/25 13:35:21 miquels Exp $

   # The default runlevel.
   id:5:initdefault:

   # Boot-time system configuration/initialization script.
   # This is run first except when booting in emergency (-b) mode.
   si::sysinit:/etc/init.d/rcS

   # What to do in single-user mode.
   ~~:S:wait:/sbin/sulogin

   # /etc/init.d executes the S and K scripts upon change
   # of runlevel.
   #
   # Runlevel 0 is halt.
   # Runlevel 1 is single-user.
   # Runlevels 2-5 are multi-user.
   # Runlevel 6 is reboot.

   l0:0:wait:/etc/init.d/rc 0
l1:1:wait:/etc/init.d/rc 1
l2:2:wait:/etc/init.d/rc 2
l3:3:wait:/etc/init.d/rc 3
l4:4:wait:/etc/init.d/rc 4
l5:5:wait:/etc/init.d/rc 5
l6:6:wait:/etc/init.d/rc 6
# Normally not reached, but fallthrough in case of emergency.
z6:6:respawn:/sbin/sulogin
# /sbin/getty invocations for the runlevels.
#
# The "id" field MUST be the same as the last
# characters of the device (after "tty").
#
# Format:
# <id>:<runlevels>:<action>:<process>
#


2. In step 4 ("Edit /etc/rc2.d/S95game") that file is actually in the /etc/rc5.d folder for me. Is that okay? Here is the start of that file. Do I enter the commands "/usr/local/bin/avrisp /usr/local/spike/netbridge.hex /usr/local/spike/netbridge.fuses" and "exit 1" between the lines starting #!/bin/sh and # path to game-specific files ?
   
   #!/bin/sh

   # path to game-specific files
   SPIKE_PATH=/usr/local/spike
   GAMES_PATH=/games
   DUMP_PATH=/dump
   LOG_PATH=$DUMP_PATH/log
   SPIKE_MENU=$SPIKE_PATH/spike_menu/game

   # link to display processor image
DISPLAY_LINK=display.hex


3. In step 5 ("Install the spike bridge") it says to "Add mpf-spike-bridge to /bin/bridge and mark it as executable." Does that mean I copy the file "bridge-spike2" downloaded from the https://github.com/missionpinball/mpf-spike repository to the /bin folder and rename it "bridge" and make it executable? Or do I copy "bridge-spike2" to the /bin/bridge folder and make it (bridge-spike2) executable? (there is no /bin/bridge folder is why I ask).