176

(323 odpowiedzi, napisanych Fabryka - 8bit)

Przypomnijmy i ustalmy jedną zasadniczą rzecz: SIMMexp nie jest moim projektem. Ja tylko zaproponowałem płytki jakie można pod to zrobić i nazwałem to rozwiązanie sobie, że jest ono "bez kabli". Pasiu udostępnił projekt dawno temu, przez wszystkie te lata jest on dostępny, i przez wszystkie te lata cała społeczność szanuje to. Ja również to uszanowałem, zrobiłem małą ilość dla chętnych przy okazji robienia tego sobie samemu i udostępniam każdemu kto poprosi. Docelowo również udostępnię na swojej stronie internetowej poświęconej różnym moim większym i mniejszym projektom.

Jak ktoś będzie chciał trzepać na tym kasę i być wbrew uczciwości, to i tak znajdzie do tego drogę. Kiedyś bym robił przeciw temu krucjaty, dzisiaj mam to w dupie. Dla mnie ważne jest że ludzie mnie lubią, jak ktoś inny za parę groszy woli być ścierwem, to co mnie to obchodzi? Niech se bierze, niech sprzedaje. Panowie, my tu mówimy o złomie elektroniki użytkowej z ubiegłego stulecia, a nie o kosmicznych tajnych technologiach za jakieś grube miliardy:-)

177

(24 odpowiedzi, napisanych Software, Gry - 8bit)

Przepiękna półeczka:-)

178

(323 odpowiedzi, napisanych Fabryka - 8bit)

Planuję zrobić stronę ze swoimi projektami, które chcę udostępnić światu. Dlatego nie wystawiam tego nigdzie na cudzych stronach itp., na razie kto chce, to mu po prostu daję osobiście, a docelowo chcę to mieć w necie udostępnione wszystko w jednym miejscu.

179

(323 odpowiedzi, napisanych Fabryka - 8bit)

Nie lubię:-)

180

(323 odpowiedzi, napisanych Fabryka - 8bit)

Dawno to było, niestety nie mam już tych płytek...

Mogę udostępnić pliki projektu w Eagle do wykorzystania we własnym zakresie.
Jak ktoś chce, to pisać do mnie na PW albo na maila.

181

(24 odpowiedzi, napisanych Software, Gry - 8bit)

Nareszcie mamy to! Wszystko jest kompletne i gotowe do dystrybucji. W najbliższych dniach będę kolejno wysyłał do wszystkich wiadomości.

Załączam zdjęcie zawartości.

Na zdjęciu są dwa magnesiki, intencjonalnie odwrócone, ponieważ to co na nich jest to niespodzianka. Magnesy są różne w poszczególnych pudełkach, a więc zawartość jest losowa. Kiedy otrzymacie swoje egzemplarze, to możecie pochwalić się zdjęciami tego co się wam trafiło na magnesach:-)

http://www.atari.org.pl/forum/misc.php?action=pun_attachment&item=10943

182

(89 odpowiedzi, napisanych Sprzęt - 16/32bit)

Fajna koncepcja, chętnie zobaczę efekty końcowe co z tego wyjdzie.

183

(20 odpowiedzi, napisanych Sprzęt - 16/32bit)

O to właśnie mi chodziło. Czyli odpowiadając na zasadnicze pytanie przetwornice ze zdjęcia są już na dzień dobry mocniejsze niż oryginalny zasilacz. Oczywiście jasna sprawa, że jak ktoś chce mocno rozszerzać sprzęt to musi brać to pod uwagę ewentualnie i dobierać zasilacz. Tyle w temacie.

Ja muszę wymienić  zasilacz na coś poważnego, osłoniętego przed dotykiem bo mnie w końcu kiedyś po prostu może zabić :/

