phaeron Posted June 20, 2021 Author Share Posted June 20, 2021 18 minutes ago, CharlieChaplin said: I am wondering if there is something (anything) we can do to avoid/remove this noise or make it less noticeable (more silent)..??? What would happen, if we used e.g. 11Khz or 22Khz, would it become better or worse ? Or would it just be impossible to use any other Khz range for audio in these videos ? The sampling rate has to be 15.7KHz as the CPU has to write each sample to POKEY and the only time available to do this is in horizontal blank. ANTIC is using the bus 100% during active display time. Quote Link to comment Share on other sites More sharing options...
Faicuai Posted June 20, 2021 Share Posted June 20, 2021 1 hour ago, phaeron said: The sampling rate has to be 15.7KHz as the CPU has to write each sample to POKEY and the only time available to do this is in horizontal blank The mere fact that local 1979/1980 chipset is actually doing the heavy lifting for all this to happen (in a GPU-dominant operation) and reading directly from mass storage (of arbitrary capacity) with NO assistance other than storage-controller for fetching byte-per-byte, is still (and will always be) a monumental feat, in my retro-book. For this reason I would forgive any audio-stream imperfection (although better is always welcome), as I do not believe anyone from Jay Miner's original team may have even imagined this could be possible or doable, back then. Total and absolute respect !! 4 Quote Link to comment Share on other sites More sharing options...
+CharlieChaplin Posted February 13, 2022 Share Posted February 13, 2022 Jakub Husak is experimenting with phaeron's Atari Videos and creating new players. He created AVF videos that are a little different from the old ones, i.e. they are louder (audio sounds better) and they do allow two text lines for subtitles. This newer format also requires a new player, but Jakub is already working on a player that supports both the old and new format and he is working on (separate?) players for Pokey and Covox. Find some examples at AOL (or use the AOL site with Google translate). To playback the currently 3 new videos one requires the new player (AVFPLAY, with 866 or 877 Bytes). With AVG cart, simply rename the old player to something else (e.g. AVFplayold) and copy the new player and the videos onto the SD-card. Since the new player will currently only play the new videos, keep a copy of the old player to still play the old AVF files. Let's wait and see what else he comes up with, besides Pokey-mono and Covox-stereo players, maybe he will also support some other gfx formats (not only Gr. 9+11 with lots of colors but therefore very low resolution). Would be nice if other A8 gfx formats with less colors, but therefore higher resolution would be doable... 7 Quote Link to comment Share on other sites More sharing options...
jhusak Posted February 17, 2022 Share Posted February 17, 2022 (edited) Hey, we're working with acid maker on this. I do the atari an partially mux side, and acid maker makes new video encoder with more graphics modes dithered (160 and 320 pixels in horiz in colour and b&w) I am working on compatibility (well, partial) between PAL and NTSC, ie you can play PAL stream on NTSC machine and vice versa with lower sound quality and 6/5 or 5/6 of speed, but you can look into movie. @phaeron, The hiss CharlieChaplin mentioned is due to hscroll settings and different place in raster for pokey firing, it is over 4khz. There is a simple cure for that "100% busy and no time" you might have overlooked. When playing with NO hscrol, simply by eating bytes (3 or 2) per horizontal line between 80-byte line data, you can write them directly to sound registers Then you have full 32 cycles of CPU in hblank. I have even put 3 streams in those 32-12 cycles (because 12 is eaten by gtia switching); if three bytes , there are 2 channels of stereo covox (vol 0-200) and one for pokey (vol 0-100). When there are two bytes, there are ehough time to mux 2 stereo bytes to one mono pokey byte 2 bytes of data between lines for pokey: lda ide ads ide ror lsr sta audf1 sta stimer 20 cycles! 2 or 3 bytes of data between lines for covox: lda ide sta covoxl lda ide sta covoxr lda ide (if 3 bytes) 20 cycles! 3 bytes of data between lines for pokey: lda ide lda ide lda ide sta audf1 sta stimer. 20 cycles! The pokey firing is exactly in the same cycle of line regardles of number of sound bytes, so you have no harmonic frequencies below 15600hz (but you still have to cycle the rest of raster) The only thing to get those bytes almost compacted is to start hblank from cycle 100, not 104 (or 101, not 105) The music is louder due to sox settings, nothing more. I use linux/osx ffmpeg, sox tools to prepare avf. Edited February 17, 2022 by jhusak typo 4 1 Quote Link to comment Share on other sites More sharing options...
flashjazzcat Posted February 17, 2022 Share Posted February 17, 2022 I'll be attempting to implement the video player on SIDE3 shortly (there being no other volunteers), so any improvements in the toolchain and/or file format would be most useful indeed. SIDE3 will be using DMA to read the complete frame directly into cartridge SRAM, and the display will have to be carefully positioned so that the CPU has easy access to the audio data surrounding the image data. 4 Quote Link to comment Share on other sites More sharing options...
phaeron Posted February 17, 2022 Author Share Posted February 17, 2022 4 hours ago, jhusak said: Hey, we're working with acid maker on this. I do the atari an partially mux side, and acid maker makes new video encoder with more graphics modes dithered (160 and 320 pixels in horiz in colour and b&w) I am working on compatibility (well, partial) between PAL and NTSC, ie you can play PAL stream on NTSC machine and vice versa with lower sound quality and 6/5 or 5/6 of speed, but you can look into movie. @phaeron, The hiss CharlieChaplin mentioned is due to hscroll settings and different place in raster for pokey firing, it is over 4khz. There is a simple cure for that "100% busy and no time" you might have overlooked. When playing with NO hscrol, simply by eating bytes (3 or 2) per horizontal line between 80-byte line data, you can write them directly to sound registers Then you have full 32 cycles of CPU in hblank. I have even put 3 streams in those 32-12 cycles (because 12 is eaten by gtia switching); if three bytes , there are 2 channels of stereo covox (vol 0-200) and one for pokey (vol 0-100). When there are two bytes, there are ehough time to mux 2 stereo bytes to one mono pokey byte Unfortunately, I didn't overlook this, it's actually intentional. When I was working on this, I found that some CompactFlash cards had problems reliably streaming data continuously over the entire frame. There's no time to buffer or check for data ready, so if the CF card isn't ready in time, the CPU/ANTIC reads garbage data and stream sync is lost. To ensure reliable operation, the format is arranged to leave enough idle cycles in horizontal blank for the CF card to prepare the next sector. That's why the normal width format is arranged with three lines contained within 128 bytes with a larger gap at the end, to ensure enough time between sectors. This isn't necessary with all cards and you might be OK with the cards that you are using and the specific timing, but YMMV. 5 Quote Link to comment Share on other sites More sharing options...
jhusak Posted February 19, 2022 Share Posted February 19, 2022 On 2/17/2022 at 10:04 PM, phaeron said: Unfortunately, I didn't overlook this, it's actually intentional. When I was working on this, I found that some CompactFlash cards had problems reliably streaming data continuously over the entire frame. There's no time to buffer or check for data ready, so if the CF card isn't ready in time, the CPU/ANTIC reads garbage data and stream sync is lost. To ensure reliable operation, the format is arranged to leave enough idle cycles in horizontal blank for the CF card to prepare the next sector. That's why the normal width format is arranged with three lines contained within 128 bytes with a larger gap at the end, to ensure enough time between sectors. This isn't necessary with all cards and you might be OK with the cards that you are using and the specific timing, but YMMV. Yes - the 128 byte for three lines is obvious. However, when you do not use the hardware scroll, in summary you get more cycles in hblank, 32 in general. That's what I had in mind. Quote Link to comment Share on other sites More sharing options...
phaeron Posted February 19, 2022 Author Share Posted February 19, 2022 51 minutes ago, jhusak said: Yes - the 128 byte for three lines is obvious. However, when you do not use the hardware scroll, in summary you get more cycles in hblank, 32 in general. That's what I had in mind. Sure, but the issue is the gap between those 128 bytes for the IDE/CF interface. With ANTIC reading only 120 bytes over those three lines, the 6502 has to read 8 bytes. There isn't enough time to read 4 bytes in two horizontal blank periods while still updating GTIA and POKEY, so the 6502 would have to read some bytes in the third hblank period -- which cuts into the idle time for the IDE interface. Currently that third period has 29 cycles during which the IDE interface is idle and the CF card can fetch the next sector. Or perhaps I am misunderstanding? If you could provide details of how many bytes the 6502 would read at the end of each line, that would help clarify. Now, that gap is really technically only needed every 512 bytes, since the IDE interface has to support burst reading of an entire sector. (It was designed to support REP INSW transfers on an 80286, which doesn't check status either.) That means that only one out of every four line groups needs that gap and IDE reads can be shuffled around. However, ANTIC is twice as fast at eating bytes than the 6502, so for every two cycles that are freed up by reducing or disabling HSCROL, it takes four cycles for the 6502 to read that byte instead. That largely eats up any time that is freed. Quote Link to comment Share on other sites More sharing options...
jhusak Posted March 6, 2022 Share Posted March 6, 2022 (edited) On 2/19/2022 at 8:13 PM, phaeron said: Sure, but the issue is the gap between those 128 bytes for the IDE/CF interface. With ANTIC reading only 120 bytes over those three lines, the 6502 has to read 8 bytes. There isn't enough time to read 4 bytes in two horizontal blank periods while still updating GTIA and POKEY, so the 6502 would have to read some bytes in the third hblank period -- which cuts into the idle time for the IDE interface. Currently that third period has 29 cycles during which the IDE interface is idle and the CF card can fetch the next sector. Or perhaps I am misunderstanding? If you could provide details of how many bytes the 6502 would read at the end of each line, that would help clarify. Now, that gap is really technically only needed every 512 bytes, since the IDE interface has to support burst reading of an entire sector. (It was designed to support REP INSW transfers on an 80286, which doesn't check status either.) That means that only one out of every four line groups needs that gap and IDE reads can be shuffled around. However, ANTIC is twice as fast at eating bytes than the 6502, so for every two cycles that are freed up by reducing or disabling HSCROL, it takes four cycles for the 6502 to read that byte instead. That largely eats up any time that is freed. Well, 114-80(antic)-2(1dlidma + 1refresh)=32 cycles. So here it is and THAT WORKS on AVGCart. 3 stas for gfx mode change and 5 lda/sta for pokey or covox, as I wrote earlier. There are 2 kind of lines: 2 x (3 bytes of sound, 40 bytes of gfx) and one (2 bytes of sound and 40 bytes of gfx). When you have to eat three bytes in a line, you eat them and you have two stas for pokey or stereo covox. When you have to eat two bytes in a line, you eat one, add soecond and divide by 4 and sta-sta to pokey or sta to stereo covox. So simple and - again - not theoretical - this WORKS on AVGCart. All is divided in 512 byte sectors, no ANTIC line is divided by sector change. HOWEVER, I have _not_ tested this on SIDE2 hardware, the only thing is that I have managed to keep ANTIC line undivided. But, _it may_ be, that gaps between reads are to short and the all thing'll go to trash... Anyway, I'll test it soon. ------------------ Next I have managed to align sta stimer to 17 cycle in EVERY line either in PAL or NTSC. NO audible whistle, only 6.5 bit noise (here attached original based AVGcart version of movplay/avfplay with corrected timing playing original AVF files, PAL or NTSC) AVFPLAY Edited March 6, 2022 by jhusak 7 Quote Link to comment Share on other sites More sharing options...
_The Doctor__ Posted March 6, 2022 Share Posted March 6, 2022 (edited) time for testing folks... Edited March 6, 2022 by _The Doctor__ 1 Quote Link to comment Share on other sites More sharing options...
+CharlieChaplin Posted March 6, 2022 Share Posted March 6, 2022 15 hours ago, _The Doctor__ said: time for testing folks... Already tested it with 3 AVF files and the hissing/buzzing/... noise was much less with this new player (compared to the old player). But I only tested three PAL AVF files and not all of my 200+ AVF files (nor did I test any NTSC AVF files, since I do not own any NTSC hardware). YMMV... 1 Quote Link to comment Share on other sites More sharing options...
Beeblebrox Posted March 6, 2022 Share Posted March 6, 2022 (edited) Bit late to the party here. Great work. I am happy to test on Side2 for PAL playback . I have my 800 Incognito with it's inbuilt Side2 loader so presumably that would also work? Or does the functionality only extend to actual Side2 carts after AVG cart? If Incognito is a go, excuse my ignorance but is it just a simple case of popping the AVFplayer (with no extender) as is onto the root of the CF and having a PAL AVF file, (perhaps one from Poison's collection), in the same root? Then running the AVFplayer from the Side 2 loader and picking said AVF file? Thanks in advance. I did read earlier posts in this thread a while back last year before this new work was done. I must admit I only got a video playing in emulation on Altirra as I assumed there was no player compatible with AVF files on real Side 2 (and Incognito) hardware. Edited March 6, 2022 by Beeblebrox Quote Link to comment Share on other sites More sharing options...
jhusak Posted March 6, 2022 Share Posted March 6, 2022 (edited) On the desk now is to put changes to SIDE2 movplay. Edited March 6, 2022 by jhusak Quote Link to comment Share on other sites More sharing options...
+Philsan Posted March 6, 2022 Share Posted March 6, 2022 Do previous AVF files work with new AVGCart player? Quote Link to comment Share on other sites More sharing options...
Poison Posted March 6, 2022 Share Posted March 6, 2022 (edited) 17 hours ago, jhusak said: Well, 114-80(antic)-2(1dlidma + 1refresh)=32 cycles. So here it is and THAT WORKS on AVGCart. 3 stas for gfx mode change and 5 lda/sta for pokey or covox, as I wrote earlier. There are 2 kind of lines: 2 x (3 bytes of sound, 40 bytes of gfx) and one (2 bytes of sound and 40 bytes of gfx). When you have to eat three bytes in a line, you eat them and you have two stas for pokey or stereo covox. When you have to eat two bytes in a line, you eat one, add soecond and divide by 4 and sta-sta to pokey or sta to stereo covox. So simple and - again - not theoretical - this WORKS on AVGCart. All is divided in 512 byte sectors, no ANTIC line is divided by sector change. HOWEVER, I have _not_ tested this on SIDE2 hardware, the only thing is that I have managed to keep ANTIC line undivided. But, _it may_ be, that gaps between reads are to short and the all thing'll go to trash... Anyway, I'll test it soon. ------------------ Next I have managed to align sta stimer to 17 cycle in EVERY line either in PAL or NTSC. NO audible whistle, only 6.5 bit noise (here attached original based AVGcart version of movplay/avfplay with corrected timing playing original AVF files, PAL or NTSC) AVFPLAY 4.4 kB · 14 downloads I would like to ask if is possible to add function - play next AVF file for AVG cart ? Or some kind of file queue, which I choose from AVF dir ? Edited March 6, 2022 by Poison Quote Link to comment Share on other sites More sharing options...
jhusak Posted March 6, 2022 Share Posted March 6, 2022 (edited) @phaeron, why there is a need to have 8kB of pad bytes at the beginning? @Philsan and others The movplay for SIDE/SIDEII, also avfplay on AVGCart will play avf movies all and only. The NEW player for format jvf (after Jakubs, two of us :) will have extended possibilities, however, if the file format is not recognized, it will switch to normal avf mode. So it will be sufficient to have one player at the end Edited March 6, 2022 by jhusak 2 1 Quote Link to comment Share on other sites More sharing options...
Peri Noid Posted March 6, 2022 Share Posted March 6, 2022 Works really well with my old AVF movies. I'm watchin Bladerunner with AVG right now. I'm waiting for MOVPLAY to test it with Side2. One question - does it still need movie files to be defragmented? Quote Link to comment Share on other sites More sharing options...
jhusak Posted March 6, 2022 Share Posted March 6, 2022 47 minutes ago, Poison said: I would like to ask if is possible to add function - play next AVF file for AVG cart ? Or some kind of file queue, which I choose from AVF dir ? This question should go to @tmp However, I think he thinks about it already For now he tuned up the firmware of AVGCart for event more powerful movie content:) But only for AVGCart, if the rest of cartridges do not follow with features. So it will be "a poor man avf player" and for AVF "full feature player" Quote Link to comment Share on other sites More sharing options...
jhusak Posted March 6, 2022 Share Posted March 6, 2022 (edited) 3 minutes ago, Peri Noid said: Works really well with my old AVF movies. I'm watchin Bladerunner with AVG right now. I'm waiting for MOVPLAY to test it with Side2. One question - does it still need movie files to be defragmented? Yes, and there is a little @tmp can do I am afraid... But, who knows... I have fired original movplay with SIDE and SIDE2 and movie on SanDisk 2GB card and they worked flawlesly. So I am ready to sound-tweak SIDE version. Edited March 6, 2022 by jhusak Quote Link to comment Share on other sites More sharing options...
Beeblebrox Posted March 6, 2022 Share Posted March 6, 2022 @jhusak Fantastic. Thanks again for all the continued work on these. I'd love to watch Blade Runner off my 800 Incognito. So I have taken from reading the other posts above in the last few hours that the original Movplayer tehnically should work on Incognito's Side 2 loader off a CF. Only I tried to play a file on Incognito's Side2 off the root of my CF in the last couple of hours and I just got static. (I tried the moveplay and Tron files in this post here). I guess it could be the CF brand and spec itself (8GB Trancend 133x) causing the issue. Anyway since I can't get it to work I'll wait for the Side2 compatible enhanced new player you are working on, which I assume will work on Incognito Side 2? Quote Link to comment Share on other sites More sharing options...
Poison Posted March 6, 2022 Share Posted March 6, 2022 (edited) There are more than 300 AVF videos. https://archive.org/details/@poison6502 Edited March 6, 2022 by Poison 3 Quote Link to comment Share on other sites More sharing options...
Peri Noid Posted March 6, 2022 Share Posted March 6, 2022 34 minutes ago, jhusak said: Yes, and there is a little @tmp can do I am afraid... But, who knows... It's kind of unfortunate. Does anyone know, if there exists a defragmentation tool for VFAT filesystem working under Linux? Quote Link to comment Share on other sites More sharing options...
_The Doctor__ Posted March 6, 2022 Share Posted March 6, 2022 Player timings are better, will re encoding tailored to this be of any benefit or is it perfect the way they are? Quote Link to comment Share on other sites More sharing options...
jhusak Posted March 6, 2022 Share Posted March 6, 2022 (edited) Timings in source files are perfect (in fact there are not at all, there is no info about them in avf file) Here is github repository I have tweaked the cycles for MOVPLAY (well, I have transferred them from AVF for AVGCart) https://github.com/jhusak/side-sideII-avfplay And here is compiled MOVPLAY (names to be consistent - MOVPLAY - SIDE/SIDEII player, AVFPLAY - AVGCart player) for SIDE/SIDEII. There is only slight white noise in the background No hiss nor brum nor nothing. @Phaeron, please check the dffierence. I have changed the version - updated credits at 21:19, 6.03.2022 MOVPLAY.XEX Edited March 6, 2022 by jhusak Fix credits 3 Quote Link to comment Share on other sites More sharing options...
Beeblebrox Posted March 6, 2022 Share Posted March 6, 2022 @jhusak Wow you move fast Ok, downloaded the above Movplay.xex, popped it on the root of the CF along with an Atari Jaguar movie (.AVF extender), from Poison's collection (assuming they are PAL), and ran the movplayer from the Incognito's Side2 loader. Got an IDE command code error unfortunately: I also tried a .img movie as well - makes no difference. Either clearly I've missed something in this process or Incognito Side2 loader requires a different approach to that of the SIDE2 cart. Quote Link to comment Share on other sites More sharing options...
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.