Kolejne pytanie czy bez tego PICa działają pady ? Podłączyłem stację dyskietek i ładnie załadowało grę na starym i nowym tosie, ale brak rekacji na pady :)

O sorki, przegapiłem wątek :)
Tak jak Mq pisze: PIC odpowiada za obsługę myszy, klawiatury i portów joysticków. Był problem z dostępnością tych PIC-ów ale pojawiły się już na Aliexpress w rozsądnych cenach.
Za to znikły generatory 32.084988Mhz, ale dzięki testom przeprowadzonym przez Mq wiadomo, że można odpalić na 32MHz :)

A oto krótka relacja z budowy mojego egzemplarza: tydzień czasu w praktycznie wszystkich wolnych chwilach lutowałem to wszystko i wylutowywałem scalaki z płyty dawcy. Spodziewałem się, że na początku nic się nie uruchomi, potem będę szukał błędów i miał z tym jeszcze kupę dobrej zabawy, ale niestety zabawa skończyła się nader szybko, bo po złożeniu całości odpaliłem kompa i od razu wstał, i wszystko w nim działa.

Drobne niuanse i podpowiedzi:

Tak jak pisał wyżej x_angel, nie miałem generatora takiego jak kwarc w ST, więc na pałę dałem zwykły 32MHz. Na takim kwarcu wszystko działa, odpalają się programy, odpalają się gry i dema. Czytałem gdzieś na forum zagranicznym, że jak się da inny kwarc niż być powinien, to się może coś tam wywalać w tzw. "docyklowanych demach", bo tam przypada inna ilość cykli w linii, czy tam inna ilość cykli w stosunku do cykli zegara od RS232, a stamtąd jest też pobierany czas do jakichś obliczeń czy coś... Nie znam się na tym:-). Ale faktycznie np. w demie Execute komputer zawiesza się w połowie dema na jakimś efekcie i widać jakieś linie obrazu wyjeżdżające na ramkę, tak jak by tam włąśnie coś się nie zmieściło czy coś... Muszę to jeszcze dokładniej przetestować z ciekawości, ale oczywiście tak czy owak generator 32MHz dałem tymczasowo, a zamierzam zbudować generator na kwarcu wziętym z płyty dawcy pozostałych części, więc będzie wszystko tak jak było w oryginale i powinno wszystko śmigać dobrze wtedy.

Pamięci dałem KM416C1200J-7. Co ciekawe te pamięci waliły błędami w Amidze, która potrzebowała EDO, a te się nie nadawały. Myślałem że są uszkodzone, ale nie wyrzuciłem i zostawiłem je. I bardzo dobrze:-) Pamięci, które działają w Amidze 500, nie chcą działać w Atari, a te które w Amidze nie działają, to z kolei w Atari działają elegancko. Moje o których mowa, chodziły w yaart sobie na testach przez kilkadziesiąt powtórzeń i nie pokazały żadnego błędu.

Mała podpowiedź dla tych, którzy tak jak ja nie mają WD1772, a nie chcą korzystać z FDD  jest on im niepotrzebny. Jeżeli będziemy korzystać tylko z IDE (w moim przypadku karta CF), to można oszukać bardzo łatwo Atari. Atari odpalone bez układu WD1772 nie pójdzie, wywali dwie bomby i koniec. Wystarczy zamiast układu w podstawce zewrzeć razem piny 27 i 28, oraz podłączyć je oba do pinu 14. Wymyśliłem to już dawno temu i korzystałem wielokrotnie z tej metody, bo WD jest deficytowy, a ja i tak zawsze używam czegoś na ACSI, albo na IDE.

I jeszcze jeden hint. Na płycie ATX jest zrobiony przełącznik TOS-ów 1.04/2.06, który wykorzystuje trzywejściowe bramki AND układu 74LS11. Nie miałem akurat takiego układu, ale wymyśliłem jak bez niego zrobić tymczasowe obejście łatwo. Użyłem układu 74LS08, który miałem pod ręką. Wystarczy odgiąć mu nogi 3,11,12 i można go wsadzić zamiast 74LS11. W takim wypadku trzeba zworki obie na płycie przestawić w pozycję TOS 2.06 i tylko z tego TOS-u można skorzystać, ale da się tak łatwo odpalić już komputer nie mając tego jednego układu. Przy okazji sobie tam podmienię jeszcze ten układ, albo może i nie:-)

