By using a common format (FAT32 in this case), they are making it very simple for anyone to copy the data to the SD card. However, in that scenario any checksum would be read on that higher level format whereas the actual memory locations would be determined by the low level format (using hard drive terminology as I'm from a decade behind this technology). So a checksum comparison would be handled on the PC through FAT32 unless a program was written to analyze the low level format, which is orders of magnitude more complex. The alternative would be to use an image of the ROM and then have some sort of bootstrap that writes it to the EPROM, but I have a feeling that would introduce its own set of problems - and I'll flat out guess having Pinheck do the hard math just isn't an option. It would need not only the processing power but also the RAM to do the work in; I'll bet a case of beer that Parker isn't trying to hear that.

A checksum could help, but it would be more about detecting if the file structure if contiguous or not.

(2) things get changed during an update. The Propeller code on the DIP8 EEPROM, and the main PIC32 processor on its internal FLASH.

Propeller (A/V) code would be easy. It's always 32k. We could append 512 bytes (one sector) to the end of the update file that would contain numbers 0-255 repeating twice. During the update (which is performed by the Propeller chip as it boots first) we could find the start of the PROP.BIN file, advance the pointer 64 sectors (512 bytes per sector x 64 = 32k) and then check if we find 0-255 0-255 there.

If we don't, then we know that file is not contiguous. We print an ERROR telling users to double check the creation of their SD card.

PIC32 code (the actual game code) is a bit trickier. Its length can change as options are added to the game. We could add a dummy sector to the front of the code that indicates how many sectors long the update is (max 1024 as the PIC32 holds 512K) and then at the end of the update file (past the remainder of course) we put a pattern of 0-255 0-255.

Only if BOTH files pass the "end of file is where we think it should be test" would the system update.

Certainly something we should add, in the meantime, READ AND FOLLOW THE SD CARD INSTRUCTIONS!

Does that mean the issue is the file being contiguous rather than where it's actually located on the SD card?

Sticker in the head? RTFM

Have a chat with Charlie at Spooky. Talking through these tweaks on the wire form will help both you and the production line.
[email protected]. He is scary fast getting back to you - so dont' be surprised.

OK let's say you have a file that's 1k long. And on the disk there's 1k of space after it, then another file starts.

If you append 2k onto the first file 1k will fit, but then you'd run into the next file. FAT32 jumps to a new location and continues the file there. This files pieces are called a cluster chain. This jumping around can slow down file seek, defragmenting a drive puts files back into contiguous lines.

pinheck doesn't follow cluster chains. It assumes all files are contiguous from their starting point. Which they should be, as long as the files are copied to a formatted card.

Please note, when you download a ZIP of the SD image, extract it to a folder on your computer first, THEN copy the files to the root of the SD. Do not copy the ZIP to the SD.

The instructions of the spooky.com/game support page are in RED, CAPS, UNDERLINED. Its really pretty simple, but you have to follow the formatting FAT32 to complete clean the SD file pointers and data, and be sure your files to copy are one of each file name, and not partially upzipped, then follow the rest of the steps. My personal experience warning!!! AN INTERRUPTED DOWNLOAD CAN LEAVE A PARTIAL prop.bin or .prog file and copy garbage to the EPROM, even if the SD card is formatted cleanly.

I'm confident Ben/David are adding the file contiguous check to verify the files, and that only one filename is there. Doing that, plus the clean SD format in FAT32, should avoid the corruption written to the A/V Eprom.

4 issues -
1) can an Android phone cleanly format an SD card in FAT32 configuration?
2) there is a special cable that can directly connect to the PinHeck board, and the prop EPROM can be written to directly, but this was a cable connected to a Windows OS laptop - would copying files from an Android OS directly would honor the contiguous bytes requirement
3) will that cable have an adapter plug for an Android phone?
4) you can foul the EPROM, and be down on location until you get a new one and presuming you know how to install EPROMs.

Please don't destroy the TFTC real classic horror pin in picture, what is it doing in pic?

Hope code updates are similar to Stern.

Download to usb stick and follow simple instructions.

They are, download to SD card and follow simple instructions.

I don't have a PC, but can run an emulator on my Mac. I hope this will work. What are people who don't have PCs doing to update the games?

..which relies on the OS doing the copying to do so contiguously. I guess the Mac fails because it likes to add its metadata files to the destination? Or does it not copy contiguously?

On a Mac, there's always dd!

I tested creating a card with a Mac the other day. Seemed to work, but then again I didn't do the actual update process.

I can try that out as well.

That would be great Ben. I'd hate to brick my card and have to send it in.

BTW, have an AMH coming. Love the game after playing it at a friends bar. Have a RZ coming as well. Thanks for your work on these.

I use a mac and it worked perfect, just follow the directions, if you skip a step it will give you an error.

