2,776 Odpowiedź przez drac030

(273 odpowiedzi, napisanych Programowanie - 8 bit)

Tym samym JIT został w tym wątku wymyślony po raz drugi (pierwszy raz przez mikera wczoraj). Kto następny? :P

Idź do forum: Programowanie - 8 bit

2,777 Odpowiedź przez drac030

(273 odpowiedzi, napisanych Programowanie - 8 bit)

jellonek: nie lubisz Turbo Pascala 3.0? ;)

Sikor: trochę mylisz pojęcia. Emulator software'owy może korzystać z właściwości Antica dla ulżenia sobie w ciężkiej, niewdzięcznej i nikomu niepotrzebnej robocie ;) bo pamięć emulowanego Z80 to ta sama pamięć, do której ma tez dostęp Antic.

W przypadku doczepiania rzeczywistego Z80 z zewnątrz rzecz ma się zgoła inaczej - taki procesor musi mieć swoją pamięć (oddzielną od tej, która jest w Atari), a do zewnętrznej pamięci dostępu nie ma z kolei Antic. Więc porażka. Odwrotnie - żeby Antic korzystał z pamięci Atari, a Z80 miał do niej dostęp z zewnątrz - to już prędzej, ale i tak nie obyłoby się bez makowego cuda służącego do translacji adresów w tę i we wtę, i to, oczywiście, w locie.

Idź do forum: Programowanie - 8 bit

2,778 Odpowiedź przez drac030

(273 odpowiedzi, napisanych Programowanie - 8 bit)

Sikor napisał/a:

4,5% w tej fazie nie jest wcale takim złym wynikiem.

Hmm, "w tej fazie"? A co ty wiesz o fazie, w jakiej się to znajduje :)

Jak po optymalizacji uda sie zrobic około 30% to nawet będzie mozna coś z tym zrobić... ;)

30%? Raczysz żartować. Od początku mówię, że tą techniką się daleko nie zajdzie, a jak z testów wypadnie takie solidne 5% to będzie dobrze.

A inne pytanie natury technicznej: jaky Z80 podłączyc przez port Cartridge-a i wtedy emulować tylko ROM maszynki opartej na Z80, jaki wynik - teoretycznie - moznaby uzyskac dla emulacji ZX-Spectrum (w podstawowej wersji 48K).

Nie bardzo sobie mogę wyobrazić, jak taki układ miałby działać.

Wtedy - wczytując hipotetyczne romy z poziomu Atari - mielibyśmy dostęp do programów na kompy oparte o Z80.

Tylko że one nie tylko ROM-ami się różnią, ale też istotnie konstrukcją - no i są bardziej skomplikowane od spektrusia. Sens ma natomiast danie możliwości załadowania dowolnego programu pod adres $0000 (czyli tam, skąd Z80 startuje) i uruchomienia go, tudzież pracy krokowej, podglądu rejestrów, pamięci itp. I to już mam zrobione :)

Inna sprawa - dołączenie emulacji odczytów obrazów programów (czyli na przykład *.tap z ZX-Spectrum)?

Do tego na razie mi daleko.

Idź do forum: Programowanie - 8 bit

2,779 Odpowiedź przez drac030

(273 odpowiedzi, napisanych Programowanie - 8 bit)

Ale panowie rozumieją, że dotychczasowy "emulator" chodzi z prędkością ok. 4,5% ZX Spectrum, więc np. jeśli w spektrusiu po włączeniu zasilania napis "(c) 1982 Sinclair Research Ltd." się pojawia po 3 sekundach[1], to tu przyjdzie nań poczekać ponad minutę? Więc o jakich demkach tu mowa?

Sikor:

a) ten rejestr nie jest "wykonywany" przez Antica

b) emulację z wyłączonym Antikiem się da zrobić, zysk jest ok. 30% (czyli nie 4,5%, tylko 6,4%), ale nie ma obrazu - a myślę, że slideshow z wyłączoną wizją traci nieco na atrakcyjności.

