Apple II Music Video - Welcome to the Jungle!!
Frank M.
Continuing my previous experiments with rasterizing video on an //e,
I've finished rendering all 6,462 frames for the music video to Guns N
Roses "Welcome to the Jungle". Each frame is a single lo-res GR screen
dump. Obviously this only will work on a machine with a CompactFlash
drive or in an emulator.
Download the GNR Disk Image here (32 Meg ProDOS 2MG image).....
http://clients.kraftworksltd.com/download/GNR-FINAL.zip
to run, boot from the drive and then enter
"-exec.me.first"
"-play.gnr"
Here's how i got the files rendered.....
1. Export 1 JPG per frame from normal MPG movie (AppleScripted
Quicktime)
2. Convert JPGs to indexed-color 40x48pixel TIFFs (custom Photoshop
actions/palettes)
3. Drop TIFFs onto a disk image (tips hat to Andy McFadden for
CiderPress)
4. Frames are rendered using a BASIC program from the TIFF file.
5. GR screen dumps saved to single binary files.
It helps to squint and/or stand back like 10 feet when watching the
video. Also, if you're in an emulator, try speeding the processor up to
get a sense of what is possible if i only cleaned up my code. ;)
The frame displaying program is in BASIC, so if anyone has any ideas
how to speed things up that would be great. I'm gonna assume that
having less than 1500 entries per subdirectory would be a good place to
start, as well as cleaning up my bad code or maybe programming in ML
instead of BASIC. any ideas are welcomed!
PS--here's a link to an earlier video i made. Only 34 frames, but
memory-resident and runs from a 140k floppy.....
William Garber
"Frank M." <frank_...@hotmail.com> wrote in message news:1163786375.4...@h48g2000cwc.googlegroups.com...
:
: Continuing my previous experiments with rasterizing video on an //e,
: I've finished rendering all 6,462 frames for the music video to Guns N
: Roses "Welcome to the Jungle". Each frame is a single lo-res GR screen
: dump. Obviously this only will work on a machine with a CompactFlash
: drive or in an emulator.
:
:
: Download the GNR Disk Image here (32 Meg ProDOS 2MG image).....
:
: http://clients.kraftworksltd.com/download/GNR-FINAL.zip
:
: to run, boot from the drive and then enter
: "-exec.me.first"
: "-play.gnr"
All I get on Kegs is horizontal lines of
alternating black and red. Could it be that
it is the ActiveGS version? I can run most
anything else on it.
William Garber
Email Address - will...@garberstreet.com
Alt. Email - will...@comcast.net
Web address - http://www.garberstreet.com
Frank M.
William Garber wrote:
> All I get on Kegs is horizontal lines of
> alternating black and red. Could it be that
> it is the ActiveGS version? I can run most
> anything else on it.
>
I haven't tried it yet on actual hardware, but it works in Virtual ][
on the mac. there shouldn't be any code that borks anything. it's all
simple BASIC and the frame renders are simple binary BSAVEd from the
lores screen.
maybe try loading just one frame....
GR:POKE -16299,0: REM turn on lores page 2
BLOAD /HD/GNR.PART3/FRAME.3001,A$800
maybe it's a ProDOS issue under KEGS...... not sure.
-f-
Frank M.
Did you exec "EXEC.ME.FIRST" before running "PLAY.GNR"?
it'll hang otherwise because when it loads the first frame it
overwrites the BASIC program. EXEC.ME.FIRST just moves the start of
basic programs above lores page 2.
-f-
Frank M.
I just messed around with KEGS. The problem is with KEGS itself not
supporting GR Page 2. I couldn't get anything to come up at all on page
2, even when POKEing directly into page 2 memory while it was 'turned
on.' Maybe try it on another emulator?
-f-
William Garber
"Frank M." <frank_...@hotmail.com> wrote in message news:1163790870....@m7g2000cwm.googlegroups.com...
:
: I just messed around with KEGS. The problem is
I'll try writing the image, or files, to a CF card
and insert it into a real Apple II and see if it'll
run there.
Thanks.
William Garber
"William Garber" <will...@garberstreet.com> wrote in message news:XYydnYhg96yIjcPY...@comcast.com...
:
: "Frank M." <frank_...@hotmail.com> wrote in message news:1163790870....@m7g2000cwm.googlegroups.com...
: :
: : I just messed around with KEGS. The problem is
: : with KEGS itself not supporting GR Page 2. I
: : couldn't get anything to come up at all on page
: : 2, even when POKEing directly into page 2 memory
: : while it was 'turned on.' Maybe try it on another
: : emulator?
:
: I'll try writing the image, or files, to a CF card
: and insert it into a real Apple II and see if it'll
: run there.
Same result on both a real IIe and IIgs.
I'm following instruction exactly. On
both machines it did try to access the
5.25" disk drive. Not sure why it did
that.
I will try the White Wedding one and see
if I can get it to work.
William Garber
"William Garber" <will...@garberstreet.com> wrote in message news:Ob-dnZ6KGP9iicPY...@comcast.com...
:
: "William Garber" <will...@garberstreet.com> wrote in message news:XYydnYhg96yIjcPY...@comcast.com...
: :
: : "Frank M." <frank_...@hotmail.com> wrote in message news:1163790870....@m7g2000cwm.googlegroups.com...
: : :
: : : I just messed around with KEGS. The problem is
: : : with KEGS itself not supporting GR Page 2. I
: : : couldn't get anything to come up at all on page
: : : 2, even when POKEing directly into page 2 memory
: : : while it was 'turned on.' Maybe try it on another
: : : emulator?
: :
: : I'll try writing the image, or files, to a CF card
: : and insert it into a real Apple II and see if it'll
: : run there.
:
:
: Same result on both a real IIe and IIgs.
: I'm following instruction exactly. On
: both machines it did try to access the
: 5.25" disk drive. Not sure why it did
: that.
:
: I will try the White Wedding one and see
: if I can get it to work.
White Wedding runs fine. Not sure what's up
with the other one.
Frank M.
ugh! maybe it's really not ready for pre-release yet. if the 5.25 comes
on it's probably because it can't find the path that the program is
specifying. maybe try and load a single-frame? the BASIC program has
pretty specific needs in terms of where the frames are located in
ProDOS. Here's a listing of the frame player program if you want to
tinker some. lines 150-210 are probably where the problem is.....
10 REM **********************
20 REM * *
30 REM * Move Movie Frames *
40 REM * by Frank Milliron *
50 REM * *
60 REM **********************
70 REM
80 HOME:GR
90 POKE - 16299,0: REM PAGE 2
100 POKE - 16302,0: REM FULL SCREEN
110 FOR N = 1 TO 6826
120 IF N < 10 THEN N$ = "000" + STR$ (N): GOTO 150
130 IF N > = 10 AND N < 100 THEN N$ = "00" + STR$ (N): GOTO 150
140 IF N > = 100 AND N < 1000 THEN N$ = "0" + STR$ (N): GOTO 150
145 n$=str$(n)
150 if n < 1501 then ?chr$(4)+"PREFIX /HD/GNR.PART1":goto 210
160 if n > 1500 and n < 3001 then ?chr$(4)+"PREFIX /HD/GNR.PART2":goto
210
170 if n > 3000 and n < 4501 then ?chr$(4)+"PREFIX /HD/GNR.PART3":goto
210
180 if n > 4500 and n < 6001 then ?chr$(4)+"PREFIX /HD/GNR.PART4":goto
210
190 if n > 6000 then ?chr$(4)+"PREFIX /HD/GNR.PART5"
210 print chr$(4)+"BLOAD FRAME."+n$+",A$800"
220 NEXT N
230 TEXT:HOME:END
TomCh
It works under AppleWin (but I had to convert the .2mg to unadorned .po
using CiderPress).
Best results running at full-tilt & with the glasses off 8-)
How about using double-GR instead?
Tom
William Garber
"Frank M." <frank_...@hotmail.com> wrote in message news:1163802547....@m7g2000cwm.googlegroups.com...
:
: ugh! maybe it's really not ready for pre-release yet. if the 5.25 comes
I see the problem already. My ProDOS partition isn't
called HD, it's GR2. Ok, I should have looked at that
first.
Thanks.
Frank M.
TomCh wrote:
> Cool!
>
> It works under AppleWin (but I had to convert the .2mg to unadorned .po
> using CiderPress).
> Best results running at full-tilt & with the glasses off 8-)
>
> How about using double-GR instead?
>
> Tom
I thought about double-GR, but kinda liked the lo-fi-ness of GR. plus i
wasn't sure how much hassle converting 6,000 frames would be and wanted
to keep it simple the first time. the next video i do will be
double-gr. i only really have to change a few numbers to run it that
way. but i still don't really have a good playback method. optimally it
would run about 15 frames per second on actual 1.0mhz hardware. that's
the capability the CFFA card has (maybe 30k second) according to the
website.
glasses off. joint lit. haha. awesome!
-f-
William Garber
"William Garber" <will...@garberstreet.com> wrote in message news:caSdnWIE5PDjpsPY...@comcast.com...
:
: "Frank M." <frank_...@hotmail.com> wrote in message news:1163802547....@m7g2000cwm.googlegroups.com...
Yes, that fixed it. Wow, the simplest things
seem to elude us, eh?
winston...@yahoo.com
Is there any other way to get these GR images?
You make me want to dust off my //-e, or at least download a new
emulator (pretty sure my 10 year old emulator is out-of-date).
Anybody got a screen-shot? Or something?
Do you think this would run on a Coleco Adam from tape? (bwg)
Can't help but think of porting this to other systems with a low-res
mode similar to GR either...
Lyrical Nanoha
> Is there any other way to get these GR images?
> You make me want to dust off my //-e, or at least download a new
> emulator (pretty sure my 10 year old emulator is out-of-date).
> Anybody got a screen-shot? Or something?
> Do you think this would run on a Coleco Adam from tape? (bwg)
>
> Can't help but think of porting this to other systems with a low-res
> mode similar to GR either...
Hm, like an IBM 5150 with a CGA? >:P
-uso.
(I could prolly pull that off.)
-----------------------------------------------------------
There are four boxes to use in the defense of liberty:
Soap, Ballot, Jury, Ammo.
Use in that order, starting now.
-- Attr. to Ed Howdershelt
Linards Ticmanis
>> Can't help but think of porting this to other systems with a low-res
>> mode similar to GR either...
>
> Hm, like an IBM 5150 with a CGA? >:P
For some systems one could easily abuse the fact that they store colors
at a lower resolution than actual pixels.
For example the C64 and (probably) the Spectrum.
Good luck loading anything like motion video from a 1541 floppy or a ZX
Microdrive though... ;-)
--
Linards Ticmanis
Lyrical Nanoha
The CGA's 40x25 text mode could be used - if blink is disabled - to do an
almost-perfect emulation of GR mode.
Juggles' Butterfly did this. (I'd STILL kill to find this program, either
Apple or IBM version.)
-uso.
BLuRry
> Continuing my previous experiments with rasterizing video on an //e,
> I've finished rendering all 6,462 frames for the music video to Guns N
> Roses "Welcome to the Jungle". Each frame is a single lo-res GR screen
> dump. Obviously this only will work on a machine with a CompactFlash
> drive or in an emulator.
Very cool -- and something I never would have expected out of a //e.
But here's some suggestions that can speed it up.
1) Don't use + in the print statements, use the ; operator
2) Don't convert the loop variable to a string or use an if statement
to zero-pad it. Just split that part off to a couple of extra loops
3) Break each directory into a separate loop and change the prefix
in-between the loops. You're causing a lot of extra conditional logic
to be processed. If you never noticed, applesoft basic is slow. ;-)
If you follow these three recommendations, you'll see it run really
fast for the first few frames and then slow down after about 50 or so
frames. Ultimately, you'll need to break up the directory structure a
lot more -- or figure out some other way to reduce the number of
entries in the directory (is it slower to read from a non-zero location
starting point of a file? if so, how much slower?) Another
possibility is to pre-cache frames into a ram card and use the mem copy
to move over pages as needed during the VBL. Using this you could load
chunks of frames at a go (probably a lot faster) and avoid having to
hit the filesystem as much.
Apart from that, because you're using a very palette-reduced rendition
of a live motion video it gets very grainy because it's downright
impossible to find good approximate color matches. If you convert
something that uses a simpler color palette and line art like a cartoon
it will be easier to make things out. If you wanted a real statement
of irony, I'd recommend "futurama" -- especially the episode where they
reveal Bender's brain is a 6502. ;-) But that's just my personal
taste.
Frank M.
Here's the code for rendering the lores photoshop TIFFs onto the A2 GR
screen.....
(you can use CiderPress to drop them directly into a disk image)
The nice part is that you can use a modern computer and photoshop to
automate most of the de-resolutionating and palette bashing of the
original image.
Axl!!!! what happened to you!!!
10 REM **********************
20 REM * *
30 REM *RENDER MOVIE FRAMES *
40 REM * by Frank Milliron *
50 REM * *
60 REM **********************
70 REM Set Frames to Convert
80 for n=1 to 6826
90 REM Add Leading Zeros
100 IF N < 10 THEN N$ = "000" + STR$ (N): GOTO 150
110 IF N > = 10 AND N < 100 THEN N$ = "00" + STR$ (N): GOTO 150
120 IF N > = 100 AND N < 1000 THEN N$ = "0" + STR$ (N): GOTO 150
130 n$=str$(n)
140 REM Load TIFF File
150 print chr$(4)+"PREFIX /GNR1/RAWFRAMES"
160 print chr$(4)+"BLOAD FRAME."+n$+".TIF,T$00,a$2000"
170 REM Find Signature Bytes
180 S=24000:home:vtab 10: ?"Now searching TIFF file #";N$:?"
for frame data..."
190 V=PEEK(S)
200 IF V=67 THEN s=s+1:v=peek(s):GOTO 220
210 S=S+1:GOTO 190
220 IF V=0 THEN s=s+1:v=peek(s):GOTO 240
230 S=S+1:GOTO 190
240 IF V=83 THEN s=s+1:v=peek(s):GOTO 260
250 S=S+1:GOTO 190
260 IF V=0 THEN s=s+1:v=peek(s):GOTO 280
270 S=S+1:GOTO 190
280 IF V=0 THEN s=s+1:v=peek(s):GOTO 300
290 S=S+1:GOTO 190
300 IF V=0 THEN s=s+1:v=peek(s):GOTO 320
310 S=S+1:GOTO 190
320 IF V=1 THEN s=s+1:v=peek(s):GOTO 340
330 S=S+1:GOTO 190
340 IF V=0 THEN s=s+1:GOTO 360
350 S=S+1:GOTO 190
360 REM RENDER FRAME AKA 6502 MELTDOWN
370 GR : POKE 49234,0
380 FOR Y = 0 TO 47
390 FOR X = 0 TO 39
400 V = PEEK (S)
410 COLOR= V
420 PLOT X,Y
430 S = S + 1
440 NEXT X
450 NEXT Y
460 REM SAVE FRAME
470 PRINT chr$(4)+"PREFIX /GNR1/RENDERED"
480 PRINT CHR$ (4)+"BSAVE FRAME."+N$+",A$400,L$400"
490 REM ON AND ON TILL THE BREAK OF DAWN
500 text:next n
Frank M.
Here's my next course of actions.....
breaking files into smaller subdirectories
fix conditionals and prefix info
drop leading zeros from frame filenames to lose all the IF statements
if you want to get really crazy you could.....
have the program pre-load track/sector info for each frame so frame
loads don't require a trip to the directory (then you could keep every
frame in a single directory). and also code everything in ML. yeah,
like that's gonna happen. it would be interesting to know what
theoretical speed it could run at give a stock 1.0mhz proc and a
standard CFFA/CF setup.
I think the colors work because there's so much dithering of single
frames, in addition to the flickering between frames, that it tends to
smooth out in your eye. strangely, squinting harder makes the video
seem more clear. it's like your brain fills in the missing parts. and
fast frame rates really help.
I always identified with bender. kinda kludgey and cantankerous yet
hardworking sort of. you can always get it to do what you want, but
it's a matter of how much effort it is.
-f-
Michael J. Mahon
How about just opening the files without specifying a prefix,
which will default to the right thing if the program is run from
the directory containing the files.
-michael
NadaNet networking for Apple II computers!
Home page: http://members.aol.com/MJMahon/
"The wastebasket is our most important design
tool--and it's seriously underused."
Michael J. Mahon
Now that I read this more carefully, I see that you are *changing*
the prefixes every 1500 frames...
Since each frame is 2KB, and a ProDOS file can be up to 16MB long,
8000 frames would fit in a single file (in the same directory as
the program).
Instead of computing a new name for each file, use one file and
compute the byte offset to do the BSAVE or BLOAD of $800 bytes.
After each "page" is written or read, bump the byte offset by
2048.
This will greatly simplify the program, and should also speed
up the file opens, since the directory entry will be buffered
by ProDOS.
In fact, a very simple machine language program could do this
with very little file system overhead by simply reading successive
2048-byte chunks of the file into the graphics buffer.
You could also turn off "mixed" mode and use both graphics pages,
so that one page is displayed while the other is being loaded,
for much smoother animation.
Michael J. Mahon
> Frank M. wrote:
>
>>Continuing my previous experiments with rasterizing video on an //e,
>>I've finished rendering all 6,462 frames for the music video to Guns N
>>Roses "Welcome to the Jungle". Each frame is a single lo-res GR screen
>>dump. Obviously this only will work on a machine with a CompactFlash
>>drive or in an emulator.
>
>
> Very cool -- and something I never would have expected out of a //e.
> But here's some suggestions that can speed it up.
>
> 1) Don't use + in the print statements, use the ; operator
Better, don't use *any* operator--concatenation is assumed if
you juxtapose quoted strings and variables.
> 2) Don't convert the loop variable to a string or use an if statement
> to zero-pad it. Just split that part off to a couple of extra loops
> 3) Break each directory into a separate loop and change the prefix
> in-between the loops. You're causing a lot of extra conditional logic
> to be processed. If you never noticed, applesoft basic is slow. ;-)
But the overhead is the only time that a whole loaded frame is actually
displayed, as opposed to being read in.
Double buffering and using byte offsets into a *single* file will
drastically reduce the overhead, smooth the animation, and reduce
the program to a 3-line loop.
> If you follow these three recommendations, you'll see it run really
> fast for the first few frames and then slow down after about 50 or so
> frames. Ultimately, you'll need to break up the directory structure a
> lot more -- or figure out some other way to reduce the number of
> entries in the directory (is it slower to read from a non-zero location
> starting point of a file? if so, how much slower?) Another
> possibility is to pre-cache frames into a ram card and use the mem copy
> to move over pages as needed during the VBL. Using this you could load
> chunks of frames at a go (probably a lot faster) and avoid having to
> hit the filesystem as much.
Byte offsets into a single file solve all these problems quite easily.
How about something like this:
80 d$=chr$(4)
90 bx=3072 : REM $400 + $800
100 gs=49235 : REM Graphics softswitch base address
110 fs=1024 : REM frame size
120 mv$="moviename" : REM (Or use dialog to select movie.)
130 fr=numframes : REM (Or first two bytes could be number of frames.)
140 GR : REM Set Graphics page 1 and clear
150 poke gs,0 : REM Select nomix
160 by=0 : REM Initial byte offset
170 bf=2048 : gp=2 : REM $800 for first frame
180:
200 for i = 1 to fr : REM Loop over all frames
210 print d$"BLOAD "mv$",b"by",l$400,a"bf
220 poke gs+gp : REM Select loaded page
230 by=by+fs : REM Advance to next page offset
240 bf=bx-bf : REM Toggle GR pages ($800/$400)
250 gp=2-gp : REM Toggle GR page numbers (2/1)
260 next
Of course, the FOR loop could easily be a short M/L program on
page 3, which would simply do a ProDOS MLI "read" of successive
1024-byte (not 2048-byte as I suggested earlier) frames. This
would bypass all the file open overhead of BLOAD for higher
frame rates.
> Apart from that, because you're using a very palette-reduced rendition
> of a live motion video it gets very grainy because it's downright
> impossible to find good approximate color matches. If you convert
> something that uses a simpler color palette and line art like a cartoon
> it will be easier to make things out. If you wanted a real statement
> of irony, I'd recommend "futurama" -- especially the episode where they
> reveal Bender's brain is a 6502. ;-) But that's just my personal
> taste.
With a sufficient frame rate, it should be possible to "dither" colors
in the time domain from frame to frame...
Michael J. Mahon
There is much to be said for testing a program before posting it! ;-)
My modified player above has a couple of problems--two trivial and
one a bit of a puzzler.
The two easy ones are that "nomix" is selected by "150 POKE gs-1,0", and
line 220 should POKE a "0" instead of nothing. ;-)
The troublesome one, which Frank already knows about, is that ProDOS
is reluctant to trample on the primary text page, so double buffering
awaits a fix for that problem...
In any case, the following program works well to play single-file
movies:
10 REM **********************
20 REM * *
30 REM * Move Movie Frames *
40 REM * by Frank Milliron *
50 REM * (modified by MJM) *
60 REM **********************
70 REM
80 D$ = CHR$ (4)
90 BX = 3072: REM $400 + $800
100 GS = 49235: REM Graphics softswitch base address
110 FS = 1024: REM frame size
120 MV$ = "movie": REM (Or use dialog to select movie.)
130 FR = 6826: REM (Or first two bytes could be number of frames.)
140 GR : REM Set Graphics page 1 and clear
150 POKE GS - 1,0: REM Select nomix
160 BY = 0: REM Initial byte offset
170 BF = 2048:GP = 2: REM $800 for first frame
180 :
200 FOR I = 1 TO FR: REM Loop over all frames
210 PRINT D$"BLOAD "MV$",b"BY",l$400,a"BF
220 POKE GS + GP,0: REM Select loaded page
230 BY = BY + FS: REM Advance to next page offset
260 NEXT
270 TEXT : HOME : END
And the multi-file movies may be made into single files by adding
the lines:
210 PRINT CHR$ (4) + "BLOAD FRAME." + N$ + ",A$1000"
212 PRINT CHR$ (4)"bsave /hd/movie,b"BY",a$1000,l$400"
213 BY = BY + 1024
215 VTAB 23: PRINT N" "
to Frank's player program. This program simply creates the
file "movie" in the root directory. The current frame number
is printed out as a progress indicator.
Polymorph
Using Michael's modifications and running in AppleWin with the
emulation speed set to 2Mhz, the animation looks almost "normal time" -
ie. not running too slow or too fast.
Without Michael's mod, I had to run it at maximum-full-tilt-speed to
get something watchable.
This is a pretty kewl little project, and I'm keen to see what else you
can manage to convert. It would probably look pretty good on an
animation (ie. cartoon) where there aren't as many colours to dither...
great stuff!
cheers,
-p
John B. Matthews
"Frank M." <frank_...@hotmail.com> wrote:
> [...]
> 1. Export 1 JPG per frame from normal MPG movie (AppleScripted
> Quicktime)
> 2. Convert JPGs to indexed-color 40x48pixel TIFFs (custom Photoshop
> actions/palettes)
> 3. Drop TIFFs onto a disk image (tips hat to Andy McFadden for
> CiderPress)
> 4. Frames are rendered using a BASIC program from the TIFF file.
> 5. GR screen dumps saved to single binary files.
> Frank
> frank_...@hotmail.com
On the source side, you might want to look at QuickASCII:
http://quickascii.sourceforge.net/
It uses QuickTime to open the media file; it then registers a call-back
that converts each frame to ASCII after QuickTime renders it. You could
replace the ASCII lookup table with a suitable lores table. It's only
353 lines of code plus a command parser. It could effectively combine
steps 1-3. For example:
$ ./quickascii -w 60 -t 28 /Library/User\Pictures/Animals/Butterfly.tif
o77+i: ==ti0xx.
7%668$$%%x+ ;0#$$@%t00s
oxss@#$66 %$@@7: !6@$$#.;@@8%0tt7
=66@6+@@$&i$$$@$00- :x$$#@#==s@$;;t%x--
66&t$%%i;i&&x;t%%$0 i%#tt+00==+=&$$ost
+80$$s67ooi66oo=o8%%+ ,&%%t=i777==iio6@xxs;
t&%%sssxx6tiiio60xx7&%$$866xx7i=;;it7xx0&@88t
x$$7=i77x0&ss00&%%@$@$$#%sttot7xxxx7;;+7$00
-@@@%@$$$$$$$$$$%%&@$$$&s8##@$###@@@@@%8x::
xx$7+++++i==+-=tt;0$@@t+;----;;;++=;;&@6
%%%o;==i==ii7t-==o,stt:+!--i;+--+;;iii%s
@@7!+ii66toot!+tt- i.. :=::!toooit;---t@..
==$6-++;-t77:;+--, ;,, !==+:xoo!;+--0$7
o$$66-=+::=:o:: 0 .++:;!+++!t##$7
t@@$$877t0, ,,6o&88$$@ss
!!ox&66x+ -ts88&0-
--
John Matthews
jmatthews at wright dot edu
www dot wright dot edu/~john.matthews/
Michael J. Mahon
> Here's the code for rendering the lores photoshop TIFFs onto the A2 GR
> screen.....
Frank, it's pretty awesome to watch the results of your rendering
on an Apple II!
I notice lots of sequences where there are regions containing
very little detail. For example, outlines of figures are
often visible, but any detail in the figure is missing (which
would be expected if the figure is only a silhouette in the
original).
Have you considered using dynamic thresholds between colors that
track "median" colors of regions, so that details would tend to be
rendered instead of "falling into the same color bucket"?
If a little noise were introduced into these thresholds, it would
also add time-domain color dither, which would have the effect of
increasing the palette.
I realize that I'm talking about an adaptive algorithm that may
have to be "custom" instead of a pre-built image filter, but maybe
this has already been done to handle the "posterization" operation...
I think that a little increase in color distortion would be a small
price to pay for increased visible picture detail.
David Wilson
> The troublesome one, which Frank already knows about, is that ProDOS
> is reluctant to trample on the primary text page, so double buffering
> awaits a fix for that problem...
With good reason - the screen holes can be very important to your disk
controller's operation...
If you want to try it, clear bits 0-3 in $BF58.
Frank M.
Thanks! i think it looks pretty cool, too! thanks for the code,
michael. i was so focused on getting a proof-of-concept that my code
was a bit sloppy. and i actually didn't know you could use offsets like
that in ProDOS (i was always more of a dos3.3 guy since that's how the
bootleg of Hard Hat Mack showed up and also because hard drives were
something we never used). it will be even better when/if we can get it
running at 25 frames per second. that's when the dithering effects will
really stand out, i think. i could write a quick program to load larger
chunks of frame data into high memory and then just rapidly swap banks
of memory into the GR screen. you could probably do hundreds of frames
a second that way. problem is that you can only fit so many frames into
RAM before you have to do another disk access. maybe it could be fast
enough to fit into the delay between swapping frames.
i'm rendering a couple more movies today, so there'll be other things
to work with. i realize the dithering method i'm using isn't perfect.
i'm not as much a programmer as i am an imaging nerd (photoshop is my
'day job'). since i'm currently using photoshop to do the downsampling,
i'm sort of constrained by what i can automate. but i can see how it is
possible to write an application that you run a quicktime movie through
and it produces these 13,707 block files formatted and ready to go. and
on top of that, 40x48 pixels isn't really a whole lot of information to
work with, so it only follows that you'll lose some information.
you realize the next step is running a sample using DAC522 during the
delay between frames, right? ;) even though there was never much of
a demo-scene for the A2, it's never too late to start.....
=f=
Frank M.
John B. Matthews wrote:
> On the source side, you might want to look at QuickASCII:
>
> http://quickascii.sourceforge.net/
>
I'll have to look into that.
This just makes me think an ASCII movie is the logical next step......
-f-
Michael J. Mahon
Right. And they seem not to cause much trouble for Oasis (!).
Here is the double-buffered (page-flipping) version of the player:
10 REM **********************
20 REM * *
30 REM * Move Movie Frames *
40 REM * by Frank Milliron *
50 REM * (modified by MJM) *
60 REM **********************
70 :
80 D$ = CHR$ (4)
85 IF PEEK (104) < > 32 THEN POKE 104,32: POKE 32 * 256,0: PRINT
D$"-play.movie"
90 BX = 3072: REM $400 + $800
100 GS = 49235: REM Graphics softswitch base address
110 FS = 1024: REM frame size
120 MV$ = "movie": REM (Or use dialog to select movie.)
130 FR = 6826: REM (Or first two bytes could be number of frames.)
140 GR : REM Set Graphics page 1 and clear
150 POKE GS - 1,0: REM Select nomix
160 BY = 0: REM Initial byte offset
170 BF = 2048:GP = 2: REM $800 for first frame
180 POKE 48984,192: REM De-protect Primary text page
190 :
200 FOR I = 1 TO FR: REM Loop over all frames
210 PRINT D$"BLOAD "MV$",b"BY",l$400,a"BF
220 POKE GS + GP,0: REM Select loaded page
230 BY = BY + FS: REM Advance to next page offset
240 BF = BX - BF: REM Toggle GR pages ($800/$400)
250 GP = 3 - GP: REM Toggle GR page numbers (2/1)
260 NEXT
270 POKE 48984,207: REM Re-protect Primary text page
280 TEXT : HOME : END
Note that it automatically relocates itself to $2000 if it is not
run at that address, so there's no need for "EXEC.ME.FIRST".
If run in Oasis at 4.7MHz, it syncs almost exactly with the
music--or with the original music video at:
http://www.youtube.com/watch?v=_zuIQkjm78o
It's kind of interesting to watch the two running simultaneously
in two windows. ;-)
Michael J. Mahon
> Thanks! i think it looks pretty cool, too! thanks for the code,
> michael. i was so focused on getting a proof-of-concept that my code
> was a bit sloppy. and i actually didn't know you could use offsets like
> that in ProDOS (i was always more of a dos3.3 guy since that's how the
> bootleg of Hard Hat Mack showed up and also because hard drives were
> something we never used). it will be even better when/if we can get it
> running at 25 frames per second. that's when the dithering effects will
> really stand out, i think. i could write a quick program to load larger
> chunks of frame data into high memory and then just rapidly swap banks
> of memory into the GR screen. you could probably do hundreds of frames
> a second that way. problem is that you can only fit so many frames into
> RAM before you have to do another disk access. maybe it could be fast
> enough to fit into the delay between swapping frames.
Yes, ultimately you can't sustain a frame rate faster than the
bandwidth of the hard disk.
Using Applesoft (BASIC.SYSTEM) to read the frames requires that the
file be opened and closed on each access, which is substantial overhead.
A short M/L loop (essentially the FOR loop in my program) could do
the job without the open/close overhead, delivering faster frame
rates on a 1MHz Apple II.
> i'm rendering a couple more movies today, so there'll be other things
> to work with. i realize the dithering method i'm using isn't perfect.
> i'm not as much a programmer as i am an imaging nerd (photoshop is my
> 'day job'). since i'm currently using photoshop to do the downsampling,
> i'm sort of constrained by what i can automate. but i can see how it is
> possible to write an application that you run a quicktime movie through
> and it produces these 13,707 block files formatted and ready to go. and
> on top of that, 40x48 pixels isn't really a whole lot of information to
> work with, so it only follows that you'll lose some information.
Actually, upon several re-viewings, I see that there is already a fair
amount of time-domain dither, like in the noise in the background.
Like you, I find that backing up about a meter from my monitor and
taking off my glasses (I'm nearsighted ;-) does wonders by allowing
my brain's pattern recognition to work without the distraction of
sharp-edged pixel detail. ;-)
> you realize the next step is running a sample using DAC522 during the
> delay between frames, right? ;) even though there was never much of
> a demo-scene for the A2, it's never too late to start.....
That would be great, but it would require another Apple II, since
DAC522 also uses 100% of the machine. ;-) Then there's that nasty
problem of not having 3MB RAM for the whole song, and not being
able to stop even for an instant to do I/O...
Now, maybe a IIgs could do it, since the DOC plays sound independent
of the processor--and 2.8MHz wouldn't hurt the frame rate, either. ;-)
--
Frank M.
Michael J. Mahon wrote:
> That would be great, but it would require another Apple II, since
> DAC522 also uses 100% of the machine. ;-) Then there's that nasty
> problem of not having 3MB RAM for the whole song, and not being
> able to stop even for an instant to do I/O...
>
Hellloooooo...! NadaNet!! haha. now that would be something. one IIe
for video and another for sound (running as master). you wouldn't even
need to spend that much time telling the slave video machine to advance
a frame. you could simply do a state-change poll on a single wire
connected between the joystick ports. you could even pre-load frames on
the video machine so you could swap a frame instantly. maybe that's
crazy talk.
BTW, how do you convert a sound file down to work with DAC522? is there
some kind of conversion program? and what is the overhead in terms of
bandwidth? i'd love to digitize some audio, too.
-f-
Linards Ticmanis
> That would be great, but it would require another Apple II, since
> DAC522 also uses 100% of the machine. ;-) Then there's that nasty
> problem of not having 3MB RAM for the whole song, and not being
> able to stop even for an instant to do I/O...
Wouldn't DAC522 be an ideal candidate for working with a slinky-style
RAM expansion? I mean, what could be a more linear type of memory access
than fetching sound samples?
--
Linards Ticmanis
Michael J. Mahon
> Michael J. Mahon wrote:
>
>
>>That would be great, but it would require another Apple II, since
>>DAC522 also uses 100% of the machine. ;-) Then there's that nasty
>>problem of not having 3MB RAM for the whole song, and not being
>>able to stop even for an instant to do I/O...
>>
>
>
> Hellloooooo...! NadaNet!! haha. now that would be something. one IIe
> for video and another for sound (running as master). you wouldn't even
> need to spend that much time telling the slave video machine to advance
> a frame. you could simply do a state-change poll on a single wire
> connected between the joystick ports. you could even pre-load frames on
> the video machine so you could swap a frame instantly. maybe that's
> crazy talk.
No, that is exactly the way to do it--and it should work great!
> BTW, how do you convert a sound file down to work with DAC522? is there
> some kind of conversion program? and what is the overhead in terms of
> bandwidth? i'd love to digitize some audio, too.
DAC522 plays files that are 8-bit "unsigned" samples, at a 11kHz rate.
This is the usual format for 8-bit sound samples. Bandwidth should be
limited to about 5kHz (Nyquist, after all), but that allows pretty good
rendition (somewhere between telephone and AM radio).
Of course, DAC522 only uses the most significant 5 bits of each sample,
so there is some quantization noise, but it's usually quite tolerable
for loud sounds.
Michael J. Mahon
Yes, it would. I never pursued it because I figured only a small
minority of Apple users would have one...
Frank M.
That looks super-cool. I just installed xcode last night, so i'll have
to play with their code over thanksgiving vacay. i guess all i would
have to do is pipe their output to a file. it would be great to
automate the frame rendering. this time through was really just a
proof-of-concept, so i didn't really mind bit-beating a little. the
second system is always the best.
i put up a 32 meg disk image of like 4 or 5 movies as a demo if you
want to check out the current status.....
http://clients.kraftworksltd.com/download/APPLE2VIDEO.2mg.zip
Fun stuff.....
-f-