Czy słyszeliście może o czymś podobnym do Taupino (C64) ale dla Atari? Dla niewtajemniczonych: Tapuino to taka sprytna maszynka dla VIC20/C64, oparta na Arduino, potrafiąca udawać magnetofon normal/turbo. Wiem, że zaraz zaproponujecie jakieś rozwiązania emulujące stację dysków, lecz nie oto mi chodzi. Chodzi o dokładne emulowanie magnetofonu normal/turbo za pomocą Arduino i karty SD. Odzwierciedlenie klimatu ładowania z magnetofonu lecz bez walki z kasetami, paskami gumowymi, głowicami itp. Jest taki projekt ->link<- emulujący magnetofon za pomocą PC-ta. Ćwiczyłem taką emulację na C64, zrobiłem też Tapuino i muszę stwierdzić, że emulacja PC-tem nie ma tego uroku, co małe sprytne pudełeczko Tapuino. Oczywiście da się przepisać projekt CasCom na Arduino, ale trzeba pokonać wiele wyzwań, np. małą ilość pamięci RAM. CasCom się nie bawi i od razu rezerwuje 64kB na bufor. Małe Adruino ma tylko 2kb i musi mu ono wystarczyć m.in. na stos assemblera.
@sun, nie chodzi dokładnie o to, bo to jeszcze większe hardcore :) Chodzi o urządzonko, gdzie wrzucasz na kartę plik cas bądź zwykły xex, a arduino przekształci taki plik w przebieg nie dwutonalny ale już zwykły serial. Proste do zrobienia zwłaszcza w przypadku pliku cas :)
@jhusak: jasne, to co wkleiłem to pierwsze co wypluła wyszukiwarka. Niemniej z "otchłani" pamięci przebija się wrażenie, że widziałem coś takiego chyba na elektrodzie daaawno temu. Tadaaam! ->link<- Czyli jednak 9 latek... Nie jest to dokładnie z CAS, ale z WAV, więc można sobie wziąć pewnie większy proc i naskrobać firmware, albo wręcz "pożyczyć" np. z SDriveMax.
Dzięki za cenne wskazówki. Zwłaszcza ta dotycząca SDriveMax jest strzałem w dziesiątkę. Kod SDriveMax jest w licencji GNU a więc nie trzeba "pożyczać", można wziąć kawałek. Z tego co się pobieżnie zorientowałem z trybem normal nie będzie żadnego problemu. Kod SDriveMax rezerwuje dla niego bufor 132 bajty. Każde Arduino da radę. Problem będzie przy turbo. Pewnie też do pokonania. Przecież ludzie na Arduino robią VGA, gdzie synchro poziome to np.35 kHz, a trzeba jeszcze po drodze zapalać pixele np. z częstotliwością przynajmniej kilka MHz, żeby osiągnąć jakąkolwiek rozdzielczość. Dla mnie mistrzem jest tutaj Slu4, który na Arduino Nano zrobił VGA z rozdzielczością 320x480 pikseli (+ 3 proste scalaki TTL = terminal tekstowy, żeby nie było wątpliwości).
The AVG cart. in combination with the SIO-plug can also load ATX and CAS files. Tested it succesfully with standard 600 Baud CAS files (e.g. Bruce Lee loading took some 10-12 minutes aaargghh), but I am much too impatient for that. I am not sure if it also supports turbo CAS files, think I have to read the AVG documentation again...
...ah yes, found the doc. and it does support turbo CAS files: ->link<-
Rozeznałem natomiast jak to jest z Turbo2000. Da się to prosto zrobić. Przerwanie zegara w Arduino trzeba ustawić na 0.25 ms. Bit zero = 1 tik zegara Bit jeden = 2 tiki zegara Synchro = 4 tiki zegara
Potrzebny jest odczyt z karty SD i bufor. Bloki Turbo2000 mają po 3kB, a TurboAST lub UM jeszcze więcej. Tu z pomocą przychodzi nam bufor z Tapuino (Ultra lightweight ring buffer, for fast insertion/deletion). Właściwie to można wziąć większość kodu z Tapuino, zmieniając tylko zapis pojedynczego bajtu, budowę bloku danych i ustawienia timera. Jeszcze prościej: wykorzystać powyższe z kodu CasCom.
Sun, Tobie to nie potrzebne. Taka zabawka będzie dla tych, którzy chcą sobie przypomnieć klimat ładowania gier z magnetofonu (paski turbo, loadery w normalu itp.). Przecież to nie chodzi o to żeby skutecznie załadować program do pamięci. Teraz jest na to wiele lepszych, a może i tańszych sposobów np. SDrive.
A właściwie kto będzie teraz odpalał realne Atari, kiedy w podstawowe gry można zagrać bezpośrednio z przeglądarki WWW. Skończy się prawdopodobnie na tym, że każda gra będzie miała swój adres WWW na jakimś serwerze i wchodząc w ten adres od razu będziemy mieli grę załadowaną.
O nie! U mnie Atari jest odpalane żeby zagrać, przetestować kod, pokeymaxa i inne urządzenia, których zwyczajnie kablami do peceta nie podepnę. Miałem turbo 2000 jako interfejs do Kasprzaka, więc wiem o czym mówisz.
Nie będę jednak robił Tapuino dla Atari. Trafiłem na rozwiązanie CAS2Audio na Android-a. W połączeniu z posiadaną przeze mnie przystawką do normalnego magnetofonu (produkt polski z 1987 roku) z wstawionym później turbo AST, osiągnę wszystko czego potrzebuję.
Zawsze warto coś nowego zrobić. Rzecz jednak jak zwykle rozbija się o brak wolnego czasu. Do tego dochodzą narzekania niezadowolonych użytkowników i czar pryska.
Z Tapuino w wersji C64 był problem ze stabilnością. Chodziło o małą ilość wolnej pamięci w Arduino Uno/ProMini. W wersji którą budowałem (kilka lat temu) wolnej pamięci było tak mało, że urządzenie często się zawieszało. Zmienne "podcinały" stos. Problem rozwiązałem rezygnując z długich nazw plików. Nie miem czy kojarzycie, ale w FAT wciąż jest zaszłość jeszcze z Windows 3.11 i nazwy pików przechowywane są dwóch tablicach. Jedna dla nazw 8+3 znaki, a druga równoległa dla nazw 256 znaków. Biblioteka w Tapuino była tak ustawiona, żeby te dwie nazwy odczytywać i trzymać w pamięci. Jak przełączyłem tylko na nazwy 8+3, wszelkie problemy ze stabilnością zniknęły. Oczywiście na wyświetlaczu pojawiły się nazwy skrócone z tyldami.
To teraz pytanie: jak takie okrojone nazwy skomentowała by społeczność Atari? :)
Dla siebie bym tak zostawił, ale na pokaz to szkoda czasu i nerwów.
kuuuurcze, to ma taką moc, że portki spadają. $4 kupiłem 2, bo więcej się nie dało. jakby to się dało dokleić do carta atarowskiego... przez jakiś bufor 5-3.3V...
Do Tapuino nie jest potrzebna duża moc, bo to małe częstotliwości. Wystarczy większa pojemność pamięci RAM. Bardzo tanie i dość mocne są STM32 Blue Pill. Jednak na Arduino jest gotowy projekt i dla Atari potrzebne są tylko niewielkie zmiany.
Ostatecznie można zostać nawet przy tych 2KB RAM-u. Dziś dowiedziałem się, że SDrive Max też ma krótkie nazwy plików. Pewnie przez kłopoty opisywane przeze mnie w poprzednim poście. To może reakcja społeczności Atari nie będzie taka negatywna. SDrive Max ma jeszcze jedną wadę: zewnętrzne zasilanie. Trochę to dziwne i niepraktyczne. Nie wiem ile prądu pobiera wyświetlacz, ale na samym Arduinie można oszczędzić kilkadziesiąt miliamperów rezygnując z USB (ProMini) i wyłączając niepotrzebne moduły (np.przetwornik A/C).
Co do nowego Raspberry PiPico: nie miałem jeszcze z nim styczności. Cena rzeczywiście super niska i możliwości spore. Jednak Arduino ma przewagę z potężną ilością gotowych bibliotek. PiPico będzie powoli podkradało Arduinowi jego obszary zastosowań.
Arduino ma dużo bibliotek, ale są one niejednokrotnie niskiej jakości, pisane przez użytkowników, a nie programisów. I nie wiadomo, na jaką czekoladkę trafisz.
Co do arduino, to ważne, aby panować nad stosem. Aby to było wykonalne, trzeba analizować kod zaczytanych bibliotek, które niejednokrotnie szastają zasobami.
Botland u nas ma na stanie PICO w cenie niecałe 20 peelenów. Brutto. Pobawiłem się tym chwilę, ma potencjał. Jest NES na to. Zakupiłem podwozie VGA i będę się bawił. Fajna była by taka płytka to niego, gdzie 3.3<>5v przerabia w locie.
To ja może pozwolę sobie napędzić Zaxonowi klientów. Jeśli chcecie gotowe TAPuino do Atari, to kupcie Fujinet. Kosztuje co prawda dużo więcej niż $4, ale działa i nie trzeba nic dokładać, a dostaje się również SIO2SD, SDrive, magnetofon i "kartę sieciową" :)
Co do VGA na PICO: Ćwiczyłem sterowanie VGĄ kolejno na Arduino Nano, ESP8266, STM32F103C8T6. Kupiłem jeszcze stm32F411 i ESP32. Te ostatnie tak długo szły z Chin, że trafiły już na zmianę zainteresowań. Równolegle próbowałem na Raspberry Pi Zero. Jego stosunek mocy do ceny jest nie do pobicia. 500MB RAM, 700MHz, wbudowany mostek USB i SVGA biją na głowę wszystkie powyższe płytki.
Faktem jest, że zabawy z generowaniem VGA są bardzo fajne, wręcz uzależniające. Człowiek łapie podobne klimaty o jakich pisze Steve Woźniak. Trzeba idealnie zestroić hardware i software żeby otrzymać stabilny obraz. Gdy już masz obraz i panujesz nad poszczególnymi pikselami, masz coś na kształt gołego komputera Apple I. Brakuje wszystkiego: generatora znaków, basica lub innego systemu operacyjnego. Fakt, że na starcie masz kompilator C ze środowiska developerskiego płytki, czego nie miał Woźniak.
Na Raspberry Pi nie ma ręcznego generowania VGA. Masz ją gotową. Zabawa trochę traci na uroku.
Na STM32F103C8T6 udało mi się stworzyć coś w rodzaju konsoli z grami: tetris, szachy i moon lander. Rozdzielczość 128X96 64 kolory. Na więcej nie pozwalała ilość RAM (20kB). Można próbować generować obraz w locie, bez podprogramu frame buffera, coś jak w Atari2600. Rozdzielczości i ilości kolorów można wtedy uzyskać większe ale napisanie jakiejś gry to już wyższa szkoła jazdy.
tak w ogóle to setup do fujineta jest strasznie i niepotrzebnie duży, ostatnio nie śledziłem, ale chyba coś się w tym kierunku dzieje. Ale tak naprawdę pomogłoby, jakby tzw. "ktoś" przepisał to do sensownej postaci.
co do pi pico - on ma taki ciekawy myk, jakby to obczaić, to by było za darmo np. generowanie obrazu dla atarki z karta, coś jak w carcie tomek - to się nazywa PIO, ma 8 state machines, w std dokumentacji generują z tego obraz VGA i komunikację z kartą SD. Myk polega na tym, że timingi itp. idą ze sprzętu, praktycznie nie obciążając procka.
A jak zmusić Fujinet do działania w trybie turbo? To wczytywanie setupa przez naście sekund jest dobijające.
U mnie chodzi pięknie w turbo. Mam spaczowany OS i w ustawieniach webowych interfejsu, przez przeglądarke ustawiasz sobie odpowiedni podzielnik.
Wiem że trwaja prace nad zmniejszeniem loadera, a w wersji firmware z 11 marca jest nowy "ficzer" przyspieszający ładowanie:
- * NEW 'mount and boot' feature: This makes FujiNet skip CONFIG and instead mounts all slots and cold starts for a faster boot up. You can press SELECT during the 'mount and boot' to re-enter CONFIG. In the web interface under BOOT SETTINGS you select/enable 'Mount Everything' to turn this on.
Fajnie, z tym przyspieszeniem, ale to droga trochę na skróty, takie DOS/DUP. Natomiast ja używam gołej atarki, a napisanie handlera turbo to nie jest rocket science, patrz np. SIO2SD.
Wg mnie ten konfigurator trzeba sukcesywnie przepisywać na asembler, bo jednak pascal (czy cc65, nie pamiętam) generują 2-3 razy większe binarki.
Przydało by się też łatwe wgrywanie nowej wersji konfiguratora... A może to jest?
Tak na szybko konfigurator powinien być przede wszystkim skompresowany najszybszym kompresorem.
