Video from CD ROM
Mathy Van Nisselroy
Last Friday I ran into a CD ROM that has video on it. (BTW, nope, no nude
ladies on this CD) It required Video for windows, Quikview or MPEG plus a
minimum of a 2 or 4 speed (I'm not sure) CD ROM player and some PC. When I
went back to get the CD a day later, the shop was closed untill further notice.
Has anybody ever tried to use one of these Video CD ROM's on an 8 bit computer?
Did you succeed? Were you able to have the video run at it's intended speed?
How much did graphics suffer?
CU Mathy van Nisselroy
Daniel Miller
Van Nisselroy) wrote:
Good gosh, Mathy, you can't run a VCD on an 8bit computer. That
requires a much more powerful processor and more memory. I am not in
the habit of saying "never" but if a programmer managed to play a VCD
on an 8bit I would regard him not only as genius, but as the new
messiah.
TFH/Fony
news:3b405c6a...@news.CIS.DFN.DE...
> Good gosh, Mathy, you can't run a VCD on an 8bit computer. That
> requires a much more powerful processor and more memory. I am not in
> the habit of saying "never" but if a programmer managed to play a VCD
> on an 8bit I would regard him not only as genius, but as the new
> messiah.
*LOL* :))
Azymuth
(okay, it stayed with 3 or 4 secs...)
"Daniel Miller" <DC...@USA.NET> schreef in bericht
news:3b405c6a...@news.CIS.DFN.DE...
Jason
> They have had Videosamples on a MSX computer !!
There are video sequences on the breadbin (mainly in demos) but they're
not realtime decoding the VCD format and that's where the processing
power comes in.
--
Jason =-)
_______________________________________________________________________
TMR / / / / / / / /\
/ /__/ / / /__/ / / / /__/ Email: t...@c64.org / /
/ /\_/ / /__ / / / / __// TMR_C0S on IRC / /
/ /__/ / / / / / / / / / http://www.tmr.cosine.org.uk / /
/_____/_____/_____/__/__/__/_____/_____________________________________/ /
\_____\_____\_____\__\__\__\_____\_____________________________________\/
Pekka "Pihti" Takala
realtime. On 8 bitties, there is also often color restrictions which
makes more problems. Many machines have only 16 colors and restrictions
with those.
On a c64/128 there is one possibility: SuperCPU that runs at 20 mhz. I
think it might be able to do the decoding, especially if it has 16 megs
of ram memory. First it would decode its memory full of images. Because
of the c64/128's heart still runs at 1 mhz and this makes slowdowns if
the supercpu is programmed wrong, the pages would be copied to the
videoram using buffer technology. So, when the vicII draws the first
picture, the second is copied to another page and page is flipped.
Again, the vic draws the following pic, the next pic is copied to the
unvisible memory area. At same time, the program could fool the video
chip to use more colors than originally intended and decode new pictures
to the memory. And, the picture copying can be possibly done with
interrupts (yeah, 16 khz interrupts on 64... wow) so that the program
flow wont slow down much. The sound could be played out using the sid
sample register or a recistor net connected to user port or own made
hardware in somewhere (it can also be driven by the interrupt handler)
Let's face the reality:
when a video cd is played it means somewhat 150-200 kilobytes per second
transfer speed. Then it must decompress the mpeg stream and grunch it
somewhat that the huge amount of colors get to fewer colors.
A general Philips Video CD needs a speedy 486-66 or faster to play
correctly. But x86 chips are somewhat crap. So I think it _is_ possible
to use the 20 mhz 65816 upgrade to decode a vcd.
--
*Pekka "Pihti" Takala *pekka....@pp.inet.fi
*asm sw developer *home: +358-6-8311341
*cellular: +358-40-5670465
Todd Elliott
> On a c64/128 there is one possibility: SuperCPU that runs at 20 mhz. I
> think it might be able to do the decoding, especially if it has 16 megs
> of ram memory. First it would decode its memory full of images. Because
> of the c64/128's heart still runs at 1 mhz and this makes slowdowns if
> the supercpu is programmed wrong, the pages would be copied to the
> videoram using buffer technology. So, when the vicII draws the first
> picture, the second is copied to another page and page is flipped.
> Again, the vic draws the following pic, the next pic is copied to the
> unvisible memory area. At same time, the program could fool the video
> chip to use more colors than originally intended and decode new pictures
>
I did this kind of thing for the SuperCPU. I created a program called
'Silicon Dreams' and was originally distributed via Loadstar. It could
create and display video streams. Audio wasn't added.
Basically, I used a utility called 'Fast Movie Processor' which cut up the
AVI or MPEG into individual BMP's. Then I used ConGo to convert these
individual BMP's into 4bit files. Silicon Dreams then pieced together
these individual 4bit files into a compressed videostream. This compressed
videostream is further compressed using pkzip2.04g.
Silicon Dreams then can playback this compressed file. First, it
decompresses the pkzip2.04g datastream into SuperRAM. Next, during
real-time, it decompresses an individual FLI frame onto the screen. This
is with the VIC-II chip into the FLI resolution. I was able to achieve an
average frame rate of roughly 6-8 frames a second.
Enjoy.
--
Todd Elliott
MagerValp
PT> Let's face the reality:
Yes, let's...
PT> when a video cd is played it means somewhat 150-200 kilobytes per
PT> second transfer speed.
Which no other device than a RamLink can achieve on the C64 (with a
SuperCPU).
PT> Then it must decompress the mpeg stream and grunch it somewhat
PT> that the huge amount of colors get to fewer colors.
If you want process 30 frames per second of 352x240 pixels on a 20 MHz
CPU you get: (20000000/30)/(352*240) =~ 8 cycles per pixel. That's not
even enough time to LDA/STA the bytes from SuperRAM to graphics
memory.
PT> A general Philips Video CD needs a speedy 486-66 or faster to play
PT> correctly. But x86 chips are somewhat crap.
Not compared to a 6502 derivate, no.
PT> So I think it _is_ possible to use the 20 mhz 65816 upgrade to
PT> decode a vcd.
Not in real time. Not even close.
--
___ . . . . . + . . o
_|___|_ + . + . + . . Per Olofsson, konstnär
o-o . . . o + Mage...@cling.gu.se
- + + . http://www.cling.gu.se/~cl3polof/
Pekka "Pihti" Takala
>
> Pekka "Pihti" Takala wrote:
>
> PT> Let's face the reality:
>
> Yes, let's...
>
> PT> when a video cd is played it means somewhat 150-200 kilobytes per
> PT> second transfer speed.
>
> Which no other device than a RamLink can achieve on the C64 (with a
> SuperCPU).
>
> PT> Then it must decompress the mpeg stream and grunch it somewhat
> PT> that the huge amount of colors get to fewer colors.
>
> If you want process 30 frames per second of 352x240 pixels on a 20 MHz
> CPU you get: (20000000/30)/(352*240) =~ 8 cycles per pixel. That's not
> even enough time to LDA/STA the bytes from SuperRAM to graphics
> memory.
The pixels in c64 are not 8 bit wide. And the frame rate needs not to be
30 frames, a degrade to 25 or 12.5 (on a PAL machine) still could be
sufficient. If you make 30 frames per second on a 50 hz screen, the
picture suffers from slight sync problems. A PAL video cd has 25 frames
speed.
>
> PT> A general Philips Video CD needs a speedy 486-66 or faster to play
> PT> correctly. But x86 chips are somewhat crap.
>
> Not compared to a 6502 derivate, no.
How a 6502 derivate is crap?
>
> PT> So I think it _is_ possible to use the 20 mhz 65816 upgrade to
> PT> decode a vcd.
>
> Not in real time. Not even close.
I think it _is_ possible if the data transfer methods are fast enough.
But you are correct in one thing: it takes much processing power.
>
> --
> ___ . . . . . + . . o
> _|___|_ + . + . + . . Per Olofsson, konstnär
> o-o . . . o + Mage...@cling.gu.se
> - + + . http://www.cling.gu.se/~cl3polof/
--
MagerValp
PT> The pixels in c64 are not 8 bit wide.
As 8 bits is the smallest unit that the processor can work on it'd be
ideal if it had 8 bits per pixel. In this case, writing pixels in
bitmap mode actually requires MORE instructions than if we'd have had
a straight 256-colour mode. Besides, as you decode the stream you will
get 24-bit pixels that you'll have to map onto the C64's 16-colour
palette.
PT> And the frame rate needs not to be 30 frames, a degrade to 25 or
PT> 12.5 (on a PAL machine) still could be sufficient.
You can get away with displaying fewer frames per second, but you
still need to decode all the frames in memory. MPEG frames can refer-
ence both backwards and forwards so you need to keep the last two I
frames and everything in between in memory.
PT> If you make 30 frames per second on a 50 hz screen, the picture
PT> suffers from slight sync problems. A PAL video cd has 25 frames
PT> speed.
Yes, but it has 288 lines instead of 240 so you have the same amount
of pixels and the same data rate:
352 x 288 x 25 fps = 2534400 pixels/second
352 x 240 x 30 fps = 2534400 pixels/second
With 20000000 cycles per second that leaves you with just under 8
cycles per pixel, and that's not even enough for LDA + STA. And don't
forget SuperRAM DRAM latency and the fact that you can't write to the
C64's internal memory more than once every 20 cycles.
MV> Not compared to a 6502 derivate, no.
PT> How a 6502 derivate is crap?
Same way an x86 derivate is crap: non-orthogonal instruction set, not
enough registers and a memory model that is based on 64K pages.
PT> So I think it _is_ possible to use the 20 mhz 65816 upgrade to
PT> decode a vcd.
MV> Not in real time. Not even close.
PT> I think it _is_ possible if the data transfer methods are fast
PT> enough.
The fastest storage we have on the C64 is the CMD RamLink. With a
SuperCPU the fastest transfer rates anyone's been able to achieve is
about 150-200 kB/s. This is a straight copy from RamLink memory using
a SuperCPU with 100% CPU utilization. Oh, and a RamLink can't use more
than 16 MB of RAM for a total of 1.5 minutes MPEG 1 video.
PT> But you are correct in one thing: it takes much processing power.
Yes -- too much. Do the math, there's no way in hell you can decode
VCD streams at full speed on a SuperCPU.
Andreas Magenheimer
Mirko Sobe (Boss-XL, XE, X) "converted" a windows video file for his own
desktop. He also wrote a driver for those videos, that can display all
*.VID files. Unfortunately, I do not know, how the converted video file
must be looking like, nor which Graphics resolution it has to use... His
video shows a surfer in Gr. 8 (it is a very very small Gr. 8 screen;
3cmx4cm on my 55cm tv, I did not count the pixels; first the single pics
get loaded, then all the graphics get animated; but still the video is
one file, not dozens of separate picture files!). maybe you can ask
Mirko Sobe (www.atarixle.de or so )how he did it and how you can do it
yourself (using his driver from Boss-XL or XE). Maybe we can then start
converting plus watching windows videos on the little atari... -andreas.
P.S.: I would prefer Gr. 9 over Gr. 8 (and Hip over Gr. 9 and RIP over
Hip; not to speak of 256 colors in a high resolution!)...
P.P.S.: Anyone got a DOS based AVI driver for my PC ??? A friend of mine
is just doing an Atari AVI CD-ROM (a CD filled with AVI Atari videos;),
but me, I do not have an AVI driver for my DOS/Win 3.11 based 486 PC...
(nor for my Atari).
Mathy Van Nisselroy schrieb:
Andreas Magenheimer
the standard Atari is a little faster than the C64 (1.8Mhz compared to
1Mhz) and it can also use the 65816 device (I thought this thing would
run with 16Mhz, maybe it runs with 20Mhz too). Next, upgrading to 16MB
with or without the 65816 would be no problem. Ask Mathy and he will
tell you, that the little Atari - provided with a second PIA chip (and
maybe other Hardware) can be upgraded to full 256 Megabytes of Ram !!
(Megabytes, not megabits!). Never thought that so much RAM would be
usefull for such a small machine, but talking of displaying realtime
Videos, it might be handy... And who says, that a 65816 (i.e. somewhat
16-bit) upgrade is the maximum you can do for a 6502/atari. it is also
possible to do/create a 65832 (or however you may call it; a somewhat
6502 compatible 32-bit) upgrade. A german ABBUC guy once created the
65816 for himself and he told the other ABBUC members, that it would not
be a big hardware problem to do a faster and better 32-bit upgrade. But
at that time (early 90`s) this was a little to expensive, maybe nowadays
it is cheaper... -Andreas
P.S.: Still thinking that realtime videos on an A8 are a little too
complicated (a very expensive and time-wasting effort)...
MagerValp schrieb:
Mirko Sobe
changed font. While playing the video from the ramdisk and main memory, I've
putted the video-datas into the actually displayed font. But unfortunaly
theese video-files are too big for the small ATARI-XLE.
Before I was converting the video, I've loaded the original (color) into
COREL PHOTO PAINT, converted it to 64 x 48, 1 bit per pixel and saved it
uncompressed. On the ATARI, I wrote a little program, that converts that
file into an .ATV file. The ATV-File is compressed. The compression mode is
not very complicated, so I was thinking, the ATARI would be fast enough to
decompress the video in realtime, but it didn't. So it must be first loaded
and decompressed into the memory (...like andreas said: first the single
pics get loaded...). Then the video can be watched. The framerates could be
up to 25fps. Possible formats are 32x12, 64x48, and 96x72.
Mirko
"Andreas Magenheimer" <mage...@mail.uni-mainz.de> schrieb im Newsbeitrag
news:3B436030...@mail.uni-mainz.de...
Mathy Van Nisselroy
>My Windsurfer had a resolution of 64 x 48 pixels using graphics 0 with a
>changed font.
> The framerates could be
>up to 25fps. Possible formats are 32x12, 64x48, and 96x72.
I've been on the site and have BOSS-X at home. But I really tried it out. SO
I haven't seen a windsurfer yet.
Maybe Roland Scholz' PC-Bridge can help (plus a PC video card). And we'll have
to get the BlackBox to share the parallel bus.
CU Mathy van Nisselroy
Mirko Sobe
sold with BOSS-XE, but I have written a viewer (like all the other viewers
in BOSS-X/XE *.DRV). Andreas has this demo. If you want, I will upload this
video-trail onto my homepage
Mirko
"Mathy Van Nisselroy" <niss...@reze-1.rz.rwth-aachen.de> schrieb im
Newsbeitrag news:9i1a61$cl8$3...@nets3.rz.RWTH-Aachen.DE...