I'd have to see what happens if I run it on one of my faster 8088 systems. I don't have a V20.
Some parts might look wrong because of timing issues. Some parts do their own music timing, they may run too fast, but nothing should actually crash or loop forever.
The parts that I developed (sprites and polygons) are not very speed-sensitive at any rate. The music is timer-driven, and the graphics don't rely on cycle-exactness.

One thing you could experiment with is this:
If you open 8088MPH.EXE with a hex editor, you'll see that there's a script at the end of the file:

18088mph.001|0|
28088mph.002|0|
38088mph.003|16|welcome to~4.77 mhz!~ ~welcome to cga!~ ~what's a~bitplane?
48088mph.004|0|and now i see~with eyes serene~the very heart~of the machine
58088mph.005|0|no copper!~no vic-ii!~what are we~supposed to do?
68088mph.006|13|dots are~my favours...~except~when they're~saviour's.
78088mph.007|28|sprites?~where we're~going,~we don't~need sprites
88088mph.008|25|you may want to~close your eyes~for this
98088mph.009|18|
108088mph.00a|30|race the beam~ ~on your mark...~get set...~go!
118088mph.00b|44|if my~calculations~are correct,~when this baby~hits 8088 miles~per hour,~you're going to~see some~serious *!?*
128088mph.00c|8|and now we must~bid you farewell~ ~no paula...~no sid...~no problem
138088mph.00d|0|

You can try deleting lines from that list to skip certain parts.
Eg, if I'm not mistaken, 8088MPH.000 is the 'old/new CGA' image, 8088MPH.001 is the calibration screen and 8088MPH.002 is the moire part.
So delete the 8088MPH.002 line, and it will skip over that part.
See how much of the demo you can get running that way, and we'll know which parts of the demo might need a fix, and which don't 😀

^ I can do that , I'll report in a couple of days when things clear up here and I have time to mess with floppies and editing 🤣 (still no HDD installed)

Is this interference normal for an IBM cga? the ACER clone didn't have that IIRC:

https://www.youtube.com/watch?v=RC1GbtuTG-8