Co jeszcze... Przetestowałem IDE, działa dobrze, przetestowałem pamięć, jest ok, przetestowałem interfejs eiffel z klawiaturą i myszą PS/2 oraz wejścia joysticków, wszystko działa ok. Odpaliłem kilkanaście gier różnych i wszystkie działały poprawnie. Odpaliłem dwa dema, jedno  zadziałało, drugie się zawiesiło w połowie, jak pisałem już wyżej.

W następnych krokach planuję wykonać generator z kwarcem z mojej płyty Atari-dawcy. Moja płyta była akurat w wersji PAL, jest tam kwarc 32.084988MHz. x_angel dawał generator bodajże 32.04245MHz, ale on miał układy w wersji NTSC i tam był właśnie taki kwarc dawany.
Dalej będę jeszcze przeprowadzał większą ilość testów dem i gier, muszę jeszcze też uruchomić midi.
Następnie jak stwierdzę, że wszystko działa dobrze, to zabiorę się za odpalenie STGA. Mam już sprawną kartę ET4000, któr ą przetestowałem w starym pececie, więc mam na czym działać.
Jak mi się uda to odpalić wszystko, to dalej pomyślę nad jakąś dopałką, może jakiś Alt-RAM dołożę, zobaczymy.
Aha, no i jeszcze jakaś obudowa będzie rzeźbiona itd. W każdym razie mam zabawy na kupę czasu:-)

Tu ktoś dociekał o co chodzi z tymi różnymi kwarcami na różnych płytach ST: https://forums.atariage.com/topic/35376 … y-choices/

A tu jest wątek obszerniejszy o tych zegarkach na forum exxosa: https://exxosforum.co.uk/forum/viewtopic.php?t=1139

Z tego co tam czytałem, chodzi o to, że układ MFP (MC68901) jest odpowiedzialny za obsługę przerwań, a on ma wbudowane swoje timery, które są taktowane oddzielnym kwarcem 2.4576MHz, który jest na płycie. Te kwarce, które są oryginalnie na płytach głównych, są tak dobrane, żeby było wszystko zgodnie z projektem całego komputera i żeby obraz miał określoną szerokość i na linię przypadała określona liczba cykli procesora. Jak dajemy wolniejszy kwarc, to np. na linię obrazu mamy troszkę mniej cykli procesora, a wiemy że w demach nieraz dla osiągnięcia jakichś efektów programiści wciskają się na styk z rozkazami wykorzystując wszystkie cykle na styk. Przy wolniejszym kwarcu to się po prostu nie zmieści i niektóre dema się wysypią.
Drugi aspekt jest taki, że przy wolniejszym lub szybszym kwarcu cały obraz na ekranie przesuwa się lekko w lewo lub w prawo, a obraz robi się minimalnie węższy lub minimalnie szerszy, bo piksele w linii są wyświetlane ciut szybciej, lub ciut wolniej niż następują przerwania związane z przejściem plamki do kolejnej linii ekranu.
Tak mi się przynajmniej wydaje, można by spróbować porównać sobie obraz przy kilku różnych generatorach, ale ja akurat nie mam żadnego innego do porównania... Jak zbuduję generatorek z tym oryginalnym kwarcem, to porównam z tym 32MHz, który mam teraz.

Na 32MHz wysypuje mi się demo Execute po około 5 minutach, zawsze w tym samym miejscu, przy czym zaczyna się to tak, że latają poziome linie śmieci, co wskazuje na jakiś bałagan w przerwaniach, jak by zaczynała uciekać synchronizacja, a za chwilę następuje zwis całkowity i śmietnik na ekranie. Myślę, że to jest problem właśnie dokładnie tego co opisałem powyżej.
-------------------

Gniazdo zasilania dodatkowe faktycznie się przydaje:-) Bardzo łatwo jets to testować ze zwykłym zasilaczem. Nie mierzyłem ile pobiera prądu ST, ja uywam na razie zwykłego wtyczkowego zasilacza 5V/2A i jakoś działa. Docelowo zastosuję dedykowany zasilacz jakiś i skorzystam ze złącza zasilania ATX.
-------------------