Tak, zawsze mnie to w ST rozwalało z tym zasilaczem, że jak się coś grzebie w sprzęcie, to wysokie napięcia są na wierzchu. Łatwo o tym zapomnieć jak na co dzień grzebiemy sobie w innych sprzętach, gdzie nigdzie nie ma takiej sytuacji.
Generalnie jak masz różnicówkę w domu, to Cię tak od razu nie zabije, ale jak spadnie Ci np. śrubokręt tak nieszczęśliwie (czy jakiś inny kawałek drutu), że puści 230V na płytę główną gdzieś, to trochę niezbyt fajnie.

184

(20 odpowiedzi, napisanych Sprzęt - 16/32bit)

No ale właśnie dlatego kilka postów wcześniej zapytałem czy na oryginalnych zasilaczach w Atari napisano coś o prądach. Ciekawi mnie jakie prądy przewidział producent w zasilaczach Atari ST(FM) i jakie w Atari STE (czy tam jest mocniejszy zasilacz może?).

185

(20 odpowiedzi, napisanych Sprzęt - 16/32bit)

Do retro w standardzie nie, ale już do poważnej rozbudowy można rozważyć. Jak chcesz np. hdd podłączyć, cd-rom, itp, to wtedy warto rozważyć. Ale generalnie zgadza się, że najważniejsze jest 5V. Tak czy owak trzeba dobierać zasilacz do konkretnych zastosowań po prostu.

186

(20 odpowiedzi, napisanych Sprzęt - 16/32bit)

Wiecie, jak ma być dużo rozszerzeń, hdd i inne obciążenia dodatkowe, to pewnie najlepiej poszukać jakiegoś mniejszego zasilacza ATX i wtedy będzie taniej, mocniej, z wielkim zapasem.

W tych przetwornicach chodzi o to moim zdaniem, że to się bardzo ładnie i zgrabnie zmieści w miejscu oryginalnego zasilacza w standardowym Atari ST(E) tak jak to jest pokazane na zdjęciu w pierwszym poście tego wątku. Wygląda fajnie, a bez zbytniego rozszerzania w standardowym Atari spokojnie wystarczy mocy, a też przy tej mocy jeszcze te przetwornice mają w miarę rozsądną cenę, bo potem im mocniejsze tym droższe się robią i faktycznie przestaje się to opłacać.

187

(20 odpowiedzi, napisanych Sprzęt - 16/32bit)

tOri nie jest to przesada?

A czy wiadomo może co jest napisane o prądzie na oryginalnych zasilaczach od ST? Nie wiem, bo nie mam... Ale do ST-ATX używam ostatnio 5V-2A i wystarcza mi z niewielkim zapasem, a 12V nie używam wcale, Atari leci na samych 5V, z tego co kojarzę na schematach, to 12V jest tylko potrzebne gdzieś tam przy modulatorze chyba. Fakt, że nie mam tam np. FDD, stare flopy wymagały 5V i 12V, nowe już też tylko 5V.

