Cierpliwość jeszcze mam. Niestety moje Atari już chyba nie. Nie chce mi się zbootować z dyskietki zawierającej sterownik XEP80. Innymi słowy nie jestem w stanie go teraz uruchomić. Chyba dyskietka padła. Sorki, ale nie mając również działającego SIO2PC nie jestem teraz w stanie nic zrobić.

Chyba pomyliłem się tylko w prawym górnym rogu tego stworka.
Po tym drugim XIO znaki naprawdę dziwnie zaczęły wyglądać, może to być mylące.

@laoo
VS express nie ma MFC więc bym musiał hqx zrobić na osobną bibliotekę. W sumie wykonalne.
Nie wiem jednak jaki jest narzut tych pętli równoległych. W emulatorze trzeba co 1/50 lub 1/60 sekundy (a w turbo jeszcze częściej) wykonywać obliczenia. Jeśli te pętle korzystają z wątków techniką Thread Spawn, to narzut ich tworzenia może być znaczący.
Myślałem raczej nad zaimplementowaniem techniki Thread Pool. Przecież liczba potrzebnych wątków się nie zmienia.

@Fox
Nie doświadczyłem problemów z uruchamianiem emulatora po zainstalowaniu go. Raz w debugerze nie chciał mi sie uruchomić a też w liście procesów go nie było. Od tej pory nie używam opcji "Reuse emulator window". Powód może być podobny. Wtedy jeśli dobrze pamiętam on jakimś cudem znalazł na liście okien okno o nazwie Atari800Win no i nie chciał się odpalić.
Przerzucanie się na okno przeglądarki lub Worda po uruchomieniu jest spowodowane tym samym. To chyba stary kod jeszcze z win9x. Trzeba by wsadzić tam lepszą implementację rozpoznawania czy aplikacja jest już uruchomiona.

Przetestowałem emulator z włączoną i wyłączoną opcją PFUSIK_ASM i włączoną opcją turbo (na ekranie startowym Draconusa):
w trybie smooth wzrost z 2000% do 3200% po przełączeniu się z asm na C++
w trybie scan lines brak różnicy, ale tutaj obie wersje są w asm.

Myślę, że rozwój kompilatorów swoje jednak zrobił. Trzeba będzie wszystko przerzucić na C++.

Nie mam obecnie planów na przerzucanie emu na GPU. Nie znam się na tym i na razie nie mam zamiaru znać.

Zajrzyj na:
http://en.wikipedia.org/wiki/Hqx

Mam w planach wprowadzenie też wersji 3x i 4x.

Biorąc pod uwagę jak skomplikowany to algorytm...
Ciekaw jestem jak wydajnościowo wyjdzie wersja 4x :) Może trzeba będzie zaangażować kilka rdzeni?

W opcjach Performance możesz zmniejszyć częstotliwość odświeżania dla trybu fullspeed.

W trybie DirectX czy GDI?
Ale w sumie to się nie dziwię. Drobna odchyłka od 50Hz i cała synchronizacja leży.

Stworzenie tej gry jest w dalszym ciągu w planie. Tak jak stworzenie dema. I ewentualnie jednego dema w Turbo Basicu.
A na PC tylko emulator. Innych rzeczy nie planuję i nie mam nawet pomysłu.

Niestety obydwie komendy wywołują u mnie zwis kompa na tyle mocny, że zwykłe wciśnięcie reset powoduje zimny start.

A co ma za znaczenie co jest w tym mitycznym wierszu 25 skoro znajduje się on około 3cm poniżej dolnego poziomu ekranu?

Rozebrałem mojego XEPa. W środku nie zauważyłem nigdzie napisu PAL, ale to nie musi o niczym świadczyć.
Na płytce jest napis XEP80 C070900 REV.D, co ciekawe na kwarcu jest podobny napis:
C070930-1
12.000
UNI 87-E

Jeżeli faktycznie XEP jest programowo przełączana, to może jest wybór pomiędzy trybami 10-11-12. Czy oprogramowanie które mam do XEP jest różne od wersji amerykańskiej? Może inne oprogramowanie włączy inny tryb?

Owszem, linia 11 i 12 są identyczne z 10 w każdym znaku który sprawdzałem. Dziwacznie przez to wyglądają ukośniki. Szerokość znaku to 7 punktów. Ekran ma 24x80 znaków z czego 2 linie są kompletnie niewidoczne a w 2 krańcowe znaki wychodzą już na rogi monitora.

Nie jestem elektronikiem i nie potrafię rozpoznać taktowania nawet gdyby wyskoczyło na mnie z krzaków i kopnęło w tyłek. Trzeba uderzyć do Electrona, on też ma to dziwo.

