1 Ostatnio edytowany przez Mq (2023-10-07 20:48:48)

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.

Post's attachments

eiffel_1.10.1(Mq)_fixedFire_noLcd.zip 50.44 kb, liczba pobrań: 15 (od 2023-10-07) 

Tylko zalogowani mogą pobierać załączniki.

2

Spodziewałem się że nie da ci to spokoju :)
Dzięki, przyda się. Zapisuję "to-do" :)

<-- Kontakt przez "E-mail" gdyż albowiem moja skrzynka "PW" jest pełna i zaprawdę nie mam czego usunąć.

--== Kup Pan/i dyskietkę http://www.atari.org.pl/forum/viewtopic.php?id=18887 ==--

3

No,no Mq - kupa roboty :) z pewnością się przyda co więcej zawsze jest możliwość przerobienia sprzętu na większy procek i większą szybkość skoro już ogarnąłeś źródło :D

Różne różności dla Atari i nie tylko - przydatne, bądź nie ale i tak warto zajrzeć...
http://atari.myftp.org  Atari - Power without price and necessary elements with some sh*t onboard
https://reversing.pl SSL enabled site

4

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.

5 Ostatnio edytowany przez Cyprian (2023-10-08 22:08:20)

pięknie dziękujemy MQ

Lynx I / Mega ST 1 / 7800 / Portfolio / Lynx II / Jaguar / TT030 / Mega STe / 800 XL / 1040 STe / Falcon030 / 65 XE / 520 STm / SM124 / SC1435
DDD HDD / AT Speed C16 / TF536 / SDrive / PAK68/3 / Lynx Multi Card / LDW Super 2000 / XCA12 / SkunkBoard / CosmosEx / SatanDisk / UltraSatan / USB Floppy Drive Emulator / Eiffel / SIO2PC / Crazy Dots / PAM Net
http://260ste.atari.org

6

@Cyprian, ale poprawki zrobił Mq, nie tOri :P

Sikor umarł...

7

Hej,

Cyprian tak z przyzwyczajenia chyba pojechał ;-D
Ale TAK! Wszystkie podziękowania idą do MQ!
Super, bo to się na pewno przyda w przyszłości.

Pozdrawiam
tOri

Różne różności dla Atari i nie tylko - przydatne, bądź nie ale i tak warto zajrzeć...
http://atari.myftp.org  Atari - Power without price and necessary elements with some sh*t onboard
https://reversing.pl SSL enabled site

8

tak tylko sprawdzam Waszą czujność ;)

Lynx I / Mega ST 1 / 7800 / Portfolio / Lynx II / Jaguar / TT030 / Mega STe / 800 XL / 1040 STe / Falcon030 / 65 XE / 520 STm / SM124 / SC1435
DDD HDD / AT Speed C16 / TF536 / SDrive / PAK68/3 / Lynx Multi Card / LDW Super 2000 / XCA12 / SkunkBoard / CosmosEx / SatanDisk / UltraSatan / USB Floppy Drive Emulator / Eiffel / SIO2PC / Crazy Dots / PAM Net
http://260ste.atari.org

9

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:-)