VOGONS

Common searches


Reply 700 of 745, by HunterZ

User metadata
Rank l33t++
Rank
l33t++

This is definitely exciting stuff.

Given that the internals of these old video chipsets are black boxes, I don't see a problem with emulation that uses tables of data generated from high quality output sampling.

Reply 701 of 745, by NewRisingSun

User metadata
Rank Oldbie
Rank
Oldbie

We still need someone to do the PCjr captures, since I only have a Tandy 1000 TX (so far). I suppose Trixter is out of the question, otherwise he would have done it a long time ago.

Reply 702 of 745, by liqmat

User metadata
Rank l33t
Rank
l33t

Not to get too off topic, but I found this CGA demo very impressive and was wondering what "mode" this is running in? It does not look like a composite demo, too clean for that. It doesn't look like the 160x100 "graphics" text mode, but maybe it is. Either way, if I had seen this back in the early 80s on my CGA PC I would have thought it was trick and you had a hidden Betamax hooked up to the monitor. 😀

cgademo.jpg

Reply 703 of 745, by reenigne

User metadata
Rank Oldbie
Rank
Oldbie
liqmat wrote:

Not to get too off topic, but I found this CGA demo very impressive and was wondering what "mode" this is running in? It does not look like a composite demo, too clean for that. It doesn't look like the 160x100 "graphics" text mode, but maybe it is. Either way, if I had seen this back in the early 80s on my CGA PC I would have thought it was trick and you had a hidden Betamax hooked up to the monitor. 😀

cgademo.jpg

It's the standard 320x200x4 graphics mode, but with per-scanline palette changes.

Reply 704 of 745, by OmerMor

User metadata
Rank Newbie
Rank
Newbie
reenigne wrote:
liqmat wrote:

Not to get too off topic, but I found this CGA demo very impressive and was wondering what "mode" this is running in? It does not look like a composite demo, too clean for that. It doesn't look like the 160x100 "graphics" text mode, but maybe it is. Either way, if I had seen this back in the early 80s on my CGA PC I would have thought it was trick and you had a hidden Betamax hooked up to the monitor. 😀

cgademo.jpg

It's the standard 320x200x4 graphics mode, but with per-scanline palette changes.

Scali already wrote a blog post about this demo:
https://scalibq.wordpress.com/2014/11/22/cgad … y-codeblasters/

Reply 706 of 745, by MobyGamer

User metadata
Rank Member
Rank
Member
NewRisingSun wrote:

We still need someone to do the PCjr captures, since I only have a Tandy 1000 TX (so far). I suppose Trixter is out of the question, otherwise he would have done it a long time ago.

Trixter regularly experiences stack overflows. I have put in a bid for a 558 for capturing PCjr.

Reply 707 of 745, by NewRisingSun

User metadata
Rank Oldbie
Rank
Oldbie

The card arrived today. I cannot try it in Win7 64bit because there do not seem to be official 64 bit drivers from Hauppauge available for this card, so I stand waiting for your instructions on how to use it for capturing purposes.

Edit: I had to user the BETA version of DScaler, not the stable one.

BC.jpg
Filename
BC.jpg
File size
33.99 KiB
Views
260 views
File license
Fair use/fair dealing exception

😀

I am a bit disappointed with DScaler's decoding quality though, at least at the default settings. In any case, I am anxiously awaiting your test programs.

Reply 708 of 745, by reenigne

User metadata
Rank Oldbie
Rank
Oldbie
NewRisingSun wrote:

I am a bit disappointed with DScaler's decoding quality though, at least at the default settings.

The hardware decoding quality is nothing special, but the real advantage of this card is that we can capture raw sample data before it's decoded, and then perform high-quality decoding in software. I've uploaded my programs for doing this to http://www.reenigne.org/misc/vbicap.zip . First make sure DScaler is closed, then run vbicap.exe from the archive. This will open a connection to the card (via DScaler's dsdrv4 driver) and stay running. Next try running capture_field.exe. This should generate two files in the current directory - captured.png (a 640x480 capture decoded with my algorithms) and captured.png.raw which is 460800 samples (approximately one field) of composite data sampled at ~28.6MHz (approximately 8 samples per colour carrier cycle). Easiest way to examine this is to open it up in an image editor that can open raw data files (in the "binary data" sense, not the "camera raw" sense). I use Paint Shop Pro 4 for this. Set it to no header, single greyscale channel (8 bits per pixel) with dimensions 1824x252. If your card is like mine there is will be a slight leftwards slope as you go down the image due to the card's sample rate being slightly slow. About 10 scanlines worth of picture will be missing from the bottom of the image (I haven't figured out how to get the card to do gapless captures or if it's even possible with this hardware).

If it complains about a missing msvcr110.dll you can install that from https://www.microsoft.com/en-gb/download/deta … s.aspx?id=30679 . Any other missing dependencies let me know.

When you're done capturing, run vbicap_close.exe to close vbicap.exe (closing it directly may cause the card to DMA over random bits of RAM and make your machine unstable).

NewRisingSun wrote:

In any case, I am anxiously awaiting your test programs.

I will work on the Tandy versions of the test image and calibration program tomorrow.

Reply 709 of 745, by NewRisingSun

User metadata
Rank Oldbie
Rank
Oldbie

This is the captured.png and captured.png.raw I get when I use your program:

captured.png
Filename
captured.png
File size
211.52 KiB
Views
245 views
File license
Fair use/fair dealing exception

