O tym też była mowa na sztabie - nie wiadomo, czy się to opłaci, bo pytanie brzmi, czy na ZX80/81 istnieje jakiś program, dla którego warto byłoby uruchamiać emulator; że o pisaniu nie wspomnę.

Poza tym spektruś jest naprawdę bardzo prosty: składa się z Z80, 64k pamięci oraz układu ULA, który ma *jeden* rejestr sprzętowy (port 254). W związku z tym emulator zawiera kod emulujący rozkazy Z80 (z czego rozkazy IN i OUT emulują wspomniany rejestr), tablice służące do adresowania RAM-u, Display List i ... nic poza tym.

No i tu widzę nieporozumienie. Owszem, SIO2IDE obsługuje "zbiorowisko flopów" (fizycznie będących plikami ATR), ale taki "flop" może mieć jak dotąd taką samą wielkość, co partycja twardego dysku.

Tak jak napisał Sikor, to jest ograniczenie filesystemu SpartaDOS. Nie ma to związku z 8-bitowym procesorem, po prostu filesystemy dla Atari przestały się rozwijać tak gdzieś koło 1984 roku - a wtedy, i jeszcze długo potem, 16 MB dysku to był kosmos.

Ograniczenie do 16 czy 32 MB wynika z tego, że filesystem jest 16-bitowy, czyli ma do 65535 sektorów. Przy użyciu zwykłego protokołu SIO (z którego korzysta np. SIO2IDE) nie da się wyciągnąć więcej. Jednak "prawdziwy" twardy dysk nie jest podłączony przez SIO, a więc ogranicznie do dwóch bajtów na numer sektora nie dotyczy go - stąd istnieje możliwość poszerzenia adresowania sektorów na partycjach do np. 24 bitów. To jest zaimplementowane w interfejsie KMK/JZ od początku (czyli od 12 lat), ale nie powstał jeszcze DOS, który byłby w stanie wykorzystać tę możliwość.

hetteh: jellonek ma rację w pierwszych czterech wyrazach swojego posta.

"Nikt" jest z pewnością przesadą, ale niewielką - zamiast dokładnie oddającego sytuację "prawie nikt". O tym natomiast nie świadczą moje chęci, tylko ilość oprogramowania, które korzysta z mozliwości przesłania programu do stacji LDW, CA-2001, TOMS Turbo, TOMS Multi, TOMS 720... oraz liczby (zerowej) toolsów deweloperskich na Atari służących do programowania w Z80 i Intelu. Na TOMS-a 720 nie ma nawet toolsów do Multiego, bo są napisane w zecie, a TOMS 720 ma Intela. Mówi to panu cos? ;)

A 6502 jest u nas używany? :P

To nie kwestia odrazy - to kwestia czasu. Wolę poświęcić wolny czas na robienie tego, co lubię, zamiast poświęcać go na zgłębianie czegoś, co mnie nie interesuje i jest nieużyteczne (bo za rok-dwa "w modzie" będą już inne mikrokontrolery). I także wolę swoją wiedzę wykorzystywać praktycznie (do kodowania) zamiast głosić, iż między mikroprocesorami nie ma żadnej różnicy, nie napisawszy przy tym ani jednej linijki kodu :P Teoretyk może różnicy między Intelem a 6502 nie widzi. Ja różnice widzę nawet między m68k a 6502.

Tak, TBXL... albo CC65.

Mam nadzieję, że niczego nie przeoczyłem. Sama Sparta natomiast ma jeszcze miejsca, gdzie nie odwołuje się przez handler "K:" (w zasadzie tylko formatter, bo jest nie w tym banku kartridża co ogólna procedura odczytu klawiatury), ale to się poprawi.

Ja widziałem go na sztabie w Warszawie i to nie raz.

Wiem o tym. Wysyłaja po kilka bajtów. Zapewniam cię, że 6502 sobie z tym świetnie poradzi.

Czy ty aby trochę nie przesadzasz? Translacja tych kodów nie wymaga transformaty Fouriera, to dwie tabelki na krzyż i góra kilkaset bajtów kodu - wykorzystanie ROM-u newdev jak sięgnie przy tym 25%, to będzie dobrze.

AKI to jest emulator firmowej klawiatury Atari przyczepiany do Pokeya  - czyli zupełnie co innego. Zresztą, wyjaśnij mi proszę kwestię, jaką postawiłem w poprzednim poście: jak zewnętrzny procesor ma dokonać translacji funkcji klawiszy na ASCII w oparciu o tablicę definicji klawiatury, KTÓRA JEST W PAMIĘCI ATARI A NIE KARTY?

Wykorzystanie mocy Atari sięgnie 100% przy obróbce skankodów klawiatury? Czy ty aby *lekko* nie przesadzasz? :P Niby co ma atarkę obciążać? Przecież przy urządzeniach I/O takich jak klawiatura, gdzie ilości transmitowanych danych są takie, że poradziłby sobie z tym dalekopis z czasów wojny, wykorzystanie procesora jest w zasadzie żadne. A przy urządzeniach gdzie transfery są intensywne (w rodzaju twardego dysku), 6502 i tak albo odczytuje dane z portu I/O, albo czeka w pętli, niezaleznie od tego, czy wsadzisz między komputer a dysk jeden mikroprocesor więcej czy nie.

