No prosze - sasiedzi ze wschodu potrafili gniazda SIO wyprodukowac. Respext.
No faktycznie, takie gniazdo SIO - to wyzwanie na miarę epoki lotów kosmicznych :lol:
Nie jesteś zalogowany. Proszę się zalogować lub zarejestrować.
Prototyp gry Raiden dla Falcona Prototyp zaginionej konwersji kultowego Raiden na Atari Falcon ujrzał światło dzienne.
Steem SSE 4.2.0 R11 Ukazała się aktualizacja Steem SSE, popularnego emulatora komputerów Atari ST dla systemów Windows i Linux.
Larek i Drwal 1.3: User Friendly Nowy odcinek kursu programowania w asemblerze 6502.
HDDRIVER 13.01 Aktualizacja HDDRIVER przynosi poprawki dla HDDRUTIL oraz lepszą obsługę szybkiego sprzętu.
192p Test Suite dla 8-bitowego Atari Nowy program do testowania i kalibracji obrazu dla Atari XL/XE od HanJammera.
atari.area forum » Posty przez drac030
No prosze - sasiedzi ze wschodu potrafili gniazda SIO wyprodukowac. Respext.
No faktycznie, takie gniazdo SIO - to wyzwanie na miarę epoki lotów kosmicznych :lol:
A co najważniejsze takie rozwiązanie było by najbardziej zgodne z orginalnym atari.
Oprócz tego, że to nie byłoby Atari, tylko zwykły blaszak.
Jak sie ktoras komenda odbierze prawidlowo, to dalej stacja pracuje z rozpoznana predkoscia, az do chwili ponownego "niezrozumienia" komendy, wtedy znowu nastepuje zmiana predkosci i kolejna proba odbioru.
Tak, to pewnie tłumaczyłoby też, dlaczego stacje TOMS Multi mają tendencje do losowego "wylatywania" z ultry od czasu do czasu ...
Wedle mej wiedzy protokół Ultra Speed w ogóle niczym się nie różni od "normalu". Komenda "?" niczego nie przełącza, ona tylko zwraca komputerowi wartość, którą należy ustawić w AUDF3/4 do pracy w US. I to jest wszystko.
Z tego co wiem, nie ma też tak, żeby komputer po poprawnej odpowiedzi stacji na "?" musiał zmienić częstotliwości do pracy z SIO, albo, że musi tę komendę w ogóle wysyłać (SpartaDOS X na przykład nie wysyła). Wykrycie, że komputer chce prowadzić transmisję w ultrze stacja (o ile mi wiadomo) robi mierząc długości początkowych bitów wysyłanej komendy (chyba, długość impulsu bitu startu po prostu).
A pokey powiniem miec mozliwość przełączenia wszystkich kanałów na 1.79 MHz przy 16 bitowej częstotliwości. (Czyli jakieś dodatkowe 9 rejestrów)
No ale po co, przecież można to (chyba) osiągnąć montując - czy też programując w FPGA - po prostu drugiego Pokeya.
Stad moj pomysl przeniesienia wnetrza Atari do programowanych matryc logicznych.
Pecuś, pomysł jest - moim zdaniem - dobry; ale:
1) ktoś musi te matryce (FPGA czy co tam) zaprogramować; jeśli jesteś w stanie to zrobić, to nie bardzo pojmuję, do czego ci potrzebna szeroka akceptacja? Zwłaszcza, że sam piszesz, iż nie byłby to projekt komercyjny; odpada ci troska o rynek i konieczność przyjęcia projektu przez aklamację.
2) wydaje mi się, że odtworzenie takich scalaków jak Antic może być trudniejsze niż się na pierwszy rzut oka wydaje. Zwłaszcza chodzi tu o jego całą współpracę z resztą komputera, z procesorem, z GTIA. Ile czasu, twoim zdaniem, zajęłoby stworzenie i przetestowanie takiej matrycy, zanim nadawałaby się do użytku?
3) ile to by wszystko kosztowało? Ktoś na forum - nie wiem, czy nie ty sam - wspominał, że matryce FPGA są drogie. Co to znaczy "drogie" w tym wypadku?
Oczywiście, ta droga ma jedną zaletę: jeśli wymyśli się np. lepszego Antica, to nie trzeba go produkować, wystarczy przeprogramować matrycę.
Anitc, między nami mówiąc, a ściślej tandem Antic/GTIA, wymaga moim zdaniem tylko jednego ulepszenia: dodatkowego rejestru, albo dodatkowego bitu w DMACTL, którym dałoby się podwoić poziomą rozdzielczość wszystkich trybów graficznych (aczkolwiek może mam za małe wymagania :))
Pokey też wymaga tylko jednego: żeby miał w środku kilkubajtowe FIFO na dane odbierane albo nadawane na złącze szeregowe.
drac030 eee nie wal tu fochow...podeslij kase na moje konto to wtedy wysle kase za nas obu ;]
Dzięki za ofertę, ale nagła choroba babci nie pozwala mi kontynuować transakcji :P
not an option
Ok, to przelicz na nowo ceny - bez mojego udziału. Wycofuję się.
odnosze wrazenie ze marnuje czas
Więc może zamiast tego załóż sobie konto w mbanku. Razem z odesłaniem umowy potrwa to krócej niż bujanie się z przekazami. By nie wspomnieć, że jest tańsze i łatwiejsze.
potem powiesz, ze na zmiany juz za pozno, ludzie powiedza 'aha, trudno' i wszystko bedzie git :)
Jak nie będzie na pokładzie interfejsu do twardego dysku (połączonego równolegle) i SDX, to ja olewam :P :D ;)
Tak, mi też przyszło na myśl, że to wygląda jak ściema. Na dobrą sprawę ktoś mógł wziąć manual od 65c816 i przerobić go w paru miejscach, a potem opchnąć kolekcjonerom jako sensację. Pieczątkę "PRELIMINARY" może sobie zrobić każdy.
Przeglądałem trochę strony o Apple II potem (głównie jakieś fora zdechłe ostatecznie cztery lata temu) i są tam jednak wzmianki, że WDC wyprodukowało "a dozen" (dla mnie to jest 12) prototypów.
Dla mnie główna porażka tutaj to wciąż ośmiobitowa szyna danych, no i oczywiście brak nowych rozkazów. A na te jest miejsce nie tylko pod WDM, ale też zamiast 128 zarezerwowanych rozkazów COP.
Nie wiem, czy to widzieliście:
http://apple2.org.za/gswv/a2zine/Docs/CPU_65832/
Manual od nie istniejącego procesora WDC 65C832. Przejrzałem to z grubsza i muszę stwierdzić, że to jest proste powielenie pomysłu, który doprowadził do powstania 65C816:
- procesor ma 32-bitowe rejestry A, X i Y (reszta bez zmian)
- ma oczywiście trzeci już tryb pracy: natywny 32-bit
- i ma oczywiście trzeci zestaw tych samych wektorów przerwań, tym razem pod $00FFD0
Piszą tam, że jest 16 MB na "program space" oraz 4 GB na "data space" - to z powodu, że wszystko generalnie jest tak samo jak w 65c816, oprócz tego, że rejestry X i Y są 32-bitowe; w związku z tym indeksowane tryby adresowania mogą generować 32-bitowe adresy. Nie wiem jednak, jak to się ma do faktu, że szyna adresowa jest 24-bitowa (co zresztą jest napisane - ale nie objaśnione - na stronie zatytułowanej "INTRODUCTION").
Tryb natywny 32-bitowy włącza się bitem E16, który stanowi cień bitu V rejestru znaczników tak samo, jak bit E (zwany obecnie E8) stanowi cień bitu C. Służy do tego oddzielny rozkaz: XFE. Ale jaki ten rozkaz ma opcod, tego nie znalazłem. Można byłoby przypuszczać, że to jest to, co w 65c816 zaznaczono jako WDM - gdyby XFE i WDM nie figurowały razem na liście rozkazów 65C832.
Z ciekawostek, na stronie TOC1 jest podpis Steve Woźniaka.
Ja się co prawda nie znam na hardwarze i w związku z powyższym nie mogę powiedzieć, co jest padnięte, ale za to znam się na sofcie i mogę odpowiedzieć na pytanie, w jakich warunkach system operacyjny ustawia kolor ekranu na czerwony.
Otóż - w żadnych. Na początku jest pętla opóźniająca, która liczy sobie jakieś 180 tysięcy cykli, a potem, w ciągu kilkudziesięciu cykli system dociera do pętli, która zeruje wszystkie rejestry I/O, co oczywiście ustawia kolor ekranu na czarny.
Wniosek: jeśli RAM jest sprawny, i ROM jest też sprawny i ma poprawną zawartość, to znaczy, że komputer zamiast ROM-u widzi jakieś śmieci. Czyli, w wyniku "innego" uszkodzenia, po włączeniu zasilania ROM nie pojawia się w obszarze $C000-$FFFF.
Hope this helps :rolleyes:
Pokey (nomoze bez przetwornikow A/C i C/A)
Bez C/A, to znaczy, bez możliwości odtwarzania sampli?
Feeling ważna rzecz, ale do oryginalnej obudowy od 65XE to raczej niewiele wejdzie.
Poza tym bez twardziela na pokładzie to raczej nie uchodzi.
Ja chcę dwie na 65XE.
Aye, sir. Ale przede wszystkim Sparta X *zna* ten protokół transmisji, a Sparta 3.2 (o ile mi wiadomo) - nie. I stąd moje pytanie.
Może o to, że stacja z załadowanym synchromeshem (czy też super synchromeshem, bo nie napisałeś jasno, w jakich dokładnie warunkach się to dzieje) jakoś źle reaguje na próby komunikacji w ultra-speedzie. Bo Sparta 3.2 chyba tylko ultrę zna (ale może się mylę).
Jak to się zachowuje pod Spartą X?
Zamawiam 2 szt. procków W65C816S8PL-14 (PLCC) oraz 2 szt. VIA W65C22S6PL-14 (PLCC)
2 resetuje kompa i probuje wczytac dysk np serious #15 :) i dupa - wczytuje w normalu - straasznie dlugo
No bo komputer sam z siebie nie umie rozmawiać ze stacją w turbo - to rozmawia w normalu. Do turbo potrzebny jest programik, który się przyczepia do przerwań serialowych i dokonuje niezbędnego szacher-macher (jak w TOMS-ie, ale programik z TOMS-a nie pójdzie). Takowy programik ma doczepiony wspomniany loader XDIR_LDW.SYS i z tego co pamiętam to działało.
Aha, XDIR jest do formatu SpartaDOS :-)
2. Czy jest mozliwe wczytywanie w tym trybie skladanek gier itp., ?
Synchromesh to nie jest program dla komputera, ale dla stacji. Więc jak go raz wczytasz, to jest w niej do wyłączenia jej zasilania. W tym czasie ewentualny loader może współpracować ze stacją w trybie turbo. Zobacz http://drac030.krap.pl/xdir-original.tar.gz, plik XDIR_LDW.SYS.
3. Czy transmisja przy wlaczonym synchromesch przyspiesza we wszystkich gestosciach, czy tylko w podwójnej?
Powinna we wszystkich.
A jaka jest różnica pomiędzy DOS 4.0 (Atari - nie Michael Barral) "w linkach", a tym w archiwum z wszystkimi?
[ Dodano: 14.03.2005 16:34:11 ]
PS. QDOS "mój" i QDOS "twój" to jest identiko to samo. Różnią się tekstem w zajawce, oraz tym, że "twój" działa.
[ Dodano: 16.03.2005 15:08:32 ]
To jest ciekawe, bo na pierwszy rzut oka widać, że handlery stacji dysków to nie są normalne ROM-y PBI. Nie ma typowego nagłówka ze znacznikami itd., a poza tym wyglądają mi na stronicowane po 256 bajtów.
Może ROM był walnięty?
TOMS 720 toleruje wartości AUDF3/4 z zakresu od 37 do 42, a z tego co pamiętam z moich eksperymentów, Atari 1050 miała dokładnie tak samo. Jest to z grubsza po 5% w każdą stronę od "standardowej" szybkości, i różnica PAL versus NTSC (ok. 1% jeśli nie mylę się w obliczeniach) mieści się w tym zakresie z wielkim zapasem.
A krap już 850 uruchomił :-)
przydało by się pozbyć "ograniczeń" partycji 16MB
Nad tym pracuje się ;)
W twojej wersji w tekstach były też $FF zamiast literek
A tego nie zauważyłem. Gdzie te $FF-y? W helpie?
atari.area forum » Posty przez drac030
Wygenerowano w 0.141 sekund, wykonano 20 zapytań