CGA doesn't output the cleanest signal I've ever seen... but this is worse than what I have seen on my systems.
It could be caused by your power supply (there is little or no power conditioning on the card itself, and old power supplies aren't as clean as modern switching ones).

^ hmmm
I do plan to recap the PSU , it makes sense that some interference passes to components.
That interference is not visible in all games, mspacman for example is clean.

I get some similar interference but not as bad. It also seems to be worst at first power up and goes away later.

Scali wrote:

I'd have to see what happens if I run it on one of my faster 8088 systems. I don't have a V20.
Some parts might look wrong because of timing issues. Some parts do their own music timing, they may run too fast, but nothing should actually crash or loop forever.
The parts that I developed (sprites and polygons) are not very speed-sensitive at any rate. The music is timer-driven, and the graphics don't rely on cycle-exactness.

I've tested on my 8088 that also is capable of 7.14 and 9.54 MHz. The whole demo runs (except for a crash at the end music, which it also does at 4.77 MHz), and only the music in the first part runs too fast, the rest of the music runs at the same speed.
So, there may be some issue specific to your V20 or to your chipset which prevents it from going beyond the first part. Since I cannot reproduce it, there's no easy way for me to find out where it may go wrong or why.

Also, I think if you would just delete or rename the parts on disk, it should also skip them (albeit in a less elegant way). Should be easier to test than having to edit the EXE everytime.

^ excellent tip, I did a quick test 😁
8088mph.003 is the offending file, I just renamed it. The rest of the demo seems to run OK in terms of speed except "beam" and the freeze at the end credits.
This is what I get for beam:

The beam moves in the very low part of the screen.

keropi wrote:

8088mph.003 is the offending file, I just renamed it.

Good to hear that's the only troublesome part. Still I have no idea what the problem could be. You say it just keeps running indefinitely? That means somehow the part that ends it ('wipes' the screen from the outside to the center) is never triggered.

keropi wrote:

The rest of the demo seems to run OK in terms of speed except "beam" and the freeze at the end credits.

That looks pretty much the same as on my 8088 at faster speeds, and is to be expected.
The freeze at the end credits is also somewhat expected. There is self-modifying code in the music replayer, which takes advantage of the fact that code already in the prefetch buffer is not affected by the write to the code. So the new code won't be executed until the next time it is fetched.
Most emulators break on this, and I had heard that the V20 doesn't work like this either. What you're seeing confirms this. The problem is that it can't really be fixed, because the code is time-critical. The V20 is a different speed anyway, so just fixing this particular crash still wouldn't make the music sound right. The fix would only make it the wrong speed on a real 8088 as well.

Fun fact: Intel deliberately made all their newer CPUs emulate this prefetch-buffer behaviour, so it should not crash on any Intel CPU, even though newer CPUs don't actually have a prefetch-buffer like the 8088 did, but a more advanced L1-cache, which gets invalidated on writes.

Yep, the moire part keeps running and running but you do get music changes. Think of it as an overlay/curtain that hides the rest of the demo.

So basically a mixture of V20+clone machine is to blame here 😁
I can understand the limitations here , I'd say don't mess with it unless there can be code that won't break stuff for the original machine and helps clones - but this takes a toll of time invested to it. Another idea would be to have the program detect a V20 and ask the user if he wants to skip parts that won't work , that would be a nice way to see past moire 😁

Well, I find it somewhat intriguing, since I don't see a direct reason why the moire effect would fail to end.
So I may look into it.
The other stuff is a problem... you'd have to tweak the code for every individual clone out there, so that's not really an option.

I think I've found the problem:
The code uses the undocumented 'salc' instruction (Set AL on carry): http://www.rcollins.org/secrets/opcodes/SALC.html
This instruction is probably not supported by the V20 CPU. The thing is that the loader API signals that the effect should end in the carry flag. If salc doesn't work, the carry is never copied to al, so the code that decides to end the effect will never work.
It is possible to create a workaround for this that works on both 8088 and V20 I guess. I'll give that a shot. Try this one instead: https://www.dropbox.com/s/8xnd7q101w5eay1/808 … PH_003.zip?dl=0
In the meantime, there is another workaround: There is code that checks the keyboard to see if 'esc' is pressed. If you hold down escape, the effect should also end (that part does not use salc, so it should already work on V20).

I didn't check the new binary posted above due to lack of time (will do it tomorrow) but I was at my office for a small period of time today and I showed 8088MPH to a friend, this time with "low" speed setting. Guess what?
Beam actually worked fullscreen and the end part with the music worked correct too! 😮
The demo completed and returned me to DOS. I only wish the end music was louder 🤣 🤣 🤣
Ofcourse with the moire part skipped, that loops regardless of speed setting.

Interesting. Do you think you could do a video recording of it? I wonder if the V20 actually makes a difference at all.
It's mainly faster at instructions like mul and div, but we don't really use those in the inner loop, so perhaps the CPU is 'cycle exact enough' to make the demo work pretty much the same as on a real 8088, as long as you run it at 4.77 MHz (and use a compatible chipset and real IBM CGA card).

Sure I can , I will make a video and upload to yt tomorrow 😀
It won't be a problem if I skip the C64 comparison part, would it be? (and moire ofcourse)

keropi wrote:

It won't be a problem if I skip the C64 comparison part, would it be? (and moire ofcourse)

Well, hopefully you can use the new moire part, and it doesn't get stuck (or you use the old one and press esc yourself to exit it), so we can see (and hear) the whole thing.
C64 part and calibration can be skipped 😀

^ Allright, I re-did a video with the new moire part, it does end this time 😀
About the beam part, after I saw a video of what it it supposed to look like I can quickly say on my setup it is rendered in half-height (will upload the video later from home as it is ~620MB - sadly not that great quality due to me using a nokia phone that records at 720p but you'll see how it runs... it will take some time to deliver mediocre recording results 🤣 )

I did upload a small video regarding the interference I am getting in composite mode, this time Hard Hat Mack: https://www.youtube.com/watch?v=MrF6jLG7tps
it has no problems, no moving pixels and picture is fine (also tested with KQ1 , it's fine too).
Ran Montezuma's Revenge after it and I get the same interference I posted before. What's the deal with it? Why some games are OK and some not? 😖 Different screenmodes/timings?

here's the video: https://www.youtube.com/watch?v=NzslHkBZsY0 (it will be available in 720p once yt finishes processing - just don't expect wonders....)

Nice Machine, Picture on TV is really good for CGA, better then composite out.

keropi wrote:

here's the video: https://www.youtube.com/watch?v=NzslHkBZsY0 (it will be available in 720p once yt finishes processing - just don't expect wonders....)

Very nice!
As you can hear, the moire effect is slightly slower.
There is a way to rewrite it so that the music is independent of the graphics, like the other effects. Problem is, it was tuned to run exactly 60 fps on a real PC, and it would probably have some tearing if it were changed, because you would lose the perfect sync.

The 'racing the beam' effect is interesting... It seems that it 'auto-calibrates'... I've seen something like this on clone CGA cards on real 8088 4.77 MHz machines as well: because they aren't cycle-exact, the effect somehow doesn't work at the top of the screen, but at some point it seems to 'click' into sync and from then on it seems fine.

The rest of the demo seems to look fine on the V20. Apparently it doesn't crash on the end-tune either, so it is compatible with the prefetch-logic of the 8088. I was somewhat surprised that the music doesn't really sound faster than on an 8088, and more importantly, that it seems to play at a constant rate. The code was tuned so that all possible effects take exactly the same amount of cycles on an 8088. So I was somewhat expecting the V20 to have some variation in pitch because it doesn't run every instruction at the same speed as the 8088 does. But perhaps this again si some kind of 'auto-calibration', perhaps because of the writes to the videocard, where the wait-states affect the CPU performance.