Yosh

It is simply marvelous... It feels like on PC - minus small things from poster above Fingers crossed

Simply awesome.

Blew my mind... Marvelous!

Yes I have completely forgotten Host Device. This was exactly what I needed on emulator. I always wanted to make compressed video container abusing Atari DOS binary format... so, here it is (requires fast xex loader - like warpseed host device on Altirra:) ) Sections in xex file goes like this: 1) INIT section setups graphic mode 2) RUN section (which will be ran at the end of load) returns to dos and gives calculated throughput (via OS clock) 3) data section for whole first frame 4,..,n) sections with delta to current frame Of course there is no frame sync, no audio... ​Converter and examples are available in movie description. You will need fast xex loader. but you can toy on emulators (on yt warp speed isn't used) DOS 2.5 CP is neat, because it understands H: correctly - can stream even big files (just opens them and reads to the end, ignoring file size) Other doses aren't so smart (even when they see H) Happy new year!

Hi Some other day I was very displeased with grabbed video from USBTV007. I don't have 25fps 576i video - my Atari produces 50fps 288p. I had to fix this (watch 720p50) https://github.com/Yoshqu/usbtv-retro It should work on NTSC, but needs linux and this particular device... (so i'm afraid this Christmas Gift isn't for everyone) Merry Christmas!

Hi As I'm trying to do some comparison / regression / performance testing I would like to ask about fastest drive emulation in Altirra (for loading binaries): - I don't have any bioses for fancier hardware, but all hacks/settings for Altirra are ok (SIO patch, CIO patch) - Which DOS/loader ? I would pick something with Sparta file system (seems much faster on paper) - 512 bytes per sector is not possible on pure Alitrra ? Yes I know it will be apples to oranges, but still I have something fun in mind Thanks

It depends on approach. If Firefox is emulated somewhere, I can patch emulator to stream all sprites positions into file, load them into yet-to-be-written generic overlay engine for my player - and voila! ... and this is Atari game ... and this is somewhat more interactive than DL (more fun and different) ... and I was flying gliders myself in real life ... and If i would only want to load games - sio2sd in 2008 was available, but I have drunk some beer back then in Wrocław and it hit me "This can be done VERY fast, on similar components" .... so lets say that "mega work" is relative but don't hold me to anything I have a lot more tricks up my sleeve for that expansion, so this goes down the list 50 FPS, so it's PAL machine. It uses Atari clock though, so It _should_ work on NTSC (of course player would be rewritten and video would be re-encoded) This is somewhat the same in the aspect of direct-to-Antic stream, but details are very different. - 44 bytes per line (wide screen, I can't find how wide screen with SIDE 2), on my TV i see 87 pixels (almost all) - and if you have 80, the 8 more are noticeable (mostly - it fills MY whole screen:P) - in those lines, I hide another 4 byte of audio data, to achieve 8bit 31k PDM - and because there is some time left i use Rybags broken last line Antic trick to do vsync myself (well Rybagself - man, this blow me away - i HAD to use it) and all counters and lives are shown below video frame (It's 239 video lines + 14 lines of status bar) - plays files from FAT32 SD card. Of course this co-processor of mine is still 8bit - I expect non-fragmented files - this sounds somewhat bad, but in practice it work that way: * fast format card (reinit FAT only) * add some files - play with atari * add some more files - play with atari. ups, it's full (up to 2GB), reformat and again (most systems write files non fragmented if they able to do so) Ha! would you believe that this part is 99% of work putted into this? Hashi (Japanese for bridge, inspired by IBM's "southbridge" word) is ... a bridge with co-processor:) I always wanted to make my own asymmetric multiprocessing computer - there are synchronization primitives between 6502 & xmega, those cpus waits for each other, can compute in parallel... just enough stuff for a nerd like me So briefly it works like that: [6502 & xmega] - player is loaded into atari (i spare details how) - as FAT32 is seen via CIO (yay! Atari engineers) player opens file via CIO OPEN (yes, you can open 0.5GB file from Atari Basic) - reads some metadata (header contains information about movie - in yt example Dire Straits are APACi, Bad apple is Graphics 8 for hires resolution - i can build fancier display lists too (more than one per movie)) - closes file (but hashi know which file was opened last, remember) [6502] - notifies hashi via register ("ok stream at me") - switches Antic in desired display list, begins playing black frames (this is seen on yt) [xmega & Antic] - xmega detects that antic wants data, sync with frame begin, data begins to flow into antic [6502] - detect data, oh it's first frame select first display list, data is shown.. ... and this is pure magic even for me:.... [6502 & xmega & Antic] Those three processors are now fully synced, they share common clock - no need for other syncing. They are working cycle after cycle, carefully programmed, xmega manifest data just in time for antic to show it, other data - just in time in order to be read via 6502 and pushed to POKEY (every scan line) Metadata for HAI format can be added without breaking existing files, It easy to image "audio format entry" - there isn't any now, so default will always be 8bit pdm 31k, but some files could switch this into 15k stereo, maybe 4bit audio ? maybe 5bit audio ? all relative easy, but TIME speaking of time, big thanks for Your time - I really appreciate that someone watched my demos / read / write something here.