c) Antic jest procesorem, ale wizyjnym - zasadniczo jest już na niego przerzucone to, co przerzucić było można (czyli tworzenie obrazu i dbanie o to, żeby nie migało mimo przełączania banków pamięci)



[1] nie wiem, ile to trwa, strzelam.

Idź do forum: Programowanie - 8 bit

2,780 Odpowiedź przez drac030

(273 odpowiedzi, napisanych Programowanie - 8 bit)

xxl napisał/a:

po pobraniu nie, po wykonaniu owszem - chociazby JP - a to jest dla nas istotne wykonujemy rozkaz i oczekujemy aktualnych wartosci w rejestrach

Masz rację, JP (HL) jest rozkazem, który nie wymaga zwiększenia PC. Tylko czy on występuje na tyle często, żeby przeniesienie zwiększania z części dekodującej do wykonującej w ogóle na czymkolwiek zaważyło? Moim zdaniem nie - kluczowe znaczenie mają rozkazy często używane w pętlach, a JP (HL) raczej do nich nie należy.

Słowem - to są wszystko szczegóły, warte 1 ramkę na 500 :/ Mało. Wciąż to bardziej przypomina slideshow niż emulator.

xxl napisał/a:

pc nie zawsze sie zwieksza o 1: rodzina ADC, SUB, OR, XOR, CP, INC, DEC, RLC, SRA, JP, CALL itd itd dwa razy robisz aktualizacje pc a wystarczy raz przy rozkazie (bo juz wiadomo co to bedzie) u Ciebie nie wiadomo dlatego 2 razy robisz to samo a cykle leca.

No przecież mówię, że nie bierzesz czegoś pod uwagę :) Bo to jest celowe. Owszem, jak mamy zdekodowany rozkaz CALL, to wiadomo, że za nim są dwa bajty - ale one są "za nim" w przestrzeni adresowej Z80, natomast w przestrzeni adresowej 6502 to już niekoniecznie.

prosze o przykladowy w miare krotki kod z80 z iloscia cykli 6502 w jakim sie wykonal, moze byc lista niepowiazanych rozkazow tylko dla sprawdzenia... od podania przykladu prosze o tydzien czasu na napisanie emula (tydzien jak nie bedzie w przykladowym kodzie udziwnien). moze mi sie uda :-)

Ściągnij sobie z netu ROM Spectruma i działaj :)

Idź do forum: Programowanie - 8 bit

2,781 Odpowiedź przez drac030

(273 odpowiedzi, napisanych Programowanie - 8 bit)

powyzsza petla dekodowania moze byc zmniejszona do 25 cykli (zawsze, a nie 29-51 u Ciebie), tylko trzeba zadbac o wlasciwe korzystanie z rej. y i to wydaje mi sie miejsce ktore pozwoli znacznie przyspieszyc emulacje.

Fakt, można to jeszcze ciut skrócić. Ale urwanie jednego cyklu z dekodowania przyspiesza moją pętlę testową o sześć ramek - z dobrze ponad pięciuset; a zatem przy skróceniu o 4 cykle pętla przyspieszy o 24 ramki, czyli niecałe 5% (w stosunku do emulatora, bo w stosunku do oryginału - o jakieś dwa promile). Oczywiście, to zawsze jest coś, ale jeszcze trochę mało :)

moim skromnym zdaniem procedura dekodujaca powinna byc jak najkrotsza (wykonywana najczesciej) a ciezar aktualizacji rejestru pc spoczywac na procedurze wykonywania rozkazow.

Czemu? Znasz rozkaz, który po pobraniu opkodu nie wymaga zwiększenia PC?

patrzac na to globalnie szybkosc emulacji powinna byc wieksza w moim przykladzie (nawet gdy dorobie stronicowanie po 16kb)

Patrząc globalnie - z punktu widzenia już zrobionego stronicowania - nie wydaje mi się. Prawdopodobnie nie bierzesz paru rzeczy pod uwagę, zwłaszcza w tym całym LD (HL),n. Zaimplementuj, zdebuguj, pogadamy :)

Idź do forum: Programowanie - 8 bit

2,782 Odpowiedź przez drac030

