31.08.2020 23:32
[#32]
Re: 68EC020 a 16MB RAM
@wali7, post #31
Mala ciakwostka.
Mozna miec w Amidze A500 nawet 2GB pamieci bez uciekania sie w 020.
Wiadomym jest ze zamontowanie takiego procesora wiaze sie z problemami z sygnalami VPA/VMA/E,
ktore trzeba odpowiednio obramkowac.
Mozna to zrobic ekonomiczniej tyle ze trzeba zdobyc procesor ktory jest pewnie jeszcze
trudniejszy do zdobycia niz 060.
A tym procesorem jest 68012
Mozna miec w Amidze A500 nawet 2GB pamieci bez uciekania sie w 020.
Wiadomym jest ze zamontowanie takiego procesora wiaze sie z problemami z sygnalami VPA/VMA/E,
ktore trzeba odpowiednio obramkowac.
Mozna to zrobic ekonomiczniej tyle ze trzeba zdobyc procesor ktory jest pewnie jeszcze
trudniejszy do zdobycia niz 060.
A tym procesorem jest 68012
01.09.2020 00:06
[#36]
Re: 68EC020 a 16MB RAM
@WyciorX, post #33
A mnie interesuje inna sprawa zwiazana z KickStartem.
Skad system wie z jak duzym KS ma doczynienia.
KS 1.3 ma 256 KB i zaczyna sie od adresu $00FC0000, pozniejsze maja 512KB i zaczynaja sie od $00F80000.
Oba koncza sie na ostatnim bajcie w przestrzeni 16MB.
Podmiana KS1.3 na nowszy powoduje ze z automatu system rozpoznaje calkowita dlugosc
i ustala poczatek przestrzeni dla KS.
Jaki mechanizm tym rzadzi?
Skad system wie z jak duzym KS ma doczynienia.
KS 1.3 ma 256 KB i zaczyna sie od adresu $00FC0000, pozniejsze maja 512KB i zaczynaja sie od $00F80000.
Oba koncza sie na ostatnim bajcie w przestrzeni 16MB.
Podmiana KS1.3 na nowszy powoduje ze z automatu system rozpoznaje calkowita dlugosc
i ustala poczatek przestrzeni dla KS.
Jaki mechanizm tym rzadzi?
01.09.2020 00:15
[#37]
Re: 68EC020 a 16MB RAM
@WyciorX, post #35
Warto tylko dodać, że mimo obecności jedynie 23 linii adresowych, 68000 adresuje dokładnie tyle samo (czyli 16 MB) co mający 24 linie 68EC020.
68000 ma bowiem 16 bitową magistralę danych, dzięki czemu odczytuje po wystawieniu adresu odczytuje od razu dwa bajty (czyli słowo): starszy jest zawsze spod parzystego adresu i młodszy, który jest zawsze nieparzysty, więc może adresować co dwa bajty, a dostęp ma do obydwu (procek ma w środku logikę która w przypadku operacji na nieparzystych bajtach ignoruje starszy, parzysty bajt). Dzięki temu można było zaoszczędzić jedną nóżkę i kilka tranzystorów, a procesor miał dostęp do pełnych 16 MB... w czasach powstawania 68000 (koniec lat 70) takie oszczędności robiły różnicę.
Chyba dopiero 68020 miał obecny najmłodszy bit magistrali adresowej, dzięki czemu potrafi także zrobić odczyt gdzie starszy bajt jest spod adresu nieparzystego.
68000 ma bowiem 16 bitową magistralę danych, dzięki czemu odczytuje po wystawieniu adresu odczytuje od razu dwa bajty (czyli słowo): starszy jest zawsze spod parzystego adresu i młodszy, który jest zawsze nieparzysty, więc może adresować co dwa bajty, a dostęp ma do obydwu (procek ma w środku logikę która w przypadku operacji na nieparzystych bajtach ignoruje starszy, parzysty bajt). Dzięki temu można było zaoszczędzić jedną nóżkę i kilka tranzystorów, a procesor miał dostęp do pełnych 16 MB... w czasach powstawania 68000 (koniec lat 70) takie oszczędności robiły różnicę.
Chyba dopiero 68020 miał obecny najmłodszy bit magistrali adresowej, dzięki czemu potrafi także zrobić odczyt gdzie starszy bajt jest spod adresu nieparzystego.
01.09.2020 00:31
[#38]
Re: 68EC020 a 16MB RAM
@Phibrizzo, post #36
Na początku kickstartu znajduje się instrukcja skoku, ks1.3 skacze pod FC, a 2.0 pod F8, zakodowane na sztywno. Podejrzyj KS hexedytorem, to sam zobaczysz. Poza tym, nawet jakby KS1.3 skakał pod F8, to nie ma to znaczenia, bo układ KS 256kb ma mniej linii adresowych, niż jest przeznaczone dla kickstartów, przez co pojawia się on i pod F8 i pod FC, a jeżeli płyta dekoduje kickstarty 1MB, to jeszcze pod E0 i E4.
Ostatnia aktualizacja: 01.09.2020 00:36:56 przez WyciorX
Ostatnia aktualizacja: 01.09.2020 00:36:56 przez WyciorX
01.09.2020 02:14
[#40]
Re: 68EC020 a 16MB RAM
@Don_Adan, post #39
A po co dwie instrukcje, skoro kickstart po resecie pojawia się zawsze pod adresem 0? Pierwszą instrukcją kickstartu 512kb jest skok do exec'a. W KS2.0+ jest to skok pod F8, a w W KS1.3 na początku jest instrukcja skoku do FC, ot cała filozofia "detekcji".
Ostatnia aktualizacja: 01.09.2020 02:29:19 przez WyciorX
Ostatnia aktualizacja: 01.09.2020 02:29:19 przez WyciorX
01.09.2020 10:18
[#43]
Re: 68EC020 a 16MB RAM
@WyciorX, post #40
No widzisz, obawiam sie ze Ty tego tez nie rozumiesz jak to dziala.
Eksperyment myslowy: Zakladam do Amigi 500 KS 1.3 ale zapisany w EPROMie 512 KB
w taki sposob ze drugie 256KB jest puste (wypelnione zerami).
I co teraz?
Wg Ciebie nastapi skok do adresu $00FC00000. Czyli gdzie? W pustke.
Dan_Adan ma racje. Sa dwie instrukcje skoku. Jedna na poczatku a druga dokladnie w polowie.
Sprawdzilem pod HexEdytorem.
I wg mnie dziala to w taki sposob ze hadrware Amigi po resecie, gdy procesor probuje
czytac dane z pod adresu $0, podstawia mu zmapowane dane z pod adresu $00FC0000 (takie mikro MMU).
Skad nastepuje skok do wlasciwego adresu $00F80000.
Uwazam wg mnie, ze inaczej nie moze to dzialac.
Czy ktos moze potwierdzic/zaprzeczyc moja teorie?
Ostatnia aktualizacja: 01.09.2020 10:25:50 przez Phibrizzo
Eksperyment myslowy: Zakladam do Amigi 500 KS 1.3 ale zapisany w EPROMie 512 KB
w taki sposob ze drugie 256KB jest puste (wypelnione zerami).
I co teraz?
Wg Ciebie nastapi skok do adresu $00FC00000. Czyli gdzie? W pustke.
Dan_Adan ma racje. Sa dwie instrukcje skoku. Jedna na poczatku a druga dokladnie w polowie.
Sprawdzilem pod HexEdytorem.
I wg mnie dziala to w taki sposob ze hadrware Amigi po resecie, gdy procesor probuje
czytac dane z pod adresu $0, podstawia mu zmapowane dane z pod adresu $00FC0000 (takie mikro MMU).
Skad nastepuje skok do wlasciwego adresu $00F80000.
Uwazam wg mnie, ze inaczej nie moze to dzialac.
Czy ktos moze potwierdzic/zaprzeczyc moja teorie?
Ostatnia aktualizacja: 01.09.2020 10:25:50 przez Phibrizzo
01.09.2020 12:20
[#44]
Re: 68EC020 a 16MB RAM
@WyciorX, post #40
Spytaj sie inzynierow z Commodore. Ja sam nigdy tego nie sprawdzalem, wiec nie wiem. Ale podejrzewam, ze dla A500 (niektorych modeli?) laduje sie tam obszar spod $fc0000, a nie spod $f80000. Byc moze to jest kwestia jakiegos ukladu Amigowego? Albo moze chodzi o reset z klawiatury? W kazdym razie we wszystkich ROM-ach Commodore pod adresem $fc0000 jest skok do execa albo do poczatku ROMu 512KB a stamtad nastepny skok do execa.Dotyczy to tez ROMow do A1200, A3000 czy nawet A4000T. Wiec w zasadzie taki 0.5MB ROM z Commodore to sa jakby 2 czesci po 256KB.
01.09.2020 13:02
[#45]
Re: 68EC020 a 16MB RAM
@Don_Adan, post #44
Spytaj sie inzynierow z Commodore. Ja sam nigdy tego nie sprawdzalem, wiec nie wiem. Ale podejrzewam, ze dla A500 (niektorych modeli?) laduje sie tam obszar spod $fc0000, a nie spod $f80000. Byc moze to jest kwestia jakiegos ukladu Amigowego?
Tak. W momencie aktywacji sygnalu RESET, niezaleznie od tego czy jest to reset zewnetrzny (z klawiatury na przyklad) czy tez instrukcja RESET procesora, aktywowany jest sygnal OVL ktory zmienia mape pamieci. W tym momencie dla adresow z przedzialu 0x00000000-0x00200000 (CHIP) aktywowany jest przez GARY-ego sygnal _ROMSEL. To, ktory fragment ROM-u sie pojawi na miejsce CHIPu chyba nigdzie nie bylo sprecyzowane i byc moze rozni sie w zaleznosci od modelu Amigi, z tego wzgledu prawdopodobnie jest owo "zabezpieczenie" w polowie 512 kilobajtowych kickstartow. Zapewne z tego samego powodu dodatkowy 512-kilobajtowy Extended ROM tez ma na poczatku instrukcje skoku pod adres 0x00f80002... Moze Toni Wilen wie jak to wyglada dokladniej.
Sygnal OVL jest dezaktywowany przy pierwszym zapisie do "nieparzystego" CIA. Co ciekawe np. w A1200 OVL z portu CIA nie jest uzywany, a sam OVL nie opuszcza GARY-ego. W tym wypadku dowolny zapis do obszaru pamieci CIA automatycznie dezaktywuje OVL.
01.09.2020 23:37
[#46]
Re: 68EC020 a 16MB RAM
@mschulz, post #45
Może jakieś pierwsze wersje Gary'ego wrzucały FC0000 na początek (albo w związku z jakimiś elektronicznymi miszmaszami inżynierów C=) i stąd to "zabezpieczenie", które pozostawiono na wszelki wypadek, bo w A500 pod adres 0 jest mapowany obszar F80000 (KS1.3 trzeba wgrywać do kości 512kb podwójnie, inaczej nie zadziała), w A600 i pewnie większości Amig obsługujących kickstart 1MB pod adres 0 wędruje E00000, stąd konieczność wrzucania tego pliku ze skokiem pod F80000 w Remusie. Zastanawiam się, czy Remus składając plik kickstartu też dorzuca ten skok do F8 po środku.
02.09.2020 00:26
[#48]
Re: 68EC020 a 16MB RAM
@WyciorX, post #46
Elektronikiem nie jestem, ale raczej po to nagrywasz ROM 1.3 2 razy na 0.5MB kosc, zeby to druga czesc byla pod adresem $fc0000, a nie pierwszy ROM pod $f80000. Jak masz checi to mozesz to sprawdzic, nagraj jakies 256KB smieci jako pierwsze i ROM 1.3 jako drugi, wedlug mnie powinno zadzialac.
02.09.2020 00:38
[#50]
Re: 68EC020 a 16MB RAM
@Don_Adan, post #49
Faktycznie, patrząc na to z tej strony możesz mieć rację, by się upewnić, czy jest to zwykły relikt, czy ma jeszcze jakieś zastosowanie, należałoby chyba usunąć ten skok z środka KS i zobaczyć co się stanie (i przeliczyć sumę kontrolną...), a także zwrócić uwagę, czy Remus wstawia skok w połowie kickstartu i czy jest on obecny kickstartach od Cloanto i Hyperionu.
Ostatnia aktualizacja: 02.09.2020 00:39:58 przez WyciorX
Ostatnia aktualizacja: 02.09.2020 00:39:58 przez WyciorX
02.09.2020 00:53
[#51]
Re: 68EC020 a 16MB RAM
@WyciorX, post #50
Z tego co wiem to Remus tego nie robil (nie mial jumpa w srodku kickstartu) , chyba ze to sie zmienilo. Po tym mozna bylo rozpoznac nieoryginalne kickstarty 0.5MB, ze uzywaly Remusa, np. te od Cloanto z serii 3.X. Co do kickstartow Hyperiona to nie wiem, sa bazowane na oryginalnych zrodlach (a nie skladaki binarek jak kicki Cloanto), wiec w teorii powinny miec, tym bardziej ze Thor to taki duzy legalista niby. Ale nie ogladalem zadnego kicka Hyperionu, to nie jestem pewien. Tym bardziej, ze zmienili zdaje sie poczatek kicka zeby dodac dluzszy tekst Hyperionu,, a to juz jest niezbyt koszerne, bo reset jest w innym miejscu teraz.
Ostatnia aktualizacja: 02.09.2020 00:54:27 przez Don_Adan
Ostatnia aktualizacja: 02.09.2020 00:54:27 przez Don_Adan
02.09.2020 12:11
[#52]
Re: 68EC020 a 16MB RAM
@WyciorX, post #46
Jestes pewny ze KS dla A500 musi byc nagrany dwukrotnie?
Wg schemtu od A500 jak i rowniez od CDTV, ROM ma 128x16bit. Watpie zeby stosowali kostki 512 KB.
Ponadto w A500 gdzie jest KS 1.3 (256KB) jak i w A500+ z KS2.0 (512KB) zastosowano ten sam uklad GARY (5719).
Przynajmniej taki mam w CDTV a ten model byl bazowany na A500.
Coraz bardziej zaczyna mnie to zastanawiac
Wg schemtu od A500 jak i rowniez od CDTV, ROM ma 128x16bit. Watpie zeby stosowali kostki 512 KB.
Ponadto w A500 gdzie jest KS 1.3 (256KB) jak i w A500+ z KS2.0 (512KB) zastosowano ten sam uklad GARY (5719).
Przynajmniej taki mam w CDTV a ten model byl bazowany na A500.
Coraz bardziej zaczyna mnie to zastanawiac
02.09.2020 12:55
[#54]
Re: 68EC020 a 16MB RAM
@wali7, post #53
No - i dlatego na większych kościach wgrywając ks1.3 powtarza się kick bo dokładnie takie zachowanie by było gdyby najstarszy pin adresowy do niczego nie był podłączony - czytając z wyższego adresu czytałoby się dokładnie to samo co na niższym. Być może to tak na wszelki wypadek, a być może część softu (może w samym kicku?) się odwołuje do "shadow copy" ROMu.
02.09.2020 14:46
[#55]
Re: 68EC020 a 16MB RAM
@teh_KaiN, post #54
Nie do końca, w starszych rewizjach A500 najstarszy pin adresowy jest podłączony, tylko nieprawidłowo. W nowszych rewizjach, np. 6, już to poprawiono.
Bez wątpienia wgranie dwóch kopii kickstartu do większej kości uodparnia nas na problem zachowania najstarszego bitu adresu. Nawet nie musimy wiedzieć co i jak, bo i tak powinno działać
Commodorowskie kickstarty 1.3 bez wątpienia są 256 kB, więc nie są zdublowane.
Ostatnia aktualizacja: 02.09.2020 14:47:17 przez wali7
Bez wątpienia wgranie dwóch kopii kickstartu do większej kości uodparnia nas na problem zachowania najstarszego bitu adresu. Nawet nie musimy wiedzieć co i jak, bo i tak powinno działać
Commodorowskie kickstarty 1.3 bez wątpienia są 256 kB, więc nie są zdublowane.
Ostatnia aktualizacja: 02.09.2020 14:47:17 przez wali7
02.09.2020 17:50
[#57]
Re: 68EC020 a 16MB RAM
@Don_Adan, post #48
Po to nagrywasz KS 2 razy, żeby pod F8 znalazła się instrukcja skoku po FC, bo pod adres 0 leci właśnie F8 (pod FC jest odbicie KS1.3 wynikające z mniejszej liczby linii adresowych układu ROM, gdybyś tam wrzucił układ, który ma 128kB, to wtedy jego zawartość w przedziale F8-FF byłaby widziana czterokrotnie), a w Amigach obsługujących kickstart 1MB leci E0.
Przerabiałem to już dawno temu, gdy pierwszy raz bawiłem się wgrywaniem KS do kości i tylko KS1.3 nie chciał działać i Toni Willen mi to wyjaśnił.
Przerabiałem to już dawno temu, gdy pierwszy raz bawiłem się wgrywaniem KS do kości i tylko KS1.3 nie chciał działać i Toni Willen mi to wyjaśnił.
02.09.2020 17:58
[#58]
Re: 68EC020 a 16MB RAM
@wali7, post #53
Czy ja niewyraźnie napisałem "do kości 512kb"?
Ależ jest powtórzone (chociaż nie w kości) , przejrzyj sobie co jest pod adresem F80000 i FC0000, kiedy jest włożony KS1.3.
Taka sama sytuacja występuje, kiedy weźmiesz sobie kość flash, która ma 2MB i wgrasz sobie KS3.1 tylko jeden raz.
Nie zawsze 256kB, ja w swojej CDTV miałem dziwną kość KS1.3 w której jednocześnie znajdował się na początku bootrom, a potem KS, przez co nie chciał mi działać bootrom w wersji 2.30, kapnąłem się, że coś jest z nim dziwnego, kiedy włożyłem KS z A500, a ten zadziałał.
Ależ jest powtórzone (chociaż nie w kości) , przejrzyj sobie co jest pod adresem F80000 i FC0000, kiedy jest włożony KS1.3.
Taka sama sytuacja występuje, kiedy weźmiesz sobie kość flash, która ma 2MB i wgrasz sobie KS3.1 tylko jeden raz.
Nie zawsze 256kB, ja w swojej CDTV miałem dziwną kość KS1.3 w której jednocześnie znajdował się na początku bootrom, a potem KS, przez co nie chciał mi działać bootrom w wersji 2.30, kapnąłem się, że coś jest z nim dziwnego, kiedy włożyłem KS z A500, a ten zadziałał.