Having a Problem with Displaying Data to Internal Display with Back 2 Back Updates

[6Bolt]

This is Darren, AKA 6Bolt, the coder of Hook Of The Reaper. I have been working on my Light Gun Display code, and ran into a problem with the OpenFire Internal Display. It seems that a long delay is needed, before the Life display data can be updated, back to back. I first started testing with displaying Life, and playing HOTD4, using TeknoParrot (Latest) and DemulShooter (v13.5).

When I start the game, the P1 Life goes from 0 to 3, which then HOTR tells the light gun that life changed to 3, and screen displays 3 hearts. I then hit the start button again to skip the cut scene. Also, it make Life go to 0, and then 3 right after. This also happens with Ammo, were it goes to 0, and back up to 30. But, the screen now displays 0 hearts. I skip another cut screen, Life and Ammo does the same, where it goes to 0, and back to starting value. But, the screen still displays 0 hearts. The game starts, and still display 0 hearts, until I get hit, and then will display 2 hearts after. I have attached the data being sent over the serial COM port to the OpenFire light gun below.

COM Port: 7 Data: "S6" - Game Starts and HOTR Connects and Inits Light Gun
COM Port: 7 Data: "MDx1" - Enables Life Display
COM Port: 7 Data: "FDLx0" - End of Game Boot Up & Makes Life 0 - Displays 0 Hearts
COM Port: 7 Data: "FDLx3" - About 10s Later, I Pushed Start Button & Makes Life 3 - Displays 3 Hearts
COM Port: 7 Data: "FDLx0" - About 5s Later, I Pushed Start Button to Skip Cut Scene, Makes Life 0 - Displays 0 Hearts
COM Port: 7 Data: "FDLx3" - Right After the Write Above, Makes Life 3 - Displays 0 Hearts (Back 2 Back Write, Ignore 2nd Write?)
COM Port: 7 Data: "FDLx0" - About 5s Later, I Pushed Start Button to Skip Cut Scene, Makes Life 0 - Displays 0 Hearts
COM Port: 7 Data: "FDLx3" - Right After the Write Above, Makes Life 3 - Displays 0 Hearts (Back 2 Back Write, Ignore 2nd Write?)
COM Port: 7 Data: "F0x2x1" - Game Starts - Displays 0 Hearts
COM Port: 7 Data: "F0x2x1" - Shooting
COM Port: 7 Data: "F0x2x1" - ...
COM Port: 7 Data: "F0x2x1"
COM Port: 7 Data: "F0x2x1"
COM Port: 7 Data: "F0x2x1"
COM Port: 7 Data: "F0x2x1"
COM Port: 7 Data: "F0x2x1"
COM Port: 7 Data: "F0x2x1"
COM Port: 7 Data: "F0x2x1"
COM Port: 7 Data: "F0x2x1"
COM Port: 7 Data: "F0x2x1"
COM Port: 7 Data: "F0x2x1"
COM Port: 7 Data: "F0x2x1"
COM Port: 7 Data: "F0x2x1"
COM Port: 7 Data: "F0x2x1"
COM Port: 7 Data: "F0x2x1"
COM Port: 7 Data: "F0x2x1"
COM Port: 7 Data: "F0x2x1"
COM Port: 7 Data: "F0x2x1"
COM Port: 7 Data: "F0x2x1"
COM Port: 7 Data: "F0x2x1"
COM Port: 7 Data: "F0x2x1"
COM Port: 7 Data: "F0x2x1"
COM Port: 7 Data: "F0x2x1"
COM Port: 7 Data: "F0x2x1"
COM Port: 7 Data: "F0x2x1"
COM Port: 7 Data: "FDLx2" - Get Hit Life goes from 3 to 2 - Displays 2 Hearts
COM Port: 7 Data: "F1x2x1" - Rumble Motor
COM Port: 7 Data: "F2x2x1" - Flash Red LED
COM Port: 7 Data: "F0x2x1"- Shooting
COM Port: 7 Data: "F0x2x1"- ...
COM Port: 7 Data: "F0x2x1"
COM Port: 7 Data: "F0x2x1"
COM Port: 7 Data: "F0x2x1"
COM Port: 7 Data: "F0x2x1"
COM Port: 7 Data: "F0x2x1"
COM Port: 7 Data: "F0x2x1"
COM Port: 7 Data: "F0x2x1"
COM Port: 7 Data: "F0x2x1"
COM Port: 7 Data: "F0x2x1"
COM Port: 7 Data: "F0x2x1"
COM Port: 7 Data: "F0x2x1"
COM Port: 7 Data: "F0x2x1"
COM Port: 7 Data: "FDLx0" - End Game, makes Life 0 - Displays 0 Hearts
COM Port: 7 Data: "E" - Gives Back Control

I tried to put 6 FDLx%s% writes into the display Life update, but still displayed 0 hearts, after skipping the cut scene, which makes the Ammo & Life bounce around. If I take out the Life updates, when Life bounces when skipping, it works as normal. Also, found if you put in an Ammo write into the mix (FDAx%s% FDLx%s%), then every other Life update works, when skipping.

What is the delay time that is needed for a Display Life amount update, before another one can be sent? Basically, if I do a FDLx3 write, how much time to I have to wait until I can do a FDLx2 write?

[6Bolt]

I added in a delay for the display. After some testing, I found the minimum delay is about 14-15ms for back to back Life display updates. With a guard band of 20%, minimum delay would be 18ms.

Will test ammo tomorrow, to see if it is the same. I am guessing it is, as I was having the same problem with ammo in HOTD4.

