Just released: MacFlim, the impracticable Vintage Video player for Compact Macs

[fstark]

I failed to release it in time for #MARCHintosh, but was able to hit Apple 45th birthday

 

Introduction video: https://youtu.be/MiRtNavqfpg

 

Website: http://www.macflim.com/

 

Let me know what you all think, and long-life to the compact Macs!

Edited April 1 by fstark

[Andy]

Very cool stuff! I will give this a try on my Classic II this weekend, curious how it will run vs the SE/30.

[BacioiuC]

Just tried it out on my SE/30 and it looks amazing. For giggles, I opened up QT2 player and ran an .aiff in paralel and it works pretty well. I'm guessing your blitting the full uncompressed frames to the screen and audio would be too taxing on a plus/se.

 

I can seeee myself using this for when I take my SE/30 on the road to expos, to demo trailers or "demos" of my games running this way. 

 

I like it

 

 

 

[68krazy]

Oh my, this is a fantastic and impressive achievement.  I can't wait to try it on a compact!

[fstark]

20 hours ago, BacioiuC said:

Just tried it out on my SE/30 and it looks amazing. For giggles, I opened up QT2 player and ran an .aiff in paralel and it works pretty well. I'm guessing your blitting the full uncompressed frames to the screen and audio would be too taxing on a plus/se.

 

 

 

Cool. You are right, I do a BlockMove of uncompressed frames directly to the framebuffer.

 

Audio would cost 22K/second, so it is completely possible to do (would cost 1fps). However, it needs to be interleaved in the original stream, which is a pain I would need to use double audio buffers, something I did when I ported Captain Blood 30 years ago, but I completely forgot how. I am also worried about the delays, as I absolutely need to hit a vbl every 60th of a second to swap audio buffers.

 

Truth is I didn't tried sound because my SE/30 have no sound and are in need of a recap  It would have added so much dev time, I am happy I "stayed with reason" (I added multiple framerate, windowed playback mode, save frame, move to frame, etc, etc, so I god my fair share of feature creep already). Maybe a v2 someday!

 

Also, it is MacFlim, not MacFilm. It is an obscure French joke about a movie created by creative not-really-authorized copies, which I found fitting

[BacioiuC]

Really good work! Seeing a full blown "HD-almost" video on the internal SE/30 screen is a treat to the eyes! Grats on the release, you shipped a pretty neat piece of software. Thank you

[fstark]

20 hours ago, BacioiuC said:

Really good work! Seeing a full blown "HD-almost" video on the internal SE/30 screen is a treat to the eyes! Grats on the release, you shipped a pretty neat piece of software. Thank you

 

It was really fun to write. And I haven't written Mac code in 30 years, so that was quite a trip on the memory lane.

 

Truth is that I am so in love with the aesthetic of Floyd–Steinberg dithering, it was in awe on my Mac Plus in 1986 looking at those fantastic images. Of course, I had no scanner, so I only had a few precious images on floppy drives to look at. The catch to make a movie like that is to get it to be temporaly stable, ie: to have the "error pixels" at the same spot between images (for instance the Return of the Obra Dinn cheats by using ordered dithering in many case). I have a blog post almost ready about that, but I focused on first getting the app out. There are a few rough edges to correct, and a few crashes, and I need to release the source code and the tools. It'll probably take a few weeks. The you will be able to make your own flims, too! Stay tuned...

[rplacd]

Hey, well done! That's a beautiful hack

I think the usual "I did it" demoscene demo video for full-motion video is Bad Apple – here's Bad Apple on an 8088 clone with a SoundBlaster card, a C64. You could be the first to get one running on a 68k compact Mac!

[nickpunt]

@fstark this is so cool, thank you for making it!

[Byrd]

Thanks @fstark: you've just created the killer app for us to show off our Macs!  Out of interest, how much additional CPU overhead does low bitrate sound use (eg. for SE/30)?

[yugen]

So very cool - will a FloppyEMU be fast enough for this, or does it need to be SCSI? 

[History_SE30_Dude]

I just tried it out on my Macintosh Portable and it runs great at the SE/30 recommended settings!

[fstark]

On 4/1/2021 at 7:55 AM, yugen said:

So very cool - will a FloppyEMU be fast enough for this, or does it need to be SCSI? 

 

Don't know yet. I'll try over the week-end to see how it runs on a plus with emulated HD20... If it runs acceptably, I will put a directly downloadable image so people can play with it easily.

