The Master

I don't believe there is a way with the current jzintv as there isn't even a way to to create rom with the save-game flag set which makes sense as the path is going to be OS specific (e.g. Mac/Linux/Android = /foo/bar/savedata.jlp, vs Windows = C:\foo\bar\savedata.jlp. With that said when the jlp-savegame flag is used it creates a new file that matches what ever you name it, and that file can be moved between computers that use jzintv

has anyone else run into the problem with the ultimate flashback that when pressing down on the Intellivision controllers or down arrows on a usb keyboard that it sometimes skips over several games instead of going to the next game in the list? If so is there a way to fix that?

Byte Knight did disable the run command menu, which can be enable/disable by running sudo ~/RetroPi-Setup/retropie_setup.sh, and navigating to Configuration/Tools -> Runcommand -> Launch Menu. Then reboot. Then right after launching a game you have a second to press any key and the Launch Menu screen will popup letting you select which emulator config you want for that specific rom. the options in the launch menu are created by the values in this file: "/opt/retropie/configs/{SYSTEM_NAME}/emulators.cfg" so I copied the jzintv param. and then renamed the copy from jzintv=... to jzintv_jlp_save=... making sure I added --jlp-savegame=%BASENAME%.save to the command in jzintv_jlp_save. if you don't want to enable/disable the Launch menu each time a new jlp game with save function is added you can modify "/opt/retropie/configs/all/emulators.cfg" by adding a new line using a specific naming convention. {SYSTEM_NAME}_{ROM_NAME_SANS_EXT} make sure to remove any spaces or characters that aren't a-z, A-Z, or 0-9. e.g. "/home/pi/RetroPie/roms/intellivision/The Pandora Incident (ECS) (2022) (Elektronite) (by Carlos Madruga and Arturo Ragozini).bin" Becomes intellivision_ThePandoraIncidentECS2022ElektronitebyCarlosMadrugaandArturoRagozini = "jzintv_jlp_save" Doing this will make sure only JLP games with save functionality generate save files. --The Master

I forgot you could make a separate system. That might be a good way to work around the save file issue. I found out you don't need a separate emulator.cfg for ECS or even Intellivoice games. Just make sure the rom's cfg files are set with "[vars] ecs=1" or "[vars] voice=1" and if they have both then "[vars] ecs=1 voice=1". I redid all the ecs and voice files the flashback came with by using jzintv rom2bin updated their cfg files to add those vars then ran bin2rom and re-added the newly generated rom files to my flashback. Now ecs and/or voice are enabled automagically on a per rom bases. The only other thing you might need is to make sure both ivoice and ecs roms are in /opt/retropie/emulators/jzintv/rom. then add to your command line for jzintv "-p /opt/retropie/emulators/jzintv/rom"

I didn't seeing anything about making jlp save game features work. This could because I have an older version of the ultimate flashback that was built back before any jlp roms with save capabilities were available to use, and this feature might already work OOTB with recent builds. Incase anyone else like me has an older build but wants to enable the recent jlp roms from IntellivisionColector to be able to save, I found the easiest way to do this was modify "/opt/retropie/configs/intellivision/emulators.cfg" by adding --jlp-savegame=%BASENAME%.save to the jzintv command line. The one draw back with this simple approach is it will create a .save file for every rom you run even if they don't need it. Ideally this is something that should be configurable in the rom's cfg file. But as far as I can tell with the latest jzIntv source code it doesn't have a way to set --jlp-savegame via cfg files. maybe with a simple option of just setting enable savegame state and have jzintv default save to the same directory as the rom file. As I could see why it might not be good to set file path info in a cfg file that might be used in LTO Flash carts that have no concept for file paths. --The Master

If I had to guess the main difference would be with Blow Out. as there are at at least 3 known rom variations. and as far as I know only one of them has the ability to be merged with the other two party line games to create what is most likely the BSR compiled version. Here are the MD5Sums of the various version of Blow Out 253266252e55bd85e98c207d82036a27 - PS2 Intelivision Lives - Blow Out (this one has a modified game selection screen so that all three options only ever load Blow Out) e8ae269dc6fa4e833b7ae4df89f406d4 - Intellivision Revolution Release - Blow Out (I either have a bad dump or cart used JLP board so it can't be dumped to compared) 460016cd532badbde26ce39a26fc2379 - Intellivision.us - Blow Out (I Believe this is the only version of the rom that has the correct menu screen to choose between the three games when it's merged with Hard Hat, and Space Cadet). both the Intellivision Revolution releases from the other two games match the md5sums of the versions released on either the Intellivision Lives! cd or the Intellivision Rocks CD. -- The Master

Ok so I must have completely forgotten about the clear button on Stampede having not played it for 20 years or so, as the clear button trick does work when the game appears to freeze (which is always when you miss 3 sheep in a row, which would explain why I got a higher score on the PI but not my desktop machine as I was just able to get over a 1000 on my desktop machine just now). As for the audio drop out it could be the way you compiled it that it fixes the audio drop outs. So the audio drop outs could be an older version of jzintv. customizations byte night makes to the ultimate flashback version of emulation station (the version byte night currently uses is 3.x) that means I should probably finish trying to upgrade Byte Nights image to 4.4 to see if the issue audio drop outs go away. With that said I my desktop machine still shows signs of audio drop outs when starting thin ice. But it is rare as mentioned above. --The Master

Blow Out, Hard Hat, and Space Cadet were already 16K Byte files. With that said are you saying that when working with Page Flipped Multi Game Carts it's a good practice to make sure each individual game's Byte size is a multiple of 8K Bytes? Even when you make your own Multi-Game ROM? Or is that something configurable when programing the Multi-Game ROM, in other words can you program your Page Flipping so it expects multiples of 4k Byte sized files instead of multiples of a 8K byte sized file? -The Master

Taking Lock N Chase which I have a 12K Byte dump as an example, why do I need to pad it with 0s or 1s so that it becomes 16K bytes? What issues would I run into if it's not padded out to a multiple of 8K Bytes? --The Master

Sorry for the confusion I wasn't looking for the controllers to be fixed. I only mentioned it because I wasn't able to confirm my memory that Thin Ice worked sound wise on the WII, because I can't find the controller that works with that port. In other words I only mentioned the memory as I figured it might help jog your memory of Changes that happened when the port took place and today that might be the culprit for Audio Drop outs. Ideally I would like to see if stampede works on there as well. I can compile for you, if it helps trouble shoot the issue quicker. I do have another PI 3 that I use for primarily watching movies and tv shots I've ripped to my NAS. That I Can ssh into and compile jzintv for it. --The Master

Something I just remembered, if I'm remembering correctly. This might be a recent regression. As it seems like I was able to play Thin Ice with the jzintv build that was available for the WII HomeBrew I installed when I hacked my WII a few years ago (version of jzintv for wii can be found here http://wiibrew.org/wiki/JzintvWii).Unfortunately I can't confirm as I can't find the WII controller that came with the WII. As all the additional WII controllers I purchased causes jzIntv to crash if I try to start it with anything other then the WII controller that came packaged in the WII I purchased.

There must be a couple different versions of LockNChase out there as I have one that is actually only 12kb on disk. And when I use beyond compare with another one I downloaded to see if there are any patterns I can look for in the 16kb rom available online. I see that that only difference HEX wise is that 16KB is padded with 0000 from 12kb up to 16kb. Then Looking at AD&D, Sub Hunt, and Shark Shark, they also where just padded with either FF, 00 or 00 up to a point followed by a bunch of 3F until the end of the file. So it seems when looking at ROMs it good to check to see if they where padded with blank data at the end of the file to see what their actual word size is. Assuming that padding at the end is the only thing causes them to be larger on disk then our assumption about size assumes. This one intrigues me. Is It possible this was a bad dump? Or is it a factor of how optimized the GROM was written that in this single case it ends up having a one to one mapping of Kiloword Size to Kilobyte size on disk? If this last question is true does that mean if someone was to optimize the code in a game rom enough that the Kiloword Size could also map one to when saved to Disk as Kilobytes like the GROM image? --The Master ---

Wasn't sure where I could report bugs with jzintv. But I think have a found a couple that at least effect linux builds (not sure about windows as I don't have a windows machine). The PI release is worse then the plain linux release. But that may be because the version I'm using on the PI, I'm assuming it is an older build then one I'm using on my main linux machine which is this exact build you posted above. Haven't been able to check the version on the PI as wifi doesn't work at my house so that I can ssh into it, so that will have to wait until I give it to my dad which will hopefully be in the next couple of weeks near his birthday (Byte Night would know which PI version since it's whatever version he uses for all his Ultimate Flashback Builds). So far I have found issues with Thin Ice and Stampede (I was checking those ones out as I know those are two of my Mom's favoriate games so much so that the last time we owned a intellivision system she played those two games for so many hours straight that she cause the smoke to go out on two intellivision machines). Both Thin Ice and Stampede on the PI wont playback any of the sound correctly, it comes out like a bad cell phone connection. However on the Linux build Thin Ice and Stampede sound wise seem ok most of the time though on a occasion during startup of Thin Ice the Sound will stutter which you can miss it if you aren't paying attention. It glitches so quickly that it seems like the linux build has no issue at all compared to the PI build. Also both the PI and Linux build causes Stampede to freezes and lock up that requires a hard quit of jzintv to get control back. Even tried starting it with the debug flag to see what instructions where causing the freeze but because of the freeze none of the debug commands work. It appears the PI build requires you gaining 500+ points before freezing where the linux build freezes after 200+ points. This is reproducible every-time you select game 1 (aka slow mode). The ROMs I'm using come from the Intellivision Lives v1.1/Rocks v1.0 3 CD Camikaze Edition. From reading up recently I see that you have stated that the dump of World Series Baseball on that set is not a complete dump as it is missing the intellivoice code. So I suppose it could also be that these two ROMs could also be bad dumps? Speaking of which do you know if any of the other ROMs found on this set are also bad Dumps? I certainly haven't tried playing all of them yet but will now that I have an Ultimate Flashback. --The Master

I must be really dense. As the wording on these two responses seem to contradict each other. The first seems to disagree with my assumption while the second seems to confirm it. My assumption being that dividing the bin/rom file size on disk in half would give you the Killoword size used in the game. For Example the Pitfall dump from the Intellivision ROCKS compilation is 8,192 Bytes on disk. If my assumption is correct than Pitfall used 4 Killoword size. While Beam-rider from the same compilation is 16,384 Bytes on disk would mean it used 8 Killoword Size. --The Master

Thanks everyone for your help as I can see where some of my trip ups have been. With that said I'm still a bit fuzzy on how much I understand what I've been told thus far. Thus, I still have a couple of questions with my assumptions of what has been stated, to make sure I'm not holding to any new falsehoods of my own making that will get me into trouble later. The Files size of the dumped ROM is not the actually size of the game's ROM size (which on this form calls "kiloword size" when loaded into the television memory). The best way to figure out a games kiloword size is to use the Memory map values in the various Intellivision config files posted in another thread on atariage. With that said pattern wise it seems there is a direct correlation to ROM file dump size and actual in game kiloword size. That is the files size on disk of a dumped ROM image appears to always be 2x the Game's kiloword size. I'm I correct to assume this? Or is there any of the original 127 intelivision and/or new Homebrew games that don't follow the, 2x kilword size = Dump ROM file size on disk, pattern. Based on my testing with changing page numbers in the config file it appears that the games only work if we use page 0, 1 and 2. Short of lucky guesses is there a way we can figure out which page # they are expected to live at? Meaning is there something in jzintv debugging tools and/or easily discovered pattern wise in the dissembled assembly code that would tell us which pages it expects the games to live in? --The Master