Media Player 128

[Hydrophilic]

Warning: long-winded post

I was playing around with videos on my Windows PC trying different formats / codecs that would work with anything.  Well it seems plain old MPEG(1) will work with anything (even Windows 3.11), but it does not have very good compression or quality (maybe bad encoding software).  Anyway, I came to the conclusion that MPEG-2 (.VOB files) should work with Mac, Windows, and Linux.  Unfortunately, I don't think they would work on iPhone or PSP.  Now MP4s will work on those portabile devices but they're not supported on Windows (at least not on standard Windows Media Player).  I downloaded a program called Media Player Classic that works on Win XP and 2K but not on 95/98/ME.  So I'm sticking with .VOBs for the moment.  (that means I need to find an MPEG2 player for Win 3.11)

ANYWAY

This got me to thinking back about playing digital audio (see this thread) on my Commodore.  I mean, I have several multi-gigabyte SD cards, but all my Commie software will only fill up half of one.  It just pains me to see all that storage potential go to waste

All this thinking made want an MP4 player for my Commodore.  So like a real hacker / moron, I started writing one.  After a day or two of coding I thought to myself, somebody has already done this... I just need to check out CSdb.  But then I thought, I might end up stealing someone's code so I better finish what I started and then compare.

So after finishing the testing of v0.9 of my software, I spent a few hours searching CSdb for things like "digi player" "video player" and "media player" and came to the conclusion there is no comparison!  By the way, search for "media player" returned 0 results.  I found that surprising considering over 400 results for "digi".  Completely off-topic, I also found a demo "Edge of Disgrace" which is totally awesome.

On topic, a lot of the "digi" software were demos.  There were some tools for creating / playing / editing digis, but none of them came with data files!  So I've downloaded several players but have nothing to play with them.  It's kinda of hard to compare.

Of course there were plenty of SID players too, and finding media files for them is no problem.  However, I'm not interested in those, as they are like CBM-specific MIDI files (is there a cool name like PETSCII to describe them?)

Most of the digi players / editors I found play 4-bit audio by banging SID's volume register.  Is there a common filename / type for these kind of files?  Like, according to the thread mentioned above, the Digimaster has DFF files, but these are 8-bit audio files.

I did find the ModPlayer which play's Amiga audio files.  I'm guessing these would be .MOD files?  I really don't know much about them, so if anybody has some info / links that could be helpful.  Also I hear there are also Amiga .IFF files?  Again any info / links would be welcome.  I didn't see anything that would play .WAV files, although I probably just missed it/them.

Now let me say there is SOME comparison because the digi-players I did find work very similar to the method I use, which is not suprising considering (yes I took a peak at their code after I finished my version 0.9).  HOWEVER, all the players I found work by loading the data into RAM and then playing them.  Well that's great if you want to play a 10 or 20 or 30 second audio clip... but it will not work for playing a 3:30 minute song or 1:30:45 video.

Of course the idea is totally ludicrous when dealing with a 1541, but quite practical for a 1581, hard drive, or uIEC.  Well you couldn't fit a video on a 1581, but you could fit one or two songs.