Z tym midi sprawdzę za jakiś czas o co chodzi. Widziałem ten opis fixu, który podlinkowałeś od tamtego gościa, ale trochę nie rozumiem dlaczego oryginalny transoptor nie działa. Z tego co patrzyłem, to układ wyprowadzeń jest chyba taki sam, tylko oryginalny transoptor ma podwójny tranzystor chyba w układzie Darlingtona, a ten zamiennik, który koleś tam zaproponował ma pojedynczy tranzystor. Nie wiem, trzeba sprawdzić, może on po prostu miał oryginalny transoptor uszkodzony i dlatego poszukał zamiennika?

Dzięki Cyprian za precyzyjne info.

Dzisiaj potestowałem trochę gry. Generalnie wszystkie działają (przynajmniej te, które testowałem), ale mam pewną zagwozdkę z tym interfejsem Eiffel. Nigdy wcześniej tego nie używałem, więc może nie wiem jak to obsługiwać, może to ma jakieś funkcje zaszyte, albo jakieś tam prawidłowości, albo coś automatycznie sobie konfiguruje, albo coś? Ale w czym rzecz: mam kilka przypadłości z tym interfejsem i nie wiem czy to tak ma być, czy coś jest nie tak, czy co.

1. Od czasu do czasu (rzadko) zdarza mi się, że jak wcisnę jakieś klawisze, to tak jak by się zapamiętały w jakimś buforze i potem np. jak odpalam jakiś program, czy grę, gdzie jest "naciśnij dowolny klawisz", to jakby z automatu naciska się "dowolny klawisz". Czasem jest tak, że tylko jeden raz się to dzieje, ale czasem jest tak, jak by jakiś klawisz był cały czas wciśnięty już na stałe. Czasami dzieje się to nawet pod GEM-em, wtedy słychać dźwięk wciskanego cały czas klawisza, a jak się powciska trochę klawisze różne na klawiaturze byle jakie, to za chwilę się to naprawia.

2. Czasami po odpaleniu różnych gier, programów, pracy dłuższej, nagle zauważam, że na klawiaturze migają regularnie z prędkością 1-2 razy na sekundę diody dwie (chyba numlock i capslock). Wszystko wtedy działa nadal niby normalnie, ale migają te diody i to jest takie wolne cykliczne miganie, jak by to jakaś opcja była czy coś, dlatego pomyślałem, że może się coś jakimiś kombinacjami klawiszy konfiguruje w tym eifflu? Niestety nie wiem co wciskam, żeby się tak stało. Dwa razy mi się tak zdarzyło, ale nie wiem jak to zrobiłem...

3. Używam myszy na PS/2, w porcie joysticka 0 nie mam nic wpiętego, a w porcie 1 mam joystick. Gram w różne gry i joystick działa zarówno jeśli chodzi o kierunki, jak i jeśli chodzi o fire. Ale jest jedna jedyna gra Prehistoryk, w której nie działa mi fire w joysticku. Wciskam ten fire, a on nie robi nic (powinien walić maczugą). A kierunki działają normalnie i chodzić postacią można. Ciekawe jest dodatkowo to, że jak wcisnę prawy przycisk myszy, to działa maczuga. Bardzo dziwne... W Atari normalnie jest tak, że fire od joysticka i prawy przycisk myszy, to jest fizycznie ten sam przycisk, więc powinna działać maczuga zarówno na ten prawy przycisk myszy, jak i na fire. A tu na myszy działa, a na joyu nie. A przypominam, że fire w joyu działa poprawnie we wszystkich innych grach, które testowałem (około 20 różnych gier). Jest jeszcze taki program Putnika do testowania joya i myszy, i w tym programie Putnika mam taki sam problem, że ten fire nie działa. Z tego co pisał Putnik na jakimś forum, to ten program używa jakichś funkcji systemowych do odczytu joya i myszy, a nie komunikuje się bezpośrednio ze sprzętem. Może większość gier komunikuje się inaczej bezpośrednio ze sprzętem i wtedy to działa, a Prehistoryk może wykorzystuje funkcję systemową też? Może to kwestia TOS-u? Używam tylko 2.06. Zmierzam do tego, że może eiffel nie obsługuje jakiejś funkcji czy coś? A w ogóle @x_angel: jakiej wersji firmware do eifla używasz?