If this isn't how it's supposed to look, then we've got a problem.

Attachments

  • Filename
    captured.png.raw.zip
    File size
    100.77 KiB
    Downloads
    13 downloads
    File license
    Fair use/fair dealing exception

Reply 710 of 745, by reenigne

User metadata
Rank Oldbie
Rank
Oldbie
NewRisingSun wrote:

This is the captured.png and captured.png.raw I get when I use your program:

I think my decoder just has parameters set up for my old CGA card which has a much lower signal voltage (38-156 instead of 56-212). If you want to use this for making screen captures then I can make a different decoder, or you can process the .raw file with your own decoder.

The good news is that the raw capture looks great - a good signal range with low noise and no clipping. Also there's a much lower frequency difference between your card's sample rate and your Tandy's color carrier than there is between my card's sample rate and my XT's carrier.

Reply 711 of 745, by NewRisingSun

User metadata
Rank Oldbie
Rank
Oldbie

There's a regular series of 0 bytes in the raw file. Is that a sign of clipping during the sync peak, or is it just that the signal offset is automatically adjusted to have the lowest voltage at zero? I am asking because I thought of looking at the sync versus blanking amplitude of a few home consoles, and I couldn't use that raw capture if the sync amplitude were clipped.

Reply 712 of 745, by reenigne

User metadata
Rank Oldbie
Rank
Oldbie
NewRisingSun wrote:

There's a regular series of 0 bytes in the raw file. Is that a sign of clipping during the sync peak,

Yes, it does clip during the sync peak unfortunately.

Reply 713 of 745, by NewRisingSun

User metadata
Rank Oldbie
Rank
Oldbie

The reason that I am after the sync peak is that it provides for a way to automatically normalize the overall signal, as the sync amplitude is defined in NTSC as 40 IRE units. In fact, that is how AGC works on an RF modulated signal, where the sync tip has the highest level because of negative modulation.

Reply 714 of 745, by reenigne

User metadata
Rank Oldbie
Rank
Oldbie
NewRisingSun wrote:

The reason that I am after the sync peak is that it provides for a way to automatically normalize the overall signal, as the sync amplitude is defined in NTSC as 40 IRE units. In fact, that is how AGC works on an RF modulated signal, where the sync tip has the highest level because of negative modulation.

For a monochrome signal that's really the only way to normalize. For a colour signal there's also the color burst which is specified as going between -20 IRE and +20 IRE. Lots of input devices (including the composite TV I use and the ImpactVCB in hardware decoding mode) will use this for normalization - I know because both give a very bright image when the colour burst is disabled. Unfortunately this is also specified as being a sine wave so a square wave burst (like CGA) will yield a different normalization depending on whether you measure peak-to-peak, RMS or peak-to-peak of the carrier frequency component.

One of my many planned projects is to make my own USB raw capture device using a Cypress CY7C68013A and an AD9708/AD9280 DAC/ADC board (which cost me 10 and 17.48 UK pounds respectively). If that works as well as I think it should, it'll allow calibrated gapless capture and generation of video signals at very high sample rates. Off-the-shelf solutions for the same thing seem to cost thousands of pounds. It may take me a while to get around to it, though.

Reply 715 of 745, by Scali

User metadata
Rank l33t
Rank
l33t
reenigne wrote:

For a monochrome signal that's really the only way to normalize. For a colour signal there's also the color burst which is specified as going between -20 IRE and +20 IRE. Lots of input devices (including the composite TV I use and the ImpactVCB in hardware decoding mode) will use this for normalization - I know because both give a very bright image when the colour burst is disabled. Unfortunately this is also specified as being a sine wave so a square wave burst (like CGA) will yield a different normalization depending on whether you measure peak-to-peak, RMS or peak-to-peak of the carrier frequency component.

Was it not also the case that the amplitude of the colorburst was much higher on old CGA than on new CGA (either in absolute sense, or relative to the actual pixel data)?
In which case, Tandy and PCjr may also have their own 'balance' here?

http://scalibq.wordpress.com/just-keeping-it- … ro-programming/

Reply 716 of 745, by reenigne

User metadata
Rank Oldbie
Rank
Oldbie
reenigne wrote:
NewRisingSun wrote:

In any case, I am anxiously awaiting your test programs.

I will work on the Tandy versions of the test image and calibration program tomorrow.

Give this a go on the Tandy for the test image: http://www.reenigne.org/misc/ttest.zip . Unfortunately DOSbox doesn't seem to handle raster effects in Tandy mode so I'm going to go and look for another emulator. Press escape to exit.

If that gives a stable image and all the different colour pairs are visible then I'll work on the calibration program that transforms the captures of this image to the chroma matrix table.

Reply 718 of 745, by reenigne

User metadata
Rank Oldbie
Rank
Oldbie
NewRisingSun wrote:

If you just need per-scanline raster effects in Tandy mode, I can send you my custom DOSBox build that supports them. (I could also post a source patch, but why bother...)

That would be very useful - thanks!

Reply 719 of 745, by NewRisingSun

User metadata
Rank Oldbie
Rank
Oldbie

Are you sure you want this with the colorburst disabled?

captured.png
Filename
captured.png
File size
131.5 KiB
Views
198 views
File license
Fair use/fair dealing exception

Attachments

  • Filename
    captured.png.raw.zip
    File size
    99.73 KiB
    Downloads
    13 downloads
    File license
    Fair use/fair dealing exception