Proporcjami ekranu bym się nie przejmował skoro to ustrojstwo generuje tak wysoki obraz, że trzeba przestrajać monitory aby to używać. Widziałem kiedyś XEPa podłączonego do monitora mającego pokrętło regulujące odstęp pomiędzy skanliniami. Dało się go wtedy używać, ale zmieniając proporcje ekranu.

A no w sumie tak, przecież trzeba przepisać kolory z powrotem. Dzięki.

Z tego wszystkiego posiadam w domu tylko XEP80. Więc pewnie za to się zabiorę najpierw. W ogóle to idiotyczne urządzenie i chyba nigdy go nie użyłem.
A co do SYNCHRONIZED_SOUND to obecnie badam problem. Chyba tylko port SDL tego używa, ciekawe czemu?
W ogóle zamieszane to wszystko. Zamiast korzystać z dotychczasowych funkcji trzeba ręcznie przepisać dane z bufora. Dziwne to wszystko.

Pewnie na tym się skończy :) Ale na razie w 4.1 nie planuję przełomowych zmian.

Witam,

Ale się miło kłócicie, aż fajnie popatrzeć :)

No to teraz kilka słów wyjaśnień ode mnie:

Atari800 jest emulatorem tworzonym od wielu lat przez wielu ludzi. Może wygląda on na zaśmiecony, ale z całą pewnością jest mniej zaśmiecony niż jakieś 6 lat temu. Obecnie ma on czystą strukturę: główny emulator + funkcje specyficzne dla platformy. Problem w tym, że struktura Atari800Win to: funkcje specyficzne dla platformy (interfejs Atari800Win) + główny emulator. Ta zamiana ról powoduje, że nie da się od tak po prostu użyć funkcji z atari800, potrzebne są zmiany, ale do tego wątku jeszcze wrócę.

Mam ogromny podziw do Phaerona, który startując od zera uzyskał w kilka lat porównywalny poziom emulacji atari jak wielu twórców atari800 przez znacznie większy okres czasu. Tyle, że nie widzę związku dlaczego rozwój Altirry miał mieć jakiś wpływ na Atari800Win. Sugestia, że jeśli przestałbym pracować nad Atari800Win to pracowałbym nad Altirrą jest śmieszna. Przede wszystkim nie sądzę aby Phaeron potrzebował mojego wtrącania się do jego kodu. Co ciekawe (jak ktoś czytał wątek na atariage ten wie), to właśnie Phaeron zdebugował i znalazł błąd w jednej z beta wersji Atari800Win. Czyli również on nie uważa, że powinien być tylko jeden jedyny zatwierdzony emulator Atari pod Windows.

Ustalmy sobie jedno. Emulatorami atari są takie emulatory jak: Altirra, atari800, Atari++ i inne. Atari800Win jest czymś w rodzaju spin-offa atari800. Realizacją pomysłu stworzenia emulatora atari800 z interfejsem znanym z Windows. Specyficznego projektu, ponieważ prawie zawsze rozwijanego przez 1-2 osoby (pomimo bycia GPL). Obecnie również ma on 2 developerów. (I pomimo iż drugi jest prawie niewidoczny, to bez jego rad nie dałbym rady zbudować wersji 4.1.)

Atari800Win polega mocno na kodzie atari800. Swego czasu mocno pracowałem z Foxem aby to połączenie uczynić silniejszym. Dzięki jego staraniom udało się doprowadzić do tego, że Atari800Win kompilował się bez przeszkód z dowolną wersją atari800. Skutki jego działań są widoczne obecnie. Po 6 latach jedyne zmiany jakie musiałem dokonać w Atari800Win aby się kompilowało z atari800 to:
-zmiana nazw zmiennych
-zmiana kilku #ifdefów
-zmiana obsługi generowania palety kolorów
niewielkie zmiany jak na 6 lat pracy trzeba przyznać.

Obecne widoki na przyszłość można opisać tak:
-Altirra, Atari++ i inne będą wydawane jak ich autorom się zechce pracować,
-atari800 wciąż będzie rozwijane przez grupę jego twórców.

A co zrobić z Atari800Win? Nie mam ochoty wtrącać się w pracę innych developerów. Phaeron pewnie niechętnie widziałby wtrącanie się do jego kodu. Nie mam również ochoty tworzyć atari800 bo nie znam się na emulacji Atari.

Mogę więc robić 3 rzeczy:
-Stworzyć międzyplatformowy interfejs dla arari800 oparty o wxWidgets. Oznacza to jednak pisanie właściwie wszystkiego od nowa.
-Zintegrować Atari800Win z atari800 na takiej samej zasadzie jak inne porty (jak np. SDL). To też jednak oznacza przepisanie większości Atari800Win od nowa.
-W dalszym ciągu rozwijać Atari800Win w jego obecnej postaci.