Wrzuć tego Prehistoryka do załącznika, to może jakoś sprawdzę. Wczoraj chciałem sprawdzić demo Execute na MegaST, którą świeżo nabyłem. Ale okazało się, że ma TOS 1.02 i 1MB ramu więc oczywiście ją rozkręciłem. W środku znalazłem jeszcze emulator PC :) No i tak zacząłem grzebać i wszystko rozgrzebałem, a nic nie sprawdziłem :)

Ten Eiffel tak ma na teście, jak napisałeś. Nie wiem, czy to jest poprawnie czy nie. Ogólnie w grach działa ale mogę obadać tego Prehistoryka. Mogę sprawdzić na Medze z oryginalną klawiaturą i z Eifflem.

Używam firmware eiffel_i.hex i to jest 1.10

Aha, do Eiffla jest w ogóle jakiś program konfiguracyjny, podobno można nawet ustawić trzeci przycisk myszy czy tam rolkę - nie wiem, bo nigdy nie używałem :)

Prehistorik stąd, wersja hdd: https://atari.8bitchip.info/SCRSH/prehist.html

Demo Execution wywala mi się dokładnie w momencie kiedy zaczyna się część, która jest pokazana np. w tym filmiku dokładnie od 5:13: https://www.youtube.com/watch?v=UJH2yIJdV_s
Czyli kończy się część z białym tłem, a wskakuje napis na ekranie "SMFX Goes fullscreen" i powinien latać obracający się sześcian po ekranie, a u mnie wtedy następuje rozjazd i zwiecha.
Na tym filmiku widać wyraźnie, że ten efekt ma polegać na tym właśnie, że sześcian lata szerzej na ekranie niż normalny obraz. Czyli właśnie tutaj chyba mamy do czynienia z tzw. "docyklowanym demem", gdzie autor pokazał wyświetlanie obrazu skrajnie od końca do końca linii ekranu i tu prawdopodobnie następuje efekt, o którym pisaliśmy szerzej w poprzednich postach.

Zrobiłem jeszcze trochę testów. Wygląda na to, że ten sam problem występuje w programie testującym joystick i mysz od Putnika (JOYMOUT.PRG) i w grze Prehistoric. W obu przypadkach po prostu nie działa fire w joysticku, natomiast działa prawy przycisk myszy. Wydaje się, że Eiffel w jakiś sposób przełącza sobie czy ma czytać przycisk z myszy czy z joya i niestety nie działa jeden i drugi na raz. Może to zależy od tego w jaki sposób jest zrealizowana obsługa fire w danej grze i wtedy Eiffel na tej podstawie jakoś to sobie przełącza. Szkoda że to tak jest zrobione, powinno być jak w oryginalnej klawiaturze Atari, że prawy przycisk myszy jest fizycznie tym samym co przycisk fire w porcie joya i po prostu działają zawsze równolegle oba te przyciski.
Zastanawiam się jeszcze i nadal poszukuję czy da się to jakoś rozwiązać, bo to w sumie dość poważny problem, będzie on dotyczył być może większej ilości gier.

Tutaj ktoś sprzedaje eifle: https://klydes-korner.site/en/product/a … joysticks/
I tam stoi napisane tak: "However I noticed that the joystick function is not supported by all games. Doing research it seems that there are several methods of joystick support by the Atari ST. The Eiffel adapter doesn't emulate all of these methods, so it's hit-and-miss."
Dalej jeszcze napisano tak: "The joystick ports also do not emulate the mouse function, so you cannot plug an Atari mouse into the joystick port."

Tak że trochę lipa z tym Eiflem, bo niby to fajne, ale nie do końca działa. To jest kawał urządzenia, z wieloma funkcjami, dość szeroko oprogramowane, bo zrobienie protokołów do komunikacji PS/2 z myszą i klawiaturą to spora robota, dodatkowo obsługa różnych map klawiatur, możliwość konfigurowania własnych itd, to jest wszystko super, ale co z tego jak nie działa dobrze normalny port joya i myszy, które są podstawowymi peryferiami, bez których nie da się używać komputera. Sorry, ale chyba będzie trzeba wywalić to wszystko i podłaczyć normalną klawiaturę od ST z normalnymi portami joysticka i myszy... No chyba, że ktoś umie i podejmie się kontynuacji projekty Eiffel i dokończy tą obsługę tych dwóch portów joya?

