Since I tend to use multiple PCs at multiple locations, is it possible to bind PB key to a VMWare virtual machine (which hopefully does not reset the UUID at every copy) ? Or does this fall into the realm of "not allowed by PB licence" ?

On another note, does the communication patch send additionnal data besides what Pinball browser uses ? Specifically game information like game mode, etc. Based on the work done by flynnsbit on his Tron Mod I would tend to think yes ?

Looking to build a simple unit to test the concept of driving external HW (lamps, etc) using a modified SAM firmware

To clarify, I don't intend to run PB on more than a single computer.

However I do find inconvenient to bind the licence to a specific HW. All modern SW have some kind of floating licence which allows the licence to be transferred.

My notebook is more than 4 years old, and while it's working fine for now, chances are that it won't last much longer (this is my office laptop, and it's being carried all over the place). From what I understand, should my notebook fail, I would have to buy a new licence for my new computer, is this correct?

Regards

Sidenote, I'm trying to see what is available in the repository, I assume the capability to load is locked, but is there a directory somewhere ? When I try to load a macro the list is completely empty

I'm specifically looking to see if there are colorizations available for Star Trek Premium and Tron Legacy Pro

Thanks and regards

I naively attempted to use Star Trek 1.61 colorization macro on a Star Trek Premium ROM.

As it turns out, the macros seem locked to a specific ROM version, and generate error if used on the wrong ROM. Even when using the correct ROM (just for testing, I don't own a Pro anyway), I get memory errors at a later time

So, a few questions:
- Am I right in my understanding that any rom change (even upgrading to newer code, but same model) would require a manual update of all the macros ?
- If the only reason memory offset of DMD frames locations ? I did a little bit of poking, it would appear than on STPRO1.61 the first meaningful DMD frame is 0x5AD (Stern logo), and on STPRO1.62 it is 0x5B4. A quick spot check on a few frames indicate that there is a fixed offset. A logical workaround (provided there is no added DMD frames or other ordering change) would be to add the capability for DMD colorization macro to provide an offset (in this case, 33 in hex), is this possible ?

[EDIT] and I checked, looks like it's only a few added frames between the two DMD sequences, 7 to be more precise, at least on the same model (ie comparing Pro 1.61 vs Pro 1.62).
[EDIT2] and I compared STPRO1.61 and STLE1.62, there is a 9 DMD frame delta, and it's constant (ie all added frames are prior to the first Stern pinball logo, ie 0x5AD on the Pro 1.61).

It would be nice to have a way to identify all DMD differences, 0x5AD is 1453 frames, not fun to go through all of them just to identify the differences, is there a "DMD frame compare" option ?

Also, I'm getting "not enough memory error" in some macros even when running the macro on the appropriate ROM (for example "EditImage,0x8FC"). Reading through various forum posts this seems to be tied to the amount of ROM memory, but in that case, why would the macro still be in the macro file ? Anyone has managed to get a full run of the macros on a STPRO1.61 ?

Regards

Thanks for this info, I'll look into it

Just for clarity: I'm trying the macro from the repository on the same ROM as what the macro was designed for, hence why I'm rather puzzled (there are hundreds of memory out error, I can't believe the author intended it that way).

Good morning,

I've been trying to use Pinball Browser to run colorization macros on a Star Trek ROM, and it's driving me crazy: even using the stock ROM for which the macro has been designed for (1.61), so no deviation from the original ROM used by the owner of the colorization, I get loads of "out of memory" error, to the point where I can't even finish the macros operation since I literally have hundreds of them, and I have to click on "Continue" every single time.

I can't imagine this is what the original developer of the mod intended. Anyone would have his contact information ?

Ah good point, no I did not as I was not aware of this capability. Will try right away

(Edit) just tested, it does indeed allow to go further, but it still fails with an out of memory error later on

@oga83, pin2dmd has been updated to natively support colorization for Stern SAM using the pal/fsq file method, which as far as I understand has no limitation with regards to rom size, and does not require patching the Rom.

It would therefore be very helpful if PB included an option to export all DMD frames so that could be imported into pin2dmd editor and used as is.

I understand this implies that your colorization mechanics would not be used anymore, but in the end I think it's for the greater good, as:
- no need for rom patching, much easier to deploy
- no rom size limitation (x-men anyone....)
- colorization can easily be tested (just put the files on a midcrosd card, insert, done)

Any comment?

PIN2DMD has a microSD card slot, and you store these two files (pin2dmd.fsq and pin2dmd.pal) which contain palette information and trigger data to display a colorized frame.

This means that you do not need to modify the ROM, everything happens downstream. It also means that you have no limitation in terms of size, since all color data is stored in these two files, not in the ROM itself.

It also means that you can update the colorization by just replacing these two files, so it's very convenient (no need to reflash the ROM) during development.

PIN2DMD Editor requires a dump of all DMD frames to colorize. Today this is done by dumping the DMD frames using vpinmame or a real recording on a physical pinball, then you edit using the editor. So just the hashes would not be sufficient.

I understand that PB cannot dump the DMD frames today, but is there a known technical constraint/limitation, or is this primarily a matter of engineering investment ?

Regards

Good morning,

Would anyone has access to PB older versions ?

Rationale: I've encountered many "out of memory" issues with PB latest revision trying to apply colorization macros from the repository. I read somewhere that it did work on older revision, and indeed I can't understand why there would be so many errors and the original author of the macros would not have realized it.

I'm trying therefore to go back in time

Based on the macros date from the repository, I'm specifically looking at:
- Last revision released before Dec 25 2019 (Star Trek and Avengers colorization by Sharkky)
- Last revision before Nov 22 2019 (AC/DC Colorization by PinballMikeD)

Hopefully I can then run and apply the macros completely

Thanks

I was looking at using In-Frame, is there a limitation ?

[EDIT] Using Side-channel instead of In-frame and most of out of memory errors are gone (two vs hundreds)
[EDIT2] Trying to apply a ShiftID rule, since the macros was defined for ST Pro 1.61, and I'm running on LE 1.62. Analyzing the DMD shows that DMD frame 0x5AD on the Pro is 0x5B6 on the LE , and everything else after that is identical

So trying to use that command, but I get a "Macro error", with no indication is to what would be wrong, any information would be welcome

ShiftID,0,0x5AD,0x5B6

[EDIT3] macro are case sensitive, it should be ShiftId instead of ShiftID, it works now.

I still get a bunch of out of memory errors though, but that might be precisely because I'm applying it on an LE which has a few more DMD frames, so less space

[EDIT] There definitely is a MAJOR difference. With In-Frame I get hundred of errors, with Side-Channel, only two
I guess i'll have to use side channel then...

So even using Side channel, extend memory, ST161 Pro ROM and the macro from the repository (so no change), I get hundred of "out of memory" errors.

I would really welcome the possibility to test the older version so I can determine if these errors disappear, as I can't figure out how the original author resolved these errors.

If you do a colorization from scratch, best is to use the new PIN2DMD method, which does not involve patching the ROM, and is therefore not limited by ROM size (plus you get 64 colors support). It also has the benefit of not being dependent on the ROM (besides the trigger), the same colorization file can be used on a Pro/Prem/LE regardless of the rom version. This is a recent method that was implemented by lucky1 on PIN2DMD, allowing to support Stern SAM machines. There has been a few very nice releases recently, unfortunately not Star Trek.

Since it was not available with the regular PIN2DMD PAL/FSQ file method, I've been looking at options to use the macros, no luck so far

Good morning everyone

I'm rather puzzled: I colorized using PB macro system a Stern Avengers (SAM version) ROM. So far so good, got a few out of memory, but in little quantity so thought I'd give it a try

I generated a serial version by adding the comm patch, and created the corresponding ROM.

Flashed it in the system, boots fine, start text is white, however even without using the serial cable I got some working colorizations, which seemed "OK", meaning hulk was green, captain america shield was red/white/blue, etc

So I'm confused, is it possible that a serial patch generated ROM actually includes in-band ?

Also, I tried to connect the PC to Stern SAM to check COM connection, but of course the serial USB adapter I have does not have a valid windows driver. Will Zadig USB drivers work ?

Regards

Yes I did

But I believe I figured out, turns out in this colorization the default palette actually works nicely for ma'y scenes. There is no palette switch though.

Will try to make it work with in-band first, and move to serial if it does not work

Usually the difference between Pro and Premium is a few shiftIDs. Probably worth checking

Yes I do

PMed you

Question to oga83 : is there any frequency filtering or dynamic compression when importing a WAV file inside the ROM of a Spike2 game (specifically Star Wars) ?

When comparing Stranger Things and Star Wars soundtrack, the difference in bass response and dynamic range is staggering. Even with stock speakers, Stranger Things sound better than Star Wars with replacement speakers (backbox and cabinet). I did a quick frequency spectrum on the "choose your hero" track from Celofane ROM, and indeed it shows a significant different in terms of bass response compared to the Stranger Things theme. Need to check with the source file if the same applies, but in the meantime it would be useful to know if PB does indeed perform some sound processing when importing (maybe to match ROM file size for ex).

Regards

Thanks for the clarification, which raise two questions: so when importing a file which is at a different sampling frequency, PB will re-sample before integrating into the game ROM, correct ? Whereas if the sampling frequency is identical, it will not re-sample ? What should be the file format for minimum conversion stages (ie WAV file, no compression I assume ?)

Also, just to be sure we are on the same page: the low pass filter cutout frequency, if enabled, will cut all frequencies above the defined value in the checkbox, right ? May I know the rationale for this particular setting ?

Another model could be monetizing the output of Pinball browser. After all, this is what is being done with PIN2DMD, where the colorization authors can profit from their work through a donation system.

Originally the colorization files were not locked down to a specific HW, over time there was abuse (as there usually is when content is not protected), so latest PIN2DMD updates enables locked content.

This ensure that a/ end users can still benefit from the work b/ creators get some profit

The same model could apply to Pinball Browser, in which case the yearly licence make much more sense

Can you clarify what you mean by 'codecs' in this case? As for me 'codec' is basically the compression algorithm. Or are you referring to something else?

So yeah that was the same understanding. Your clarification did make more sense then.

But that means that Stern is not using a standard codec for all samples, each is different?

What a pain....

h264 is a general purpose codec with many different subsetting (level, profile, yuv format). You probably need to match your encoder settings to use the exact same settings as the original file.

One way to identify the settings would be to use the Mediainfo application. It will report codec details, in particular Level and profile (usually in parenthesis, for example High@L4 which means High Profile Level 4.

Load from USB stick? Can you clarify what you mean?

Pinball Browser is really not complicated. I'm not sure why your two sw guys can't get it to work, and there's a lot of info on this thread. I mean, I was able to make it work seamlessly, and I'm not a SW guy (OK, maybe a little, but I certainly can't claim that title)

A few points:
- you need to download the full binary image (not the update file!) of the game from stern website, that's what PB can load (and it can take a long time to load sometimes)
- the latest release by stern cannot be opened by Pinball Browser, the usual cat and mouse, so you have to download older revisions (there's a post somewhere outlining which revision PB supports)
- once your modifications are done, you need save the full image from PB, then flash it using BalenaEtcher for ex on a new SD card, and use that one instead of the original in your machine. This will reset to factory default by the way.

With regards to swapping content, ie replacing songs, please be aware that you need to match duration of sound clips, you can't simply replace one sound clip with another one of a complete different size.

Otherwise, there's ton of content and posts in this thread.

Apologies, missed that question

We'll I don't know if Stern hosts the old version (I doubt it, but hopefully if you ask on the Rush owner thread someone has it somewhere). I don't know on my side where to locate it

Is it me, but where have all links pointing to IMG code gone on Stern site ? I can only find SPK files now.

If this is for a real pinball, it won't work. Star Trek physical ROM is too small. The macros you have were designed around the Virtual pinball version, for which there is obviously no limitation. I know, I spent countless hours to try to make it work (I have a Star Trek Premium), I could not get these macros to complete without numerous "out of memory" error.

When I tried to make it work, I did complete the macro run, but you get many out of memory error, so the colorization is incomplete. Hence why I gave up.

Maybe 5.97 does not have the issue, but if i recall (that was many months ago), I did try with it and could not make it work either. But best to ask Oga in that case.