(273 odpowiedzi, napisanych Programowanie - 8 bit)

tebe napisał/a:

skoro jest przeszło 500 rozkazów CPU, to wasze w/w przykłady dekodują ich max 256

Mylisz się :)

Idź do forum: Programowanie - 8 bit

2,783 Odpowiedź przez drac030

(273 odpowiedzi, napisanych Programowanie - 8 bit)

xxl napisał/a:

i to tyle, emulec nie jest taki ciezki do zrobienia cos mi sie wydaje. cos przegapilem?

Prawie nic. U mnie dekodowanie wygląda tak:

nop lda (epc),y
    tax
    lda zzlo,x
    sta ?jp+1
    lda zzhi,x
    sta ?jp+2
    iny
    bne ?jp
    inc pc+1
    ldx pc+1
    lda hicon,x
    sta epc+1
    lda mbank0,x
    sta portb
?jp jmp $ffff

sorry, ale LD (HL),$xx nie chce mi się przepisywać ... :) mniej więcej to samo jest u ciebie, tylko w moim jest bankowanie RAM-u. No i lepsze wykorzystanie rejestru Y.

500 rozkazow :-) ufff to ja chyba zerknalem na inna tabele rozkazow z80 :-) zlamilem :-)

W tej, co ja mam, jest ich 564. Ale podobno są też jakieś nielegalne.

Idź do forum: Programowanie - 8 bit

2,784 Odpowiedź przez drac030

(273 odpowiedzi, napisanych Programowanie - 8 bit)

miker napisał/a:

może coś w typie konwertera, który "przetłumaczyłby" asm spektrumowski na pure 6502 assembler? To, o czym już kiedyś kolega Pirx wspomniał...

To jest właśnie JIT (patrz posty wyżej). http://en.wikipedia.org/wiki/Just-in-time_compilation

xxl napisał/a:

a wtedy z 18 cykli robi sie od 8, bardzo rzadko 15 a w szczegolnym przypadku 19

No, dobrze, ale gdzie tu zalety uproszczonej organizacji RAM-u, skoro oszczędności w porównaniu do wersji 64k (bankowanej) są groszowe albo żadne (istotna różnica jest tylko przy przekraczaniu granicy stron, co występuje bardzo rzadko)? Chyba tylko tyle, że uruchomienie emulca nie wymaga 130XE.

A na dodatek weź pod uwagę, że przy zajęciu 32k na pamięć emulowanego procesora masz spore szanse, że program emulatora nie zmieści ci się w pozostałym obszarze - Z80 ma dobrze ponad 500 rozkazów :)

BTW. zredukowałem dekodowanie do 29 cykli w najczęstszym przypadku (max. 51).

Idź do forum: Programowanie - 8 bit

2,785 Odpowiedź przez drac030

(273 odpowiedzi, napisanych Programowanie - 8 bit)

48 cykli na NOP-a = dużo. U mnie, gdyby nie konieczność bankowania pamięci, maximum byłoby 36 cykli. Tak samo przy ld (HL) - sprawdzenie, czy ROM, kosztuje 12 cykli (EDIT: jednak 4 :)); a jak nie ROM, to pamięć trzeba przełączyć dwa razy. No i tak to idzie.

Idź do forum: Programowanie - 8 bit

2,786 Odpowiedź przez drac030

(273 odpowiedzi, napisanych Programowanie - 8 bit)

PC aktualizowany jest przy dekodowaniu, a potem przy wykonywaniu też, jeśli to potrzebne.

Co do najdłuższego rozkazu, to trudno orzec. Np. pozornie prosty rozkaz LD I,A zajmuje bardzo dużo czasu, bo ma prefiks, a prefiks dorzuca do czasu wykonywania rozkazu od 34 do 56 cykli. Czyli mamy w najlepszym przypadku 32 dekodowanie + 34 prefiks + 9 wykonanie = 75 cykli. W najgorszym - 22 więcej (97).

JR NZ,disp:

* niewykonany: 32+19, 32+41 albo 54+19 cykli
* wykonany wstecz na tę samą stronę: 32+36 cykli
* wykonany wstecz na inną stronę: 32+55 cykli
* wykonany w przód na tę samą stronę: 32+37 cykli
* wykonany w przód na inną stronę: 32+56 cykli

LD (HL),$xx:

* niewykonany (adres wskazuje ROM): 32+32, 32+54 albo 54+32 cykle
* wykonany: 32+67, 32+89 albo 54+67 cykli

EDIT: policzyłem od nowa czasy ostatniego rozkazu.

Idź do forum: Programowanie - 8 bit

2,787 Odpowiedź przez drac030

(273 odpowiedzi, napisanych Programowanie - 8 bit)

xxl: 32-54 cykle, jak napisałem, to dekodowanie opkodu, bez wykonania rozkazu (chyba, że to NOP, który nic innego więcej nie robi).

ld r,$xx u mnie to 32 cykle na dekodowanie + 19 na wykonanie, razem 51 - znowu, najszybszy przypadek (best case). Najgorszy: 54 cykle dekodowania + 19 wykonania (73), albo 32 cykle dekodowania + 41 wykonania (też 73).

Przypominam, że u mnie emulowany Z80 ma całe 64k pamięci. :)

dely napisał/a:

nie chcesz pisać po to, żeby używać, tylko żeby pokazać, że się da lub dla "dobra narodu i partii" :)

No, ale dobrze by było, żeby było też choć trochę używalne przy okazji, nieprawdaż? ;) Poza tym poczytałem o ZX80/81 w wikulcu i nie wiem, czy to nie cięższy przypadek niż ZX Spectrum - w spektrusiu ULA tworzy obraz, więc da się do tego łatwo zatrudnić Antica i sprawa jest z głowy. A w ZX80/81 obraz wytwarza Z80 ... :)

Idź do forum: Programowanie - 8 bit

2,788 Odpowiedź przez drac030

(273 odpowiedzi, napisanych Programowanie - 8 bit)

dely napisał/a:

Może faktycznie nie warto się brać od razu za ZX Spectrum tylko coś prostszego - ZX 80/81?

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.

Idź do forum: Programowanie - 8 bit

2,789 Odpowiedź przez drac030

(273 odpowiedzi, napisanych Programowanie - 8 bit)

Ja (jak już niektórzy wiedzą) od czasu sztabu wyszedłem nieco poza same przemyślenia. Konkretnie napisałem trochę kodu - i rezultat jest niezadowalający. Zresztą chyba pirx doszedł już przedtem do takich samych wniosków.

To co zrobiłem, to emulator "klasyczny" (z pętlą interpretującą kolejne rozkazy). 64k pamięci Z80 to cztery (z pięciu) banków pamięci znajdujących się w 130XE pod adresami $4000-$7FFF. Maszyna emulowana to ZX Spectrum, więc w jednym z banków jest ROM systemu operacyjnego, w pozostałych RAM (łącznie z pamięcią obrazu).

Sekwencja dekodująca opkod ma w "best case" 9 rozkazów 6502 zajmujących 32 cykle (worst case jest dużo gorszy - 15 rozkazów, 54 cykle - ale występuje tylko w 0,94% wszystkich przypadków). Tyle dokładnie czasu wykonuje się NOP. NOP na Z80 zajmuje 4 cykle, a że Spectrum ma zegar 3,5 MHz, więc te 4 cykle trwają tyle, co dwa na Atari. Ergo, taki NOP wykonuje się idealnie z wydajnością 6,25% oryginału, a w rzeczywistości - ze względu na działalność Antica - nieco ponad 4%. Taką też szybkość - 4% oryginału - rozwija ZX OS przy początkowym zerowaniu pamięci. I nie sądzę, żeby tą metodą się dało wycisnąć wiele więcej.

Jak o tym była mowa na sztabie, rozwiązaniem może być JIT.

Idź do forum: Programowanie - 8 bit

2,790 Odpowiedź przez drac030

(15 odpowiedzi, napisanych Sprzęt - 8bit)

hetteh napisał/a:

gdy widzi go jak zbiorowisko flopów, to mimo, że podłączony jest 2gb twardziel, to i tak maksymalna pojemność 1 dyskietki jest mniejsza niż 2MB.

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.

hetteh napisał/a:

draco030: ale to i tak 32MB partycji * 15 = 480MB. Czy 32MB jednej partycji to ograniczenie spowodowane 8bitowym prockiem, czy z jakiś innych względów?

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ść.

Idź do forum: Sprzęt - 8bit

2,791 Odpowiedź przez drac030

(15 odpowiedzi, napisanych Sprzęt - 8bit)

DOS z prawdziwego zdarzenia istnieje, jest to SpartaDOS X w bieżącej wersji, z limitem wielkości partycji do 32 MB i limitem ich liczby do 15. Wersja 4.40 będzie na Forevera (jak się wszystko uda).

Idź do forum: Sprzęt - 8bit

2,792 Odpowiedź przez drac030

(15 odpowiedzi, napisanych Sprzęt - 8bit)

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

Idź do forum: Sprzęt - 8bit

2,793 Odpowiedź przez drac030

(709 odpowiedzi, napisanych Fabryka - 8bit)

Pytanie do konstruktora: czy przy pomocy "mapy kolorów" mozna nakładać atrybuty na obraz generowany przez Atari, tak żeby np. w zwykłym GR. 8 można było zaemulować atrybuty ZX Spectrum albo C-64? Jeśli tak, to czy można poprosić o jakiś obrazek demonstracyjny? Nie musi być ładny, byle by było widać, jak to działa ...

Idź do forum: Fabryka - 8bit

2,794 Odpowiedź przez drac030

(221 odpowiedzi, napisanych Sprzęt - 8bit)

jellonek napisał/a:

Ty sie nimi nie interesujesz

"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? ;)

(co widac m.in. po proponowanych przez ciebie mikrokontrolerach - praktycznie u nas nie uzywanych) :P

A 6502 jest u nas używany? :P

tak na prawde to roznic jest niewiele miedzy tymi mikroprockami i poza nielicznymi przypadkami (tak, o Ciebie rowniez tu chodzi ;) ), ktos kto zna jednego assemblera, nie powinien miec "odrazy" do innych...

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.

kwestia zwiazana z tym ze "nikt sie nie interesuje" jest bardziej zwiazana z tym ze malo kto w ogole sie interesuje assemblerem, bo przeciez turbobasic jest taki szybki :/

Tak, TBXL... albo CC65.

(programy ktore dostosowywales do nowej sparty, czy do 816OSa odwoluja sie przez handler K: ?)

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.

Idź do forum: Sprzęt - 8bit

2,795 Odpowiedź przez drac030

(221 odpowiedzi, napisanych Sprzęt - 8bit)

jellonek napisał/a:

tu akurat nie trafiles - karta sieciowa nie potrzebuje uniwersalnego mikroprocka - wystarczy uklad kontrolera, kapke ramu i kilka linii sterujacych (skoro 8051 potrafi tym sterowac, to atarka tym bardziej...)

Ok, to zależy, co umie "układ kontrolera". Niemniej obróbka np. pakietów TCP/IP, wydaje mi się, wymaga sporo pamięci, a wobec tego słuszne jest, żeby ta pamięć była na karcie. A jeśli pamięć - to pewnie mi mikroprocesor też. Ale jeśli można BEZ, to ja osobiście jak najbardziej byłbym za. Nie ma co strzelać z armaty (a co dopiero laserowej) do wróbli, zwłaszcza że są na wymarciu ;)

Poza tym nie ma co ukrywać, zależy mi na tym, żeby uniknąć stosowania mikrokontrolerów tam gdzie się da po to, żeby uniknąć sytuacji, jaka powstała na Atari ze stacjami dysków. Niektóre są nawet programowalne - tylko co z tego, skoro są oparte na Z80 albo 8080, których programowaniem na Atari nikt się nie interesuje. A przecież poza wszystkim (czyi użytecznością urządzenia) chodzi też o trochę koderskiej rozrywki, nie tylko dla konstruktora, ale też dla usera - żeby mógł sobie obejrzeć kod sterownika albo go ewentualnie poprawić, jeśli sa błędy.

