Ja mam wersję stąd i stąd. Jest też wersja taka.
Miłej zabawy!

Dzięki, pomogło, zapomniałem o "ficzerach". :)

Niedługo chciałbym zaprogramować sobie Eproma z tym QMegiem, ale wolałbym wcześniej sprawdzić co wgrywam. Może dałoby się zmusić emulator by go jednak odpalił?

Z tego co zauważyłem, po uruchomieniu tego QMega program wykonuje JMP (VIMIRQ), ale pod wskazywanym przez ten wektor adresem nic nie ma, procesor napotyka więc BRK, następuje restart i tak w kółko...

Ok, dzięki wielkie za informację, poszukam tych programów, o których pisaliście. A Spartę i QMEG-a też sobie zainstaluję, ale do środka komputera, jak radzi Pasiu na swojej stronie. :)

Zainstalowałem sobie Robbo Istelle'go na swoim SE 510i i gra naprawdę mi się podoba.
Zauważyłem jeden szczegół, niby bez znaczenia: nieco inaczej niż w oryginalnym Robbo działają kolizje latających 'nietoperzy'. Widać to na przykład w planszy nr 3 - w oryginalnym Robbo nietoperz latający w pionie na tej planszy nigdy nie zderzy się od góry z tym latającym w poziomie, a na komórkowym Robbo to się zdarza. Pewnie nie spowoduje to, że będą trudności z przejściem jakieś dalszej planszy, ale kto wie...
Jednak kłaniam się jednak nisko autorowi za to co zrobił.

Nie jestem elektronikiem i napisałem tylko to, co udało mi się zaobserwować. Być może przy wyższych częstotliwościach Pokey zachowuje się tak, jak napisałeś. Ja w każdym razie patrząc na jego schemat wewnętrzny nie zauważyłem elementów opóźniających, takich jak we Freddim.

Układ pracuje mi obecnie bardzo ładnie, dzisiaj na przykład sprawdzałem jak mój Pokey odczytuje sobie klawiaturę, której nie ma, ale ja udaję że jest. Być może coś przyspieszę w moim programie, bo 1KHz to wynik bardzo mizerny.

No właśnie, mnie się też wydaje że takie opóźnienie może mieć miejsce. Dzisiaj czytałem sobie dokumentację do GTIA, bo jest to układ trochę podobny do Pokeya pod względem komuinikacji z procesorem znalazłem trochę lepsze schematy przebiegów.

Wydaje mi się, że sprawę może rozwiązać prosty zatrzask (np 74574), który zapamięta stan magistrali D podczas opadającego zbocza. Być może, gdy program odczytuję magistralę D przez zboczem, dane nie są one jeszcze w pełni gotowe, a po zboczu już ich nie ma. W dokumentacji do GTIA znalazłem bowiem informację, że po opadającym zboczu dane utrzymywane są one jedynie przez kilkadziesiąt nanosekund. Może i dla Pokeya jest podobnie, ale to tylko taka moja teoria, gdyż schemat Pokeya jest bardzo nieczytelny. Popróbuję jeszcze.

Może i prościej. Ja na razie zrobiłem układ bez mikrokontrolera, aby było mniej układów.
Zrobiłem wczoraj test i wydaje mi się, że sposób podany przez Macgyvera nie jest dobry. Po narastającym zboczu na O2 sygnał na magistrali D szybko znika i nic nie udaje się odczytać.
Obecnie mój układ i program odczytuje jakieś dane z magistrali D przed narastającym zboczem O2, ale problem w tym, że nie zawsze takie same - czasami jeden z bitów jest przekręcony.
Czy może ktoś z Was wie, czy potrzebne są rezystory podciągające sygnały magistrali D do +5V? Rezystory takie są w prawdziwym Atari (10k).
Trochę brakuje mi dokumentacji elektronicznej do Pokeya, a w tej którą mam (pokey.pdf) są niestety błędy a niektórych istotnych rzeczy nie ma wcale.
Trochę próbowałem analizować schemat wewnętrzny tego układu i jak na razie nie widzę powodu, dla którego nie będzie on działał przy niskich częstotliwościach. Wszystko jest na bramkach i prostych MOS-owych tranzystorach.