Ta moja robota, to nie jest jakiś wielki geniusz, a raczej prowizorka - ale taka z cyklu, że raz zrobiona i służy na zawsze, bo nikt nie zrobi tego później już nigdy profesjonalnie skoro działa:-) Coś jak przytwierdzenie czegoś co luzem latało trytytką - i jest już na wieki:-) No a wcześniej nie działało, więc jest lepiej niż było, nie? :-)

Z przerabianiem na większy procek to nie taka pojedyncza sprawa. Tzn. oczywiście z tej samej rodziny procek jak by wziąć i po prostu przerobić, to by się dało w miarę jako-tako, ale wydaje mi się, że nie ma to sensu, bo obecna wersja jest na PIC16F876, który kosztuje z pięć dych, no to większy procek z tej rodziny był by jeszcze droższy, a cały czas jest to PIC, za którymi nie przepadam i nie umiem. Gdybym miał to przenosić na inny procek, to już wolał bym pójść w kierunku jakiejś Atmegi, które lubię i umiem programować, bo kiedyś dużo się nimi bawiłem. Jednak idąc jeszcze dalej, obecnie są inne rozwiązania emulujące IKBD np. na pi pico tutaj: https://github.com/fieldofcows/atari-st-rpikb
Dziś są te wszystkie pi zero, pico, esp32, to są procki znacznie mocniejsze, a kosztują kilkanaście zł a nie kilkadziesiąt. Taki projekt jak Eiffel jest na tyle duży, że łatwiej było by to zrobić na mocniejszym procku, gdzie można to wtedy zaprogramować sobie w języku wyższego poziomu, co uprościło by modyfikacje, łatwość i szybkość programowania. No po prostu czasy się zmieniły.

Inna sprawa, że do obecnych zastosowań interfejsu Eiffel, ten procek który tam jest, jest wystarczająco mocny, ale projekt jest już blisko sprzed 20 lat (ostatni firmware pochodzi z 2005 roku). Projekt z jakichś względów stanął wtedy w miejscu, a dziś z tego co wiem nie ma też żadnego kontaktu z autorem, bo są osoby, które próbowały coś tam do niego wysyłać i nie było odpowiedzi, więc ja nawet nie próbowałem. Na stronie Eiffla obecny firmware ma oznaczenie 1.10, przy czym jest informacja jeszcze że autor pracuje nad wersją firmware, którą oznaczał 2.0 i zapowiadał, że będzie wymagała zmian sprzętowych, bo chce zmienić taktowanie procka z 4MHz na 8MHz. Motywował to tym, że czasami gubią się ramki w transmisji danych, bo są jakieś specyficzne sytuacje gdzie się to nie wyrabia. Druga rzecz, że jest tam też podane, że są jeszcze funkcje IKBD, które nie są obsługiwane, więc możliwe, że też było by to jeszcze dopisane w kolejnych wersjach. W procku były wolne banki pamięci, więc autor miał tam pole do manewru jeszcze dość spore jak mi się wydaje.

Tak jak mówię: przepisanie tych 6tys linii kodu w assemblerze PIC-a na inny procesor było by na tyle trudne i czasochłonne, że chyba szybciej było by to napisać od nowa, tak jak zrobił to np. autor wspomnianego wyżej rozwiązania na pi pico.
Nie wiemy też jakie jeszcze ewentualnie poprawki były by konieczne w Eifflu, ja trafiłem na ten kłopot z fire, ale może są jeszcze inne problemy wymagające poprawek? Możliwe, że autor Eiffla planował jeszcze jakieś inne ulepszenia, no ale wiemy tylko tyle ile wiemy. Na tym etapie osobiście nie mam innych potrzeb dot. Eiffla ponad tą jedną poprawkę, którą tu zrobiłem.

Ile osób na świecie ma MapRAM?

Ten kopier, którego ja miałem pamiętam że pozwalał na wybór 600/900/1200 bodów. Pamiętam to dlatego że 900 bodów działało mi bez problemu zawsze, a 1200 bodów jak zapisałem taśmę, to był problem z odczytem tego później. Niestety nie pamiętam nic więcej na temat tego kopiera, którego miałem, ale tak jak mówię, może znajdę go na jakiejś kasecie, choć najpierw muszę same kasety w ogóle znaleźć:-)

No to przy wolnej chwili poszukam starych kaset i zobaczę co tam na nich zostało. Ten Crumbles Crisis pamiętam dość dobrze, bo bawiłem się wtedy w przyspieszanie transmisji i jakiś kopier miałem, który pozwalał kopiować z prędkościami zapisu innymi niż 600 bodów. Robiłem wtedy testy na moim XC12 i bez problemu wszystko mi się wczytywało w 900 bodów, więc tak nagrywałem później sobie kasety i na pewno tak też nagrałem ten Crumbles Crisis. Poszukam.

