Tim-
Never realized how much work you are putting into this project, until now! Literally every clip in the game could be changed which take some consideration of options, some discussion amongst pinsiders and then created or editted from the 2-hours worth of movie dialog. Once a plan is made for any clip, the perfect second or two needs to be extracted and then cleaned up removing pauses, trimming to just the right words, etc. Thats for ONE clip. Now do this a hundred or a thousand times, and this process is quite an undertaking. I get why you wanted to start with a bulk transfer and re-map from Stern's official kit rather than starting with a blank canvas. Any idea how many hours you have into Jurassic Park?

Just wanted to say... wow, and thanks.

If you are willing to use clips from other movies, your options increase dramatically. You'll have to weigh staying true to the soundtrack with having the right material. There may be a mid-point to use existing dialog which fits the purpose from the same actors but from other soundtracks.

Think carefully on this one as once you cross the line, there is no going back.

Flashed it no problem with Win32DiskImager software. Took about 3 minutes to download, and another 3 minutes to write the card.
Just need to slide the card into the machine tonight...

Thanks Tim

I got the correct 29 version, even though the link was originally for the earlier version

I had an existing 8GB card with a bunch of old stuff on it for use in my PC. I didn't bother preparing it in any way. I just fired up the Windows32Dskimager and it wrote Tim's file without any extra steps or issues.

Video Clips? LOL

For what its worth, my NIB end of July manufacturing date Premium shipped with a SDCARD made by ADATA and labelled "MLC 8GB"

Just checking code mod status at this point... Tim's original V29 audio-only upgrade code is solid. No bugs detected by anyone on this thread. The combined V31 audio+video update has a few bugs, some minor and rarely seen, but none the less, still there.

Is this accurate?

The more I hear about the circumstances of these crashes, the more it feels like a PB problem. It feels like PB is not respecting the code/data boundries, and allowing data to be written on top of code. (I think this comes with the territory of working with binary files, rather than source code and re-compiles...)

Does anyone know for sure if the STERN CPU board reads the entire SDCARD into memory at boot-up, or does it R/W to the SDCARD throughout gameplay and normal operation? If the former, then the type of SDCARD card has MUCH LESS effect on this situation. If the latter, then the card performance will make a difference.

Based on the boot times I see, the system seems to be R/W directly to the card during normal operations, which means the card R/W specs matter.

The imaging tools essentially ZERO the card since they write the entire block on top of anything that is already there. What they do is drop the entire image down to the card, starting at the first byte. Think of the imaging tool as a bucket of paint that gets thrown on the floor. Doesn't matter what was on the floor previously, its all going to be covered with a coat of paint. (The software V29 or V31 is the 'paint')

I am pretty sure it is the IMAGE itself that is corrupted, and I suspect that either a bug in PB is causing this, or the person specifying where to put a piece of data (audio or video) is mistaken on the starting point or the size of the data block. If a data block is too big, it could easily overwrite code.

Downloading 31TS now. Before I jump into going from 29TS to 31TS, any thoughts on its stability?

I thinking it has more to do with the actual shots your are making, which is triggering parts of the code and/or pieces of the data to be accessed which other people may not be using. So your SDCARD may have the same bugs in it, but you are not hitting those based on how you play the machine (Or how you have some of the audio settings setup). I truely do NOT think this is a memory-card type/format/reading/writing error. The same bugs exist, you just don't see them because you don't use that function or feature or sound or video clip...

If the crashes and reboots were occuring at random points throughout the games, the problem could more easily be attributable to the quality of the card and its read/write speeds, etc. But when the problems occur essentially at the same point that the system is accessing a specific piece of video data, it is starting to look like the problem is either 1) the block of code is not valid in the binary image. Data and code may be set on incorrect boundries due to a bug in PB, or 2) The type or size of data being read is incompatible with ther rest of the system. i.e. the video clip is making their decoder crash. perhaps a subtle V.264/V.265 issue?

Complicated to explain the two scenerios above without a ton of software details, but this is feeling to me more and more unrelated to the card quality or the mechanism used to write the card. I beleive in most folks cases mentioned above (where the system successfully boots to the first screen), the card *IS* written properly, but the video clip is being decoded improperly, or the video codec in use by Stern is struggling with the format of the clip in certain memory available conditions, or the video is overwriting actual code, or other even more difficult to find problem.

