In short, Luciano Cadari rediscovered one of his old game loaders which set some VDP registers in an undocumented way. After much discussion and a lot of back-and-forth between he and some people who were trying to confirm and understand the VDP behaviour in the Brazilian WhatsApp group, it became apparent that an undocumented bit in mode register 1 changed the way the blink feature works. Usually it justs alternate two pages automatically slowly (maximum 6Hz, if I'm not mistaken). When this previously undocumented bit is set, it looks like the two pages are switched every scanline. At least, this is how Paulo Peccin implemented it, and it seemed to be consistent with what real hardware was showing. It creates a visually interesting windowblinds animation effect and it needs no CPU interference to work.
It's not clear whether this is a bug or a hidden feature, but it works in every real MSX that has a V9938 or V9958. It doesn't work in Zemmix Neo. Leonard Oliveira believes it is some hidden test feature. It seems BASIC ignores this bit when setting screens, so it remains active even when you use the SCREEN statement.
EDIT: Of course, since it's previously undocumented, there are no links to documentation, for now.
Change VDP(1) value to 112 to disable the bit, and change VDP(14) to e.g. &H11 to increase the blink rate.
That's so cool. Just tested on a turboR GT and works as described.
played around, interesting. noticed one thing - once i do this first time i have black stripes over the screen, then after CTRL+STOP next time i run it i have cool effect. machine is Sanyo Wavy 70FD. i cannot test on others because i didn't brought them here yet (next year, maybe). i can make a video if anyone interested
played around, interesting. noticed one thing - once i do this first time i have black stripes over the screen, then after CTRL+STOP next time i run it i have cool effect. machine is Sanyo Wavy 70FD. i cannot test on others because i didn't brought them here yet (next year, maybe). i can make a video if anyone interested
Saw something similar on a Sony F1XDJ. First run the bars are dark blue (like the inital background color), while the circle is drawn on a light blue background. Second run the bars are in the light blue background color as well.
Leonard Oliveira believes it is some hidden test feature.
Apparently setting the undocumented bit at R#1 changes the clock source for the blink/page switch counter decrease from VSYNC to HSYNC. Also, setting it seems to make the registers EO and IL at R#9 irrelevant. (This needs more testing)
That's why I suspect this "feature" was meant for testing, since it doesn't seem to have a practical use outside of checking the operation of the VDP internal circuitry.
On the FM chips the test registers are grouped nicely together but since the VDP is based on work from other company I believe they might have fitted the test stuff where it was possible instead of making new specific test registers.
Apparently setting the undocumented bit at R#1 changes the clock source for the blink/page switch counter decrease from VSYNC to HSYNC.
Yes, that's exactly what the first impl. on WebMSX does. The effect produced is that the blinking frequency increases a lot (around 200 times faster), making the 2 pages switch several times inside the same raster field (on the higher settings).
Since the switching is no longer in sync with the VSYNC, depending on the values used, the moments inside the frame where the switches occur will vary from one frame to the next, making the "moving bars" effect that Luciano Cadari discovered back in the 90's.
So cool!
Peccin
Are there already more testing results on this new bit?
Seems Paulo is working on some interesting stuff... ;-)
Hi Paulo,
Great work on version 6.0!
I shared a link with the community yesterday, WebMSX is featured.
Take a look if you like - I hope you like how it's integrated.
I managed to integrate WMSX (release) into my build by using shimming techniques.
So the process is as follows:
When WMSX is not available (first request to start) it fetches it. Then it sets WMSX properties (like MACHINE etc), and starts by calling WMSX.start()
If the user closes the window it does a wmsx.room.machine.powerOff().
Though when user closes the window before WMSX could properly load it polls via an interval wmsx.room.machine.powerIsOn, and powers off when that evaluates to true. Ugly, but it works (for now) :) I haven't really looked into it if I could that in a smarter/better way.
When the user starts another game it calls WMSX.changeMachine, WMSX.fileLoader.readFromURL, WMSX.room.diskDrive.removeStack & WMSX.room.cartridgeSlot.removeCartridge where needed. Then WMSX.room.screen.focus()
I hacked in a WMSX.room.screen.setDisplayScale function (based on displayScaleIncrease/Decrease) to accommodate for the auto-rescale on windows resize.
It would be sweetest if the MSX screen would completely converge with the window (like an embedded YT vid), but for now I calculate it depending on the avail. clientWidth & clientHeight and take some margin there (and make a distinction between MSX & MSX2).
Then I did some mouseenter/leave stuff regarding the bar o/c :) (only when client can hover).
The animated bg has an impact on performance I think, so I'll auto-disable it when WMSX is running.
Btw: I'm running into an issue where after running Ugamma, Syntax Infinity has a distorted hi-hat sound. I checked with embedded WMSX out-of-the-box: it's there as well. Perhaps the audio should be properly destroyed, and re-initialized or something when user changes media / restarts the machine?
Hope you're doing well & thanks!