I checked it on YT and it is amazing, there's also a colored pop video clip to see and listen to.
Let's assume that there's 160 kb available for frames (the rest for code, music and that picture at the end). At the end of the C64-version there's been mentioned there are 2200 frames. 160000/2200 means ~72 bytes per frame on average. And this was about 12 frames per second, based on 2200 divided by roughly 180 seconds of animation time.
How about live streaming from tape, and deal with its limited bandwidth approximately how Youtube would deal with your limited network bandwidth, by buffering in advance?
For 72 bytes/frame at 12 frames/second you need 864 bytes/second.
At 2400 baud, you can obtain 300 bytes/second from the tape. So you're running at a 564 byte/second deficit. Or a 47 byte/frame deficit.
So to get to 2,200 frames, you need to buffer 2200*47 = approximately 101kb before you begin, and you can live stream what you're missing. So on a 128kb machine it's possible workable.
Assume that, unlike Youtube, you actually preload all but 47 bytes of each frame. You don't have any complete frames, just partial fragments.
Then tape itself would be formulated as a collection of packets like: frame number, missing bytes for this frame, frame-complexity-dependent gap (+10% for tape speed tolerance), repeat.
I'm assuming that with a suitable VDP management scheme you can get a double buffer for this 1bpp stream. So post the bytes from the tape as you receive them, then throw in the extra 25 that you preloaded, flip the buffers, go back to looking at the tape.
You'd probably need to up the baud rate because I've thrown some gaps into the format, but I think 3600 baud can survive on tape for long enough for this not to be an emulator hack?
For dealing with the fact that not all frames are exactly 72 bytes, I guess there are a bunch of options, but it's only problematic if any is below the 47 on the tape. But if the CPU is just doing what the tape asks, you can use an adaptive frame rate.
Or 3600 baud, no gaps, post to the VDP upon receipt, average 72 bytes per frame, nothing loaded in advance, is still 6fps. Which is not terrible?
If you want to get mass storage involved, just use an audio source with a fixed, stable clock rate and bump up your baud rate considerably. Then basically everybody already has the required mass storage.
As mentioned before sharkym's made a MSX2 + stuff version of Bad Apple video.
Lately Yeomang Seo (sharkym's) released a tutorial with
tools for making bad-apple and any video streaming on MSX2 w/its MMC/SD driver cartridge.
That's good!
Yes,, is true, the sharksym video converter works great look what I got :
Full screen, 256x192, 30 fps, 15.7 kHz PCM. Including 2 shades of gray for nice AA. Played on a turboR for the PCM but does not require one in principle. Only 121 MB . Looks awesome.
https://twitter.com/r_y_u_n/status/1292513827595014145
https://www.nicovideo.jp/watch/sm37328426
Increíble quality , looks very nice , maybe can get a little more information about this.
I was amazed when I saw the video
This screen5 30hz versione is pretty amazing. All it lacks is enable not turboR MSXs, saying MSX2/2+, because PCM is a turboR feature, but some cartridges have DAC feature, other soundcards can do PCM too.
What is the trick used here? Partial updates? But worst case it will still be too slow, wouldn't it?
Yes it only updates the pixels that change. This music video is well suited for it because it is basically just a lot of moving edges. If I understood the video description correctly it does sometimes dip under 30 fps, but pshah.
Additionally, if I understood this tweet correctly, his conversion program outputs data as code.