What I have now is player that plays my custom (I haven't seen anything else like it) audio files at 15kb/s.  By the way a 1541 / 1571 can work, IF you use the exact sector interleave of 12 for tracks below the directory and 11 for tracks above.  But you only get about a minute of audio (or two for 1571).

Now a 1581 or uIEC should be able to handle double the bandwidth, that is 30kb/s.  This could be used for stereo audio (umm, did I mention the software is only playing mono right now).  I haven't tested this yet because I don't have a second SID in my C128.  I guess I could test it in VICE if somebody wanted me to.

Or the extra bandwidth could be used for video.  An idea I'm still playing with...  Or the extra bandwidth could be used for playing 8-bit digis (if I can figure out how Digimaster works).

So right now, it plays my custom audio format of psudo-2-bit audio.  This is combination of 1-bit PW modulation plus 4-bit Volume.  The 1-bit samples play at 8kHz while the volume is updated at 1/4 rate or 2kHz.

Now this format has several consequences.  The pros:

- uses 1/2 the data of traditional(?) 4-bit digis
- high frequencies can be filtered
- good dynamic range / bass

The cons:
- the high frequencies are 1-bit, and sound rough, even with filtering
- the low frequencies can't be filtered (like traditional 4-bit digis)

After listening to some of the 4-bit digis on the demo software (not actual file players) that I found, I think they sound a lot better than my psudo-2-bit digis (duh).  If I went with 4-bit digis, at 7.8kHz, that would mean no possibility for stereo or video... unless...

The audio sample rate was reduced to 5.23kHz.  You loose a lot (more) of the high frequencies this way.  But even so, the "cleaness" of 4-bit over psudo-2-bit makes this desirable.  I should probably just put an option in the player.  When run at 5.23kHz (at 4-bit/sample) I should get a data rate of 21kb/s with another 21kb/s to spare for stereo audio or video.  I say "should" because I have not tested it... but am fairly confident it would not work with 1541/1571.

What I have tested is the 7.8kHz psudo-2-bit audio in the following scenarios:

- real c128 with uIEC (no problem)
- real c128 with 1571 (only works with optimal sector interleave)
- VICE with 1581 (no problem)
- VICE with 1541 (same problem as 1571)

Oh yeah, this requires drive to have JiffyDOS.  I guess it could be programmed with a fastloader if no JiffyDOS, but since this is only possible (AFAIK) with Commodore floppy drives and they are rather useless (except maybe 1581) I haven't worked on that.

What?  You're still reading this?  Wow, you sure have patience!

Anyway, I just wanted to toss these ideas and questions out there and see what you folks think before I publish something foolish.

[redrumloa]

Very cool project!   I guess you don't have a SuperCPU 128? If you did you could load everything into SuperRAM and play back at a higher bitrate?

[RobertB]

I did find the ModPlayer which play's Amiga audio files.  I'm guessing these would be .MOD files?

Yes, the Dannenberg (Ezekowitz) ModPlayer plays .MOD files.

I really don't know much about them, so if anybody has some info / links that could be helpful.

You can e-mail Vanessa Ezekowitz at vanessaezekowitz(at)gmail.com for more information on .MODs.  Also you can place your questions at the forums at Amiga.org and at Amigaworld.net, and I'm sure many can help you there.

Also I hear there are also Amiga .IFF files?  Again any info / links would be welcome.

Again try the forums at Amiga.org and Amigaworld.net

I didn't see anything that would play .WAV files, although I probably just missed it/them.

There is the Dannenberg (Ezekowitz) Sound Studio v3.71 (I prefer v3.71 over the v3.8, because the latter is buggy).

Or the extra bandwidth could be used for playing 8-bit digis (if I can figure out how Digimaster works).

If you need contact information for Digimaster developer Chris Brenner, just send me a private message.  He may be able to help you out.

               Truly,
               Robert Bernardo
               Fresno Commodore User Group
               http://videocam.net.au/fcug
               July 24-25 Commodore Vegas Expo 2010 - http://www.commodore.ca/forum
               and click on ComVEX

[RobertB]

This got me to thinking back about playing digital audio (see this thread) on my Commodore.  I mean, I have several multi-gigabyte SD cards, but all my Commie software will only fill up half of one.  It just pains me to see all that storage potential go to waste

All this thinking made want an MP4 player for my Commodore.

Well, there is the MP3 plug-in for the MMC Replay/MMC64 and for the IDE64.  Several months ago, one of the SCCAN members showed me how MP3s were easily played through the MMC64.  I have yet to try MP3s on my IDE64 v4.1.

              Truly,
              Robert Bernardo
              Fresno Commodore User Group
              http://videocam.net.au/fcug
              July 24-25 Commodore Vegas Expo 2010 - http://www.commodore.ca/forum
              and click on ComVEX

[Hydrophilic]

I guess you don't have a SuperCPU 128?

I wish!  Maybe somebody better at hardware than me can mod Andre Fachat's design for the C128... with that kind of processing power, you might be able to do conversion real-time.  My player requires .WAV/MP3/MPEGs etc to be converted for CBM format before playing.  When I was messing around with video files on my PC and decided I need to convert my videos to play on my DVD player and older Windows versions (should also play on Linux and Mac), I figured I would try converting them for Commodore too.

If you did you could load everything into SuperRAM and play back at a higher bitrate?

Right.  Because I don't have a SuperCPU, I can try using an REU... but only in VICE, because I don't own one of them either.

Another reason I started on this is to see what kind of bitrate I can get out of various drives, 1581 and uIEC in particular.  I imagine MMC, CMD-HD, or 64HDD could match, but I won't be able to test myself.  Also I want to be able to play media "on the fly" without having to load everything into memory first.  I guess this won't be possible for SID files because some of the ones I've seen will call an initialize routine that's located at the end of the file

For higher bandwidth, there is fast serial and ACIA to try.  If we're lucky, uIEEE could become a possibility.

@RobertB,

Thanks for the tips about Amiga.org and Sound Studio.

If you need contact information for Digimaster developer Chris Brenner, just send me a private message.

Thanks for the offer.  Hopefully I can figure it out myself.

Well, there is the MP3 plug-in for the MMC Replay/MMC64 and for the IDE64.  Several months ago, one of the SCCAN members showed me how MP3s were easily played through the MMC64.  I have yet to try MP3s on my IDE64 v4.1.

See, I knew somebody would have already tried playing MP3s on their Commie.  Do you have any more info about this?

[RobertB]

See, I knew somebody would have already tried playing MP3s on their Commie.  Do you have any more info about this?

For more details on how the MP3 plug-in works for the IDE64, I suppose you can contact the developer.  That would be Kajtár "Soci/Singular" Zsolt at kajtarzsolt(at)googlemail.com

             Truly,
             Robert Bernardo
             Fresno Commodore User Group
             http://videocam.net.au/fcug
             July 24-25 Commodore Vegas Expo 2010 - http://www.commodore.ca/forum
             and click on ComVEX

[wte]

Also I hear there are also Amiga .IFF files?

Wiki: http://en.wikipedia.org/wiki/Interchange_File_Format

Well, there is the MP3 plug-in for the MMC Replay/MMC64 ...

As far as I remember the MP3 plugin for the MMC Reply requires a little piece of hardware: http://www.schoenfeld.de/inside/Inside_MP3AT64.txt

Regards WTE

[RobertB]

...the MP3 plugin for the MMC Reply requires a little piece of hardware...

Not only that but the MMC Replay/MMC64 is no longer manufactured.

          Now that's missing hardware, 
          Robert Bernardo
          Fresno Commodore User Group
          http://videocam.net.au/fcug
          July 24-25 Commodore Vegas Expo 2010 - http://www.commodore.ca/forum
          and click on ComVEX

[Mark Smith]

You can plug the MP3@64 into the IDE64 as well .. works a treat :-)