Te na zdjęciu mają
5V - 4A (https://www.tme.eu/pl/details/irm-20-5/ … mean-well/)
12V - 1.8A (https://www.tme.eu/pl/details/irm-20-12 … mean-well/)

To mi się wydaje być już z wystarczającym zapasem.

Po wielu miesiącach męczenia mnie przez środowisko twórców gier na Atari, postanowiłem poprawić w grze jeden niedokończony dotąd drobiazg. Otóż zrobiłem zmianę kierunku nóg bohatera przy zmianie kierunku joysticka, co pozytywnie wpłynęło na dynamikę samej postaci.

Podmieniłem plik gry w pierwszym poście. Proszę sobie podmienić w archiwach prywatnych, folderach z ulubionymi grami itp.

Dziękuję za uwagę.

189

(20 odpowiedzi, napisanych Sprzęt - 16/32bit)

Fajne!

190

(114 odpowiedzi, napisanych Fabryka - 8bit)

No to może opiszcie w czym była rzecz i które egzemplarze mogą wymagać poprawki, bo być może jest to drobiazg, który wiele osób by sobie samodzielnie zrobiło we własnym zakresie, a może ktoś kiedyś trafi tu z podobnym problemem jeszcze?

191

(24 odpowiedzi, napisanych Software, Gry - 8bit)

Jesteśmy na finiszu!

Wszystko mamy działające, kartridże gotowe, wsad przetestowany.
Poligrafia na ostatnim etapie - produkuje się już w drukarni.

Gra powinna być gotowa do dystrybucji w ciągu kilku dni.

Kto się jeszcze nie zapisał - zapraszamy!

Mogę już potwierdzić co będzie zawierało fizyczne wydanie gry:
- pudełko w pełnym kolorze oryginalnie zafoliowane, z miejscem dedykowanym na kartridż
- kartridż z grą (złocone styki, obudowy najwyższej jakości od Sikora, grube wysokiej jakości nieścierające się naklejki)
Gra w wersji kartridżowej ma przygotowane specjalne menu, instrukcje w języku polskim i angielskim i ukrytą niespodziankę:-)
- instrukcja do gry - kolorowa wielostronicowa, na dobrym papierze

Dodatkowo dwie niespodzianki - gadżety:
- "wojskowy" dyplom ukończenia kursu naszych walk czołgowych z miejscem na wpisanie własnego imienia i nazwiska, własnoręcznie podpisany przez prowadzących szkolenia Pecusia i Pirxa - dyplom można sobie gdzieś powiesić np. w antyramie
- dwa przepiękne magnesy "na lodówkę" umożliwiające symulację toczenia walk w formie bezkomputerowej właśnie np. na wspomnianej lodówce:-)

Informacje dot. zamówień są podane w pierwszym poście niniejszego wątku.

192

(114 odpowiedzi, napisanych Fabryka - 8bit)

O! Wielkie dzięki! Przetestuję sobie wieczorem jak zdążę, a jak nie, to jutro, bo dziś w rozjazdach jestem...

193

(114 odpowiedzi, napisanych Fabryka - 8bit)

Ok, czyli ja mam z wcześniejszej partii pewnie i jest jakaś różnica, tak? Niemniej jednak jak by się komuś chciało jakiegoś atr-a podrzucić, to był bym wdzięczny, bo teraz mnie to zaciekawiło i bym sobie odpalił, ale nie mam za bardzo z czym, a nie chce mi się ryć internetu w poszukiwaniach jak to zrobić na szybko:-)

194

(8 odpowiedzi, napisanych Sprzęt - 16/32bit)

Hehe:-) Właściwie to ja też dziękuję tOriemu, bo on robi tak dużo do ST, że czyny każdego przy nim bledną, a w zasadzie to nawet jak ktoś inny coś zrobi, to i tak zawsze jest w tym jakiś udział tOriego też:-) Tak że dzięki tOri!:-) W tym konkretnym przypadku powiem tylko tyle, że ja się głównie małym Atari bawię, ale tOri zasypuje tak ogromną ilością informacji i zabawek z dziedziny ST, że się wkręciłem i też się bawię:-) Tak że całkiem serio mówię o tych zasługach tOriego:-)

195

(114 odpowiedzi, napisanych Fabryka - 8bit)

Wrzućcie jakiegoś atr-a na którym można to na szybko przetestować, to sprawdzę i swój egzemplarz, bo mówiąc szczerze nie pamiętam nawet czy go kiedyś odpalałem, ale mam:-)

196

(114 odpowiedzi, napisanych Fabryka - 8bit)

Ile to jest amper "extra hiper mocny"? Może zestaw bierze prąd na granicy możliwości zasilacza, a ten przegrzewa się i włącza jakieś zabezpieczenie i odcina prąd, wtedy siada mu napięcie, bo podaje coś tam tylko szczątkowo, ale nie zasila tak na prawdę. Atarki jakoś mocno porozszerzane? Trzeba by prąd pomierzyć a nie napięcie.

197

(8 odpowiedzi, napisanych Sprzęt - 16/32bit)

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.

198

