są też inne projekciki: MCLZ8 - Zilog Z80 emulator which runs on a Teensy 4.1 and can be used as a drop-in replacment MCL86+ - Intel 8088 emulator which runs on a Teensy 4.1 and can be used as a drop-in replacment MCL86jr - IBMPCjr Accelerator which boosts performance to IBM PC/AT speed MCL65+ - MOS 6502 emulator which runs on a Teensy 4.1 and can be used as a 6502 drop-in replacment MCL64 - MOS 6510 emulator which runs on a Teensy 4.1 and can be used as a drop-in replacment in the Commodore 64
@jhusak. Kilka projektów wzorowałem na pracach Daryl'a :-) fajnie, że to odkopałeś... mam nawet kartę grafiki na VIA/ATMEGA możliwą do podłączenia do Atari.. ale jakoś nie było czasu dokończyć...
@sun, możesz jakoś więcej coś powiedzieć o SAVO google nie słyszało a jak nie słyszało znaczy, że nie istnieje...
@pancio: człowiek wymyślił, że w miejsce modulatora zrobi kawałek pcb z gniazdem sega staturn i tam podłączy sygnały np. z vbxe i pokeyów, a gniazdko małe, to pasuje do dziury po rca z modulatora. Ale piany nabite jest tyle wokół tego, jakby to było co najmniej nie wiadomo co :) Zajrzyj na discorda a nie tylko latasz tą rakietą w kółko :) Wysłałem Ci pm'a discordem. Zdjęć tu nie wkleję, bo nie moje a prawnicy już czają się za rogiem ;) ->link<- - tu link do wątku
Jak komputer wystartuje to zrobię demonstracje na video :)
@pin - to nawet nie jest prototyp, ale "kanapka" w celu weryfikacji działania. Jeśli zadziała, to całość będzie na malutkiej płytce i w SMD oczywiście ;) Poza tym to coś ma tyle mocy, że mogłoby emulować VBXE.
Takie pytanie, czy technicznie jest realizowane coś takiego, żeby 6502 szedł w trybie - wszystkie instrukcje miały 1 cykl lub 2 cykle (jeżeli najpierw pobierany jest rozkaz a potem to co robi)? Taki niby RISC :)
Nie (ale patrz mój następny wpis, że da się inaczej, lepiej), bo trzeba pobrać/zapisać z pamięci dane do wykonania rozkazu. To jest wykonywalne w emulatorach, ale w realu nie. Można przyspieszyć tryby domniemane (implied) do jednego cyklu (co nota bene jest stosowane w nowszych wersjach 6502), ale natychmiastowe wymagają pobrania dwóch bajtów. Jedyne, co można zrobić, to cykl wykonania rozkazu skrócić do minimum, czyli 0, ale i tak trzeba pobrać następny rozkaz z pamięci, więc tracimy. Można przyspieszyć skoki o cykl, można przyspieszyć operacje poza stronę pamięci tam, gdzie kosztuje to dodatkowy cykl. Wreszcie można zrobić cache i optymalizować pętle, ale to rodzi niekompatybilność albo zaawansowane sposoby wykrywania konfliktu cache<>pamięć.
Jest jeszcze kilka możliwości, ale są one skomplikowane, typu dzielenie pamięci na wewnętrzną i wtedy speeeeeed, ale są problemy z rozstrzygnięciem, czy akurat te dane powinny być czytelne dla innych układów, typu antic (bo ten akurat ma dma).
Takie tam rozkminy, dużo roboty i przypadków szczególnych.
No ale jak taki 6502 ma być szybciej taktowany to siłą rzeczy musi mieć jakąś inną pamięć (cache czy coś takiego), bo ta standardowa z ATARI to nie wyrobi. Jeżeli ma być na pamięci ATARI to usprawnić można tylko instrukcjami nielegalnymi, typu jednobajtowe MOV (A0),(A1), które trwałoby 3 cykle.
@gienekp - Jest tryb turbo, który dokładnie tak działa. Wszystkie instrukcje wykonują się 1 cykl, odczyty są wtedy cachowane, natomiast zapisy są zgodnie z zegarem komputera :) Natomiast Kuba ma trochę racji, bo nie wiadomo czy ten cache do odczytu na 100% zadziała z Atari. Mam tu na myśli DMA. Jeśli coś innego, niż procesor zmodyfikuje pamięć, to Teensy o tym się nie dowie (przynajmniej w obecnej wersji płytki). Póki co jedynym obejściem tego problemu jest wykluczenie z cacheowania obszarów adresowych, które są lub mogą być modyfikowane przez inne układy czy urządzenia bez udziału procesora.
Nielegale są zaimplementowane :) tylko trzeba sprawdzić czy są zgodne z wersją "Sally" i ewentualnie poprawić niezgodności.
Natomiast jak wspomniałem, można zawłaszczyć dowolny obszar pamięci. Wówczas, jeśli program odwołuje się np. do Pokeya, to procesor nie będzie się w ogóle komunikować z prawdziwym fizycznym Pokeyem, tylko np. swoim wewnętrznym emulowanym :) Teoretycznie można tworzyć dowolne wirtualne układy, urządzenia, rejestry etc. i nie będzie to kolidowało z już istniejącymi rozszerzeniami.
Przyznam, że jestem zachwycony tym jakże prostym rozwiązaniem, które dodatkowo jest praktycznie nieinwazyjne w montażu (nie licząc montażu podstawki pod procesor).
Ciekawe, czy podsłuchując szynę można by się uporać z z tymi problemami. Mianowicie "procek" tworzy za każdym rozkazem mapę pamięci we własnej pamięci, jeśli ta jest "pusta, niezainicjalizowana". Poza stroną rejestrów, to której by nie wnikał i zawsze czytał z szyny, reszta adresów mogła by siedzieć w nim, a tylko zapisy szły by do regularnej pamięci jako cykle zapisu, jako bufor do odczytu dla dma antica (obrazu i dl) i pmg. Jeśli KAŻDY zapis szedł by do fizycznego ramu jako "składowisko", to wszystko mogło by banglać bez problemu.
Czyli wykonanie odczytu z pamięci polega na "czy mam skaszowany ten adres?" -> pobranie z wewnętrznej pamięci else pobranie z fizycznej pamięci i zapis w wewnętrznej.
A zapis zawsze w wewnętrznej i zewnętrznej. Powinno działać i to szybko. Wtedy inc na pamięci to jeden cykl szyny. lda(88),y to zero odczytów szyny, a sta(88),y to jeden cykl zapisu szyny.
Aby ułatwić sprawę inicjalizacji, mogła by być pamięć wewnętrzna zainicjalizowana poprzez wykonanie np. zerowania/uzgadniania zawartości pamięci przed ruszeniem, trwało by to 0.037 sekundy.
Ponadto w takim "procku" można umieścić program inicjalizujący i konfigurujący komputer, coś a la U1MB.
A na koniec - przejście w specjalny tryb "natywny" i możliwość odpalania działań FP i operacje na soft sprajtach typu amiga, czyli wbudowany blitter z operacjami logicznymi, okienkiem i tzw. stride, czyli możliwość kopiowania 3 obszarów do czwartego z logiką Boola i przesunięciami bitowymi. Chociaż, jeśli byśmy to zakodowali w tym modelu, i tak by działało 1 bajt na cykl, przez co można wymienić całe 8k obrazu w jedną ramkę i jeszcze sporo czasu zostaje. Oraz możemy zmieniać 1 kolor co każdy cykl procesora, czyli co 2 piksle koloru, z wyjątkiem linii, gdzie antic pobiera dane.
Teensy 4.1 ma ca 1MB ramu, można by więc emulować spoko 512 kb. pamięci skeszowanej.
Jest genialne w swojej prostocie, a przy tym niedrogie :)
Jedyne, co mnie niepokoi, to współpraca z Antickiem i urządzeniami przejmującymi kontrolę nad magistralą. Na pewno trzeba będzie zaimplementować możliwość monitorowania szyny adresowej w trybie HALT, aby można mirrorować wszystkie zapisy do pamięci komputera w pamięci wewnętrznej Teensy.
Finalna wersja będzie dostępna na GitHubie tak, jak w przypadku FujiNet-u. A co już sobie kto z tym zrobi, to jego rzecz ;)
A w ogóle jakiś układ w ATARI oprócz procka potrafi zapisywać? Chyba nie. Więc procek ma pełną wiedzę o stanie pamięci. Więc na HALTa odepnie się od magistrali, żeby wpuścić ANTICa, ale w środku dalej może sobie coś tam dłubać.
Tak naprawdę przy tym drugim podejściu można do środka wrzucić Z80 i mieć CPM :) Albo 68k. Albo 8086/640 kb i turbo pascala odpalić.
@tebe, za AHRM:
The ANTIC custom chip handles DMA, memory refresh, display timing, and playfield graphics decoding for the system. It is the only other bus master in the system, halting the 6502 whenever it needs access to the memory bus for DMA or memory refresh.
Co ma być problemem, że trzeba go rozwiązywać? Jak działa HALT, to działa refresh.
Z ciekawości - czy da sie jakoś Anticowi powiedzieć, żeby sobie odpuścił refresh? Bo nawet jak sie SRAM założy to i tak te cykle są tracone, nieprawdaż? Zakładam, że nie bo po cholerę mieliby coś takiego uwzględniać w planach projektanci ale jakby się dało to by mogło być ciekawie.
@gienekp - W samym stockowym komputerze niczego takiego nie ma, ale jeśli przełączysz bank pamięci lub włożysz carta tudzież nowe urządzenie, to Teensy się o tym nie dowie i będzie "myśleć", że w podmienionych obszarach nadal jest to, co było.
@tebe - To jest nieinwazyjne:) Antic sobie normalnie odświeża pamięć jak zawsze.
@jhusak - Dokładnie tak można :) Coś a'la Commodore C128.
@Peri Noid - Myślałem o rozwiązaniu tego problemu już w latach 90-tych i wymyśliłem system buforowania Antica. Polegało to na tym, że jeśli Antic wystawia HALT z powodu odświeżania, to się go odcina od szyny i nie informuje o tym fakcie CPU :) Nie pamiętam co się stało z prototypem i jakie były efekty, ale gdzieś pewnie mam jeszcze schemat.
Zmiana banków będzie wiadoma bo to STA PORTB. Z cartem gorzej, bo co cart to ma to inaczej. Ale raczej to programista powinien się martwić a nie hardware czy w turbo mode cache odleciało od reala.
Jak dam 0 do DMACTL to ANTIC coś robi? Czy tylko refresh pamięci?
@gienekp - bankowanie pamięci jest stosunkowo najprostsze do implementacji. W ogóle można rozszerzoną pamięć zrobić w Teensy:) Tylko wtedy trzeba by było odłączyć fizyczną pamięć i podawać Antickowi dane, a póki co do tego brakuje pinów. Ale zobaczymy :)
@solo - To będzie bardzo ciekawe i rozwojowe rozwiązanie, a przede wszystkim nieinwazyjne :) Poza tym open source, więc każdy będzie mógł się pobawić. Mi głównie zależy na prawdziwym turbo, o którym marzyłem od lat 90-tych i to marzenie za parę tygodni ma się szansę spełnić ;)