Exactly!!!! We need to start ruling out variables. The cards, the clips themselves, the game settings, the sequences before it happens, the sequences while it happens.

One reminder: there does not appear to be any crashes for the AUDIO-ONLY software modification. Seems like a bunch of folks are successfully running 26TS or 29TS (the AUDIO-only version) on the various cards they have, without crashes. Am I correctly remembering this? if so, this would seem to rule out the card. (BUT, then again there is a long shot that the hardware SD card reading hardware system used by Stern on the main CPU BOARD has no problem with Stern's originally supplied low-resolution video clips which may be highly compressed, but when reading new higher resolution video clips, the hardware may struggle, resulting in instability of the entire system)

Anything that rules out a variable will make this easier to track down.

Its starting to feel a lot like a decoding issue based on using more complicated video clips. Frame rates and video codec encoding/decoding differences may be part of the root problem. Encoding is done during the authoring, so PB and other tools are involved. And then to decode this more complicated video, it takes more CPU and memory to do so. ("Complicated" in this note means the rate of image change and the level of detail in each frame) Not exactly knowning the architecture and real-time Operating system of the Stern CPU main board, I can only venture that this higher CPU&memory resource demand for decoding these newer video clips from the movie may be causing a problem.

It could be the amount of free memory at the specific point in time that a clip is played, and the available resources at that moment, which is affected greatly by the sequence of clips that have played previously which varies from player to player, and game to game. Most operating systems leak memory over time. Even a Windows PC has less available free memory after 2 days of usage versus when you first reboot it. Applications and drivers get loaded and consume memory over time. Operating system designers include a bunch of 'housekeeping' routines in the operating system itself which try to free up this stranded memory which is not really needed.

My thought is that decoding certain hi-resolution or action intensive clips may require more resources, and depending on what resources are available at the MOMENT of decoding, it may cause other critical system services to run out of memory, and fail. THis is just a theory, and if true, MUCH harder to resolve since the hardware itself is fine... (including the SDCards)

I feel like we are trying to thread a needle while wearing boxing gloves. Without the assistance of Stern engineering, using PB and most of the other things that are being applied to their code is a struggle and creating a partially obscured result. We can only see the accuracy of what was done by NOT seeing crashes. We can't really verify the code itself... just the observable operation effects of using the new code (and any crashes or hiccups that may be seen)

I know we will find the answer, but lots of trial and error required. And PB is the wildcard because we trust it is doing the conversions and placements properly. That said, it sure feels like software to me, not hardware.

Not to ignore hardware possibility entirely, the main thing that changes inside an brand of SDcard is the controller. The specific controller used defined the speed at which data can be accessed in a sustained fashion. There is a possibility that a card with slower read could cause some of the rest of Stern's real-time operating system code to timeout. This is a very long shot, because for slower reads, I would expect to see stuttering, not crashing. And I know that Stern uses the lower cost "MLC" type memory cards, which are slower in most cases.

But, anything is possible, so we need to keep looking for cases that CAUSE crashes. (Ironic, but keeping track of cases that DON'T CRASH is less helpful, because any sequence related issues simply may not have occured on those machines: e.g. Hitting Skill-shot, followed by a Trex multi-ball, and then a Jeep rotate.)

Still just looking to eliminate variables...

This is starting to feel again like a software only problem. If I am keeping score properly, the Stern software on the stern cards doesn’t crash. I don’t see a single report of a crash using unmodified 1.02 or 1.02 with audio only mods. It’s only when more complicated video clips are added that it seems to crash “some of the time” on a myriad of card types.

Feels like software to me. Either the video encoding or a bug in PB itself.

Yes, there is something causing crashes in the 31TS audio+video build, whereas the Stern factory stock 1.02 and the audio-only 29TS do not. While we don’t know the cause just yet, appears that it could be a sequence of play that causes crashes when accessing a video clip. Still lots of unknowns and we’d love to hear about the specific brand/size SD card you were using when it crashed just to try and help track it down.

In my last note #769 I made a statement that regardless of brand of SDcard, when running factory 1.02 or when running Tim’s 29TS audio mod code, we have NOT seen crashes on anyone’s machine. I WANTED TO CHECK THIS STATEMENT FOR ACCURACY to be thorough in the process to track this down. If you have an experience that conflicts, please let us know as much detail as possible. Card type, how you wrote the binary image to the card, which version of the software, how long you had been playing the machine since it was powered on, how many games since power on, how deep into the current game were you when in crashed, and what shot you were making when it crashed.

I think you were running 30TS the first video+audio mod

Is another version coming soon? Just want to know if I should leave my backbox open... LOL

8GB

Any last consideration of replacement of the two short clips used at the end of each ball, when rolling up achievements, the DNA Collected and Amber sequences are awkwardly cartoons. Surely a better video must exist?

For what its worth, it appears that I found city information for two of the addresses:
beachfrontcondo314 (Petra & Randy in Daytona Beach, FL)
haris.hsdistribution (London, UK)

I like it...

My understanding is that everything the game needs to run is on each SD card. If you swap the card, you swap the entire software. 100%. Each time the machine is powered on, it reads all of the games base software from the SDcard. In fact, it appears that throughout game play, the card is accessed continuously for audio/video data. (That why fast read Class-10 SD cards are a must). The only thing that is on the CPU board that 'stays with' the game post card swap are some NVRAM counters for things like high scores. (and those appear to be zero'd everytime a software version is changed).

Think of "installing the software" the same as "installing the SDcard". They appear to be exactly the same. Again, if you swap the card with software versions up or down, you swap the entire software and the machine is happy.

My understanding is the 8GB software image that is stored on the SD card is the entire environment that gets loaded throughout the machine at each power up which is why you can swap software version numbers back and forth without worrying about code mis-match. I do NOT think there is any type of permanent code flashing for the cpu or other node boards. So when power it applied, the cpu board reads the operating system for the game, reads the node initializing code and sends each node boards their individual code, and the SD card then becomes the pool of audio/video images to be used throughout each game play. That card is the heart of the machine and loads EVERY piece of code during its lengthy boot-up process.

(Note: There is a slight chance it also reads the ~6GB of audio/video data into some type of CPU board on-board memory at power up, but based on looking at the board itself and seeing no large RAM memory chips, as well as the amount of time it takes to boot up which is a bit too fast if it were reading the entire operating system, node initialize blocks, and ~6GB of audio/video data. Either way, this does not affect my above comments)

Yes, just open the backblass, pull the factory SD card, and put in Tim's code that you put on an SD card. Close it up and start playing!

Side note: I think this maybe confusing to people because they are trying to compare the Stern machine to what happens on a PC. On a PC, the operating system is supplied on some kind of media, and is installed to a local hard disk in the PC. THEN additional applications and features are ADDED to the PC's hard disk. If Windows needs an update, then portions are layered on top of what you already have. The PC's hard disk keeps everything. It's a clean, and supportable approach used by Microsoft for 30 years.

THAT IS NOT HOW IT WORKS WITH SPIKE2. As it was explained to me: The entire machine software and media is contained on the SDCARD. Pull the card and the machine won't boot or run. There is no hard disk or SSD on the CPU node board. The SDCARD *IS* the disk so to speak. What Tim does is use PinballBrowser (a binary editor that specifically understands the layout of Stern's binary images) to modify the binary system image that resides on the SDCARD and overwrites the stock audio and video clips which are located inside the binary image on the SDCARD where it remains. Each boot, it reads the SDCARD software portion of the image into RAM memory, initializes the various node components, and then from that point forward simply uses the SDCARD as the data source for audio/video clips (Thats why fast Class-10 SDcards are important because it is reading those mdeia clips from the SDCARD in real-time). Stern's software doesn't know the difference between their own clips and Tim's, it just plays an audio clip that it expects to find at location XXX, and which it believes has a duration of YYY seconds.

If you liked the 35TS version, you'll love the most recent one!!!! Get ahold of Tim and see if you can gain access to it. It's a simple download, unzip, and then using Win32diskimager, just take a blank 16GB card, write the new version, and replace the card in your machine now, with the newly written one. Nothing else has to be touched. Everything goes with the card inserted, so you could keep multiple cards if you like, including stock 1.02, stock 1.03, and Tim's code. Swapping the card changes the whole machine.

Yes and No.

Updated:

Yes, Support for the JP1.03 code has been added to PB. The 1.03 software can be modified by anyone using PB now and you can add audio and video as you like.

But... Updating Tim/Delts clips into the 1.03 image will take hours (update: Tim says not too long) of his time required to convert the media placements that were used in 1.02 to be compatible with the 1.03 code. It is NOT as simple as pushing a button to install Tim's updates on top of 1.03. It is a hand crafted and very complicated process, in many cases clip by clip, and there are 3500+ clips.

Cross our collective fingers!!!

Win32diskimager will overwrite whatever is already on the card, but make sure you are writing to the correct drive letter!

It will be interesting to watch if Stern will keep putting resources into additional firmware gamecode updates for JP. I suspect it's directly related to revenue potential (measured by orders/backlog) on each title. For comparison, I just checked the changelog for JP and 1.03 is the TENTH official release of JP code, with the first version shipped in September 2019 and the most recent in late Oct20. That is 10 releases in 14 months. Other titles have various updates and project lifespans, such as Beatles had 6 releases over 4 months latest in Feb20, StrangerThings has had 15 releases in a year most recent two weeks ago. With the current demand and backlog for JP, I suspect we have more to come!

One observation: The game code for StrangerThings had 15 updates, and with just a couple of exceptions, each one of them added significant new functionality. Again, we'll see if JP has more to give, or if we are getting towards bug fix only mode...

Time will tell.

It will be announced in this and a couple other JP related threads shortly. Tim is hard at work finalizing it now...

The Spike system DOES has random access "memory" but DOES NOT appear to have any significant amount of FLASH memory, so every power ON sequence, loads the entire operating system from the card in it's entirety. That is why you don't see any screen information for 10-15 seconds after you turn the power on while it's loading the operating system.

My crystal ball: I am predicting 1.04 in the February timeframe, based on a little research on the changelogs for a bunch of other tables when production is still underway (which I see due to delivery dates already being given for Feb21). At least that gives Tim some holiday rest time....

If you've donated to Tim's effort anytime in the past, he has your email address and will be sending new emails to confirm the 39TS link is active for you. Due to some recently encountered Google policies, it's been harder for him to get those emails out in one batch. Be patient...

Unless someone buys Tim a JAWS machine and drops it in his house, the likelihood is low that he would (could) work his magic on a new title. I think he's done enough for us lucky JP owners!

https://www.amazon.com/SanDisk-Class-UHS-I-Memory-SDSDUNC-016G-GN6IN/dp/B0143RTB1E/ref=sr_1_2

Normally you can just overwrite whatever is on the card already. That said, there are a FEW CASES I have seen where the card will have more than one partition on it already and Win32diskimager has failed. The remedy for that is to open Windows's own disk partitioner (Type "Disk Part" in the lower left search bar and you'll see the application popup. Then simply find the SD card typically called "Disk 1" or 2,3,4 etc and make sure it just has a single partition on it. Right click to remove all partitions and then create a single partition).

******************************************
***** Do NOT attempt this if you are unfamiliar with the above partitioning process!!! It could kill your PC if done wrong!!!!!!!!
******************************************

If this sounds too complicated, grab another fresh $6.50 SanDisk card from Amazon.

I never really looked into the root cause of this multiple partition behavior, but I suspect he was using a USB plug-in multiple card card reader. It may have something to do with the way Win32Diskimager interacts with windows disk subsystem, causing Windows to attempt to enumerate ALL of the drives on the multi-card SDCARD reader- even if they have empty slots!

I would venture to say that you saw a new drive letter popup for each slot on the reader.... no worries. Just ignore than all.

Fat-32 has a 4gb file limit, but most PCs have their hard disks formatted as NTFS which eliminates that limit

Posted several times earlier, but here is the shortened list of steps:
1.Download file to your Windows PC's hard disk which is local (not one-drive hosted)
2.Using file explorer, find the ZIP and Double-click on it, a windows will open showing contents of the ZIP file It will be a single RAW file about 8GB in size
3.Select the RAW file with the mouse right-click and COPY.
4.Find any directory you have space on and right-click in that folder to PASTE the RAW file into that directory
5.Insert your fresh 16GB or larger SDcard into your PC, noting the drive letter identified by Windows. (It will never be C: !!!)
6.Now start Win32DiskImager (installed previously) and locate the RAW file for input in the left size box, assure the SDcard drive letter is selected on the right side of the screen, and then hit WRITE button at the bottom.
7. Wait 10 minutes for the "Success" message
8. Done. Don't look back. Don't read or write the card in the PC, just physically move the card to the Pinball machine.

The safety net is: you always keep the original SDcard that came with the machine. It can always be reinstalled if something goes wrong.

That said, it’s quite easy if you have a factory fresh SDcard and follow the instructions.

Lots of notes covering this exact process inside this thread, but try #1453 to get a short version I wrote awhile back

One of the issues Tim and I wrestled with a few months ago is the fact that the first attempt writing the image to an SDCard creates multiple partitions on the SDcard card. If the first write fails for any reason, then you now have a SDcard which has multiple partitions on the card which may interfer with subsequent attempts to write the card. (The resolution on a Windows PC is to open Disk Manager and remove all of the partitions on the SDCard, then use Disk Manager to create a single new partition which restores the card to the condition it was when shipped by the factory).

The high scores you reach can be saved to a USB stick before you swap the code. Do the save to USB, the load new code, and then your high scores from USB based stick can be restored.

40TS is the latest. That said, it would be really hard to tell if you are running it by just looking at the card. I would suggest just contacting timlah79 for details on how to rewrite your card.

Have your grandson take a listen to Tim's music at the link he provided above. I have listened and it's quite good. I am sure Tim would be thrilled if his music started generating a 'buzz'. Although he is in high-tech as his day-job, and the digital author of the amazing JP A/V update, one of his 'hidden passions' is creating original 'RAP-ish' music. He's quite the musical artist. (At one point he offered a version of the JP code with one of his own original tracks)

If you have ANY valid new gamecode image, and the SDcard write was completed successfully, then you are good to go.

Refer to this guide from Stern: https://sternpinball.com/wp-content/uploads/2019/02/How-to-Create-a-SD-Card-for-a-SPIKE-System-Pinball-Machine.pdf

Note1: This Stern guide works for any valid gamecode image. You download the ZIP file, you open the ZIP and copy the 8Gig gamecode image itself, then you use the utility to write the card. Don't even try opening the resulting SDcard in Windows. Just pop it in place of the SDcard already installed and power up the pinball.

Note2: Stern prefers to use the Etcher utility, but many others use Win32Disk utility. They both do the same thing, but some folks have PC compatibility issues with one or the other so you can try them both.

Actually it would be pretty easy for Stern to see that the data block section has changed if they wanted to. They own the operating system and could easily scan the data block anytime they wish and compare the actual checksum against the expected checksum and report any discrepancy next time the internet is accessed for any reason. That said, no evidence yet they have anything like that in place.

Intellectual Property is always a very real topic. The license holder is always obligated to comply, and the IP owner is legally entitled to full compliance. Stern must demonstrate to the owner of the IP that they are protecting their license, and the way they do so TODAY is with their license agreement that they supply with every machine (yes, albeit unsigned). This notice identifies the existence of the IP and their desire for compliance. That is the simplest and most basic step a license holder can use. There are other steps of enforcement and remedies that are possible and more aggressive. It depends on how big the problem becomes. Look at what some of the biggest software vendors do... When they detect a license abnormality, they usually start enforcement by advising the consumer of the situation, and offering the means to comply. Other vendors are more aggressive. Like I said, there are a range of approaches and remedies.

Could Stern put a notice on the screen next time your machine boots that says that unauthorize gamecode is detected? Sure. It would be a next step, doesn't mean they brick the machine, but it would be an indication from Stern that something may be awry. Their enforcement is up to them, and they usually want to maintain a happy consumer base so lots of things for them to consider...

Always best to drop a note to timlah79 for the latest update and status.

Anything is possible, but if I were in the enforcement game, I would have a startup process that checks the data block locally.

I think the most tangible response to code modification to date has simply been advisory about the licensing. That satisfies the early stages of infringement, but would need more teeth if the issue gets out of hand. The IP holder could demand more enforcement or pull the license, but those are extreme next steps...

Depending on the NVRAM or flash chips used, they can easily flash 10,000 to 400,000 times these days. I think you are safe...

timlah79 got your ears on good buddy? LOL!!!

The machine retains NONE of the operating software between power-cycles. When you swap the card and re-power, the entire machine reloads based on the card that is installed in the slot. If you swap the card again, it reloads entirely again. What that means is the machine is running 1.06 entirely because it has a 1.06 card installed. The machine can be powered off at any time, swap in the 1.05 card, and the machine reloads to 1.05, and then do the same to go back to 1.06.