Przejdź do treści forum
atari.area forum
Twoje polskie źródło informacji o Atari
Nie jesteś zalogowany. Proszę się zalogować lub zarejestrować.
Aktywne tematy Tematy bez odpowiedzi
Aktualności ze świata Atari
Forever 2025 - już wkrótce! Coroczne spotkanie entuzjastów platform takich jak Atari, Commodore, ZX Spectrum oraz innych komputerów 8-bitowych.
7th Annual Atari Homebrew Awards Oczywiście nie zabrakło polskich akcentów.
Wyniki FujiCup 2024 Sprawdź, czy były niespodzianki!
Mad Pascal 1.7.2 Optymalizacje, poprawki błędów oraz nowe funkcjonalności.
Tydzień na oddanie głosu w FUJICUP! Głosowanie potrwa tylko do 22 lutego 2025...
Opcje wyszukiwania (Strona 70 z 176)
A przypadkiem w MegaSTE proc już nie jest podkręcony? Do 16MHz?
Ty wiesz, kto po tej butelce stąpał... :)
Wielu może nie, ale to jest akurat najbardziej kompetentna osoba, a mianowicie sam projektant urzadzenia :) Jedyny problem to taki, że wydaje sie być dość zajety, ale może uda Ci sie wstrzelić ;)
@BartoszP: to zabawne ale akurat tak jest w ActionScript - co prawda dotyczy to długości nazw zmiennych :) Tzn w ciele funkcji to nie ma wielkiego znaczenia ale wewnatrz petli jak najbardziej - czas wykonania petli zależy proporcjonalnie od długości nazw zmiennych w środku a najbardziej od iteratora dlatego daje sie i albo j. Podobnie jest w wiekszosci interpreterów.
Jak zamaknie to znowu trzeba będzie naprawiać :)
Ja się piszę na sztukę, może i ze 2 - jedno pytanie - czy tylko prototyp jest taki duży czy tak już ma zostać? Moim celem jest wpakowanie bebechów optycznej myszy usb do oryginalnej obudowy Atari czy Amigi, a z tym to się nie uda.
willy napisał/a:niektóre myszy nie wspierają protokolu BOOT. W chwili obecnej wszystkie szanujące się myszy to wspierają
Co za czasy - myszka się bootuje... Jak dostanę pierwszą informację o patchu do zasilacza, przechodzę na emeryturę i wyjeżdżam w Bieszczady. Kiedyś wszystko było prostsze...
swinkamor12 napisał/a:Nie mam nic przeciwko ciekawym rozszerzeniom starego sprzetu, jesli jest w tym jakas logika i naturalna kontynuacja tego co ten sprzet potrafi. Np taki atari z coldfire. To jest wypas 264 MHz. Oczywiscie jeszcze lepiej by bylo jakby sie udalo atarowcom zrobic atari z powerpc. To dopiero bylby mega wypas.
O i tak właśnie umarła Amiga. Poprzez nieuzasadnioną wiarę, że z trupa da się zrobić współczesną maszynę i włączenie do przegranej z góry walki o megabajty i megaherze. Wyścig się nie udał - bo nie technologią rynek się zdobywa - a komputer stracił swój charakter.
Tymczasem rozszerzenia do małego Atari inną zupełnie inną drogą i NIE ZMIENIAJĄ charakteru maszyny (tak jak robi to Coldfire czy współczesne "Amigi" przerabiane z MacIntoshy). Najbardziej rewolucyjnym i ew. zmieniającym charakter tak naprawdę jest VBXE - nie Rapidus - i jak widać wykorzystanie jest umiarkowane.
Dokładnie - obie ceny "już od" mogą mówić o różnych konfiguracjach - trzeba by było porównać te same. A tu różnica jakieś 15% raptem. Przy tym co po ujednoliceniu konfiguracji będzie się różnić (pewnie będzie już kilka procent) można zrzucić na różnice podatkowe/walutowe/koszty importera.
Adam Klobukowski napisał/a:Z punktu widzenia asemblera to dwie różne instrukcje robiące dwie różne rzeczy
W sensie MULU.W i MULU.L ? Czy źle rozumiem? Wytłumacz mi na czym polega różnica (poza długością słowa) bo nie kumam w takim razie.
swinkamor12 napisał/a:Z punktu widzenia programisty ważna jest długość int w C.
Większej głupoty w życiu nie czytałem. A co ma kompilator C wspólnego z budową procesora? Nawet na małym Atari w C możesz mieć int 32 bity.
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).
I się zgadza:
http://www.youtube.com/watch?v=aY_sukuVKGc
(eg innej nomenklatury odc. 022) ten fragment od 11:30.
Według:
http://pl.wikipedia.org/wiki/Sonda_%28s … .85_emisji
i ponieważ na filmie jest rok (89) wydaje się że może to być odcinek nr 461 - "Liczyć aby żyć" (opis: "Komputery w sklepie, hotelu, restauracji, projektowaniu dźwigów, bankowości.")
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 :)
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ę.
marekp napisał/a:"To akurat nie musi być wielki problem" - no nie wiem... Dla mnie to był problem
Ok, bo mnie to zaciekawiło. Problem to jest jeśli zechcesz z klawiatury ST zrobić klawiaturę podłączaną do PC przez USB/PS-2/DIN-5. Czyli z zewnątrz. Trzeba dodać koder sygnałów - podobny do Eifell (klawiatura od PC dla ST) tylko w drugą stronę.
Sytuacja się zmienia jeśli grzebiesz się już wewnątrz w bebechach - a to wyraźnie robić autor wątku. Po prostu pomijasz / usuwasz sterownik klawiatury ST i podłączasz do sterownika PC samą folię - tu oczywiście teoretyzuję , bo nie wiem teraz bez schematu jaka jest różnica w liniach sygnałowych. Ale nawet jeśli taka jest to konwersja to już jest drutologia. Dlatego z ciekawości pytam - na którym etapie podłączenia miałeś problem :)
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 :)
To akurat nie musi być wielki problem - wystarczy, że pominie sterownik klawiatury ST i zrobi połączenia na poziomie linii wprost od klawiszy. Zauważyłem ostatnio w swoim laptopie, że sterownik klawiatury znajduje się na płycie a od samej klawiatury idzie szeroka taśma - nie ma żadnej elektroniki. Zakładając pewne różnice może to być czysta drutologia.
Spróbuj na ebay.co.uk, widziałem paru gości sprzedających same obudowy, klawiatury etc.
Sikor napisał/a: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.
swinkamor12 napisał/a: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 :)
Atic Atac , Sabre Wulf - trzeba przyznać, że Ultimate miało swój styl i był on świetny - animacja bohatera i stworów niezwykle prosta - chyba nawet dwuklatkowa a mimo to ładnie, dynamicznie i grywalnie.
Z tymi myszami jest ciekawa sprawa - praktycznie wszystkie PS/2 (przynajmniej te z którymi się spotkałem) przechodzą bezboleśnie konwersję na USB. Konwersja na RS-232 była podobnie problematyczna jak powyższa - z niektórymi działało, z niektórymi nie. Przypuszczam że problemem mogły być różne warianty protokołów na które PS/2 - USB są gotowe a Atari/Amiga/RS-232 nie. Czy ktoś, kto się na tym zna mógłby zasugerować dlaczego? Może dałoby się prościej działające myszy identyfikować. Albo usprawnić przejściówki. A może jest to kwestia DPI / szybkości transmisji danych?
To zależy:
http://atarionline.pl/forum/comments.ph … ionID=2171
Jak się pogrzebie po aukcjach, jest całkiem sporo drukarek które zadziałają.
Faktycznie teraz zwróciłem uwagę na maskę z przodu. Ale pod spodem jest szuflada na drugi napęd i ciekawy jest też zestaw wtyczek - oprócz SIO wystaje jakiś DIN - może ktoś sobie zrobił stacjo-zasilacz :)
Atarka jak Atarka, ale ta stylowa obudowa flopa... Co to jest??
http://www.ebay.ie/itm/Atari-800xl-plus … rames&
hash=item4d17b32543
Znalezione posty [ 1,726 do 1,750 z 4,377 ]
Forum oparte o: PunBB
Currently installed 7 official extensions. Copyright © 2003–2009 PunBB.
Wygenerowano w 0.124 sekund, wykonano 13 zapytań