Odp: Czy Atari 400/800 miały być (pseudo) 16 bitowymi komputerami ??
hahahahahhh - dobre ;)
Nie jesteś zalogowany. Proszę się zalogować lub zarejestrować.
4th Atari ASCII Compo - wyniki Dostępne są już wyniki tegorocznego ATASCII Compo.
thing neo 1.60 Olivier Landemarre wydał nową wersję desktopu Thing.
VIII. Basque Tournament of Atari 2600 Kolejna relacja, wśród otrzymywanych od naszego przyjaciela Egoitza z Kraju Basków.
Przezroczysta obudowa dla Atari 800XL Rusza przedsprzedaż wyjątkowej, przezroczystej obudowy do komputera Atari 800XL!
RECOIL 6.4.5 RECOIL to przeglądarka retro plików graficznych, obsługująca ponad 550 formatów, dostępna na różnych systemach operacyjnych, z regularnymi aktualizacjami.
Strony Poprzednia 1 2 3 4 5 6 Następna
Zaloguj się lub zarejestruj by napisać odpowiedź
hahahahahhh - dobre ;)
Rozumie się samo przez się że atari 400/800 nigdy nie miały być 16 bitowymi komputerami.
32 bitowym Atari miał być komputer który stał się później Amigą, tyle że Commodore zapłacił więcej.
Atari ST to już była żałosna próba dogonienia Amigi i na 100% nikt by tam nie wsadzał 16 bitowego procesora gorszego niż ten w macu czy Amidze.
Atari ST to już była żałosna próba dogonienia Amigi
Śmiem wątpić. Amiga była projektowana jako konsola do gier, w dziedzinie muzyki i DTP do pięt nie dorastała ST. I - aby było śmieśniej - monitor mono dla DTP był wybawieniem...
Ale nie zaśmiecajmy wątku - nie ten dział.
re up: Coś w tym jest, Na większości reklam prasowych (lata 80-90) Atari ST jest pokazywane jako maszyna do DTP, Muzyki, Baz danych, Pisania, gry pokazują się w ogłoszeniach sprzedaży (że też są). W przypadku Amigi jest dosłownie odwrotnie, gry, rozrywka (no ale też można napisać list i niewiele więcej). To tylko takie luźne spostrzeżenie, btw w latach 90tych sprzedałem Amigę 1200 i kupiłem Atari STE z Calamusem, do pracy. (Czyli jakbym się uwstecznił sprzętowo)
dziedzinie muzyki i DTP do pięt nie dorastała ST
Trzymajmy się faktów - te cechy zostały zdeterminowane wyłącznie oprogramowaniem/strategią marketingową, nie sprzętem. Po prostu te zastosowania Amigi nie były tak znane/popularne - z prostego powodu : Amiga była droższa. Zarówno MIDI jak i DTP miało miejsce na Amidze - tylko Amiga nie była do tego potrzebna i interfejs trzeba było dokupić osobno - wystarczyło ST.
400/800 nigdy nie miały być 16 bitowymi komputerami. 32 bitowym Atari miał być komputer który stał się później Amigą
Twoje "nigdy" jest bardzo pewne siebie, prawie jakbyś był członkiem zespołu projektowego. Natomiast Twoja wypowiedź zawiera dziurę logiczną, domyśl się gdzie :)
@wieczór: nie miała interfejsu, jak sam wspomniałeś - a interfejs midi był droższy od samej Amigi. W ST to był strzał w 10-kę. Tak samo jak monitor mono - dla wczesnego DTPto było błogosławieństwo. Natomiast ST było gorsze w grafice jako takiej - a co się z tym wiąże - w grach. Choć i tak wolę STE od A500 (ten modulator, co co chwila dawał obraz czarno-biały) ;P Ale jak napisałem - nie offtopikujmy, nie ten dział.
Rozumie się samo przez się że atari 400/800 nigdy nie miały być 16 bitowymi komputerami.
32 bitowym Atari miał być komputer który stał się później Amigą, tyle że Commodore zapłacił więcej.
Atari ST to już była żałosna próba dogonienia Amigi i na 100% nikt by tam nie wsadzał 16 bitowego procesora gorszego niż ten w macu czy Amidze.
no niezły troling,
po pierwsze, amiga miała być konsolą a nie komputerem (widać to po jej konstrukcji - parę istotnych funkcji 'komputera' zostało usuniętych);
po drugie amiga nie była 32bitowa tylko 16bitowa;
po trzecie Atari nie chciało projektu Jay Minera, więc odszedł on z Atari by samemu utworzyć nową konsolę.
po czwarte Atari lepiej wyszło na ST niż Commodore na amidze które to zbankrutowało parę lat wcześniej.
no i po piąte ST było lepszym komputerem niż amiga.
Trzymajmy się faktów - te cechy zostały zdeterminowane wyłącznie oprogramowaniem/strategią marketingową, nie sprzętem
no nie wiem, w/g mnie te cechy zostały zdeterminowane właśnie sprzętem. Np. dzięki zdecydowanie lepszej rozdzielczości/jakości obrazu ST czy choćby twardym dyskiem.
palnales glupote
Nawet wiem, co będzie dalej: za jakiś czas (parę lat pewnie) zrozumiesz, jak to działa i o czym tu była mowa. I wtedy przybiegniesz na forum z "kolejnym epokowym odkryciem".
Tak po ludzku to Ci nawet współczuję.
no niezły troling,
Fakty
po pierwsze, amiga miała być konsolą a nie komputerem (widać to po jej konstrukcji - parę istotnych funkcji 'komputera' zostało usuniętych);
Po pierwsze z tego co można sprawdzić w umowie między Amiga a Atari miała być komputerem a nie konsolą.
po drugie amiga nie była 32bitowa tylko 16bitowa;
po drugie amiga nie była 16bitowa tylko 32bitowa;
po trzecie Atari nie chciało projektu Jay Minera, więc odszedł on z Atari by samemu utworzyć nową konsolę.
To po co z nim umowę podpisywali w 1983?
Tę można łatwo znaleźć. Atari chciało by komputer który znamy Amiga był nowym Atari.
po czwarte Atari lepiej wyszło na ST niż Commodore na amidze które to zbankrutowało parę lat wcześniej.
Tylko po to by się wyłożyć na Jaguarze.
no i po piąte ST było lepszym komputerem niż amiga.
no i po piąte ST było gorszym komputerem niż amiga.
Np. dzięki zdecydowanie lepszej rozdzielczości/jakości obrazu ST czy choćby twardym dyskiem.
ST miało gorszy obraz niż Amiga, niestety Commodore pokpiło sprawę i do A500 nie było łatwo podłączyć twardego dysku.
Jakby tu różni kota ogonem nie wykręcali, 65816 pojawiło się już po tym jak Atari kombinowało z Amigą, więc na pewno następcą atari 400/800 byłby jakiś 32 bitowy sprzęt z 68000 a nie 16 bitowy z 65816.
@swinkamor12: zarówno Amiga 500 jak i ST były komputerami 16-bitowymi. Może chodzi Ci o Amigę 1200 ?
Ostatnio edytowany przez Rastan (2014-01-31 10:01:34)
Procesor Motorola 68000 jest procesorem 32-bitowym więc sprzęt był 32 bitowy choć z otoczeniem komunikował się szynami mniejszymi niż 32 bity.
Na tej samej zasadzie IBM XT był 16-bitowy bo miał architekturę procesora 8086 choć szyny miał przycięte do 8-bit w procesorze 8088.
Procesor Motorola 68000 jest procesorem 16-bitowym, z co najwyżej z 32-bitowymi rejestrami (często pisze się 16/32). Ale nie jest to procesor 32-bitowy. Była już o tym dyskusja. Podstawowym czynnikiem decydującym o tym czy ilu bitowy jest procesor jest ALU. Inne elementy nie mają wpływu (albo mają marginalny wpływ). Z dokumentacji procesora 68000 wynika, że jego ALU jest 16-bitowa.
Dodam jeszcze, że jeśli chodzi o Amigę 500 to cała architektura, połączenie procesora z układami, szyny danych jest 16-bitowa i jeśli czynnikiem o jej 32-bitowości miałby być procesor to jest to czynnik nie wystarczający. A nawet jeśli tak jest, to ST też jest komputerem 32-bitowy.
Ostatnio edytowany przez Rastan (2014-01-31 10:45:34)
http://www.ppa.pl/forum/amiga/29460/motorola-68000
Panowie, nie idźcie tą drogą;)
Jest takie źródełko - apropos Motoroli - które pozwoli odpowiedzieć sobie na to pytanie : Programmer's Reference Manual wydany przez Motorolę. Widać tam wyraźnie dwie rzeczy :
a) MC68000 jest procesorem 16-bitowym - mimo posiadania 32-bitowych rejestrów - operacje arytmetyczno logiczne wykonuje z reguły na słowach (W - 16-bit) - wynik oczywiście może być 32-bitowy. Te same instrukcje mają wariant operacji na longach (L- 32-bit) dla procesorów 68020/030/040 (i wyżej - wydanie które miałem nie przewidywało nowszych). Inny jest też rozmiar danych dla operacji adresowych.
b) W wymienionym manualu jest wyraźnie wyróżniona rodzina MC68000 i MC68020/030/040 - akronim CPU32 jest używany do tej drugiej grupy. Te procesory nie różnią się wyłącznie szerokością szyny danych (jak 386SX i DX) ale zasadniczo rozmiarem danych dla operacji arytmetyczno-logicznych.
To jest chyba zasadniczy argument - jeśli producent procesora wprost nakreśla granicę pomiędzy CPU16 i CPU32 z dobrym uzasadnieniem w liście rozkazów - gdzie wymienia się wyraźnie na których procesorach jaki rozmiar danych dla danych instrukcji jest dopuszczalny. W świetle tego Amiga 500 / Atari ST to komputery 16-bitowe ; 32-bitowe to Amiga 1200 / Atari TT / Falcon. A skrót ST to marketingowa papka :)
Ostatnio edytowany przez wieczor (2014-01-31 12:33:36)
Cyprian napisał/a:no niezły troling,
Fakty
raczej Fanbojowanie, np jeśli chodzi o konkrety to np to:
po drugie amiga nie była 16bitowa tylko 32bitowa;
to:
ST miało gorszy obraz niż Amiga,
to:
no i po piąte ST było gorszym komputerem niż amiga.
i to:
Po pierwsze z tego co można sprawdzić w umowie między Amiga a Atari miała być komputerem a nie konsolą.
ad 1) amiga jest 16 bitowa gdyż ma 16bitową architekturę: 16 bitową szynę danych, 16 bitową organizację pamięci, w OCS/ECS obraz pobierany jest w 16 bitowych porcjach, jest też tam 16-bitowy blitter ( nawet A1200 ma stary 16bitowy blitter :) )
ad 2) ST oferuje obraz 72HZ, amiga 50hz interlace. Co jest lepsze VGA czy migający TV?
ad 3) kwestia gustu, dla dzieciaka/amatora gier/konsol może i amiga była lepsza, ale w przeciwieństwie do amigi, ST był sprzętem wykorzystywanym przez profesjonalistów do profesjonalnych zadań. Oczywiście oprócz tego oferował możliwość grania w gry na przyzwoitym poziomie.
ad 4) Temat wiele razy wałkowany, Jay Miner tak właśnie definiował amigę. Zresztą sam możesz znaleźć sporo informacji na ten temat w sieci, np tu:
" Rozpoczęto prace nad prototypem Amigi - pierwotnie miała to być konsola do gier. "
http://amigarlz.w.interia.pl/story.htm
http://www.ppa.pl/publicystyka/historia … amigi.html
Zresztą konsolowość widać po tym że zbędę z punktu widzenia konsoli (ale istotne z punktu widzenia komputera) elementy nie zostały zaimplementowane: brak ochrony pamięci rejestrów (bus error), brach trybów User/Superuser, czy chociażby błąd implementacji obsługi instrukcji TAS (zawiesza ona amigę)
proponuję nie zaśmiecać tego wątku i albo nie kontynuować tego wątku dyskusji albo przenieść go do nowego miejsca.
zresztą tego typu tematy były tu wielokrotnie wałkowane, wystarczy sięgnąć do archiwum
Ostatnio edytowany przez Cyprian (2014-01-31 12:37:46)
wieczór: dokładnie tak jest. Dzięki za przypomnienie tego źródła.
MC68000 jest procesorem 16-bitowym - mimo posiadania 32-bitowych rejestrów - operacje arytmetyczno logiczne wykonuje z reguły na słowach (W - 16-bit) - wynik oczywiście może być 32-bitowy.
Nie zgodzę się.
Seria 68K od początku była zaprojektowana jako architektura 32-bit.
Czymś innym jest realizacja sprzętowa a czymś innym architektura logiczna. Rejestry A i D są rejestrami 32 bitowymi, PC, SP jest 32 bitowy. To czy procesor ze światem czy też jego bloki wewnętrzne połączone są przez 8/16/32 bit nie ma specjalnie wpływu na jego bitowość. Na wydajność tak ale nie na model programistyczny. Przynajmniej dla tej architektury.
Na tej samej zasadzie to czy w samochód osobowy wsadzimy silnik benzynowy/disel/gaz nie wpłynie na jego "osobowość". Nawet zamontowanie kasety do przewozu pieniędzy nie zrobi z niego pancernego bankowozu a kratka nie robi z niego ciężarówki. Oczywiście w przeciwną stronę też...z traktora nie zrobisz "osobówki" montując 2 rząd siedzeń.
Gdyby decydować na podstawie szerokości wewnętrznych/zewnętrznych szyn o architekturze procesora, to robiąc emulator np. Z80 procesorem ARM 64 bit, to ten emulowany procesor nie staje się przez to 64-bitowy choć wszystkie operacje robione by były w 64-bit a tylko wynik przycinany do 8 bit.
Rozkazy 68K od zawsze miały znacznik (w asm był to sufix .l, .w, .b) oznaczający odpowiednio 32/16/8 bitów wyniku. To czy ALU jest 8-mio czy 16-sto czy też 32-wu bitowe nie ma wpływu IMHO na funkcjonalność procesora.
Pozostaję więć przy zdaniu, że Motorola 68000 to architektura 32-bit, która w różnych wykonaniach miała/mogła mieć realizację sprzętową 8/16/32 bit.
Tak mi dopomóż ATARI.
Ale doczytałeś do końca? Wyraźnie napisałem, że szerokość szyny danych nie ma znaczenia. To architektura jest 16-bitowa. I nie, rozmiar rejestrów to jeszcze nie architektura. Motorola wyraźnie rozgranicza 2 rodziny procesorów - te same instrukcje w w MC68xx000 działają na słowach , a w MC68xx20/30/40 - na longach (32-bity). To jest architektura.
Gdyby się upiąć do rozmiaru rejestrów tylko i wyłącznie to 6502 zawiera 16-bitowy rejestr.
Wszystko co procesor robi to operacje logiczne i arytmetyczne - więc logiczne jest że rozmiar danych dla tych operacji wyznacza jego "bitowość". I 68000 nie jest "w różnych wykonaniach" - we wszystkich wariantach jest 16-bitowy. 68020 to nie jest "wykonanie" 68000 - masz nowe instrukcje, nowy rozmiar danych na których operują te stare - a co za tym idzie, nową architekturę.
Ostatnio edytowany przez wieczor (2014-01-31 14:27:03)
BartoszP: może zdefiniuj co to znaczy, że architektura procesora jest 32-bitowa. Wcześniej pisałeś, że procesor jest 32-bitowy. Jaka jest różnica pomiędzy procesorem 32-bitowym, a procesorem o architekturze 32-bitowej ? Co decyduje o tym, że mamy do czynienia z procesorem 32-bitowym lub procesorem o architekturze 32-bitowej.
Z Twojego postu wynika, to, że procesor jest 32-bitowy jeśli ma 32-bitowe rejestry. To jest nieprawda, procesor Z80 ma 16-bitowe rejestry, ale nikt o nim nie mówi, że to jest procesor 16-bitowy, ani nawet, że jego architektura jest 16-bitowa. 80486 ma 80-bitowe rejestry koprocesora, a również jest to li tylko procesor 32-bitowy. To nie rejestry decydują o tym ilu jest bitowy procesor, ani o tym jaka jest jego architektura.
BartoszP, czytałem parę dokumentacji o 68000 no i jest ona zgodna z tym co wspomina Wieczor.
68000 ma 32bitowe rejestry ale wewnętrznie jest to procesor 16bitowy (ALU są już 16 bitowe)
Tutaj jest ciekawy artykuł z roku 1983 http://www.easy68k.com/paulrsm/doc/dpbm68k1.htm
"A 16-bit processor with multiple 32-bit registers."
"The MC68000 has a 16-bit-wide ALU that essentially performs all data calculations and provides single-pass evaluation of the 16-bit data, for which the MC68000 is primarily designed. There are also two other internal arithmetic units. Both are 16 bits wide and are generally used in conjunction with each other to perform the various address calculations associated with operand effective addresses."
Ostatnio edytowany przez Cyprian (2014-01-31 14:28:16)
Motorola wyraźnie rozgranicza 2 rodziny procesorów - te same instrukcje w w MC68xx000 działają na słowach , a w MC68xx20/30/40 - na longach (32-bity).
Eee? Które?
Chociażby mnożenie:
MULU.W < ea > ,Dn
*MULU.L < ea > ,Dl - applies to MC68020, MC68030, MC68040, CPU32 only
To samo z dzieleniem. No dobra, nie wszystkie :)
wieczór: to nie są 'ta sama instrukcja'. To są dwie różne instrukcje.
To chyba kwestia nomenklatury - Motorola opisuje to jako jedną i tą samą instrukcję MULU z postfiksem .W i .L - czego najwyraźniej nie traktuje jako zasadniczą część instrukcji - a jedynie jako sprecyzowanie romiaru danych.
http://www.freescale.com/files/archives … 000PRM.pdf , strona 242 (4-138)
I faktycznie, kod maszynowy instrukcji jest inny, jednak z punktu widzenia assemblera instrukcja jest ta sama. Zresztą we wprowadzeniu opisują jak szczególny przypadek instrukcji jest spójny z przypadkiem ogólnym i jakie są zasady ich tworzenia (w sensie bitów poszczególnych pól kodu).
Strony Poprzednia 1 2 3 4 5 6 Następna
Zaloguj się lub zarejestruj by napisać odpowiedź
[ Wygenerowano w 0.104 sekund, wykonano 9 zapytań ]