Ta ostatnia opcja oznacza, że przy każdej nowej wersji atari800 trzeba będzie dopasowywać Atari800Win do atari800. Jak jednak pokazałem wcześniej nie jest to aż takie straszne. Byłoby oczywiście miło, gdyby autorzy atari800 zaakceptowali moje patche do atari800. Nie psują one nic w ich kodzie a mi ułatwiają pracę na przyszłość. Ale jak nie, to nie. Nie ma problemu. Czas potrzebny na utrzymywanie nowych wersji Atari800Win jest i tak wciąż mniejszy niż tworzenie nowych wersji emulatora (WX czy innego). A ponieważ czasu mam mało, to nie mam wyjścia. Albo będę raz na jakiś czas wypuszczał nową wersję Atari800Win opartą nowy kernel atari800 (mam nadzieję tylko, że częściej niż do tej pory), albo nie będę robił nic. (No w sumie to mi jeszcze pozostaje zrobienie ostatniego dema.)

Nie oczekuję, że twórcy atari800 będą utrzymywali kod Atari800Win. Chociażby z powodu nieposiadania kompilatora VC. Sam jednak fakt, że części Atari800Win znajdują się w atari800 wielce pomaga w pracy. Z reguły bowiem programiści nie usuwają bez potrzeby #ifdefów nawet jak ich istoty nie rozumieją. Mogę co każdą wersję podsyłać zmiany jakie musiałem dokonać w atari800 aby Atari800Win się budowało (tak wyglądała moja współpraca z Foxem). Przynajmniej nie będę musiał drugi raz nakładać tych samych zmian. (A patch nie zawsze działa, zależy ile w oryginalnym kodzie jest zmian.)

Nie wiem jakie super funkcje ma Atari800Win, które powinny niby się znaleźć w atari800. Co do odtwarzania dźwięku to zaprzeczam, nie ma w nim nic, co by zmieniało emulację dźwięku. Zresztą przecież wszystko jest opensource. Można kopiować co się chce. Swoją drogą dziwię się, że nikt przez 6 lat nie zrobił własnego buildu. Widać nie było to aż takie niezbędne do życia. Przeceniacie rolę Atari800Win.

I na razie tyle. Idę spać.

P.S. Coś się chrzani w emulacji w NTSC przy DirectSound (i chyba nie przy WaveOut, ale nie mam jak sprawdzić bo mój domowy komputer nie odtwarza WaveOut, tylko DirectSound, dziwne nie?), ale już mi się nie chce tej nocy debugować.

P.S.2 Pierwsze przykazanie: piłeś, nie pisz.

P.S.3 Umieściłem już beta 5 na githubie.
Tym razem dodałem też pełny instalator. Można sprawdzić czy działa.
Zmiany w tej wersji:
-Przypomniałem sobie, że trzeba dokompilować patch dla drukarki.
-Drobne poprawki w monitorze.
-Zwiększony bufor DirectSound, dzięki czemu w trybie NTSC działa płynnie nawet przy latency 2.

Hejka, witam ponownie :)

Wrzuciłem już na githuba 4 betę, jak nie będzie narzekań, to już wkrótce wypuszczę oficjalne 4.1.

Muszę sobie tylko przypomnieć jak się logowało aby wrzucać pliki na stronę emulca. Ktoś wie do kogo powinienem się zwrócić o instrukcje? Dely a może Krap?

Zmiany w beta 4:
-Poprawiony (chyba) błąd wywalający emulator w oknie wyboru folderu.
-Włączona opcja SYNCHRONIZED_SOUND w atari800. Podobno to robi bardziej dokładny dźwięk, ale ja tam nie słyszę różnicy.
-Poprawki w synchronizacji pracy emulatora w trybie DirectSound. Może to trochę zmniejszy trzaski dźwięku?

Tryb fullscreen używa starych trybów paletowych (256 kolorów) jeśli dobrze pamiętam. Cud, że to jeszcze działa. Ja ich nie używam, bo mi się emul zwiesza. Całość kodu na ten temat jest do przepisania.

@syscall
A kiedyś tak mówili o Atari800Win :)

Chociaż trzeba przyznać, że Arai800Win cierpi na chorobę starczą. Są w nim rzeczy z 95 roku. Najlepszą rzeczą byłoby wywalić go całego i napisać wszystko od nowa. Tyle, że to właśnie zrobił phaeron z Altirrą :)

Jedyne co ja mogę zrobić, to stworzyć możliwie najlepsze GUI do atari800.