• Please review our updated Terms and Rules here

Trixter's latest magic... Holy how-in-the-hell!!!???

Well, gave it a run on my Compaq mk1- the Compaq CGA card connected to my plasma TV via the composite-out, 512kb of RAM, NEC V20, MS-DOS 6.22

It does give me a warning that it's not a real IBM-PC. Ignored the warning, as is the norm.

20150410_185926.jpg


It only did two bits totally not as per the film I'd watched on Youtube- the speed of the moire pattern spinning round was fine, the speed at which it disappeared to black was considerably longer (about 6 minutes), most of the colors seemed to be pretty accurate and of course the one segment with the wiggly line didn't run due to inadequate memory (that's my problem, ha).

Very impressive. Actually doesn't look too bad on just the greenscreen- it's rare to see multiple shades of green on it.

--Phil
 
Last edited:
Just a quick note:
I have successfully run the entire demo on a Philips P3105 clone, using a real IBM CGA card.
Apparently the CPU and chipset are close enough cycle-wise, that the result is identical to a real IBM system.
The stock videocard was an ATi Small Wonder, which did not work entirely correctly:
- It does not seem to handle hsync width of 0 (which should be interpreted as 16) properly, resulting in loss of sync during the high-colour parts. Even some real IBM CGA cards suffer from this. We have identified these problematic cards as using a Hitachi HD6845 rather than an original Motorola MC6845. We can probably make some minor adjustments in the code to avoid this issue.
- It is not entirely cycle-exact with a real IBM CGA card, which manifests itself in the Kefrens bars part looking different... There are no Kefrens bars at the top of the screen.
- There appears to be a phase-shift compared to IBM CGA when using artifact colours. This makes most parts of the demo look completely wrong colour-wise.

So the conclusion so far is that having an original IBM CGA card is the most important ingredient. Apparently you can get away with at least some clones, as long as they have a real 8088 at 4.77 MHz.

I have also run it on my Commodore PC20-III with the onboard Paradise PVC4:
- It seems to handle hsync width 0 correctly, image is stable. However, the high-colour parts come up in B/W, so it seems that it simply doesn't enable colorburst in 80-column mode at all.
- Kefrens bars has the same issue as on ATi Small Wonder
- Artifact colours are also off, although in mode 6 the colours seem closer to CGA than the ATi is.
- When the DeLorean sprite is at the top of the screen, some flicker can be seen, indicating that the timing of the video card is off.
- The machine crashed at the end tune. It has a Siemens 8088. This may or may not be the cause (if the prefetch buffer behaves differently for self-modifying code, it would crash in the same way as emulators do).

I have yet to get it running on the Commodore with the real CGA card, since there seems to be an issue with detecting the video card properly when you have both CGA and MDA. Since the video card is onboard, I cannot remove it, so the only way to make it work is to set it to MDA mode, so it can cooperate with the IBM CGA card. This seems to be the same issue also reported by MauriceH, which I can probably fix in the code.

Update:
I have found the correct DIP settings to make the machine work with the IBM CGA card, and not run into the runtime error in the loader.
Results:
- Aside from the endpart, the demo works correctly. The only visual difference is that the rasterbars during the Kefrens part are slightly off in timing, giving a visible seam.
- The endpart still crashes. I have swapped CPUs with an original Intel 8088 one from the Philips machine, which plays the endpart correctly. This did not make any difference. The Siemens chip also works correctly in the Philips machine, so that is not the problem. It is likely some kind of incompatibility in the Faraday chipset that the Commodore uses.
 
Last edited:
Scali said:
Just a quick note:

I have also run it on my Commodore PC20-III with the onboard Paradise PVC4:
- It seems to handle hsync width 0 correctly, image is stable. However, the high-colour parts come up in B/W, so it seems that it simply doesn't enable colorburst in 80-column mode at all.
Click to expand...

MY PVC4 CGA Card does not work with the demo and I can get the whole demo to run on my Vendex in 4.77 Mhz mode except the mode with the wavey lines has the wrong top image timing for flicker. My on-board would likely not fare better and I do not have composite out regardless, so I would be capturing the RGB output anyway.
 
We're not entirely sure what is going on on the Commodore yet, but we have found that if the screen updates of the end scroller are replaced with nops, the music plays properly.
 
The difference between the Commodore and the Philips is that the Philips uses a 'real' chipset, as in 82xx-chips, made by Intel or a second-source (such as AMD or NEC).
Commodore uses a single-chip solution, the Faraday FE2010. By the looks of it, the Faraday chipset is not a 100% exact clone, which means that things like the DRAM refresh and timer chip run at a slightly different phase relative to the CPU.

So to make the code work properly on a machine like the Commodore, we would have to rewrite all cycle-exact routines to match the Commodore's specific behaviour (and do the same for every other incompatible clone that we encounter). Clearly this is way beyond the scope of this project.

Therefore we can conclude that *some* clones are able to run the demo 100% correctly (which is actually better than what we initially aimed for). But certainly not all of them.

The old style IBM CGA card however is a VERY important ingredient to get the demo working 100% as intended.
There is one problem with non-Motorola 6845 chips, which we might address. Currently the background colour and hsync width are hardcoded to values that worked best on our development systems. This includes a hsync width of 16, which is set with value 0 (since it is a 4-bit register with range 0-15). Apparently not all 6845 clones interpret a value of 0 as 16 (which they should, as the original Motorola chip does so).
If we modify our code somewhat so that the values can be set in the loader, and all effects query these values, rather than using hardcoded values, it would be easy to adjust these values for incompatible 6845-chips.

We do not know whether or not there are 100% exact IBM CGA clones out there (one would think that cheap Taiwanese clones would just copy the board 1:1, as it's just built from off-the-shelf chips anyway). We do know however, that popular third-party solutions from ATi and Paradise are not 100% exact clones. Neither outputs the proper artifact colours in any mode. Aside from that, their CRTC behaviour is somewhat off, meaning the Kefrens bars cycle-exact effect will not look exactly as intended.
Other than that, the demo will work on these cards.

Another thing we are working on is to get the demo working with DOS 2.x. During development we used PC-DOS 3.30. Apparently some 3.x-only code snuck in there. Most parts already seem to work under DOS 2.x, but it's the loader that crashes. While this is no big deal really (you can boot even the oldest of PCs with 3.30 or higher, if they meet our memory requirements), it should probably be easy to make the code work with 2.x as well.
Making it work with DOS 1.x is going to be a lot more difficult, since it does not implement functionality for TSRs/background processes. This means that our loader would have to be rewritten. On the other hand, if we need to implement this functionality ourselves anyway, we basically don't need DOS at all anymore, so we could convert the demo to a booter easily.
 
Last edited:
Scali said:
Another thing we are working on is to get the demo working with DOS 2.x. During development we used PC-DOS 3.30. Apparently some 3.x-only code snuck in there. Most parts already seem to work under DOS 2.x, but it's the loader that crashes. While this is no big deal really (you can boot even the oldest of PCs with 3.30 or higher, if they meet our memory requirements), it should probably be easy to make the code work with 2.x as well.
Click to expand...

We've found the error, and fixed it:
The loader has a script embedded at the end of the binary. It tries to open itself, then scan for the embedded data.
This is done with some Turbo Pascal code, which uses paramstr(0) to get the name of the binary. For some reason, this does not work on DOS 2.x, and the string remains empty. Therefore it fails to open the file, which crashes the runtime.
We have put an extra check in there to see if the string is empty, and we revert to '8088mph.exe' as a default value in that case.
The whole demo now runs on DOS 2.x.

I am interested to know how the Pascal runtime tries to determine the filename, and if there's any way to do this in DOS 2.x. A quick perusal of Ralfs Interrupt List did not come up with any API to do this, and looking in the PSP and env block data did not give any hints either, so perhaps it's just not possible.
 
Scali said:
I am interested to know how the Pascal runtime tries to determine the filename, and if there's any way to do this in DOS 2.x. A quick perusal of Ralfs Interrupt List did not come up with any API to do this, and looking in the PSP and env block data did not give any hints either, so perhaps it's just not possible.
Click to expand...

I have looked at the OpenWatcom 1.9 startup code as a reference, and they do a version check for DOS 3+. Then they look up the program name in the environment block pointed to by the PSP. I assume Turbo Pascal does something similar. I have checked with debug.com, and indeed, only in DOS 3+ will you find the program name in the environment block. So it seems that getting the program name is simply not possible in earlier versions of DOS, since it was not implemented.
 
Scali said:
More specifically, it takes advantage of the color fringing artifacts as generated by an 'old style' IBM CGA card.
'New style' IBM CGA cards have slightly different output, making the colours slightly different. This means that things will look 'wrong' in our demo.
All the clones we have tried so far are even more off colour-wise than the 'new style' IBM CGA cards.
Click to expand...

I remember a thread on this a bit back. Does anyone know if there were model number differences or if there is an easy way to just tell which card is which (old vs. new)?
 
Hey,

A truly mindblowing masterpiece of CGA rape, but... It completely freezes after displaying the "What are we going to do?" part. DTK/Siemens XT 8088 (running on 4.77), some unknown clone CGA board. Curiously, the demo freezes at the exact same spot with the PCE-IBMPC emulator.
 
Shadow Lord said:
or if there is an easy way to just tell which card is which (old vs. new)?
Click to expand...

The easiest way to tell visually is to look at the circuitry for the composite output. It was discussed earlier in this thread: http://www.vintage-computer.com/vcforum/showthread.php?36212-A-little-survey-for-(IBM)-CGA-owners

This is a good picture that illustrates the differences in the circuitry... The new card (bottom image) has a few extra resistors, located near the 9-pin RGBI output:
5150_compare_cga_adapter.jpg


Note that the colour of the PCB is not a clue. This old style card happens to be green. The one we used during our demo was the same purple-ish colour as the new style card below. Neither is the 6845 chip by the way. In this case the new style card has a Hitachi HD6845 (which is not 100% compatible with our code, but a final version should change that). I have a new style card with a Motorola 6845, like the old style card pictured here. It might be possible that even old style cards have non-Motorola 6845s, but we have not seen such a card yet.

These extra resistors modify the colours of the composite signal, so that you get more unique luminances on a monochrome monitor (perhaps the changes were done for the IBM 5155, which connects the internal monitor on the composite output of the CGA card). The old style card had 8 shades in monochrome, the new style has 16 shades.

We chose to target the old-style card for our demo however, since the old colours were slightly more useful for our high-colour tricks. Also, if we want to target an actual 1981 machine, it would also have a 1981 CGA card, which would be old style.
 
Shadow Lord said:
I remember a thread on this a bit back. Does anyone know if there were model number differences or if there is an easy way to just tell which card is which (old vs. new)?
Click to expand...

Here's the thread. There's software for testing (if you have a composite monitor) there and also some model number differences (though there are some model numbers that are unknown). You may also be able to tell by the number of resistors (small cylinders with multi-coloured bands) close to the bracket. If there are less than 12 of them it's probably an old style one, more than 12 and it's probably a new style one.
 
Scali and reengine:

Thank you for the very detailed responses. I have a number of IBM CGA cards floating around. I will have to check to see if any of them are the old style. A question on the monitors: does it have to be a particular type? For example does it have to be a CRT for the trickery to work or can an LCD w/ a composite input work as well? Although I have a number of CGA cards all of my old style CRT monitors are either RGB or monochrome.
 
Shadow Lord said:
A question on the monitors: does it have to be a particular type? For example does it have to be a CRT for the trickery to work or can an LCD w/ a composite input work as well?
Click to expand...

Some LCDs might work - they can be very variable with how well their NTSC decoders cope with the CGA's marginally compliant signal. We had very poor results with the small LCD we brought to Revision (I think it's a PL8006) - colours would be wrong and sometimes flashing in and out of black and white mode.
 
During development at home, I used an old Samsung LE26R32B LCD TV. I'm in a PAL country, and finding NTSC-compatible devices is difficult. Apparently this particular Samsung was dual-standard, and it worked perfectly.
Funny enough the newer Samsung LCD TV I have, did not work. It does not seem to handle NTSC-signals at all, since the image was jumping all the time, indicating that it did not know how to sync to a 60 Hz signal.

So yes, LCD TVs can work (they basically do the same as a capture device: convert the signal to a digital framebuffer), but you have to have a bit of luck with them. They have to be able to handle the CGA signal.

In fact, even though my Samsung TV handles the CGA signal, it could not handle a ZX81. The ZX81 is notorious for not having a back porch pulse in its signal:
https://youtu.be/gsJQPwcFXeg

In order to fix that, I passed the signal through an old VCR first, which would decode the image, and then send a new signal, including proper back porch, to the TV:
https://youtu.be/DsvpfDjeMs0
You could try that trick with CGA as well, it may make it easier for a TV to lock onto the signal once the VCR has 'reconditioned' it.
 
Gabucino said:
A truly mindblowing masterpiece of CGA rape, but... It completely freezes after displaying the "What are we going to do?" part.
Click to expand...

Does it really freeze completely, or does it play the music VERY slowly?
That part is the 1024-colour part. As you can read in reenigne's article, this effect works by triggering 100 CRTC frames of 2 scanlines to compose a frame on your monitor with 200 scanlines.
On certain cards/emulators, this does not work properly, and every 2-scanline CRTC frame that is triggered takes the full frame time, so the effect runs about 100 times as slow as intended.
If you wait long enough, the demo will just run to the end.

And the only way to fix that is to use a real IBM CGA card (or one that is 100% compatible).
 
Scali said:
Does it really freeze completely, or does it play the music VERY slowly?
That part is the 1024-colour part. As you can read in reenigne's article, this effect works by triggering 100 CRTC frames of 2 scanlines to compose a frame on your monitor with 200 scanlines.
On certain cards/emulators, this does not work properly, and every 2-scanline CRTC frame that is triggered takes the full frame time, so the effect runs about 100 times as slow as intended.
If you wait long enough, the demo will just run to the end.

And the only way to fix that is to use a real IBM CGA card (or one that is 100% compatible).
Click to expand...

It's stuck on a low note, and does not seem to budge anywhere even after several minutes (keyboard LEDs work though). I've tried another CGA card with the same results. Unfortunately I do not have an original IBM one yet.
 
Have you thought about adding a command line option to start the dome at any given part? Just like what Second Reality has (1...5 as parameter).
 
You must log in or register to reply here.
Back
Top