O, to mnie zaskoczyłeś tym znaleziskiem Cyprian:-) Na oko wygląda, że tam wszystko jest, ciekawe czy kompletne i czy działa:-) No tylko tak... ja nie umiem tego zebrać do kupy i skompilować na jakiś konkretny scalak, ani też nie umiem tego testować:-) Podejrzewam więc, że przysłowiowy Kowalski z lutownicą, też z tego sobie nie wybuduje kontrolera do FDD... Trochę bawiłem się xilinx ise, ale mój szczyt tego co wyprodukowałem obejmował kartridż do małego Atari, po czym skończył mi się wolny czas na tą zabawę:-) Ten projekt kontrolera WD jest znacznie większy niż drobiazgi które sobie dłubałem...

Podzielam opinię tOriego. Akurat na dniach poskładałem sobie ST ATX na płycie od x_angela, tam mam "prawdziwe" scalaki, kupę pinów do wszystkiego, scalaki w podstawkach i teraz taką górę pomysłów na rozbudowywanie tego, że aż nie wiem co robić najpierw. Ja oczywiście rozumiem, że fpga to bardziej "prawdziwy" sprzęt niż emulatory, ale w takiej formie to dla mnie bez różnicy czy to ST jest w fpga, czy bym sobie jakiś emulator odpalił. Kiedyś się tymi wszystkimi nowymi projektami tego typu zachwycałem, ale dziś kompletnie nie wiem do czego mogło by to służyć. Nie daje ani ducha zabawy w retro, bo to nie retro, ani nowoczesnego sprzętu do współczesnych zastosowań, bo przecież nikt na takim Atari nie będzie robił niczego poważnego i współczesnego. Ot ciekawostka i może frajda dla kogoś kto to implementował, ale dla użytkownika to moim skromnym zdaniem projekt do niczego nie potrzebny i nieprzydatny.

Cyprian, ale z tymi przyciskami myszy, to nie jest że gry nie ogarniają, tylko Eiffel nie ogarnia. Standardowo sprzętowo w Atari połączony jest na sztywno prawy przycisk myszy i fire w drugim porcie joya. W oryginalnym Atari bez względu na to czy wciśniesz prawy przycisk myszy czy fire w joy w drugim porcie, to dla Atari nie robi różnicy, bo to jest ten sam przycisk fizycznie. W Eifflu natomiast zostało to rozdzielone, a nie do końca obsłużone i dlatego są kłopoty.

A taki "tryb zgodności" jak piszesz, to dało by się zrobić jako jakiś program rezydentny, który by w grach ten fire dodatkowo z prawego przycisku myszy czerpał? Jeśli tak, to by też rozwiązało problem dla wszystkich gier od razu.

Z obrazem właśnie nie jest tak jak piszesz, bo przerwania generowane są odrębnym zegarem. Jak zmieniamy podstawowy zegar, to ilość linii się nie zmienia, ilość ramek na sekundę też nie, natomiast zmienia się ilość cykli procesora w linii. I z tego robią się problemy z tzw. docyklowanymi demami, gdzie programiści przewidzieli, że mają określoną ilość cykli, a jak dajemy minimalnie wolniejszy zegar, to tam się robią jakieś pojedyńcze cykle w linii mniej, zaczyna ich brakować i program się sypie.

No chyba, że coś źle zrozumiałem, ale z moich obserwacji wynika, że tak właśnie jest.
Jak budowałem teraz generator z kwarcem z płyty oryginalnym, to potwierdziło się to co mówię. Kwarc przez przypadek wzbudzał mi się na niższej częstotliwości (3x niższej, bo to kwarc tzw. overtonowy i trzeba go odfiltrować, żeby wzbudzał się na 3x wyższej częstotliwości, co już naprawiłem nawiasem mówiąc). No i jak się kwarc wzbudzał na 3x mniejszej częstotliwości, to obraz wyglądał jak na załączonym zdjęciu. Ilość linii obrazu, częstotliwości przerwań synchronizacji poziomych i pionowych się zgadzają, bo inaczej obrazu by w ogóle nie było na monitorze. Natomiast zawartość leci trzy razy wolniej, przez co jest wszystko trzy razy większe i oczywiście jest dodatkowo bajzel. Startujące na tym zdjęciu Atari nie uruchamia żadnych procedur synchronicznie do przerwań, więc nic się nie wysypuje, a komputer normalnie wstaje, tylko wyświetla to co wyświetla. Jednak jak w demach jakieś procedury mają się odpalać zgodnie z przerwaniami, to zaczyna się to sypać, bo procedura nie zdąży wykonać się w całości przed wystąpieniem następnego przerwania.