Jeśli chodzi o to, co opisałem wcześniej w punktach 1 i 2, czyli miganie diod klawiatury, zapełnianie bufora itp., to wygląda na to, że te rzeczy występują tylko w przypadku kiedy odpinam i wpinam wtyczki na włączonym komputerze. Po prostu dużo rzeczy przepinałem, odpinałem i przypinałem mysz i klawiaturę, zmieniałem porty joya itp. Wtedy Eiffel potrafi ześwirować, ale z drugiej strony nie jest to raczej problemem, bo jak wszystko mamy podpięte i nie grzebiemy w kablach, to problemy te nie występują, a przynajmniej dziś po dłuższych testach nic takiego mi się nie działo już.

Zasilacz zwykły wtyczkowy mam na razie do testów 5V/2A. Ale z tym nie ma problemu, to wszystko działa dobrze jak już wyżej napisałem.

Dzień dobry,

czy jest ktoś, kto ma do sprzedania pustą płytkę PCB ATX?

Przepisywać na inny mikrokontroler, czy tam pisać od nowa to nieee...

Ja pomyślałem, że jak są źródła, to można by je spróbować skompilować na ten sam mikrokontroler i sprawdzić czy się uda osiągnąć taką sytuację, że się uzyska identyczny wsad jak ten gotowy.

Jak to by się udało, to wtedy dziabnąć tam tylko "oszustwo" w kodzie, żeby fire joysticka zapisywał się jako przycisk prawy myszy jednocześnie (żeby się fire joya i prawy przycisk myszy sumowały logicznie). To by wystarczyło prawdopodobnie, żeby działały wszystkie gry poprawnie.

Chodzi o to z tego co zauważyłem, że w Atari system ma gotowe procedury odczytu joya, myszy. Programiści pewnie to wiedzą lepiej, bo ja nigdy nic jeszcze na ST nie programowałem, ale wiem że są inne procedury do odczytu myszy, a inne do odczytu joya, pomimo że fizycznie dzieje się to na jednym i tym samym porcie. W Atari fizycznie to się dzieje na tych samych portach, więc wybór procedur odczytu zależy od programisty i tych metod na odczyt danych z portów joya i myszy jest kilka. To że procedura nazywa się "odczyt przycisku myszy", to nie znaczy że nie można jej użyć do odczytu przycisku joya i w grach najwyraźniej nieraz tak jest.

W Eifflu oprogramowanie PIC emuluje tego chipa, co on siedzi w oryginalnej klawiaturze. A więc naśladuje uruchamianie procedur systemowych w ST.
Początkowo Eiffel nie miał w ogóle portów joyów, na początku była tylko obsługa myszy i klawiatury PS/2. Obsługa procedur komunikacji z myszą i klawiaturą została dość dobrze dopracowana. Dopiero w późniejszych wersjach Eiffla dołożono te dwa porty joya i zrobiono im odrębną obsługę, ale te porty są związane tylko z obsługą procedur związanych z joyem. Z tego powodu nie da się np. podłączyć normalnej myszy od Atari, bo procedury komunikacji z myszą, z automatu rozmawiają tylko z myszą PS/2. I odwrotnie, procedury joya działają tylko z portem joya. No i tak jest ok, dobrze ktoś to wymyślił, bo w większości przypadków działa to poprawnie, ale właśnie ten nieszczęsny fire/przycisk myszy nie został wzięty pod uwagę.

Z punktu widzenia projektanta podobnych urządzeń, a także programisty mikrokontrolerów i mikrokomputerów, jestem na 100% pewny, że zmiana w firmware żeby połączyć prawy przycisk myszy z fire joya, jest bardzo prosta i da się ją łatwo "na kolanie" zrobić. Dla mnie problem jest w tym, że nigdy nie programowałem na PIC-a, więc musiał bym poszukać sobie środowiska jakiegoś, softu do kompilacji, doczytać jak się to wszystko kompiluje, doczytać datasheety PIC-ów itd. Rzecz mnie na tyle intryguje, że pewnie się tym w końcu będę chciał zająć, ale przewiduję tutaj walki z moją własną niewiedzą i zużycie dużej ilości zasobu jakim jest czas, a tego obecnie nie posiadam w nadmiarze:-)

A z innej beczki: wsadziłem brakujący układ HC11 i sprawdziłem przełączanie TOS-ów - działa dobrze, startuje 1.04 i 2.06.

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.