Będą oczywiście przypadki, kiedy mikrokontrolera nie da się uniknąć, jeśli chce się mieć np. szybką stację dysków, która nie wyłącza Antica podczas transmisji itp. ;) Ale wtedy - 65C134 czy 65C256 to też są mikrokontrolery, nieprawdaż.

co do klawiatury - "Atarka otrzyma gotowy keycode": jesli masz na mysli ze program odczyta kod znaku - to nie tylko o to chodzi, bo wazne sa "eventy" czyli: key up, key down.

Dokładnie.

(ps. jakos nie widze mozliwosci "pelnej kompatybilnosci" klawiatury podpinanej inaczej niz pod pokeja)

Zależy, co rozumiesz pod pojęciem "pełna zgodność". Oczywiście jeśli ludek (programista) każe programowi odczytywać skankody z Pokeya, bo inaczej nie umie/nie zna się/tak łatwiej, to żaden handler na to nic nie poradzi. Ale programy odczytujące klawiaturę z urządzenia "K:" będą spokojnie działać. Te które nie będą działać, podzieli się na dwie klasy: potrzebne (te się poprawi) i niepotrzebne (te się skasuje). ;)

Idź do forum: Sprzęt - 8bit

2,796 Odpowiedź przez drac030

(53 odpowiedzi, napisanych Zloty)

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

Idź do forum: Zloty

2,797 Odpowiedź przez drac030

(221 odpowiedzi, napisanych Sprzęt - 8bit)

No można, ale po co marnować miejsce (w HATABS mieści się tylko 11 wpisów). Zresztą nadpisać istniejący wektor jest łatwiej, niż dodać drugi taki sam, jest do tego procedura w OS-ie.

Idź do forum: Sprzęt - 8bit

2,798 Odpowiedź przez drac030

(221 odpowiedzi, napisanych Sprzęt - 8bit)

toriman napisał/a:

drac030 - no i tu jest leciutka skucha bo klawiatury PC wysyłają owszem kody, i owszem - po swojemu, i owszem czasami jest tego całkiem sporo :(

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

Szkoda by było zajmować atarkę obsługą takich bzdetów jak tłumaczenie kodów z PC na Atari ( szkoda czasu )

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.

A AKI to niby co jest ? ;-)

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?

W końcu wykorzystanie mocy Atari osiągnie 100% i co wtedy... ?

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.

Kiedyś był niejako przymus projektowania "na piechotę" i sam widziałem
FDD 8" zbudowane w oparciu o kilogram (albo więcej) scalaków TTL - a przeciez nie o to chodzi.

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.

Jeśli mam skutecznie rozwalić brzęczącego komara nie zawaham się użyć lasera jeśli to mi da 100% pewności, że już go nie usłyszę

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.

Idź do forum: Sprzęt - 8bit

2,799 Odpowiedź przez drac030

(221 odpowiedzi, napisanych Sprzęt - 8bit)

toriman napisał/a:

Po co zwalać na Atarynkę osługę jakiejś klawiatury ?:)

A co tu jest do zwalania, przecież klawiatura piecowa właście "gotowe keycody" wysyła. Wystarczy je przełożyć na ATASCII, co i tak trzeba robić wewnątrz komputera (a nie na karcie), bo to wewnątrz kompa jest tablica definicji klawiatury, ... tak więc, podtrzymuję, overkill i to znaczny. :)

EDIT: przy tym karta klawiatury bardzo dobrze pozwoli wypróbować, czy działa generowanie przerwań IRQ przez urządzenie.

Idź do forum: Sprzęt - 8bit

2,800 Odpowiedź przez drac030

(221 odpowiedzi, napisanych Sprzęt - 8bit)

toriman napisał/a:

drac030 - przewiduję tak z lekka, że na kartach nowych urządzeń zagoszczą na dobre mikrosterowniki :) Myślę, że użycie do budowy jakiegoś PICa czy ATMEGA wcale nie bedzie bezsensowne.

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.

Idź do forum: Sprzęt - 8bit