Nie jesteś zalogowany. Proszę się zalogować lub zarejestrować.
Golden Axe na Atari: Nowy silnik Vegi Vega prezentuje szybki silnik dla portu Golden Axe, oferujący tryb dla dwóch graczy, muzykę Mikera i grafikę Gaspara.
FujiNet Go 800 na Androida Emulator Atari 8-bit z wbudowaną obsługą FujiNet zadebiutował w sklepie Google Play dla Androida.
Fujisan 2.0.3 Aktualizacja emulatora Fujisan przynosi poprawki FujiNet, FastBasic i naprawę obsługi joysticków.
TURGEN 9.4.3 Aktualizacja narzędzia TURGEN do tworzenia taśm dla 8-bitowych Atari z nowymi poprawkami.
Wyniki GRAWITACJA 8bit GameJam Znamy zwycięzców krakowskiego jamu. Temat: PROMIEŃ. Najlepsza gra to 3.14RANHAS na Atari.
atari.area forum » Sprzęt - 16/32bit » Procesor MC68010
Zaloguj się lub zarejestruj by napisać odpowiedź
Podmieniłem w ST procesor na MC68010. Z TOS-em 2.06 działa OK, natomiast z TOS-ami 1.XX podczas staru wywala bomby i się resetuje i tak w kółko. Czyli wynika z tego, że dopiero TOS 2.0X jest w stanie obsłużyć 68010.
Próbował ktoś i ma podobne przemyślenia ? :)
Jaka Atarka ?
260ST, wcześniej sprawdzałem też w MegaST i efekt identyczny.
I wszystko chodzi bez problemu? Nic się nie wywala?
Nie robiłem testów kompatybilności. System działa :)
No ciekawe. Też się kiedyś zastanawiałem nad 68010. Z dokumentacji wynika że ma coś w rodzaju pamięci wirtualnej. Ciekawe jakby to wykorzystać na ST ?
Jeśli dobrze pamiętam 68010 ma jakiś rejestr za pomocą którego można zrobić coś w rodzaju pamięci wirtualnej, ale chyba nic tego nie wykorzystywało. Do tego jeszcze dwuinstrukcjowy cache, oraz oidp. move from ccr zmieniono na instrukcję uprzywilejowaną. W sumie - już lepiej zajmować się 68020 lub 68030.
Nie ma żadnej pamięci wirtualnej. Poprostu 68010 ma więcej informacji w ramce stosu przy bus errorze, co pozwala na wirtualizację (przy uzyciu dodatkowego sprzętu). 68000 nie zapisuje wystarczającej ilości informacji. Stacje uniksowe, które uzywały 68000 radziły sobie z tym w ten sposób, że posiadały dwie 68000 wykonujące te same rozkazy, z tym, że jedna działała o cykl wolniej, czy coś w tym stylu. Gdy jeden procek zaliczał bus errora, drugi był zatrzymywany.
Jest sporo info o tym na wiki:
The 68000 was also unable to easily support virtual memory, which requires the ability to trap and recover from a failed memory access. The 68000 does provide a bus error exception which can be used to trap, but it does not save enough processor state to resume the faulted instruction once the operating system has handled the exception. Several companies did succeed in making 68000 based Unix workstations with virtual memory that worked by using two 68000 chips running in parallel on different phased clocks. When the "leading" 68000 encountered a bad memory access, extra hardware would interrupt the "main" 68000 to prevent it from also encountering the bad memory access. This interrupt routine would handle the virtual memory functions and restart the "leading" 68000 in the correct state to continue properly synchronized operation when the "main" 68000 returned from the interrupt.
These problems were fixed in the next major revision of the 68K architecture, with the release of the MC68010. The Bus Error and Address Error exceptions pushed a large amount of internal state onto the supervisor stack in order to facilitate recovery, and the MOVE from SR instruction was made privileged. A new unprivileged "MOVE from CCR" instruction was provided for use in its place by user mode software; an operating system could trap and emulate user-mode MOVE from SR instructions if desired.
Pamiętam jak kiedyś chyba w jednym z numerów C&A był opis jak wymienić w Amidze 500 procesor właśnie na model 68010. Dawało to kilku procentowy wzrost wydajności w niektórych aplikacjach.
Były jednak drobne problemy z kompatebilnością między starym 68000 i nowszym 68010. Wydaje mi się, że do Amigi był jakiś rezydentny, mały program który korygował ten problem.
Bez niego czasem można było obejrzeć "medytację guru" :)
Pewnie z podobnych względów nie działają stare TOSy.
Prawdopodobnie chodzi właśnie o wielkość ramki stosu, oraz instrukcje move from sr (a nie jak wyżej napisalem move from ccr, która właśnie zastępuje move from sr na 68010 dla trybu użytkownika).
a propos amigi - takie cus odkopalem :-)
Tu ten artykuł z C&A
Czy ktoś (to zawsze fajnie brzmi "ktoś" :) ) biegły w asemblerze byłby w stanie zaadoptować ten programik na Atari, czy to raczej niewykonalne. Ja się na tym kompletnie nie znam.
http://aminet.net/package/util/boot/Decigel
Artik, ten program jest dla 68020
** The trap handler wedged into the privilege violation vector. **
** **
** If the instruction was MOVE SR,<ea> it is converted to MOVE CCR,<ea>. **
** The instruction cache is flushed, then the instruction is re-executed. **
Dodatkowo, jeśli TOS nie startuje to też nie było by okazji uruchomić ten program.
If the instruction was MOVE SR,<ea> it is converted to MOVE CCR,<ea>.
Kojarzę, że TOS 4 zawiera coś takiego. Zgadywałbym, że TOS 2.06 także.
Pamiętam panie dziejku, jak w 1994 żeśmy podmienili 68000 na 68010 w amidze 500.
Całkiem fajnie to działało.
Nawet dało się przekręcić na 10 czy 12 MHz. Wyżej już nie.
To już dwadzieścia lat przeszło. Jak ten czas leci.
Odświeżając temat, czy ktoś biegły w asemblerze napisze, czy to pójdzie na ST:
http://atari.wroclaw.pl/pliki/DeciGEL.asm
Wrzucić programik w AUTO i wio :)
Nie pójdzie, ale powinno się dac przystosowac bez większego problemu.
ten kod dodaje do amigi to co jest w ROMie od TOS 1.06
Instaluje on nową procedurę obsługi "Privilege violation vector" (adres $00000020):
MoveMe movem.l D0/A0,-(SP) ; Save registers
move.l 8+2(SP),A0 ; Pointer to opcode
move.w (A0),D0 ; Pickup opcode
andi.w #~%111111,D0 ; Mask out EA field
cmpi.w #$40C0,D0 ; Is it a MOVE SR,ea?
bne.s NotOne
bset #1,(A0) ; Convert it to MOVE CCR,ea 40C0 --> 42C0
movem.l (SP)+,D0/A0 ; Restore regs
rte ; Rerun new opcode
NotOne movem.l (SP)+,D0/A0 ; Restore regs
jmp $FC0000 ; To previous handler, patched on
; installation of this routineTak wygląda Atarowa procedura w TOS 1.06:
movem.l D0/A0,-(a7)
movea.l 10(a7),a0
move.w (a0),d0
and.w #$ffc0,d0
cmp.w #$40c0,d0
bne.s +10 {$E00536}
move.b #$42,(a0) ; Convert it to MOVE CCR,ea 40C0 --> 42C0
movem.l (a7)+,D0/A0
rte
{$E00536} movem.l (a7)+,D0/A0
jmp $8e00ca2 40C0 -> move SR,D0
42C0 -> move CCR,D0
Bawiłem się dzisiaj z MegaSTE i procesorami w wersji DIP.
68000 w wersji 8, 10 i 16MHz oraz 68010 10 i 12MHz.
Wszystkie startują i działają na 8MHz, po włączeniu 16 i cache działa tylko 68000 16MHz. 68010 12MHz sypie się (ciekawe czy przez cache, czy przez 68010). Wygląda na to, że procesory w tej wersji były mniej podatne na zmianę częstotliwości. Wersja 10MHz nie działa na 16, podczas gdy analogiczny procesor PLCC 68HC000FN10 działa na 16.
EDIT: Procesor PLCC 68010 w wersji 25MHz działa tylko na 8MHz, więc problemem jest cache w MegaSTE (?prawdopodobnie).
A jak wyłączyc cache?
Jak uruchamiam z Ctrl to startuje na 8MHz.
Bawiłem się dzisiaj z MegaSTE i procesorami w wersji DIP.
68000 w wersji 8, 10 i 16MHz oraz 68010 10 i 12MHz.Wszystkie startują i działają na 8MHz, po włączeniu 16 i cache działa tylko 68000 16MHz. 68010 12MHz sypie się (ciekawe czy przez cache, czy przez 68010). Wygląda na to, że procesory w tej wersji były mniej podatne na zmianę częstotliwości. Wersja 10MHz nie działa na 16, podczas gdy analogiczny procesor PLCC 68HC000FN10 działa na 16.
EDIT: Procesor PLCC 68010 w wersji 25MHz działa tylko na 8MHz, więc problemem jest cache w MegaSTE (?prawdopodobnie).
Procesory PLCC 68010 @25MHz, to zwykłe "malowanki". Z mojego Amigowego doświadczenia, procki 68010 dają się podkręcić max. do 14 MHz. Żaden z tych które miałem nie poszedł na 16MHz, a miałem ich trochę na testach.
Jak te procki są z jakiegoś ali od chinola ,to na bank są malowane.
Jeżeli wierzyć cpuworld to maks dla 010 PLCC to 16 MHz.
A jak wyłączyc cache?
MSTE startuje w trybie 8Hz i z wyłączonym cache
Wszystkie startują i działają na 8MHz, po włączeniu 16 i cache działa tylko 68000 16MHz. 68010 12MHz sypie się (ciekawe czy przez cache, czy przez 68010). Wygląda na to, że procesory w tej wersji były mniej podatne na zmianę częstotliwości. Wersja 10MHz nie działa na 16, podczas gdy analogiczny procesor PLCC 68HC000FN10 działa na 16.
EDIT: Procesor PLCC 68010 w wersji 25MHz działa tylko na 8MHz, więc problemem jest cache w MegaSTE (?prawdopodobnie).
czy 68010 działa w MSTE na 16MHz z wyłączonym cache?
Zaloguj się lub zarejestruj by napisać odpowiedź
atari.area forum » Sprzęt - 16/32bit » Procesor MC68010
Wygenerowano w 0.029 sekund, wykonano 62 zapytań