(251 odpowiedzi, napisanych Fabryka - 16/32bit)

Poprawiłem interfejs Eiffel na potrzeby na potrzeby płyty ATX w kwestiach opisywanych we wcześniejszych postach.
Tu jest osobny wątek na ten temat: http://www.atari.org.pl/forum/viewtopic.php?id=19470

199

(8 odpowiedzi, napisanych Sprzęt - 16/32bit)

Oryginalne oprogramowanie mikrokontrolera PIC interfejsu Eiffel ma przypadłość taką, że niestety w niektórych grach nie działa fire joysticka podpiętego pod port 1 joysticka.
Problem jest dość szeroki, bo dotyczy wielu gier i to raczej dobrych i ważnych, np.:
- Gods
- Prehistorik
- Dizzy Yolkfolk
- Fred
Pewnie więcej jest takich gier, ale to przykłady pierwsze z brzegu.
Podobnie nie działa fire joysticka w programie testującym joystick i mysz od P.Putnika i jest tu ta sama sytuacja.

Zauważyłem, że we wszystkich tych przypadkach gdzie nie działa fire, działa jako fire prawy przycisk myszy.
W oryginalnym Atari prawy przycisk myszy (port 0) i przycisk fire joysticka (port 1) to fizycznie jest to samo, bo linie te są połączone.
W przypadku Eiffla nie mamy fizycznego połączenia tych dwóch rzeczy, bo mysz jest PS/2, a joystick ma swój własny port.

Problem wynika z tego, że w Atari odczyt danych joysticków, myszy i przycisków można robić na kilka sposobów. Odpowiada za to interfejs IKBD, który znajduje się w oryginalnej klawiaturze Atari i obsługuje zarówno klawiaturę, mysz i joysticki. Odczyt przycisku fire jak zauważyłem autorzy gier robią z wykorzystaniem różnych funkcji interfejsu IKBD i czasem odczytują się stany joyów razem z przyciskami, czasem osobno kierunki i osobno przyciski, czasem przycisk jako przycisk myszy itd., a tych procedur odczytu jest kilka różnych.

Emulacja interfejsu IKBD stworzona w Eifflu odczytuje przycisk joysticka tylko w wypadku kiedy jest to faktycznie fizycznie przycisk joysticka, a myszy gdy mamy takie dane z PS/2.
Wymyśliłem więc najpierw, że skoro prawy przycisk myszy działa jako fire w grach, to trzeba po naciśnięciu fire dodać go do przycisku myszy.
Pierwsze próby zrobiłem tak, że wstrzyknąłem się w kod obsługi PS/2 i tam dodałem ten fire podczas wciśnięcia przycisku. To zadziałało, ale fire działał tylko jeśli w tym samym czasie szła jakaś faktyczna transmisja danych z myszy, żeby było do czego ten fire dodać. Takie rozwiązanie było o tyle dobre, że to były tylko dwie instrukcje, a dokładnie tyle wolnej pamięci na kod zostało w PIC-u. Jednak trudno wyobrazić sobie granie w gry i jednoczesne szuranie cały czas nogą myszką, żeby cały czas szła jakaś transmisja do której będziemy dodawać przycisk fire:-)

Dlatego wymyśliłem, że fire trzeba wysyłać bezpośrednio po stronie transmisji danych do Atari i po prostu wysłać fake-dane myszy.
Mój kod działa tak, że jest uruchamiany w miejscu gdzie wysyłane są dane joysticka do Atari, bezpośrednio przed tymi danymi. Jeśli przycisk fire jest wciskany lub puszczany, to mój kod wyśle transmisję danych od fejkowej myszy, w których to danych zapisane jest wciśnięcie (lub puszczenie) prawego przycisku myszy oraz brak ruchu myszy, czyli dwa zerowe bajty dla kompletności transmisji.

