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.