Ale komu dzisiaj jest potrzebna ośmiocalowa FDD z kilogramem scalaków? :) Poza tym akurat FDD to jest takie urządzenie, że oddzielny mikroprocesor musi mieć - ale nie dlatego, że to dobre i nowoczesne :P tylko z zupełnie przytomnego powodu: tandem 6502 + Antic nie wyrabia się na odbiór danych szeregowych z kontrolera FDD.

Weź jeszcze przy tym pod uwagę, że karty pewnie niektórzy będa chcieli zmontować sobie w domu. Nie ma więc sensu komplikować ich konstrukcji ponad miarę - oczywiście do konwersji kodu klawiaturowego na ASCII można zatrudnić nawet Pentium 4; tylko po co, skoro ten interfejs można zrobić z kilku prostych scalaków dostępnych za grosze w każdym sklepie, a handler dla 6502 będzie nie dłuższy (albo będzie i krótszy) niż oryginał odczytujący skankody z Pokeya?

PS. SIO2IDE oczywiście znam, ale jakoś nie rzuca mnie na kolana.

Ee, no, zależy do czego :) Wsadzanie na kartę oddzielnego procesora tylko po to, żeby obsługiwał klawiaturę od pieca albo UART typu SCC to lekki overkill moim zdaniem. W innych przypadkach - np. wymarzonej przez Sikora karty sieciowej - bez oddzielnego mikroprocesora się oczywiście nie obejdziemy.

Ok, jak dla mnie bomba.

Co do kart, niezła na początek mogłaby być karta pozwalająca podpiąć klawiaturę od peceta. Oczywiście nie na drodze emulacji Pokeya, tylko normalnie wpinająca swój driver w system jako urządzenie "K:". Elektronicznie taka karta nie powinna być trudna, driver do ROM-u mogę napisać, to raczej banalne zadanie. Oczywiście karta też musiałaby mieć oprócz dwóch gniazd (AT i PS/2) wajchę ON/OFF, żeby można było ją prosto wyłączyć, gdyby nie była potrzebna (to znaczy gdyby się chciało skorzystać z defaultowej klawiatury i oryginalnych procedur OS-u).

Innym niezbyt skomplikowanym, a pewnie przydatnym urządzeniem byłaby chyba karta RS-232C z jakimś UART-em zapewniającym dobre prędkości (np. 115,2 kbps), hardware flow control itp. To też mogę oprogramować.

U Fiszera jest całkiem spoko, to niezły pomysł - o ile będą miejsca.

No tak. Może wyjaśnię, czemu się czepiam. Oczywiście, od przybytku głowa nie boli, ALE gniazdo kartridża wchodzi również w skład gniazda CART/ECI. A zatem, biorąc rysunek ext_board6.gif, gdzie są 3 gniazda CART, oraz jedno CART/ECI, mamy na nim w sumie CZTERY gniazda kartridży.

To jest mało ekonomiczne, bo prawdopodobieństwo, że wszystkie będą obsadzone, jest chyba równe zeru; a to dlatego, że większość kartridży żre się miedzy sobą i na raz wetknięte być nie mogą, jak już była o tym mowa powyżej.

Dlatego wydaje mi się, że optymalny układ to jedno CART/ECI plus jedno CART. Wtedy, kiedy ktoś nie używa ECI, ma dwa gniazda CART i może sobie w nie włożyć np. SpartaDOS X w jedno, a R-Time8 w drugie (pod warunkiem, że ma - ale np. ja mam ;)). Wszelkie dodatkowe kartridże, np. BASIC XL czy Action, i tak trzeba wsadzić w przelotowy kart Sparty, żeby to działało AFAIK.

Dobrze byłoby mieć tez możliwośc wyboru, które gniazdo ma być aktywne (jedno, drugie, albo oba). To na wypadek, gdyby ktoś np. chciał raz uzywać BASIC-a XE, a raz Action...

Natomiast jeśli ktoś używa ECI, wtedy będzie miał wolne jedno gniazdo CART (i postąpi tak samo, jak z wtykaniem kartridży do komputera, gdzie też jest jedno gniazdo). Ale generalnie zakładam, że gniazdo CART/ECI na ekspanderze to tylko proteza do użytku tak długo, jak nie powstanie zastępnik danego urządzenia w postaci właściwej karty. Z chwilą, kiedy powstanie, jego jedyną funkcją będzie robienie za dodatkowe gniazdo kartridża.

Tak to sobie mniej więcej wyobrażam.

To znaczy, praktycznie, żeby było jasne: planujesz zamontowanie dwóch gniazd CART, oraz jednego oddzielnego zespołu CART/ECI - czyli razem trzech CART + jednego ECI - dobrze rozumiem?