Chciałem kupić coś takiego:
http://www.allegro.pl/item839920741_mon ... _cdtv.html
ale okazuje się, że jest niesprawne :(
Czy ktoś podjąłby się ewentualnie naprawy?
Nie jesteś zalogowany. Proszę się zalogować lub zarejestrować.
Alternatywny firmware dla A8PicoCart Ulepszone oprogramowanie dla A8PicoCart z odtwarzaczem SAP, wygaszaczem ekranu i obsługą tysięcy plików.
bm800xl 0.7.2 Nowa wersja emulatora 8-bitowego Atari na Raspberry Pi działającego bez systemu Linux.
BMAtariST v0.1.1 Nowa wersja BMAtariST v0.1.1 przynosi poprawki błędów dla bare-metal emulatora Atari ST/TT/Falcon na Raspberry Pi.
NeoST 0.6.4 Wydano NeoST 0.6.4 z obsługą NetUSBee, wbudowanym stosem sieciowym NAT oraz poprawkami dokładności.
Premiera "At the End of the Rainbow" Dziś premierę ma nowa książka Pawła Grabarczyka.
atari.area forum » Posty przez mono
Chciałem kupić coś takiego:
http://www.allegro.pl/item839920741_mon ... _cdtv.html
ale okazuje się, że jest niesprawne :(
Czy ktoś podjąłby się ewentualnie naprawy?
Z ustawianiem fuses uważaj, żebyś sobie nie przeprogramował którejś linii uniemożliwiającej programowanie szeregowe (doczytaj w dokumentacji - nie pamiętam która to linia). Jedyne wyjście potem to skasowanie takiego delikwenta programatorem równoległym. Procesory mogą być jeszcze dobre...
Edit: Mam na myśli RSTDISBL (b7 high fuse byte) i sytuację kiedy ustawiasz pin RESET jako GPIO.
@Pin: A dlaczego Crownland nie działa na real Atari?
Najpierw trzeba swoje odczekać a potem obsługa z SHIFTem i SELECTem o ile pamiętam. Interface tam był naprawdę niecodzienny :)
Edit: Spacją się przechodziło do następnej pozycji w patternie.
Zdaje się, że tylko Automat Perkusyjny wydany przez Avalon miał oryginalnie samplowaną perkusję. Ten z Chaos Software był prekursorem automatu wydanego przez Avalon.
Za to Rythmizer miał perkusję graną POKEYem! Bardzo fajny program.
Automat perkusyjny z Chaos Software z samplami z Digi Drum (tak, jak i produkcja Iron Soft)?
Digi drum?
TTL logika dodatnia - "0" - 0V, "1" - 5V. bit startu to "0", następnie idzie 8 bit danej, potem 1 bit stopu - logiczna "1".
Edit: Dane w kolejności od najmłodszego bitu do najstarszego.
Mono - jak dostaniesz kompa (pewnie dziś electron go odbiera z poczty - swoje zrobi to odeśle) - to obaczysz QMEGa. Który może przemapować nr napędu dyskietki (swap np. D3 <-> D1, itp).
O ciekawie. Ale chodzi mi o to, jak to będzie wyglądać kiedy boot będzie z nowego urządzenia bez tricków z remapowaniem właśnie.
Ale dla DOS II/D mamy komendę "JOB namefile". Owe "namefile" trafia do 1.sektora do obszaru 23-63 ($17-$2F). Zawsze domyślnie jest to D1:
Przykład: D1:JOB MEMTEST.COM -> zapisze pod $17 "MEMTEST.COM"
Podczas bootowania uruchomi się test pamięci (a z niego ESC wykona powrót do dosu).
Czyli nawet bez sprawdzania zawartości pierwszego sektora dysku można spokojnie założyć, że bootowano z urządzenia, którego numer jest w DUNIT tak, jak to opisywano parę postów wyżej w tym wątku.
Co do podglądania pod E:
W DOS II/D można dublować linie komend, a co drugą poprzedzać znakiem apostrofu - komentarza, np.
'UNL *.COM
UNL *.COM
Czyli to taki prompt, ale nie o to mi chodziło. Scenariusz jest taki:
Robię sobie program, który będzie ładowany automatycznie przez DOS podczas bootowania (np. jako AUTORUN.SYS). W momencie kiedy DOS przekaże mi sterowanie do tegoż programu chciałbym dowiedzieć się:
1. Z jakiego urządzenia CIO (nazwa i numer) zostałem załadowany i uruchomiony.
2. Z jakiej konkretnie ścieżki odpalony jest program AUTORUN.SYS.
Odpowiedź na 2 nie jest bardzo trudna jeśli jest to AUTORUN.SYS - ładowany z głównego katalogu na dysku. Ale diabeł tkwi w szczegółach :)
Co jeśli użytkownik zechce załadować ten program samemu z linii poleceń (mogę, jak to opisano wyżej, sprawdzić co ostatnio wpisywał w E:; ale co w przypadku kiedy ładował program jakimś managerem...)?
A jeśli dany DOS nie ma AUTORUN.SYS'a tylko plik wsadowy, w którym mogę wpisać listę programów do uruchomienia?
Wydaje się, że problem sprowadza się więc do tego czy na jakiejś podstawie da się sprawdzić skąd nastąpiło załadowanie mojego programu, który właśnie (tuż po załadowaniu) dostał kontrolę.
Jeśli masz jakieś uwagi, to pisz. Jestem na etapie przerabiania QMEGa, zaawansowanie już spore.
Bardzo się cieszę - zaraz podeślę Ci jeszcze maila :)
Chciałbym zapytać o inny wariant problemu.
1. Czy jesteśmy w stanie rozpoznać z jakiego urządzenia i ścieżki ładowany jest program AUTORUN.SYS (DOS2x, MyDOS, Sparta, DOS II+/D)?
2. Analogicznie dla dowolnego programu ładowanego z polecenia wsadowego?
3. Czy da się bootować nie z D: a np. z H: (w systemie jest zdaje się przewidziana możliwość bootowania z nowego urządzenia) - co wtedy z rozpoznawaniem urządzenia, z którego automatycznie załadowano program AUTORUN.SYS lub dowolny program z pliku batchowego?
Interesuje mnie automatyczne ładowanie, bo chyba nie można wtedy skorzystać z podglądania E:?
No piękne. Ja bym się pisał na to. Jaki soft to będzie obsługiwał? KMK?
Tak właśnie mi się zdarzyło.
Właśnie natknąłem się na błąd (tak mi się wydaje) w mads 1.8.5. Assemblacja:
cmp #kończy się generowaniem:
C9 00Poprosiłbym może o jakiś syntax error? Albo przynajmniej warning jeśli to jest usprawnienie.
Używam madsa kompilowanego fpc na ubuntu 9.04 (x86_64).
$ sudo su
<podajesz hasło swojego użytkownika>Z poziomu roota możesz ustawić hasło roota za pomocą
$ passwdpo czym z dowolnego usera możesz już zrobić
$ su
<podajesz hasło rootai jesteś root.
Możesz też skonfigurować dostęp do programów, jako root w pliku /etc/sudoers (polecenie visudo) np. wstawiając tam linię:
piotr ALL=(ALL) ALLi wtedy odpalać programy przez:
$ sudo <program odpalany z uprawnieniami rootaale jak widzę jesteś w grupie admin (w sudoers jest domyślnie %admin ALL=(ALL) ALL) więc powinieneś mieć już możliwość odpalania aplikacji przez sudo.
Z ST nie mam doświadczenia - więcej z 8-bit, dlatego pisałem że odnośnie ST musisz pytać kogoś innego.
Na codzień używam linuxa ubuntu 9.04.
The PC is running linux. Just type in:
pppd crtscts lock 192.168.1.1:192.168.1.2 /dev/ttyS1 115200
jak probowalem to pokazywal sie permision denied
Sprawdź czy twój użytkownik jest w grupie dialout za pomocą:
$ groupsbo tylko wtedy będziesz mógł otworzyć urządzenie do odczytu i zapisu (ttyUSB0 ma uprawnienia rw dla grupy). Jeśli nie ma przeedytuj /etc/group tak, żeby znalazła się tam linia:
dialout:x:<id grupy>:<nazwa twojego usera>np. u mnie to wygląda tak:
dialout:x:20:monoIMHO nie potrzebujesz uruchamiać pppd (który służy do ustanawiania połączeń p2p między hostami w sieci), bo wystarczy że dobierzesz się do łącza szeregowego dowolnym programem umożliwiającym odczyt i zapis z łącza szeregowego (np. wspomnianym minicom'em, czy innym microcom'em).
To co opisałem, to tylko konfiguracja linuxa (też ubuntu, ale 9.04) odnośnie uruchomienia i sprawdzenia kabelka.
Nie mam niestety Falcona. Szczegółów dotyczących Atari musi Ci udzielić ktoś inny :(
Edit: Dzięki za model kabelka - spróbuję go namierzyć i wypróbuję.
Bus 003 Device 006: ID 0403:6001 Future Technology Devices International, Ltd FT232 USB-Serial (UART) IC
To jest raczej to.
usbserial 36232 1 ftdi_sio
Bardzo dobrze. usbserial korzysta z ftdi_sio - sprawdź dalej ftdi_sio za pomocą
$ lsmod | grep ftdi_sioaż trafisz na moduł, który nie korzysta już z innego. Ale te poszukiwania nie są już konieczne w świetle tego co poniżej.
crw-rw---- 1 root dialout 188, 0 2009-11-12 23:59 ttyUSB0
To jest to.
Kabla jeszcze nie zapetlalem z obu stron mam zenskie koncowki ale jak potrzeba to cos takiego zrobie
Jeśli masz wtyczki DB9 to wystarczy pin 2 połączyć drutem z 3.
BTW. Możesz mi podać konkretny model twojego kabla? Sam (jak dało się zauważyć) używam noname'a opartego o prolific pl2303, ale to jest niedobry kabelek i chętnie przesiadłbym się na lepszy.
Po włączeniu przejściówki do usb polecenie:
$ lsusb
powinno ci ją pokazać (zależy od modelu przejściówki jaki posiadasz, ale najczęściej coś z pl2303). Ponadto:
$ lsmod
powinien pokazać załadowany automatycznie moduł pl2303 właśnie.
Z kolei:
$ ls -ltra /dev/ | tail
powinno pokazać urządzenie ttyUSBx (gdzie x to nr urządzenia od 0 włącznie).
Sprawdzić transmisję można zapętlając kabel i malując:
$ picocom /dev/ttyUSB0
wciskanie literek powinno dawać echo (przy niezapętlonym nie zobaczysz nic).
Hehe. Fakt!
Hmmm. Faktycznie jest na szybie PBI zanegowany więc teoretycznie elektronika mogłaby nim wyłączać w dowolnej chwili pakiet fp. Znane są takie przypadki w istniejących urządzeniach? Może są jakieś zalecenia firmy ATARI co do konstruowania nowych urządzeń?
@drac030: nie wiem skąd się wzięło to "podnoszenie" romów, ale odkąd pamiętam zawsze w ten sposób określaliśmy (z kolegami) wyłączenie romu i włączenie ramu :) Może z c64 - w podręczniku Bohdana Frelka ( http://www.starekompy.pl/frelek.jpg ) przy konfigurowaniu pamięci rysunki przesuwały części pamięci to w górę, to w dół...
Dzięki.
W atariki i tym wątku wyczytałem, że rom nowego urządzenia włączany jest tylko na czas operacji i/o.
Analiza kodu procedury reset i przerwań maskowalnych wskazuje, że ten rom jest włączany przy manipulacjach rejestrem PDVREG ($d1ff), czyli przy wyborze nowego urządzenia (zapalenie konkretnego bitu odpowiadającego urządzeniu), a wyłączany po jego wyzerowaniu.
Czy dobrze więc rozumiem, że kiedy żadne nowe urządzenie nie jest wybrane wtedy zwyczajnie jest tam pakiet fp (o ile rom z systemem jest opuszczony)? Można na tym polegać, czy są jeszcze jakieś sytuacje (prócz podniesienia romu z systemem) kiedy pakiet fp nie jest widoczny dla cpu?
Miło i przyjemnie czasem się zafortepianić.
atari.area forum » Posty przez mono
Forum oparte o: PunBB