[Hydrophilic]

Thanks for the info folks!  It seems the Amiga IFF are the big-endian version of MS RIFF files.  This reduces the learning curve since I'm already familiar with RIFF files (at least WAV and AVI).

Both versions make heavy use of 32-bit numbers.  From a programming stand-point, anything over 8-bits is the same on our little 8-bit Commies.  But in terms of bandwidth / filesize, 32 bits is excessive most of the time.

So I was going to implement "CIFF" format (Commodore Interchange File Format).  This would use 16-bit packet sizes.  Only the file header would have a 32-bit number (for total file size).

Also there is no LIST element; the file is always a LIST of packets (even if it is only 1 packet).  In case you have packet over 64kiB, you would need to split it in two or more pieces.

My player is working with custom "psudo-2-bit" audio and 4-bit audio in CIFF file format.  With a little work, I think it could play native WAV 8-bit files in 4-bit resolution, but only if the sample rate is 8kHz... I don't think the CPU is up to real-time frequency translation.

16-bit WAV should also be possible with the same constraints (8kHz sample rate, reduced to 4-bit resolution), but only if I can increase the bandwidth...

Lately I've been working on 160x176 multi-color (grayscale) video.  The width of 160 is the whole VIC2 multi-color screen.

The 176 height is based on aspect ratio.  Although VIC2 output is for a device with 4:3 aspect ratio, measurements on my television show the visible (inside borders) aspect ratio to be very close to 6:5.  Or more importantly, a multi-color pixel aspect ratio of 2:3 (hi-res pixel aspect ratio 4:3).