Jakąś podobną wtyczkę miałem w jednym z pierwszych aparatów Kodak. Też taka mała i też 4-pin. Mój brat miał inny model Kodak, jakiś następny, ale w tym samym roku i miał tam też taką małą wtyczkę z 4-pin, ale miała inny kształt i już nie pasowały nawzajem do siebie te kable do tych aparatów. Z pewnością to jest od jakiegoś aparatu, kamerki, mp3, albo jakiegoś starego telefonu.

Dziś testów ciąg dalszy nastąpił.

Zacząłem od zbudowania sobie generatora kwarcowego, żeby odpalić płytę na tym kwarcu oryginalnym z ST (32.084988 MHz) zamiast standardowych 32MHz, który to miałem do pierwszych testów.
Od razu napiszę, że różnica jest taka, że ów demo co mi się zawieszało, to się przestało zawieszać. Poza tym jakichś wielkich różnic nie zaobserwowałem, obraz nie przesunął się i na oko ma takie same rozmiary na obu generatorach. Gry, które testowałem działały na obu kwarcach w zasadzie tak samo. Krótko mówiąc generator 32MHz z grubsza spełnia swoją rolę i można tak Atari odpalić. Pewnie z czasem powychodziły by jeszcze jakieś niuanse i ograniczenia, ale do zastosowań ogólnych 32MHz daje z grubsza radę. Niemniej jednak skoro już mi się udało zbudować i uruchomić generator na oryginalnym kwarcu Atari, to taki zostaje w mojej płycie.

Obejrzałem 10 długich dem z czołówki najlepszych i wszystko działa chyba dobrze.

W kwestii Eiffla podszedłem do tematu dzisiaj raz jeszcze z chłodną głową i postanowiłem precyzyjnie określić co działa, a co nie.
Na spokojnie przetestowałem to i owo, i generalnie urządzenie jest fajne, ma jakieś tam drobne niedogodności, ale ogólnie jeśli chodzi o mysz i klawiaturę, to działa bardzo dobrze.
Problem jest tylko z joystickiem, ale w gruncie rzeczy kierunki też działają bardzo dobrze, więc jedynym poważnym problemem jest fire.

Dziś przetestowałem łącznie 30 gier i oprócz Prehistoryka trafiłem jeszcze na drugi hit, w którym też jest ten sam problem z przyciskiem fire. Chodzi o grę Gods.
W zasadzie to jest jedyny problem z Eifflem i jest powtarzalny w różnych grach. Nie działa w niektórych grach fire, ale jednocześnie działa on pod prawym przyciskiem myszy.
Firmware od Eiffla ma już blisko 20 lat, a na stronie jest info o planach kolejnej wersji. Co się stało, czy ktoś wie coś na temat autorów, albo dlaczego nie był ten projekt już dalej rozwijany?

W sumie kody źródłowe są upublicznione, a skoro fire działa pod przyciskiem myszy, to może dało by się jakoś łatwo zdublować fire, żeby działał razem z tym przyciskiem?
W sumie wystarczyło by po stronie odczytu joya zrobić tak, że jak się wciska przycisk fire, to on oprócz swojej obecnej akcji, powinien równolegle zapisać się tam gdzie zapisuje się prawy przycisk myszy, że niby wciśnięto przycisk w myszy. Podejrzewam, że jest to na jakiejś takiej zasadzie, że jest jakiś rejestr osobny dla myszy, gdzie zapisuje się stan przycisku, a osobny dla joya gdzie się zapisuje stan fire. Kiedy system odpytuje klawiaturę o stan myszy, to eiffel zwraca rejestr przycisku myszy, ale kiedy odpytuje o fire, to zwraca rejestr fire. Tymczasem oba te rejestry powinny przyjmować wartość zarówno prawego przycisku myszy, jak i fire z joya, bo oryginalnie w Atari te linie są fizycznie połączone ze sobą. Gdyby tak to zmienić to już było by dobrze wszystko.
Nie mam na to czasu, ale jeśli nikt nie zajmie się tym, to sam spróbuję pewnie kiedyś to zrobić, ale lata lecą coraz szybciej i istnieje ryzyko, że mogę nie dożyć tego momentu:-)

Okres wakacyjny sprzyjał trochę rozleniwieniu, a trochę zwyczajnie szybko zleciał nie wiadomo kiedy i ani się obejrzeliśmy a tu po wakacjach. Przez ten czas prace nad wydaniem Scorcha cały czas postępowały, ale przyznaję, że bardzo powolutku. We wrześniu wszyscy z ekipy wzięli się za robotę i idziemy do przodu. Powoli zbliżamy się do celu. Załączam zdjęcia z placu boju - elektronika kartridży jest już poskładana i trafiła właśnie w nowiutkie obudowy od Sikora.

Kto się jeszcze nie zapisał, a chciałby grę w formie fizycznej, to zapraszamy serdecznie, wyprodukujemy tyle egzemplarzy ile będzie potrzeba.