[fstark]

23 hours ago, History_SE30_Dude said:

I just tried it out on my Macintosh Portable and it runs great at the SE/30 recommended settings!

 

This is completely awesome. I got a portable 2 days ago, but it has no battery, so I could not test. I really wanted to add a portable to the mix in the video...

 

If anyone has a spare Mac Portable battery for a reasonable cost, I would be the happiest ever (even if dead, I can have someone change the cells).

 

[fstark]

On 4/1/2021 at 7:13 AM, Byrd said:

Thanks @fstark: you've just created the killer app for us to show off our Macs!  Out of interest, how much additional CPU overhead does low bitrate sound use (eg. for SE/30)?

 

If I remember correctly, there is no low or high bitrate sound on the compact macs. You have two a 370 bytes buffers that needs to be filled alternatively every 60th of a second. That is about nothing on CPU load (but you can't use BlockMove, as the bytes are interleaved with, I think, the drive motor speed), and only adds 22Kb per frame data overhead (ie: a full screen frame).

 

The 2 big issues with sound are that my SE/30 have no sound (need the recap!) and that it needs to be *absolutely perfect* every 60th of a second, or it will be ugly and cracking (right now, the 24fps flims run at 21fps and no-one complained. Sometimes the MacPlus skips a frame, or display unsynced with the VBL, and no one bu me noticed. But with sound, it'll be a different story). And I am afraid that the background SCSI read + screen blit could make it to miss interupts. That would make the app less useful (you would need a 64Mb or 128Mb SE/30 with a RAM disk or similar to avoid cracks. Ugh )

[LaPorta]

You can use this as a drop-in Portable battery replacement. It’s basically the original cells from the original manufacturer in a different package. It firs physically, you just need to rig some sort of extension for the contacts:

 

https://www.batteriesplus.com/battery/sla-sealed-lead-acid/6/hawk0809=0012

[Crutch]

First off, thanks for making MacFlim!  It looks amazing and I can’t wait to try it.  I also love those dithered 1-bit graphics!

 

A couple comments on sound if helpful, mainly because I really want you to add sound 

 

21 hours ago, fstark said:

If I remember correctly, there is no low or high bitrate sound on the compact macs. You have two a 370 bytes buffers that needs to be filled alternatively every 60th of a second. That is about nothing on CPU load (but you can't use BlockMove, as the bytes are interleaved with, I think, the drive motor speed), and only adds 22Kb per frame data overhead (ie: a full screen frame).

 

On the Plus and below:  That’s true of the main sound buffer, but in the alternate sound buffer (370 words) the disk timing info is ignored (see Guide to the Macintosh Family Hardware).  You still need to put sound data in the high-order byte of each word only, but you can in fact use BlockMove if you only use the alternate sound buffer and copy the sound from a buffer that stores each sound data byte alternating with a byte of zeros (wastes space but maybe faster).  Do you really need to switch buffers?  I bet you can BlockMove 370 bytes into the alternate sound buffer reliably fast enough every VBL interrupt.

 

The SE lacks the alternate sound buffer so you’d have to deal with the byte interleaving thing.  I would think, though, you can still use BlockMove and just pre-stage a buffer with zeros in the low-order bytes of each word.  Just wait for any 400k floppy drive accesses to stop before starting playback and realize the floppy drive won’t work during flim-watching.   

 

You are correct that low-bitrate sound only saves space, not CPU (the Mac will blip one byte’s worth of sound every horizontal blanking interval no matter what so the sound buffers must be populated at the same rate no matter what; lower bitrate sound just means writing the same byte multiple times).

None of this applies to the SE/30 since it’s really a stealth Mac IIx and has an Apple Sound Chip which reads sound data from its own 2KB of dedicated RAM.  I don’t really know how to control the ASC directly but on an SE/30 you can probably just use the Sound Manager.  Sound playback doesn’t tie up the 68030 much because the ASC does most of the work.

 

 

 

[Crutch]

p.s.  I think this link might be bad:  http://www.macflim.com/releases/flims/Star_Wars_Death_Star.5.1.sit   (the StuffIt 3 version works!)

[fstark]

22 hours ago, Crutch said:

p.s.  I think this link might be bad:  http://www.macflim.com/releases/flims/Star_Wars_Death_Star.5.1.sit   (the StuffIt 3 version works!)

You are right. It should have been:

 

http://www.macflim.com/releases/flims/Star_Wars_Death_Star_1.5.1.sit

 

Fixed.

 

[fstark]

22 hours ago, Crutch said:

On the Plus and below:  That’s true of the main sound buffer, but in the alternate sound buffer (370 words) the disk timing info is ignored (see Guide to the Macintosh Family Hardware).  You still need to put sound data in the high-order byte of each word only, but you can in fact use BlockMove if you only use the alternate sound buffer and copy the sound from a buffer that stores each sound data byte alternating with a byte of zeros (wastes space but maybe faster).  Do you really need to switch buffers?  I bet you can BlockMove 370 bytes into the alternate sound buffer reliably fast enough every VBL interrupt.

 

The SE lacks the alternate sound buffer so you’d have to deal with the byte interleaving thing.  I would think, though, you can still use BlockMove and just pre-stage a buffer with zeros in the low-order bytes of each word.  Just wait for any 400k floppy drive accesses to stop before starting playback and realize the floppy drive won’t work during flim-watching.   

 

You are correct that low-bitrate sound only saves space, not CPU (the Mac will blip one byte’s worth of sound every horizontal blanking interval no matter what so the sound buffers must be populated at the same rate no matter what; lower bitrate sound just means writing the same byte multiple times).

None of this applies to the SE/30 since it’s really a stealth Mac IIx and has an Apple Sound Chip which reads sound data from its own 2KB of dedicated RAM.  I don’t really know how to control the ASC directly but on an SE/30 you can probably just use the Sound Manager.  Sound playback doesn’t tie up the 68030 much because the ASC does most of the work.

 

 

This is amazingly useful info. You are slowly cornering me into implemeting the sound

 

However, I am still wondering if that can really work, as I have the suspicion that the SCSI driver may turn off interrupts at some time, in which case there may not be much taht can be done. Maybe the SE/30 approach would work. Unfortunate that my SE/30 are mute

[fstark]

On 4/1/2021 at 4:50 PM, LaPorta said:

You can use this as a drop-in Portable battery replacement. It’s basically the original cells from the original manufacturer in a different package. It firs physically, you just need to rig some sort of extension for the contacts:

 

https://www.batteriesplus.com/battery/sla-sealed-lead-acid/6/hawk0809=0012

 

This is great, thx!

[Crutch]

20 hours ago, fstark said:

 

This is amazingly useful info. You are slowly cornering me into implemeting the sound

 

That was my secret plan!  You might be right about the SCSI driver, I might read up on that a little myself out of curiosity.

 

By the way I just downloaded everything but it looks like it won't run on my SE/30 with a Micron Xceed grayscale card even in 1-bit mode.  I am guessing that is because the Micron messes with screenBits so the rowBytes is different ...  ?  Bummer!  I understand though.  I will have to bring out my vanilla SE/30 to try it.  By the way, your error message is hilarious.  "Are you from the future?  Get a real Mac!!"  ha ...

[fstark]

20 hours ago, Crutch said:

By the way, your error message is hilarious.  "Are you from the future?  Get a real Mac!!"  ha ...

 

This error message is if the screen is not exactly 512x342, 64 rowbytes.

 

You can actually COMMAND-click on the button, and it will go forward, using a slightly different blitting approach, that should work if the situation is not too different from a "normal" SE/30 (if for instance, it is only a rowByte issue, but you are 8 pixels per bytes, it will work).

 

You can then disable this test in the Flim/Tuning... menu.

 

Let me know how it goes, I want this thing to work in every plausible configuration.

Edited April 1 by fstark

[Crutch]

It works!  (Option click actually did it for me.)  Brilliant!  The Star Wars clip is sensational.  Also the app generally is really well done with the various features, Tips at startup, etc ... so cool.  The dithering is spectacular.  Amazing work!

 

(I think the Xceed card bumps up rowBytes to something huge like 1024, even in 1-bit mode, to “make room” in case you later increase the pixel depth ... in 8-bit mode it changes the screen resolution to 512x341 so that old apps that assume 512x342 = black&white won’t deprive us of lovely grayscale.) 

Edited April 1 by Crutch

[PowerMac_G4]

I got the 1984 clip running on my Classic and it looks fantastic! You have created something truly astonishing here. 

 

Here's a video of the "flim"