Megalextoria
Retro computing and gaming, sci-fi books, tv and movies and other geeky stuff.

Home » Digital Archaeology » Computer Arcana » Apple » Apple II » PLAY.HGR - movie playback in HGR graphics mode
Show: Today's Messages :: Show Polls :: Message Navigator
E-mail to friend 
Switch to threaded view of this topic Create a new topic Submit Reply
PLAY.HGR - movie playback in HGR graphics mode [message #367879] Thu, 17 May 2018 00:27 Go to next message
Anonymous
Karma:
Originally posted by: frank_o_rama

Hey All,

Finally had some time to work on some dumb projects. Today's exercise is exporting video frames via ffmpeg, converting them to HGR graphics mode using Bmp2DHR, concatenating everything, and then siccing my PLAY.HGR code on the resulting data. Thanks to Bill Buckels and Peter Ferrie for supplying their respective pieces (Bmp2DHR and ProRWTS version 2, respectively). You can check it out here...

http://frankjames.net/downloads/CHERRY.PIE.HGR.2mg.zip

The audio playback code needs a rework so you'll have to just enjoy silent movies for now.

Works on ][+ and up with mass storage (preferably a CFFA3000 for the best speed). If using on actual hardware the image needs to be mapped to the actual slot your mass storage card resides in (first or second SmartPort positions on a CFFA3000). I've also taken the liberty to "correct" my code for the buggy emulators Virtual II and Sweet16 so it will run correctly there (AppleWin required no corrections).

Frank
Re: PLAY.HGR - movie playback in HGR graphics mode [message #367881 is a reply to message #367879] Thu, 17 May 2018 02:26 Go to previous messageGo to next message
Anonymous
Karma:
Originally posted by: Lifepillar

On 17/05/2018 06:27, frank_o_rama@hotmail.com wrote:
>
> Hey All,
>
> Finally had some time to work on some dumb projects. Today's exercise is exporting video frames via ffmpeg, converting them to HGR graphics mode using Bmp2DHR, concatenating everything, and then siccing my PLAY.HGR code on the resulting data. Thanks to Bill Buckels and Peter Ferrie for supplying their respective pieces (Bmp2DHR and ProRWTS version 2, respectively). You can check it out here...
>
> http://frankjames.net/downloads/CHERRY.PIE.HGR.2mg.zip
>
> The audio playback code needs a rework so you'll have to just enjoy silent movies for now.
>
> Works on ][+ and up with mass storage (preferably a CFFA3000 for the best speed). If using on actual hardware the image needs to be mapped to the actual slot your mass storage card resides in (first or second SmartPort positions on a CFFA3000). I've also taken the liberty to "correct" my code for the buggy emulators Virtual II and Sweet16 so it will run correctly there (AppleWin required no corrections).

Wow, cool! Looks really smooth in Virtual ][!
What frame rate can you achieve?

I am wondering how much fun it would be to turn these into
laserdisc-style games. Like, make a movie out of Space Ace or Dragon's
Lair, then add the (simple) control logic to make it playable.

Nicola
Re: PLAY.HGR - movie playback in HGR graphics mode [message #367896 is a reply to message #367881] Thu, 17 May 2018 10:15 Go to previous messageGo to next message
Anonymous
Karma:
Originally posted by: frank_o_rama

The code does a test to see if it's running under Virtual ][ or Sweet16, then uses the vertical blank interval to slow down disk loads under emulation.. Otherwise, both those emulators just blaze through the frames. The Vblank interval is 1/60th of a second, and it waits 2 periods per frame, which gives a rate of 30 frames per second. On an actual //e w/CFFA3000 it seems to run maybe 15-20 frames a second or so (it ignores Vblank there).

It's also alternating loads to page 1 and page 2 of hires, loading to the page which isn't visible at the time.

A Dragon's Lair-style game had crossed my mind. I had a rip of the original laserdisk for that one but can't seem to find it now.

I have audio playback code in there as well, but it needs to be refined a bit. I'm working on another project to convert audio from Audacity to a 1-bit stream so I can move on from recording through the cassette input.

This can also be adapted for double-hires, at half the frame rate. I did the bulk of work for coding that when I did the double-lores versions a couple months back. The hires version is capped at 2048 frames (8192 bytes per frame x 2048 frames = 16mb prodos max per file), so double-hires would only be 1024 frames per file. At roughly 20 frames per second that's only 50 seconds of video, though, and only 2 videos per 32mb partition. Maybe another rainy day...


Also: forgot to mention, space bar pauses playback, left and right arrows do rewind and fast forward, escape exits.

f



On Wednesday, May 16, 2018 at 11:26:55 PM UTC-7, Lifepillar wrote:
>
> Wow, cool! Looks really smooth in Virtual ][!
> What frame rate can you achieve?
>
> I am wondering how much fun it would be to turn these into
> laserdisc-style games. Like, make a movie out of Space Ace or Dragon's
> Lair, then add the (simple) control logic to make it playable.
>
> Nicola
Re: PLAY.HGR - movie playback in HGR graphics mode [message #367903 is a reply to message #367896] Thu, 17 May 2018 10:52 Go to previous messageGo to next message
Anonymous
Karma:
Originally posted by: Nicola

On 17/05/2018 16:15, frank_o_rama@hotmail.com wrote:

> A Dragon's Lair-style game had crossed my mind. I had a rip of the original laserdisk for that one but can't seem to find it now.

Maybe this can help: http://www.dragons-lair-project.com/games/

N.
Re: PLAY.HGR - movie playback in HGR graphics mode [message #367967 is a reply to message #367879] Sat, 19 May 2018 02:17 Go to previous messageGo to next message
Anonymous
Karma:
Originally posted by: frank_o_rama

Calculating 10 frames per second in HGR mode on actual hardware with a CFFA3000. Double-lores mode runs at 40 frames per second there.

Using ProRWTSv2 vs. the ProDOS MLI shows a 218% speed increase. Using a CFFA3000 vs. the old firmware CFFA nets a 317% increase (both using ProRWTSv2).

I have a Floppy Emu but haven't tested it yet. Guessing it would be similar to the older CFFA's numbers.

f
Re: PLAY.HGR - movie playback in HGR graphics mode [message #367969 is a reply to message #367967] Sat, 19 May 2018 05:33 Go to previous messageGo to next message
STYNX is currently offline  STYNX
Messages: 453
Registered: October 2012
Karma: 0
Senior Member
On Saturday, 19 May 2018 08:17:12 UTC+2, frank_...@hotmail.com wrote:
> Calculating 10 frames per second in HGR mode on actual hardware with a CFFA3000. Double-lores mode runs at 40 frames per second there.
>
> Using ProRWTSv2 vs. the ProDOS MLI shows a 218% speed increase. Using a CFFA3000 vs. the old firmware CFFA nets a 317% increase (both using ProRWTSv2).

These are really impressive results! Im amazed... I have to test this with my SCSI card to see, if it would have been possible with 'original' hardware. To date, I only used my Apple IIe in a custom case with the CFFA3000 and even though the video seems to be in slow motion, I have not seen any stutter and the frame rate looks very good (>10 frames/s).

Congratulations!

If you optimize the saved images to only update the changed lines/pixels, you would most likely get more frame rate. I suspect that you would have to pre-process the video to be of variable frame rate to allow this method to be used. -> 8088 Domination

A good demo would be the "Bad Apple" intro since it has been done on nearly every retro computer available. -> c64 demo with 16mb REU: https://www.youtube.com/watch?v=h1g3A-70SrI

-Jonas
Re: PLAY.HGR - movie playback in HGR graphics mode [message #367970 is a reply to message #367967] Sat, 19 May 2018 05:55 Go to previous messageGo to next message
STYNX is currently offline  STYNX
Messages: 453
Registered: October 2012
Karma: 0
Senior Member
On Saturday, 19 May 2018 08:17:12 UTC+2, frank_...@hotmail.com wrote:
> Calculating 10 frames per second in HGR mode on actual hardware with a CFFA3000. Double-lores mode runs at 40 frames per second there.

Does the demo run an Apple II+ or even the original Apple II?
Prodos 2.4.2 runs on all Apple ii. Do you use any specific A2e features in your program?

-Jonas
Re: PLAY.HGR - movie playback in HGR graphics mode [message #367973 is a reply to message #367969] Sat, 19 May 2018 06:22 Go to previous messageGo to next message
Steve Nickolas is currently offline  Steve Nickolas
Messages: 2036
Registered: October 2012
Karma: 0
Senior Member
On Sat, 19 May 2018, STYNX wrote:

> On Saturday, 19 May 2018 08:17:12 UTC+2, frank_...@hotmail.com wrote:
>> Calculating 10 frames per second in HGR mode on actual hardware with a
>> CFFA3000. Double-lores mode runs at 40 frames per second there.
>>
>> Using ProRWTSv2 vs. the ProDOS MLI shows a 218% speed increase. Using a
>> CFFA3000 vs. the old firmware CFFA nets a 317% increase (both using
>> ProRWTSv2).
>
> These are really impressive results! Im amazed... I have to test this
> with my SCSI card to see, if it would have been possible with 'original'
> hardware. To date, I only used my Apple IIe in a custom case with the
> CFFA3000 and even though the video seems to be in slow motion, I have
> not seen any stutter and the frame rate looks very good (>10 frames/s).
>
> Congratulations!
>
> If you optimize the saved images to only update the changed
> lines/pixels, you would most likely get more frame rate. I suspect that
> you would have to pre-process the video to be of variable frame rate to
> allow this method to be used. -> 8088 Domination
>
> A good demo would be the "Bad Apple" intro since it has been done on
> nearly every retro computer available. -> c64 demo with 16mb REU:
> https://www.youtube.com/watch?v=h1g3A-70SrI
>
> -Jonas
>

Heh, I think I proposed doing that here a while back...and it's from 8088
Domination I first heard of Bad Apple.

Bad Apple being simple monochrome makes it a good fit for the 280x192
mode.

-uso.
Re: PLAY.HGR - movie playback in HGR graphics mode [message #367983 is a reply to message #367879] Sat, 19 May 2018 12:18 Go to previous messageGo to next message
Anonymous
Karma:
Originally posted by: frank_o_rama

Thanks guys.

It runs fine on a stock ][+ with language card, but not an a ][ because my stub loader requires BASIC.SYSTEM ("PRODOS BASIC REQUIRES AN APPLE ][+" my emulator says). It's on my list to rewrite the launcher into a SYSTEM file but I wanted to focus on audio playback first (which obviously is better suited for double-lores mode since hires is so much slower, but would then require an enhanced //e).

One problem with only updating the changed pixels is that the dithering modes add so many dots that you'd be effectively updating the entire frame. This white background hair metal video is highly compressible, as well, but you have to unpack it which would cut into the frame rate. I'd have to dig into LZ4 or aPLib further to see if it's possible to avoid double-buffering.

It always comes back to bad apple/8088 domination :) Just want to note I did my first video conversions in lores mode back in 2006 or so when bad apple was still in grade school and electroclash was on your iPod mini (with a playback engine by Mike Mahon). Yeah, it was only showing half the frames but whatever! (I kid). Have to say using ffmpeg and BMP2DHR is tons easier than my original process of AppleScript video export/Photoshop actions/BASIC renderer. I can post details of how to export and convert the frames if anyone is interested in trying it out.

f
Re: PLAY.HGR - movie playback in HGR graphics mode [message #368002 is a reply to message #367983] Sat, 19 May 2018 17:36 Go to previous messageGo to next message
STYNX is currently offline  STYNX
Messages: 453
Registered: October 2012
Karma: 0
Senior Member
On Saturday, 19 May 2018 18:18:29 UTC+2, frank_...@hotmail.com wrote:
> Thanks guys.
>
> It runs fine on a stock ][+ with language card, but not an a ][ because my stub loader requires BASIC.SYSTEM ("PRODOS BASIC REQUIRES AN APPLE ][+" my emulator says). It's on my list to rewrite the launcher into a SYSTEM file but I wanted to focus on audio playback first (which obviously is better suited for double-lores mode since hires is so much slower, but would then require an enhanced //e).
>
> One problem with only updating the changed pixels is that the dithering modes add so many dots that you'd be effectively updating the entire frame. This white background hair metal video is highly compressible, as well, but you have to unpack it which would cut into the frame rate. I'd have to dig into LZ4 or aPLib further to see if it's possible to avoid double-buffering.
>
> It always comes back to bad apple/8088 domination :) Just want to note I did my first video conversions in lores mode back in 2006 or so when bad apple was still in grade school and electroclash was on your iPod mini (with a playback engine by Mike Mahon). Yeah, it was only showing half the frames but whatever! (I kid). Have to say using ffmpeg and BMP2DHR is tons easier than my original process of AppleScript video export/Photoshop actions/BASIC renderer. I can post details of how to export and convert the frames if anyone is interested in trying it out.
>
> f

I have read that LZ4 can archive a higher output data rate than native copying since it is optimized for extraction speed.
--
Personally I like 2x2 ordered dither more than error diffusion. The ordered dither generates more stable images. If you implement a 'bad apple' demo, you only use BW and that would be highly compressible...
--
If you want to add music via the internal speaker, I would be amazed if you could implement it synchronous with the images. But as the A2 has slots, it might be better to try using S.A.M. or Mockingboard first?
--
I think your achievements are very good so far and im hoping to see more in there future :-)

-Jonas
Re: PLAY.HGR - movie playback in HGR graphics mode [message #368031 is a reply to message #367983] Sun, 20 May 2018 13:43 Go to previous messageGo to next message
Anonymous
Karma:
Originally posted by: fadden

On Saturday, May 19, 2018 at 9:18:29 AM UTC-7, frank_...@hotmail.com wrote:
> One problem with only updating the changed pixels is that the dithering modes add so many dots that you'd be effectively updating the entire frame. This white background hair metal video is highly compressible, as well, but you have to unpack it which would cut into the frame rate. I'd have to dig into LZ4 or aPLib further to see if it's possible to avoid double-buffering.

I contemplated using LZ4 for full-frame compression a couple years ago:

https://groups.google.com/d/msg/comp.sys.apple2/SDgtVW3h4is/ l073d_yhDgAJ

You'll max out around 5fps. It's tough to beat HS SCSI DMA for bulk data movement.
Re: PLAY.HGR - movie playback in HGR graphics mode [message #368034 is a reply to message #368031] Sun, 20 May 2018 14:44 Go to previous messageGo to next message
Anonymous
Karma:
Originally posted by: frank_o_rama

My current player runs at 10 frames a second using a CFFA3000 so I guess compression is out. Unfortunate, as LZ4 was reducing a typical file by more than half.

My double-lores player does 40 frames per second, so I think there's plenty of time to play some audio there. I've been working on a version of that player which plays 1/10th a second of audio after every page flip but the audio converter isn't finished yet. ffmpeg can export audio streams as well as video frames so I should be able to sync playback.

Made a couple of updates to the HGR player; clearing page 2 and showing it while the first load to page 1 happens, waiting for the vertical blank period before switching video modes to reduce glitches, and changing the emulated playback speed to match real hardware. Have a couple better video conversions too which I'll upload shortly.

f
Re: PLAY.HGR - movie playback in HGR graphics mode [message #368038 is a reply to message #368002] Sun, 20 May 2018 21:24 Go to previous messageGo to next message
Michael AppleWin Debu is currently offline  Michael AppleWin Debu
Messages: 1262
Registered: March 2013
Karma: 0
Senior Member
On Saturday, May 19, 2018 at 2:36:47 PM UTC-7, STYNX wrote:
> I have read that LZ4 can archive a higher output data rate than native copying since it is optimized for extraction speed.

That's correct -- but only true for modern CPUs when multi-threading is used. i.e. On 6502 you aren't going to beat a native asm memcpy(). :-)

e.g.

LDY #nBytes2Copy
Copy
LDA src,Y
STA dst, Y
DEY
BNE Copy

How is LZ4 even faster then a native memory copy? When decompressing you copy previous matches to the end of the output -- an "overlapping src+dest memcpy()" so to speak. Since the (source) data is already in the data cache (due to it being written recentl) you can get a big win. This alone isn't enough. You need to use all cores efficiently. (I'm not sure if any implementations of memcpy() are multi-threaded -- but again I haven't looked.)

I could of swore either Charles Bloom or mentioned the LZ4 vs memcpy() speed but I can't find the (original) link(s).

You'll notice the official github page only lists single-threaded performance.

* https://github.com/lz4/lz4

For anyone interested in more details:

* Matt Mahoney has pretty comprehensive benchmark results
http://mattmahoney.net/dc/text.html

* https://github.com/inikep/lzbench

The last isn't LZ4 but gives technical details on how to beat memcpy():

* Blosc: Sending Data from Memory to CPU (and back) Faster than Memcpy by Francesc Alted

https://www.slideshare.net/PyData/blosc-sending-data-from-me mory-to-cpu-and-back-faster-than-memcpy-by-francesc-alted

Cheers
Michael
Re: PLAY.HGR - movie playback in HGR graphics mode [message #368071 is a reply to message #367879] Mon, 21 May 2018 20:24 Go to previous messageGo to next message
Anonymous
Karma:
Originally posted by: frank_o_rama

Did some more testing and have some bandwidth comparisons of a few different mass storage options as a side benefit. I divided the total number of frames by the playback time in seconds to get frames per second.

Considering each frame is 8192 bytes:


CFFA3000 - 10 frames per second (81,920 bytes per second)

CFFA (v1.2) - 6.3 fps (51,609 bytes per second)

Floppy Emu - 2.3 fps (18,842 bytes per second)


Under the Floppy Emu it looks like it might actually increase the frame rate to employ LZ4 compression.

f
Re: PLAY.HGR - movie playback in HGR graphics mode [message #368080 is a reply to message #368071] Tue, 22 May 2018 07:09 Go to previous messageGo to next message
Antoine Vignau is currently offline  Antoine Vignau
Messages: 1860
Registered: October 2012
Karma: 0
Senior Member
See our BenchmarkeD tool at http://www.brutaldeluxe.fr/products/apple2gs/benchmarked.htm l and follow a link to a Google spreadsheet, you'll see what are the best options for the best bandwidth,
av
Re: PLAY.HGR - movie playback in HGR graphics mode [message #368090 is a reply to message #368071] Tue, 22 May 2018 18:46 Go to previous messageGo to next message
Michael AppleWin Debu is currently offline  Michael AppleWin Debu
Messages: 1262
Registered: March 2013
Karma: 0
Senior Member
> Considering each frame is 8192 bytes:

Is there a reason you are storing the wasted 512 bytes (32 pages * 16 bytes of holes/page) of HGR screen holes?

I.e. An HGR screen only needs 8192 - 512 = 7680 bytes uncompressed data read per frame.

Is this so you don’t need to move the data later? (Size vs Speed tradeoff.)

Michael
Re: PLAY.HGR - movie playback in HGR graphics mode [message #368092 is a reply to message #368090] Tue, 22 May 2018 22:22 Go to previous messageGo to next message
qkumba is currently offline  qkumba
Messages: 1584
Registered: March 2013
Karma: 0
Senior Member
Frames are read directly into screen memory, as opposed to read-and-copy.
Re: PLAY.HGR - movie playback in HGR graphics mode [message #368093 is a reply to message #368090] Tue, 22 May 2018 23:43 Go to previous messageGo to next message
Anonymous
Karma:
Originally posted by: frank_o_rama

Yes. Frames are read directly into screen memory. The speed penalty to skip copying the screen holes would drop the average frame rate below what it currently is. The player is optimized for speed because of the inherent bandwidth limitations of the hardware.

Also, using full, sequential, multiples of 512 bytes allows the use of prodos block copy, which is what ProRWTSv2 is ultimately using (bypassing prodos' file handling and allowing an average 58% speed increase by more efficiently managing the tree index--correct me if I have the wrong terminology here qkumba).

f
Re: PLAY.HGR - movie playback in HGR graphics mode [message #368094 is a reply to message #368080] Tue, 22 May 2018 23:49 Go to previous messageGo to next message
Anonymous
Karma:
Originally posted by: frank_o_rama

Is it an apples-to-apples comparison with an accelerated //gs? (no pun intended). Obviously the CFFA3000 with a Sandisk stick is the gold standard.

My data also shows how much slower the SmartPort-based Floppy Emu is. Though it's never seemed objectionable to me for games or applications. Just a note for anyone who's interested in one (and obviously this demo doesn't work great using one). Its cross-compatibility with old macs makes it a bit compelling however, and it's also less expensive.

F


On Tuesday, May 22, 2018 at 4:09:18 AM UTC-7, Antoine Vignau wrote:
> See our BenchmarkeD tool at http://www.brutaldeluxe.fr/products/apple2gs/benchmarked.htm l and follow a link to a Google spreadsheet, you'll see what are the best options for the best bandwidth,
> av
Re: PLAY.HGR - movie playback in HGR graphics mode [message #368095 is a reply to message #368093] Tue, 22 May 2018 23:52 Go to previous messageGo to next message
Anonymous
Karma:
Originally posted by: frank_o_rama

On Tuesday, May 22, 2018 at 8:43:33 PM UTC-7, frank_...@hotmail.com wrote:
average 58% speed increase


Some of you may know this as a 158% speed increase :)

f
Re: PLAY.HGR - movie playback in HGR graphics mode [message #368096 is a reply to message #368095] Tue, 22 May 2018 23:59 Go to previous messageGo to next message
Anonymous
Karma:
Originally posted by: frank_o_rama

ugh. I had the wrong column. ProRWTSv2 is actually 2.18x times faster than the prodos MLI for this application (10 vs. 4.5 frames).

I accidentally used the speed increase over the old CFFA card vs new (1.58 -- both using ProRWTSv2).

f



On Tuesday, May 22, 2018 at 8:52:05 PM UTC-7, frank_...@hotmail.com wrote:
> On Tuesday, May 22, 2018 at 8:43:33 PM UTC-7, frank_...@hotmail.com wrote:
> average 58% speed increase
>
>
> Some of you may know this as a 158% speed increase :)
>
> f
Re: PLAY.HGR - movie playback in HGR graphics mode [message #368107 is a reply to message #368092] Wed, 23 May 2018 10:54 Go to previous messageGo to next message
Michael AppleWin Debu is currently offline  Michael AppleWin Debu
Messages: 1262
Registered: March 2013
Karma: 0
Senior Member
On Tuesday, May 22, 2018 at 8:22:55 PM UTC-6, qkumba wrote:
> Frames are read directly into screen memory, as opposed to read-and-copy.

Gotcha.
Re: PLAY.HGR - movie playback in HGR graphics mode [message #368108 is a reply to message #368096] Wed, 23 May 2018 11:05 Go to previous messageGo to next message
Anonymous
Karma:
Originally posted by: fadden

On Tuesday, May 22, 2018 at 8:59:17 PM UTC-7, frank_...@hotmail.com wrote:
> ugh. I had the wrong column. ProRWTSv2 is actually 2.18x times faster than the prodos MLI for this application (10 vs. 4.5 frames).

Compression work made me give up on percentages (20% compression means it's 20% smaller or 20% of original size?), and graphics work made me give up on frames per second (going from 60fps to 59fps is a 1fps improvement, and going from 4fps to 3fps is also a 1fps improvement, but they're much different.)

Milliseconds per frame and multipliers seem less confusing.
Re: PLAY.HGR - movie playback in HGR graphics mode [message #368367 is a reply to message #367879] Thu, 31 May 2018 15:54 Go to previous messageGo to next message
Anonymous
Karma:
Originally posted by: frank_o_rama

Here are an additional 7 video conversions. These images incorporate my updates to the player itself, as well as adding qkumba's latest version of ProRWTSv2 which allows the use of device-driven smartport drives (for example, CFFA3000 in slot 7 with disk image mapped to slot 4).

http://frankjames.net/downloads/HGR_Renders-5_31_2018.zip

f
Re: PLAY.HGR - movie playback in HGR graphics mode [message #368369 is a reply to message #368367] Thu, 31 May 2018 16:15 Go to previous messageGo to next message
Anonymous
Karma:
Originally posted by: frank_o_rama

Left Arrow = rewind
Right Arrow = fast forward
Space Bar = pause
Escape = quit

Control-Reset restarts playback

f


On Thursday, May 31, 2018 at 12:54:59 PM UTC-7, frank_...@hotmail.com wrote:
> Here are an additional 7 video conversions. These images incorporate my updates to the player itself, as well as adding qkumba's latest version of ProRWTSv2 which allows the use of device-driven smartport drives (for example, CFFA3000 in slot 7 with disk image mapped to slot 4).
>
> http://frankjames.net/downloads/HGR_Renders-5_31_2018.zip
>
> f
Re: PLAY.HGR - movie playback in HGR graphics mode [message #371847 is a reply to message #367879] Wed, 08 August 2018 02:34 Go to previous messageGo to next message
ol.sc is currently offline  ol.sc
Messages: 211
Registered: January 2013
Karma: 0
Senior Member
Hi Frank,

> Finally had some time to work on some dumb projects. Today's exercise is ex=
> porting video frames via ffmpeg, converting them to HGR graphics mode using=
> Bmp2DHR, concatenating everything, and then siccing my PLAY.HGR code on th=
> e resulting data.

Would you mind sharing the source code?

> The audio playback code needs a rework so you'll have to just enjoy silent =
> movies for now.

I'd be interested to learn how you approach audio playback in the
context of a movie player. Things like frequency, interleaving, ...

Thanks in advance,
Oliver
Re: PLAY.HGR - movie playback in HGR graphics mode [message #371862 is a reply to message #371847] Wed, 08 August 2018 08:56 Go to previous messageGo to next message
Anonymous
Karma:
Originally posted by: frank_o_rama

;
; PLAY.HGR.S
; Play hires (HGR) Video File
; hacked together by Frank Milliron
; with help, advise, and code from
; Peter Ferrie, Rob Giddings, & Michael Mahon
; May 19, 2018
; (Code can be pasted into Merlin Pro 2.33)
;
ORG $C00 ; CALL 3072
************************************************************ ****
* Initialize Everything *
************************************************************ ****
SETUP JSR $FC58 ; Clear screen/HOME - Removes BASIC.SYSTEM bracket
JSR EMUTEST ; Run emulator test for Virtual ][ / Sweet16
JSR TESTGS ; If we're on a GS, fix a couple things
JSR $1100 ; Initialize ProRWTS2 (relocates itself to $1000)
LDA #$00
STA $57 ; $0300 namlo - name of file to access
STA $52 ; $2000 sizelo - size of the data to load (always $00)
STA $55 ; $2000/4000 ldrlo - address to load the data (always $00)
STA $51 ; auxreq - set load to MAIN
LDA #$03
STA $58 ; $0300 namhi - name of file to access
LDA #$20
STA $53 ; $2000 sizehi - size of the initial data to load
STA $56 ; $2000/4000 ldrhi - address to load the data (start $2000)
LDA #$01
STA $54 ; Set reqcmd to #cmdread (1)
CLRPG2 LDA #$40 ; set HGR to clear page 2 ($4000-7FFF)
STA $E6 ; HGR.PAGE zero-page variable
JSR $F3F2 ; Clear page 2 before we show it (part of HGR2)
JSR VBL ; Wait until vertical blank period to mess with video modes
STA $C055 ; Turn on page 2 (first load is to page 1)
STA $C05F ; Turn off Double-Lores/Hires Mode in case it's on
JSR GRFX ; Setup graphics/memory modes
SETRESET LDA #<DORESET ; Change reset vector to DORESET
STA $03F2 ; low byte
LDA #>DORESET-1
STA $03F3 ; high byte
JSR $FB6F ; Set valid power-up byte based on reset vector
JSR $1003 ; hddopendir (also sets up cache structures)
************************************************************ ****
* Main Playback Routine *
************************************************************ ****
PLAY LDA #$00 ; set load to MAIN
STA $51 ; auxreq
LDA #$20
STA $53 ; $2000 sizehi - size of the data to load
JSR $1000 ; hddrdwrpart - initial load to $2000 main then $4000 main
BCS EXIT1 ; Quit at end of file
SOFTSW EQU *+1 ; This instruction patched if we find an emulator
BIT $C054 ; Start showing Page 1 (self-modifying!)
LDA SOFTSW
EOR #1 ; Alternate displaying $2000/$4000
STA SOFTSW
LDA $56 ; ldrhi - address to load the data
EOR #$60 ; Alternate loading to $2000/$4000
STA $56 ; ldrhi
CHKKEY LDA $C000 ; Check for keypress(JSR AUDIO;play audio snippet)
BPL PLAY ; none!
JMP KEY ; handle keypresses
EXIT1 JMP EXIT ; BCS can only jump +127 or -128 bytes
************************************************************ ****
* Keypress Handler *
************************************************************ ****
KEY BIT $C010 ; Clear keyboard strobe
*
REW CMP #$88 ; Left arrow key pressed? ($08+80)
BNE FASTF ; No, check next key
REW1 LDX $F6 ; treeidx
BEQ PLAY ; if treeidx is already 0 don't rewind
DEX
BEQ REW2 ; if it's 1, decrement 1
DEX ; Otherwise decrement 2
REW2 STX $F6
JMP DORESET1 ; Restart playback using reset routine
*
FASTF CMP #$95 ; Right arrow key pressed? ($15+80)
BNE PAUSE ; No, check next key
FASTF1 INC $F6 ; Increment treeidx
JMP DORESET1 ; Restart playback using reset routine
*
PAUSE CMP #$A0 ; Space Bar pressed? ($20+80)
BNE ESC ; No, check next key
* Pause screen display setup here?
PAUSELP LDA $C000 ; Check for keypress
BPL PAUSELP ;nothing yet
* Second pause screen keypress handler here
CMP #$9B ; Escape key pressed? ($1B+80)
BEQ EXIT2 ; Goodbye
CMP #$A0 ; Space Bar pressed again? ($20+80)?
BEQ PAUSELP1 ; Yes, start playing again
BIT $C010 ; Any other key, clear strobe
JMP PAUSELP ; And just keep waiting
PAUSELP1 BIT $C010 ; Clear keyboard strobe
JMP PLAY ; Start playing again
*
ESC CMP #$9B ; Escape key pressed? ($1B+80)
BEQ EXIT2
JMP PLAY ; No, do next frame
EXIT2 JMP EXIT ; BCS can only jump +127 or -128 bytes
************************************************************ ****
* Set Graphics Modes *
************************************************************ ****
GRFX STA $C010 ; Clear keyboard strobe
STA $C000 ; Let $C054/C055 change page 1/2 instead of AUX mem
STA $C050 ; Turn on Graphics Mode
STA $C052 ; Turn on Full Screen Mode
STA $C057 ; Turn on Hires Graphics Mode
RTS
VBL LDA $BF98 ; ProDOS MACHID byte
AND #%01000000
CMP #%01000000 ; Do we have a ][+ doesn't have VBL signal
LDA $BF98 ; ProDOS MACHID byte
AND #%10001000
CMP #%10001000 ; Do we have a //c?
BEQ NOVBL ; //c does VBL signal as interrupt
VBLON BIT $C019 ; Wait for full vertical blank (every 1/60th sec)
BPL VBLON ; if already off, loop, as we want a full VBL cycle
VBLOFF BIT $C019 ; VBLANK happening?
BMI VBLOFF ; if on, loop until it's off
NOVBL RTS
************************************************************ ****
* Control-Reset Handler *
************************************************************ ****
; Also used to restart playback on REW/FF
DORESET JSR TESTGS ; Re-test for //gs border color and speed
JSR GRFX ; On reset, re-setup graphics modes
LDA $F6 ; treeidx
BEQ DORESET1 ; Already at the beginning, don't adjust
DEC $F6 ; treeidx - play last section again
DORESET1 LDA #$00 ; set load to MAIN
STA $51 ; auxreq
STA $F8 ; Clear entries
LDA #$20
STA $53 ; $2000 sizehi - size of the data to load
JSR $1000 ; hddrdwrpart (to main)
BCS EXIT3 ; Quit at end of file
JMP PLAY ; Resume playing
EXIT3 JMP EXIT ; BCS can only jump +127 or -128 bytes
************************************************************ ****
* Emulator-specific Routines *
************************************************************ ****
; Fixes for Virtual ][ and Sweet16 playback problems
EMUTEST LDX #$FF ; Test floating bus 255 times
LDA #$00
STA $FF ; Zero out count of positive tests
EMU1 STA $C04F ; Tickle Sweet16
LDA $C04F ; Load value from bus
CMP #$00 ; Virtual ][? (always returns $00)
BEQ EMU3
CMP #$16 ; Sweet16? (returns $16 when tickled, $30 otherwise)
BEQ EMU3
EMU2 DEX ; Decrement test count
CPX #$00
BEQ EMU4 ; Done with 255 tests yet?
JMP EMU1 ; If not, keep going
EMU3 INC $FF ; Found potential emulator, increment count
JMP EMU2
EMU4 LDA $FF ; Load counts
CMP #$FF ; 255 tests of 255 runs positive for emulation?
BEQ EMUFIX ; If yes, patch the code
RTS ; Otherwise, just exit. We're on "normal" "hardware".
EMUFIX LDA #$4C
STA SOFTSW-1 ; 4C = JMP instruction
LDA #<EMUWAIT ; set branch from normal playback routine
STA SOFTSW ; during page flipping operations
LDA #>EMUWAIT-1 ; (which emulators can't display properly)
STA SOFTSW+1 ; to slightly revised EMUWAIT routine.
LDA #$05 ; number of times to wait
STA $FF ; playback speed variable
RTS
EMUWAIT LDX $FF ; Wait for 6 vertical blank periods (10fps)
VBLOOP JSR VBL ; sync next vertical blank period
DEX
BPL VBLOOP ; Do it till X = zero (remove to EMUWAIT with audio)
BIT $C054 ; Always show Page 1
LDA #$20 ; Always load to $2000
STA $56 ; ldrhi - address to load the data
JMP CHKKEY ; Resume playback using PLAY after keypress check
************************************************************ ****
* //gs-specific routines *
************************************************************ ****
TESTGS SEC
JSR $FE1F ; Does RTS on //e, clears carry on //gs
BCC SETGS ; Do we have a //gs?
CLC
RTS ; Not a //gs, just exit
SETGS LDA #$00 ; Change some //gs-specific settings
STA $C034 ; Turn border color black
LDA $C036 ; Read Speed register (bit 7 is speed control)
ORA #%10000000 ; Force bit 7 on (fast speed)
EOR #%10000000 ; now turn it off (normal speed)
STA $C036 ; Sets processor speed to normal
RTS
************************************************************ ****
* Audio Playback *
************************************************************ ****
AUDIO JMP GetNote
SamePage LDY #8 ; BitsPerByte
SameByte PHA
LDA #3 ; Playback speed - 3 faster, 4 slower
JSR $FCA8 ; WAIT based on accumulator value
PLA
ASL
NOP
BCC Delay
STA $C030 ; Click speaker
BCS Next
Delay CMP ($00,X)
Next DEY
BNE SameByte1
GetNote LDA $2300,X ; *** SELF-MODIFIED! test audio starts at $2300
INX
BNE SamePage1
INC GetNote+2
LDA #$80
CMP GetNote+2
BEQ Restart ; if at $8000 we are at the end
RTS
Restart LDA #$23 ; set audio playback back to $2300
STA GetNote+2
RTS
SameByte1 CMP $44,X
CMP ($00,X)
CMP ($00,X)
JMP SameByte
SamePage1 CMP ($00,X)
NOP
JMP SamePage
************************************************************ ****
* Goodbye! *
************************************************************ ****
EXIT STA $C010 ; Clear keyboard strobe
JSR $FB2F ; Set TEXT mode
JSR $FC58 ; Clear screen (HOME)
INC $03F4 ; Invalidate reset vector
JSR $BF00 ; Exit using ProDOS QUIT
DFB $65 ;CALL TYPE = QUIT
DW PARMTABLE ;Pointer to parameter table
PARMTABLE DFB 4 ;Number of parameters is 4
; None of the parameters are actually used
Re: PLAY.HGR - movie playback in HGR graphics mode [message #371863 is a reply to message #367879] Wed, 08 August 2018 09:06 Go to previous messageGo to next message
Anonymous
Karma:
Originally posted by: frank_o_rama

Realizing that I could make some changes to the VBL-polling code. Apparently $C019 is available on the //c without using interrupts, but only if you tickle a couple of softswitches first.

http://www.1000bit.it/support/manuali/apple/technotes/aiic/t n.aiic.9.html


On a ][ or ][+ you could use the "vapor lock" code discussed here recently to find VBL. I'm really only using VBL here to smooth transitions between video modes so in this case I just ignore it.


On a CFFA3000 load time is 0.1 seconds per HGR frame (10 fps). My plan was to play 128 bytes of audio data after each frame load (roughly 0.1 seconds).. Would be choppy in HGR mode, but in double-lores mode it's pretty smooth (40 fps - 0.025 seconds per image frame).

Don't have much time right now to play with it though.

f
Re: PLAY.HGR - movie playback in HGR graphics mode [message #371864 is a reply to message #367879] Wed, 08 August 2018 09:08 Go to previous messageGo to next message
Anonymous
Karma:
Originally posted by: frank_o_rama

Also note, some of the variable locations for PRORWTS2 have changed a bit since it's official release, but functionality should be the same.

f
Re: PLAY.HGR - movie playback in HGR graphics mode [message #371867 is a reply to message #371864] Wed, 08 August 2018 13:46 Go to previous messageGo to next message
Antoine Vignau is currently offline  Antoine Vignau
Messages: 1860
Registered: October 2012
Karma: 0
Senior Member
There is room for a golf course ;-)
av
Re: PLAY.HGR - movie playback in HGR graphics mode [message #371878 is a reply to message #371864] Wed, 08 August 2018 15:03 Go to previous messageGo to next message
qkumba is currently offline  qkumba
Messages: 1584
Registered: March 2013
Karma: 0
Senior Member
> Also note, some of the variable locations for PRORWTS2 have changed a bit since it's official release, but functionality should be the same.

Yes, functionality is identical. There are a set of options available that produce exactly the binary that was used. The ZP locations can be moved freely. I moved them closer together for a smaller hot-swap region for an unrelated option.
Re: PLAY.HGR - movie playback in HGR graphics mode [message #371883 is a reply to message #371867] Wed, 08 August 2018 15:29 Go to previous messageGo to next message
Anonymous
Karma:
Originally posted by: frank_o_rama

I'm not a programmer by trade, but I think it's not too bad for a multi-family landlord and father of two small kids who just happens to be into old computers and music videos. :)

Would love to hear optimizations and thoughts on a small, fast VBL wait subroutine that works across the entire ][ line.

F


On Wednesday, August 8, 2018 at 10:46:18 AM UTC-7, Antoine Vignau wrote:
> There is room for a golf course ;-)
> av
Re: PLAY.HGR - movie playback in HGR graphics mode [message #371884 is a reply to message #371883] Wed, 08 August 2018 15:30 Go to previous messageGo to next message
Antoine Vignau is currently offline  Antoine Vignau
Messages: 1860
Registered: October 2012
Karma: 0
Senior Member
Sure, your work is awesome! Don't misinterpret my previous message, I am a great fan of what you achieved!

Antoine
Re: PLAY.HGR - movie playback in HGR graphics mode [message #371886 is a reply to message #371884] Wed, 08 August 2018 16:09 Go to previous messageGo to next message
Antoine Vignau is currently offline  Antoine Vignau
Messages: 1860
Registered: October 2012
Karma: 0
Senior Member
So, let's start with the IIgs routine:

SETGS LDA #$00 ; Change some //gs-specific settings
STA $C034 ; Turn border color black
LDA $C036 ; Read Speed register (bit 7 is speed control)
ORA #%10000000 ; Force bit 7 on (fast speed)
EOR #%10000000 ; now turn it off (normal speed)
STA $C036 ; Sets processor speed to normal
RTS

It is not safe to play with bits 4-7 of $C034 (CLOCKDATA) and bit 7 change of $C036 (CYAREG) can be simplified:

SETGS
LDA #$0F
TRB CLOCKDATA
LDA #$80
TRB CYAREG
RTS

The other optimization is within VBL. Why not patch it on entry and never test the MACHID byte again?
Let's imagine a new INITVBL routine called early in the code (before the JSR to EMUTEST)
INITVBL
LDX #$60 ; a RTS
LDA MACHID
AND #%01000000
BNE INITVBL8
LDA MACHID
AND #%10001000
CMP #%10001000
BNE INITVBL9
INITVBL8
STX VBL ; store a RTS, or let the original routine...
INITVBL9
RTS

and the new VBL routine
VBL
BIT RDVBLBAR
BPL VBL
]lp BIT RDVBLBAR
BMI ]lp
....which will either be a RTS or your previous (but simplified) routine

Antoine
Re: PLAY.HGR - movie playback in HGR graphics mode [message #371950 is a reply to message #371863] Thu, 09 August 2018 18:54 Go to previous messageGo to next message
ol.sc is currently offline  ol.sc
Messages: 211
Registered: January 2013
Karma: 0
Senior Member
Hi Frank,

Thanks for the very quick reaction - and sharing your code :-)

> On a CFFA3000 load time is 0.1 seconds per HGR frame (10 fps). My plan was =
> to play 128 bytes of audio data after each frame load (roughly 0.1 seconds)=
> . Would be choppy in HGR mode, but in double-lores mode it's pretty smooth =
> (40 fps - 0.025 seconds per image frame).

I see.

Regards,
Oliver
Re: PLAY.HGR - movie playback in HGR graphics mode [message #372217 is a reply to message #371886] Tue, 14 August 2018 18:45 Go to previous messageGo to next message
Anonymous
Karma:
Originally posted by: frank_o_rama

Hmmm... TRB...
must have left that one out of my copy of "Understanding the 6502" ;)

f


On Wednesday, August 8, 2018 at 1:09:12 PM UTC-7, Antoine Vignau wrote:
>
> SETGS
> LDA #$0F
> TRB CLOCKDATA
> LDA #$80
> TRB CYAREG
> RTS
>
Re: PLAY.HGR - movie playback in HGR graphics mode [message #372218 is a reply to message #372217] Tue, 14 August 2018 19:08 Go to previous messageGo to next message
Steve Nickolas is currently offline  Steve Nickolas
Messages: 2036
Registered: October 2012
Karma: 0
Senior Member
On Tue, 14 Aug 2018, frank_o_rama@hotmail.com wrote:

>
> Hmmm... TRB...
> must have left that one out of my copy of "Understanding the 6502" ;)
>
> f
>

That's because it's not per se a *6502* opcode but a 65*C*02 opcode.

-uso.
Re: PLAY.HGR - movie playback in HGR graphics mode [message #372243 is a reply to message #372218] Wed, 15 August 2018 07:29 Go to previous message
Antoine Vignau is currently offline  Antoine Vignau
Messages: 1860
Registered: October 2012
Karma: 0
Senior Member
you enter setgs knowing you're running under a IIgs, so use its dedicated opcodes,
av
  Switch to threaded view of this topic Create a new topic Submit Reply
Previous Topic: ProDOS - 64K ProDOS-8 on a ///?
Next Topic: Midi2Echo+ music conversion soon....
Goto Forum:
  

-=] Back to Top [=-
[ Syndicate this forum (XML) ] [ RSS ] [ PDF ]

Current Time: Thu Mar 28 20:20:11 EDT 2024

Total time taken to generate the page: 0.03548 seconds