When I convert 4:3 video (for example 480x360) directly to 160 width, I get height of 120.  Because multi-color pixels are twice the width of hi-res pixels, using a height of 240 (cropped to 200) looks fine in VICE because my PC monitor has square pixels (1:1 pixel aspect), but on a real C128/TV the image is squashed vertically (expanded horizontally).  This because the VIC2/TV has a multi-color pixel aspect of approximately 2:3...  Anyway, the inverse, 3/2, times 120 equals 180.  And multi-color 160x180 has correct aspect on my TV.

But 180 is not a multiple of 8, which is important for my video conversion / compression scheme.  So I could go with 176 or 184.  Either results in minor (I can't notice) distortion to aspect ratio, but 176 reduces the bandwidth / filesize while 184 would increase it... so I'm using 160x176.  This results in TV display very close to 4:3 aspect ratio (like the source video).

I just went and measured on my TV, and 160x176 is closer to 4:3 aspect than 160x180... I guess my 2:3 pixel aspect ratio isn't accurate enough...

Can any NTSC users confirm 160x176 multi-color results in an image with (approximately) 4:3 aspect ratio on a real hardware (like TV or 1084)?  Is 160x180 or 160x184 any closer to 4:3?

If it helps, you can issue BASIC command

Code Select Expand

GRAPHIC3,1:BOX1,0,0,159,175[,,1]
You can omit ,,1 to make a hollow box or use it to make solid box (go eat a sandwitch or brew some coffee if you choose solid box).

Is this also true for PAL on real hardware?  Thanks!

[RobertB]

Can any NTSC users confirm 160x176 multi-color results in an image with (approximately) 4:3 aspect ratio on a real hardware (like TV or 1084)?  Is 160x180 or 160x184 any closer to 4:3?

I'm a bit confused.  Are you using 40-column mode, or are you trying to do this in 80-column mode?  In 40-column mode, multicolor on the Commodore used 160x200.

          And that's leaving a border around the image,   
          Robert Bernardo
          Fresno Commodore User Group
          http://videocam.net.au/fcug
          July 24-25 Commodore Vegas Expo 2010 - http://www.portcommodore.com/commvex

[saehn]

160x184 is pretty close to 4:3, and it's definitely closer than 160:180.

[Hydrophilic]

160x184 is pretty close to 4:3, and it's definitely closer than 160:180

Thanks saehn.  Can you tell me what type of device you have (TV, monitor, NTSC, PAL)?  From some PAL screen shots I've seen, they look wider than NTSC.  Like I said when I checked my NTSC TV, 160x176 was best, but it could just be my TV...

I'm a bit confused.  Are you using 40-column mode, or are you trying to do this in 80-column mode?  In 40-column mode, multicolor on the Commodore used 160x200.

This is 40-column mode because... I like making things difficult?  (Syncing loader and player to avoid bad lines is pretty messy, and running at 1MHz).

You are correct, the multi-color screen is 160x200, but it does not cover an area with 4:3 aspect ratio (which is what standard definition video has).  So if I play a SD video on the whole VIC screen, it is stretched too tall (or, equivalently, squeezed to thin).  Kinda of like movies you might have seen on TV years ago, when they would squash the film horizontally so you wouldn't miss anything, but then everybody in the movie looks really tall and thin.

In other words, I need to scale the SD video to a dimension like 160x180 so on the VIC2 screen it will have 4:3 aspect ratio (that's 4/3 = 1.333).  To determine aspect ratio, just get a ruler or tape measure, and measure the width of a BOX on the screen.  Then measure the height.  Aspect ratio is then width/height.  It doesn't matter if you use cm, inches, or nautical miles (as long as both measurements are the same units)!

But I only have one TV and none of my PC monitors would accept VIC2 (40-column) video output.  So I only have one measurement to go by.  So I just wanted to know what size BOX other people need to draw that measures 1.333 (4:3) aspect ratio. 

Using VICE doesn't count because PC monitor has square pixels while VIC2 does not (note: some video cards / monitors can display something close to VIC2 if you use strange settings like 640 x 350) 

...

In the meantime (awaiting some type of size consensus), I've been working on the demultiplexer / packet scheduler.  O.M.G. This has to be the most difficult thing I've ever tried to program.  Get this: I had to actually make a program flowchart!  The first time in my life I ever had to make one!  Sure I've made a few flowcharts in the past, but that was per request not out of neccessity.  (Maybe mind is getting rusty)

I think I've got it working... more testing needed... without multiplexing audio, the frame rate is wildly inconsistent...  Something like 20 to 0.2 frames per second!  Of course that is also an encoder rate control problem.  But we can discuss that later.

Right now, I'd like to know what size is your BOX?

UPDATE: Before posting this, I noticed in WinVICE 2.2 there is a new setting under Settings/Video Settings/FullScreen.  Here I found a checkbox "Keep Aspect Ratio" and it works in window mode too (not only fullscreen mode).  Anyway, beside the checkbox is an edit box where you can type in a value.  Entering 0.8 gives a close approximation without using strange video modes.  I believe this is the pixel aspect ratio (different from screen aspect ratio discussed above).  So this leads to another question... what pixel aspect ratio in VICE looks most like a real 40-column screen to you?

[saehn]

I have both an NTSC monitor and TV. I believe that NTSC and PAL have the same ration: .82. Using the BOX command and a simple test program, I've confirmed that this gets fairly accurate results. We're never going to have extremely precise results due to the variety of output devices, as you've probably guessed.

Code Select Expand

10 graphic1,1:x=100:y=100:y=y*.82
20 box1,159-x/2,99-y/2,159+x/2,99+y/2

By plugging in a 4:3 ratio, I get pretty accurate results with a physical measurement.

Code Select Expand

10 graphic1,1:x=160:y=120:y=y*.82
20 box1,159-x/2,99-y/2,159+x/2,99+y/2

[saehn]

That was hi-res mode, by the way. The following multi-color version is fairly close to 4:3, which amounts to slightly less than the total height (200).

Code Select Expand

10 graphic3,1:x=160:y=120:y=y*1.64
20 box1,79-x/2,99-y/2,79+x/2,99+y/2

[Hydrophilic]

Wow, my TV must be warped because the full VIC screen (or a few rasters short as in your program) is not 4:3, more like 6:5.

I wish I still had the test videos from back in the day when I repaired VCRs.  You might have seen these test patterns before.  The one I'm thinking of has a huge circle in the center that spans top to bottom (but not left to right because it is a circle, not an elipse) with an X going from each corner of the screen.  With a test video like that, it would be easy to see if my TV was warped (by measuring height/width of the circle).

I have both an NTSC monitor and TV...I've confirmed that this gets fairly accurate results.

Thanks for checking on two different devices!  I guess my TV really is warped

We're never going to have extremely precise results due to the variety of output devices, as you've probably guessed.

I agree there isn't going to be a precise value, but I was hoping some other people would post some BOX sizes, just to see what the range of values are, so some sort of average could be used.

...

In the meantime I finally got the demuxer debugged.  It's funny how you think everything is working when using test values that should cover all the bases, only to discover more bugs when you use real data...

The frame rate has improved very slightly.  My last testing was with simple RLE encoding.  I'm working on a slightly more complex scheme that does some memory copies and pattern runs.  Of course this will never give the type of compression you'd get with entropy encoding (variable bit-size codes), but because over 50% of CPU time is spent in the IRQ (playing samples and loading data), I don't think the CPU would have the time for lots of bit shifting that entropy coding would need.  I'm hoping to get the worst-case frame rate upto 1fps.

Now 1fps is less like video, and more like a slide show on crack.  But right now the video is I-frames only.  The real speed boost will come from P-frames, which only encode the difference between two frames of video.  I don't think the CPU will be able to handle B-frames, which interperolate a frame between two encoded frames.

[saehn]

There are some screenshots here if you want to burn them to DVD and use... I don't see a freeware calibration DVD anywhere but maybe you can find one online anyway.

http://www.calibrate.tv/

[Hydrophilic]

Thanks for the link.  Unfortunately it seems focused on color calibration.  There is a link with all the calibaration images on the disk, but none, from what I could see, would be useful for testing aspect ratio.

If anyone else (thanks again, saehn!) has a real C128 and tape measure or ruler, and a few minutes to spare, please try this program and let me know which Y value makes a BOX with aspect ratio of 1.333 (width / height)... you can type it in or download...

Code Select Expand


10 color4,1:y=180:do
20 graphic3,1:box1,0,0,159,y:getkeya$
30 ifa$<>"+"anda$<>"-"thenexit
40 ifa$="+"theny=y+1:elsey=y-1
50 loop:graphic0:printy


It's very easy to use.  It will draw a BOX on the screen.  Press + or - to change the height of the BOX (the Y value).  Press any other key to exit the program and print the Y value.

You just need to measure the width and height on your screen (the reason you need a ruler or tape measure), and calculate aspect ratio = width/height.

It's a game!  Figure out what Y value gives aspect ratio as close to 1.333 as possible.  Once you know, please report the Y value and what type of display you have (NTSC or PAL, TV or monitor).  Thanks!

...

I've finally finished debugging the new compression codec.  What a pain!  Every time I decided to change the decoder, I had to re-write and debug the encoder and then test/debug the decoder!  Sometimes I wish there were two of me...

It's an extremely simple (thus fast) compression that gives an average of 47% compression.  (This was tested with real video images -- traditional, "human drawn" bitmaps generally gives compression over 60%.).  This is almost 50% better than the original (in terms of file size / compression).  So in theory, the worst-case frame rate is almost 1 fps (0.81 is a better value), as I originally hoped...

But now it takes longer to decompress a packet than it does to load it (even though the code is fairly well optimized).  This is not all bad, because it means their will be bandwidth available for audio / subtitles.  But it does mean the worst-case frame rate (still only I-frames, see previous post) is under 1 fps.  I don't have an exact value, but the average frame rate is 0.777 according to my testing.

So let's hope P-frames will give a dramatic improvement.  Otherwise I would have to reduce the size of the video...

[bacon]

I use a video capture card connected to my EeePC with its tiny screen as output for my C128, so I had to change the program slightly to be able to measure the box. I quadrupled the X size to 76 pixels and with Y=105 I got a perfect 4:3 apect ratio (48x36 mm, see screenshot).

Edit: FYI, I use a PAL C128.

[Hydrophilic]

Thanks bacon for the PAL results!!  So by my calculations, a 160 (multi-color) pixel-wide image would need to be 221 rasters tall (which explains why you would need to modify things, considering VIC-II only supports 200 rasters).  This is a major difference from saehn's and my measurement for NTSC (around 192 rasters).  So either something is wrong with my calculation or your capture card, or more likely (from photos of PAL screens I've seen), there is a significant difference in pixel aspect ratio between NTSC and PAL video on the C128.

Anybody else have some BOX sizes to report?

...

I thought I was ready to implement P-frames, but I realized I would need to implement screen-flipping (a.k.a. back buffers), but my code had no provision for it...
So I had to modify the IRQ routines to check for the border (a good time to flip screens).  Well as long as I had to do that, I did what I didn't want to do: implement 2MHz in the border (now it can never be directly ported to the C64).

What a pain!!!  Originally I had a set of IRQ routines (2 or 4 routines, depending on audio format) to play audio and load data; this change made 2 sets of IRQ routines... (4 to 8 routines).  And it gets worse, the transition from 1 to 2 MHz (and vice versa) can't be done in a single IRQ routine, so 2 additional routines were added; so now there's 6 to 10 IRQ routines... and these have to co-ordinate with each other and with the main (non-IRQ) code.

The good news is the worst-case I-Frame rate has improved to around 0.92 NTSC or 0.95 PAL.  This is (almost) what I originally wanted for I-Frames.  The bad news is now debugging is taking longer than ever.  Only now (finally!) am I really starting on coding P-Frames...

Off topic: I took a break from all that ugly coding and fired up an old save file of Final Fantasy X.  There I already had every character with max MP = 999 and max HP > 9999 and all other stats (except Luck) at 255.  Luck for all characters was around 120.  So after another 24 hours or so of additional game time, all characters have Luck (and other basic stats) at 255, and all characters have max HP > 66666 which means if they equip armor with HP+50%, they can all have max HP of 99999.  Although completely pointless, I think it's pretty cool to load up a game with all characters with max stats.  The game desginers did an awesome job; I had to maximize (almost?) every node on the sphere grid to accomplish that!

On topic: after resuming coding of P-Frames, it occurred to me that even though our little 8-bit CPU can't handle B-Frames, the (32-bit) encoder can... So I'm thinking we can have the benefit of "psudo-B-Frames".  Which is to say the encoder can output future frames which are used to derive current frames (contrary to P-Frames which derive current frames from past frames).  Umm, maybe these should be called "F-Frames"?

[saehn]

Thanks bacon for the PAL results!!  So by my calculations, a 160 (multi-color) pixel-wide image would need to be 221 rasters tall (which explains why you would need to modify things, considering VIC-II only supports 200 rasters).  This is a major difference from saehn's and my measurement for NTSC (around 192 rasters).  So either something is wrong with my calculation or your capture card, or more likely (from photos of PAL screens I've seen), there is a significant difference in pixel aspect ratio between NTSC and PAL video on the C128.