I wanted to be at SV with that. Dragons Lair was converted "by hand" (i manually queued scene sequence). However, this was done from my DVD (it can be played on DVD alone) - which means I could write automatic converter for all DVD based games. Firefox it's more complicated though... Yes, in theory I could overlay ugly PMG based missiles on Firefox footage, but this is a lot of work.

Original idea was "maximum compatibility & maximum performance via cartridge slot". It's more and more apparent that dropping ECI will actually increase compatibility... with number of Ataris. Yes the SIO will be little PITA, like: - move os rom to ram and patch it there (should work for older disc games) - during loading of xex, detect JSR SIOV and patch it on the fly to JSR HASHISIOV - patch some games by hand (the really bad ones wouldn't work with hashi anyway (which are doing serial communication by themselves) But I'm more a software developer than a electronic engineer, I'll welcome easier, smaller board with open hands. I'm open for questions/suggestions. This shouldn't be very pricey. I just knew that I can do transmission faster than ramdisk - and I HAD to do it. That's why xex/dos parts are more sophisticated than the video player which I programmed 6 months before SV (being inspired via PDM). I only pity that it took soo long (http://www.atari.org.pl/forum/viewtopic.php?id=5522 - but I learn a lot electronic along the way) If you look up wiki https://pl.wikipedia.org/wiki/Dragon%E2%80%99s_Lair It's '83... This is SICK. We had VHS in '90 here, '83 for me is more about "our family first color TV " I just had to honor this on Atari, and honor Antic itself - marvelous gem.

As shown on Silly Venture 2018. Hashi is an experimental high throughput cartridge for stock Atari 8 bit. It uses EPM3064 & ATxmega192D3 + SD card. Dos like features: - Loading xex is at least about 200KB/s (more with Antic off). - some CIO & SIO support (SIO via ECI but i'm going to drop this - pure cartridge only is a new target) Streaming API features: - Video: 352x239 (gr8) 50 FPS, timed directly into Antic. - Audio: 31khz mono 8 bit PDM audio timed to 6502 which writes to POKEY (Thanks kool kitty89)) - HAI format supports RIFF like metadata with Atari video settings and index. - gapless stream sequencing - all directed from Atari (yes this is interactive and playable - not everyone on SV noticed, which makes me very happy:P) And of course, some classic: https://youtu.be/kXNTymTJfSk?t=124 This sums to over 0.5MB throughput. I remember when I saw SIO2SD first time... it was soo slow, so I have made mine

Horizontal could be selectable too Narrow screen comes to mind. 3d window has exactly that width.Should be not hard to do it - i wonder is it worth though? any insights? "cockpit details off" option, as it would strip 2d borders. But don't get me wrong - i'm not nitpicking, I'm amazed, but even more - THANKFUL . EDIT - heh... it's already that way I suppose:) PMG as borders...

I so glad that this got ported! This is Atari at it's bests - no sprites, just raw computing power! I'm speechless. This feels better that my birthday party... thanks!!!!! - popped in my head

When I saw a "rotating 3d perspective preview" I thought it's super nice, even that he will be never able to add walking. What a small faith I was. It's awesome now - one of the best xmass present for me. I salute you!