W kodzie źródłowym Eiffla w procedurze zaczynającej się od etykiety SendAtariJoysticks dodałem swój kod (są to linie w pliku źródłowym od 1867 do 1881).
Kod ten sprawdza czy włączona jest obsługa myszy (konieczne, bo jak Atari wyłączyło całkowicie mysz, to nie spodziewa się danych od myszy, więc jak się takie dane pojawiają, to występują błędy).
Jeżeli mysz wyłączono, to następuje przeskok mojego kodu i nie wykonuje się nic. Jeżeli natomiast mysz jest włączona, to można dokonać transmisji fejkowych danych.
Dane fejkowe to trzy bajty: pierwszy nagłówkowy zawiera informacje że to dane od myszy i tam też stan prawego przycisku myszy. Dwa kolejne bajty są zerowe i oznaczają ruch myszy w osi x i y.

Poniżej ten mój fragment kodu, który tu opisuję:

;-----------------------------------------------------------------------------
; BEGIN Fake mouse data (right mouse button) - added by Mq (2023-10-07)
        btfss Flags,MOUSE_ENABLE
            goto Not_Fake_Mouse_Data; no authorization from Atari
        movlw 0xF9; joy1 fire pressed
        btfss JOY1,4
            movlw 0xF8; joy1 fire released
        call SerialTransmit_Host
        movlw 0
        call SerialTransmit_Host
        movlw 0
        call SerialTransmit_Host
Not_Fake_Mouse_Data
; END Fake mouse data
;-----------------------------------------------------------------------------

I to załatwia temat. Przetestowałem na około 30 grach, wymienione wyżej gry zachowują się poprawnie, program testowy P.Putnika też działa poprawnie.

Jest tylko jeden jeszcze szkopuł. Otóż, żeby to dodać, musiałem wyłączyć obsługę wyświetlacza LCD, a więc wersja firmware, którą tu prezentuję nie będzie wyświetlała nic na wyświetlaczu LCD jeśli ktoś ma taką wersję interfejsu Eiffel. Zrobiłem tak dlatego, że w pamięci na kod Eiffla zostało miejsce tylko na dwie instrukcje. Eiffel ma na początku kodu w liniach od 130 do 140 kilka flag dotyczących kompilacji, które pozwalają wyłączyć część kodu odpowiedzialną za niektóre funkcjonalności Eiffla. Ponieważ mój Eiffel nie posiada wyświetlacza LCD i nie przewiduję go używać, więc najprościej było zmienić jedną wartość odpowiedzialną za LCD z 1 na 0, co wyłącza całkowicie obsługę wyświetlacza LCD, za to zwalnia miejsce w pamięci na dodatkowy kod, który dopisałem, żeby obejść problem niedziałającego fire.
Tak na prawdę w PIC-u jest jeszcze miejsce, z tym że pamięć tego układu jest bankowana i żeby użyć pamięci wolnej w innych bankach, trzeba by pozmieniać trochę więcej w kodzie, bo trzeba te banki przełączać, żeby np. wykonywać skoki do procedur zapisanych w innych bankach. Ja nigdy wcześniej nie programowałem na PIC-e niczego, więc i tak sporo trudu kosztowało mnie to co już zrobiłem. Dla siebie jak pisałem nie potrzebuję LCD, jeśli okaże się, że to jest potrzebne, to w przyszłości spróbuję jeszcze poprawić to tak, żeby jednak zmieścił się ten kod obsługi wyświetlacza. Można to zrobić na dwa sposoby: albo skorzystać z bankowanej pamięci dodatkowej, która jeszcze jest wolna, albo znaleźć miejsca w kodzie, które dało by się zoptymalizować i zyskać miejsce na kilka instrukcji, bo tego miejsca brakuje chyba na jakieś chyba 8 instrukcji tylko.

Załączam całkowity kod źródłowy z moją poprawką oraz skompilowany wsad do PIC-a.

O, nie wiedziałem, że w emulatorach jest. Przy wolnej chwili sprawdzę sobie jak działa. (serio)
Ale moje pytanie raczej dotyczyło real sprzętu. (też serio)