51

Kurde, mam taka jedną, ale zawaloną softem i samplami, nie chcę jej czyścić... Poszukam takiej drugiej. Chyba, że ktoś ma nadmiarową i chciałby odstąpić, to z chęcią nabędę na drodze kupna.

grzybson/SSG^NG

52

Odgrzewając kotleta, nie dało by rady aby MOVPLAY był na partycji APT a sam filmik na FAT16 pod montowanej do SDX i tak odpalać to to?

53

jest inny problem, mianowicie dane odczytywane są sektorowo i sekwencyjnie, bez jakiegokolwiek systemu plików. Stąd też odpada problem fragmentacji plików, alokacji sektora itd i stąd też wynika prędkość tego rozwiązania. Być może można by to obejść, lecz robiąc to tak jak w R0l0 Playerze Epiego. System plików z klastrem 128kB np. więc zachowując jakąś tam organizację danych uzyskujemy w praktyce szybkość odczytu jak po sektorach.

Kontakt: pin@usdk.pl

54 Ostatnio edytowany przez flashjazzcat (2017-12-16 20:12:22)

I already have a mechanism in mind to support FAT storage with 8KB clusters (or 4KB if files are defragmented), but Phaeron would have to change the video encoder in order to remove a few scanlines from the frame (reducing each frame to <= 8KB, including audio data). On the 6502 side, building a RAM-based table of sectors from the FAT chain is trivial.

55

-- digging out --
The problem is that there are 2 (fat16) or 4(fat32) bytes per sector. So in naive approach there is ~32 kb/4=8 000 frames to remember, which gives 160 seconds of uninterrupted video. Less naive approach is to remember only jumps to "not next" sectors with run length encoding of "next" sectors. Then it makes sense. But reading of 8kb by the CPU takes some time and processing of those 8 kb also, so I bet 1/2 of the second to one second is needed to process one fat sector. For 3-minutes movies it is acceptable to wait 2-3 seconds, but for full-length movies waiting for minute or two is too long. Of course, the time may be stripped down by clever programming, but the time needed to start playing will be annoying.