I'm positive I did not delete the entire contents until "after" I put the card in the machine and tried again after it was already bricked. Since I do not have a SD card reader in my PC, my Surface, nor my work laptop, I'm assuming it's OK to go ahead and buy a USB to SD reader for $10 or so? I just don't feel like ruining another board.

Great thanks for feedback!

Great pin guys, played it last week and it was a blast!

Nice where did you get to play it at man?

I've had two of the three....Not had the 1000 corpse issue, but I've also blown out the flipper fuses, and I had the same ball stuck on wires issues in two different areas. The wires definitely need either a better route or something to secure them better. The fuse issue for me coincided with infection where the flippers swap, so who knows...It's not happened since, but I've also not had infection mode active again.

Right in your home town, on Main Street.

Ummm, blew a fuse I think, lost all my "Sol Bank 2 coils", soooo where the hell are the fuses and how do you replace them?! I need a live in pinball tech, I hate working on games anymore

On a side note I'm not sure if it was random or maybe a code thing. I had this problem occur when I was doing a 2 player game and at the very end of a ball got my first "infected flipper" or whatever it is where the flippers were reversed(I think anyway, it was weird) It only happened for a quick moment and lost the ball, after that was when my coils weren't working.

Nevermind found them, hidden in those black covers. Still curious on the cause of these fuses blowing, seems a common problem occurring for a lot of people.

They are very easy to replace and I don't typically like to work on machines. However, I'm getting better and better each day working on them and aren't as afraid to pull up the playfield to figure out what's wrong.

As for the fuse, which fuse is blowing? If it's the far left fuse (looking at the board from the player's view) then that is the fuse most are having issues with. I can positively say 100% that my knocker was causing that fuse to blow. Otherwise, I've had zero fuse issues.

Cool that's my machine was just curious if there was another in Indiana or not. Glad it played well.

Heck yeah! Thanks for sharing it with us!!

Wish I would have been more aware and was able to get my name on the list for it.

While we were there Larry was talking about the upcoming tourney, said there would be a AMH machine there. I take it that one is yours as well?

Anyone have an update on what's being done in production to troubleshoot/solve the fuse blowing issues? Seems like there are plenty examples of this being a problem that needs to be remedied.

If I was to make a guess. Which I can in no way verify. I would say the following:

the 60's are wrapped up and ready to go.
The 70's are in production.
The 80's are in pre-production

Cool thanks. I'm in the late 70s so I should be finding out soon.

That's exactly how my fuse blew....Got infection mode, lost the ball and the fuse blew. Except mine was the center fuse for the flipper. Sounds like a code issue possibly.

Yes sir.

Having the fuse issue too - emailing Charlie but sorta good to hear it's not just on this machine

Our game will most likely ship this week, and we have #67

Nice..

I hope Charlie/Ben/Spooky figures out why the games are tripping fuses. I guess that's better than blowing up a board.

I think you left off Fawzmagames, the current Spooky programmer. Gonna need the lead code guy on the case (guessing he is already working long hours to get it sorted out).

We turned off the "infected mode" on our game once hearing of possible issues and everything has been smooth.

I'm looking into the flipper code and changing the order of logic to see how it works. Suspecting there is a possibility that the high and low coils could fire at the same time. I'm also going to kill the flippers after the ball drains.

Don't forget to set the switch speed to fast in the game menus on version 8. It's not set by default, it greatly improves gameplay.

Thanks - I didn't realize this wasn't set to fast by default. It makes such a huge difference on my machine.

what setting needs to be set to fast, looked through the menu but wasn't sure what setting needed to adjust speed things up.

It's the 'POP-SLNG SPD' setting in the main settings.

Awesome thanks for the info. Will have to adjust it when I get home.

Hopefully this is fixed as default in version 9.

A lot of technical shit lately, how is everybody liking the game play. Looking forward to getting mine soon!

Yeah... we need to dig a little deeper in the code before we release more updates. We know the fuse issue is related to "Infection" mode / PWM. In my defense, I almost understood some of what Ben is saying! Lol...

Talked to Terry at Pinball Life over the weekend, and he's going to stock all our fuses asap to make this easier.

Sorry for the issues! At least they're all things we can address.

it is no big deal Charlie. Your guys customer service is EXCEPTIONAL!

The community knows this is just a small hiccup. I am sure it will be fixed in no time.

Curious, is there any RGB insert or GI lighting in Rob Zombie? What's the lighting like?

All standard LED's in the GI and inserts... with RGB strips in the backbox and over the back of the playfield.

Thanks Hilton! We do our best man. Last thing I want is to show up anywhere with people mad at me.

Thanks Charlie, I was reading about the rev 5 of the pinheck board and noticed it supported external RGB. I assume you are using the RGB strips as extended GI to set the atmosphere. Very nice.