[6Bolt]

I did the testing for the Ammo, and was the same.

I read the datasheet for the SSD1306, and some of the firmware. It seems that there is a I2C connection to the display controller. The fastest that the I2C can go on the SSD1306 is 400KHz. The 128x64 monochrome data is 8,192 bits, which equals 1,024 bytes. For the I2C, to transfer a byte, it takes 9 bits, because of the ACK. So would be 9 * 1,024 is 9,216. The period for 400KHz, is 2.5us * 9,216 is 23,040us, which is 23.04ms. This is 7-8ms more that the minimum that I saw. Since, I don't know the settings, will have to guess on the display clock. A period of 23.04ms, which equals 43.4 Hz, so fastest the display clock with the I2C. Will try 30ms for the display refresh time. As it seems safe, and make the display clock 33.33 Hz.

[SeongGino]

Not ignoring btw, this is genuinely fascinating to see.

What I'm wondering is what game triggers that fast of status updates? For the conventional <60hz game, that seems like sub-frame timing which I haven't personally witnessedwith games that could actually transmit live data updates for the display.

I can't personally speak to much on the implementation, other than the screen updates are all offloaded to the Adafruit display library. From what you're saying though, it seems like it might help if the firmware limits display updates to around every ~24ms?

[6Bolt]

The only game that I know of that does this fast signal toggling is HOTD4, when skipping the cut scenes. It toggles the life and ammo, as I mentioned above. I believe it does this to make a shot go off for the gun, to give the player feedback, that it is skipping the cut scene. That explains the ammo toggling, but don't know why life does it. So I don't think it was intended for display. But it did show me that I needed a refresh delay, as all displays are different, and why I love to use HOTD4 as my main tester.

Before testing the oled on the OpenFire, the only thing I did before was the Alien Light Gun, with it's 2 8-way LED segment displays. Since the segment displays are very fast, I never worried about refresh delays. I had people test it out, and showed me that there was no problem with the display, with ammo. I did put the ammo display in for the OpenFire too. But never heard that things were not working. Probably, because the display didn't work when skipping cut scene, but soon worked after firing the first shot for HOTD4. Or maybe they never skipped the cut scene.

So, I don't think this will affect most games. If the game had Output Signals to a display, I am sure that it would have refresh delay in it, unless it was 8-way LED segment. But I think problem could occur, is when displaying info that was not intended to be displayed by the original arcade. Or it was on a 8-way LED segment, and now HOTR is trying to display it on a LED display.

What I am planning, is to put the refresh delay into the light gun .hor file. So if the light gun has a display, like the OpenFire, it will load up the light gun display refresh delay. Then the Alien Gun will have a small refresh delay, and the OpenFire will be set to 30ms. So there will be 4 refresh delays, one for each player. Then the OpenFire 30ms delay, will not impede the Alien Gun segment display with a refresh of like 5ms.

[6Bolt]

I got the majority of the light gun display code done. I did a preview of the OpenFire display in action, with Hook Of The Reaper. After testing and some other things, it will be released in Hook Of The Reaper v1,1,4 later on. Also, I updated all the included game files, to display Ammo and Life.

Link to YouTube video of the Light Gun Display Preview
https://youtu.be/ieqMwB9k_GQ

The only other problem I ran into, was with the Split Screen and when Life is a Bar. When closing the HOTD4 game, it would crash the display. By increasing the display refresh delay from 30ms to 35ms, made it not crash anymore. It is the only display option I have to do that with, as all other work at the 30ms. Also, it is weird that it crashes when the game is closing. But it is working at 35ms, so it is not a big problem. Just wanted to note it.

From what you're saying though, it seems like it might help if the firmware limits display updates to around every ~24ms?

That would be a good thing to do. Especially when changing the screen display. I noticed that the screen can crash, if the screen type changes, and then Ammo or Live is updated is fast behind. Sometimes it doesn't crash, but thing get messed up. For example, using the split screen and fast writes, the screen would flip on horizontal axis. So everything would be upside down, except for the Ammo numbers. So the Life glyphs or bar would be upside down and the Ammo number next to it would be fine. Was a little weird.

But it might not be that much of a problem, as HOTR is taking care of the display timing. I don't know if MAMEHokker can do it or not. I know you can put in delays, but would it mess other things up. So depends if people are having problem with MAMEHooker and display.

[6Bolt]

I am pretty sure you guys know, but if not. I released Hook Of The Reaper v1.1.4, which includes all the light gun display code. Besides what I showed in the video above, I updated the Life Glyphs for life bar games. So if max life is 100, then 1 glyph is 10. So if you had 40% life, it would show 4 glyphs.

I also added Recoil_Value to the commands. This is where the game output signal controls the solenoid. The usual Output Signal is PX_CtmRecoil. I also have a safety times for it too. If the solenoid is left open for over 200ms, it will then close the solenoid, and then block the Recoil_Value for the rest of the game.

Then the last big one is adding reload. Now Ammo & Ammo_Value have reload function. If a reload happens, then Ammo & Ammo_Value will send the reload commands. For the Recoil games, I used the PX_Clip signal for reload. But the ammo has to be empty for it to work, and make the PX_Clip go to 0. Then when it goes to 1, it does a reload. I am planning on making an Ammo_Reload command for the future.

Also, I have updated all the included game files for the display and reload stuff.

Link to the Release v1.1.4
https://github.com/6Bolt/Hook-Of-The-Reaper/releases/tag/v1.1.4