There's quite possibly a real difference between NTSC/PAL monitors, but keep in mind that bacon was using his EeePC screen as video output. Frankly, I think your basis of comparison between NTSC/PAL should always start with a CBM monitor. Once you get into TVs and non-CBM outputs, we can expect to see a pretty wide range of variation. :-)

[bacon]

Thanks bacon for the PAL results!!  So by my calculations, a 160 (multi-color) pixel-wide image would need to be 221 rasters tall (which explains why you would need to modify things, considering VIC-II only supports 200 rasters).  This is a major difference from saehn's and my measurement for NTSC (around 192 rasters).  So either something is wrong with my calculation or your capture card, or more likely (from photos of PAL screens I've seen), there is a significant difference in pixel aspect ratio between NTSC and PAL video on the C128.

There's quite possibly a real difference between NTSC/PAL monitors, but keep in mind that bacon was using his EeePC screen as video output. Frankly, I think your basis of comparison between NTSC/PAL should always start with a CBM monitor. Once you get into TVs and non-CBM outputs, we can expect to see a pretty wide range of variation. :-)

The problem with CBM monitors (at least the two 1084S monitors I've owned) is that you can adjust both the width and height of the picture over a wide interval, so there's no guarantee that the picture from two CBM monitors are comparable. Most TVs made the last ~10 years, on the other hand, have a fixed width/height ratio afaik. This is even more true for video capture cards and software, where you will always get a true 4:3 aspect ratio. I'd say that video capture cards are a very good basis of comparison. As for the EeePC's screen, it has square pixels so the output from the video capture card will be as correct there as on any other screen.

[saehn]

Yeah, I was thinking about that too. I remember the vertical size adjustment on my 2002 but wasn't sure about other monitors, and I couldn't find a list of controls online. Interesting point about the square pixels on the EeePC, but CBM monitors didn't have square pixels. The average ratio for CBM pixels has been roughly estimated as .82.

Well, in any case, as long as Hydrophilic gets close, I think we'll all be happy. I don't think anyone is expecting a high-fidelity video output on his Commodore 128. :-D

[bacon]

Interesting point about the square pixels on the EeePC, but CBM monitors didn't have square pixels. The average ratio for CBM pixels has been roughly estimated as .82.

The EeePC's monitor (or any other PC monitor) doesn't know anything about the pixels being output from the VIC chip, and neither does the video capture card. The capture card takes the video signal from the C128 or any other source and outputs a 4:3 aspect ratio picture to the PC, which shows it on the screen. As long as the PC monitor has square pixels the image on the screen will retain the 4:3 aspect ratio, i.e., the CBM pixels will show up with the correct ratio since the C128's video output was meant to be shown on a 4:3 aspect monitor. Hence my pointing out that the EeePC screen shows square pixels.

[saehn]

The EeePC's monitor (or any other PC monitor) doesn't know anything about the pixels being output from the VIC chip, and neither does the video capture card. The capture card takes the video signal from the C128 or any other source and outputs a 4:3 aspect ratio picture to the PC, which shows it on the screen. As long as the PC monitor has square pixels the image on the screen will retain the 4:3 aspect ratio, i.e., the CBM pixels will show up with the correct ratio since the C128's video output was meant to be shown on a 4:3 aspect monitor. Hence my pointing out that the EeePC screen shows square pixels.

I get what you're saying but I still think that it's slightly off since it's 4:3 aspect ratio whereas the average CBM monitor aspect ratio is closer to .82 (this is something of a scene standard---for both NTSC and PAL---not just my own personal opinion). And as we can see from our earlier posts, your output (on the eeePC) differs from mine (on a CBM monitor).

If Hydrophilic can make it adjustable, then all problems will be solved.