Rozszerzenie 16MB RAM dla c64.

Tutaj możemy porozmawiać o sprzęcie i modyfikacjach C64.
Wiadomość
Autor
Awatar użytkownika
wegi
Posty: 839
Rejestracja: 14 lip 2009, 01:17

#21 Post autor: wegi »

NOWOSTI77x aka 8bit2 - zacny projekt i ciekawy.

Chciałbym zwrócić uwagę wszystkim, którzy myślą "ścieżką" carriona, że wbrew pozorom doczytywanie danych z cartridge'a jest takie super-duper i tak wiele może dać. Otóż tu się robi niebywale niewygodna sprawa, że podczas pobrania bajtu z cartridge'a - aby można było pobrać ten bajt w $01 musi być wartość #$37. To oznacza, że w najlepszym przypadku obszar $E000-$FFFF będzie przesłonięty oryginalnym KERNEL'em i obszar $A000-$BFFF będzie przesłonięty BASIC'iem. To dla urządzenia w stylu RAMCART - o ile pamiętam dochodzi także przesłonięcie $8000-$80FF coldstartem RAMCART'a. W przypadku wielu innych cartów dochodzi jeszcze przesłonięcie RAM'u obszaru $8000-$9fff lub włącznie z przesłonięciem BASIC'a do $BFFF.

Mamy więc przesłonięte wektory IRQ $FFFE - $FFFF, NMI i RESET.

W przypadku dem najczęstszymi wartościami w $01 jest #$35 i #$34 kiedy to widać prawie cały RAM przesłonięty I/O od $D000-$DFFF, albo widzimy całe 64KB RAM'u.

Proszę spróbować sobie wyobrazić co się stanie z demem kiedy będziemy pobierać bajt a nasz kod będzie gdzieś pod $E000-$EFFF. Wówczas trzeba będzie nieźle kombinować, aby pobierać bajty z cartridge'a z innego miejsca w RAM, gdzie nie jest przesłonięty ROM'em i dodatkowo strzec się przed zgłoszeniem przerwania IRQ/NMI w trakcie kombinacji z $01. W sumie wydłuży to cyklowo procedurę pobierania bajtu, oraz może to rozjechać ustabilizowanego rastra.

Wbrew pozorom ładowanie z driva i synchronizowanie się przy tym ATN staje się rozwiązaniem bardzo optymalnym, który pozwala na utrzymanie wysokiej płynności dema...

8bit2
Posty: 38
Rejestracja: 15 gru 2015, 21:21

#22 Post autor: 8bit2 »

Do tego co napisal Wegi dodam jeszcze ze wzgledu na architekture c64 jest jeszcze tak ze obszary pamieci (fizycznie w cartridgach) 8000-9fff i A000-BFFF swobodnie mozna jedynie odczytywac, aby je zapisywac trzeba je albo dodatkowo dzielic na banki po 256 B adresowane pod innymi adresami tj. W obszarze I/o, lub pozoztac tylko w koncigiracji jak Ultimate czyli tylko 4kB RAM w obszarze 0-0fff. U mnie jest latwo zmienic bank wystarczy tylko miec dostep do obszaru i/o.
Nie znam sie na pisaniu dem, ale u mnie aby przepisac bajt z banku do banku wystarczy tylko kilka dodatkowych instrukcji i wstrzymanie przerwan na te kioka cykli. Duza pamiec mozna tez wykorzystac do procedur wywolywanych w formie podprogramow z tablicowaniem co powinno sporo przyspieszyc wszelkie obliczenia.No i po zmianie banku mamy pelna swobode dostepu do calego RAM tj porcji 64kB zmozliwoscia uruchomienia w nim dodtakowej kopii calego systemu tj BASIC+KERNAL, czy tez co akurat ja uzywm innej wersji jezyka BASIc. Zreszta jesli przerobi sie procedure z $73 na podobna jak w c128 lub c+4 to kolejne instr. BASICa moga byc brane z innego banku co latwo daje 64kB na program w basic + dodatkowe ok 38 kB na zmienne tego programu.

comankh
Posty: 1622
Rejestracja: 08 wrz 2009, 12:10
Kontakt:

#23 Post autor: comankh »

8bit2 pisze: Duza pamiec mozna tez wykorzystac do procedur
nie.

8bit2
Posty: 38
Rejestracja: 15 gru 2015, 21:21

#24 Post autor: 8bit2 »

comankh pisze:
8bit2 pisze: Duza pamiec mozna tez wykorzystac do procedur
nie.
A mozesz uzasadnic dlaczego ?
Bo ja nie mam problemow z umieszczeniem czesci kodu w innym banku, ba dzieki duzej ilosci pamieci mozna nawet przyspieszyc podprogramy rezygnujac z petli.

Awatar użytkownika
kmeg
Posty: 468
Rejestracja: 08 wrz 2009, 15:33
Grupa: Albion Crew

#25 Post autor: kmeg »

wegi pisze: Wbrew pozorom ładowanie z driva i synchronizowanie się przy tym ATN staje się rozwiązaniem bardzo optymalnym, który pozwala na utrzymanie wysokiej płynności dema...
Tak ale DMA (z grubsza 1 bajt na 1 cykl) daje mimo wszystko możliwości do tej pory niedostępne i myślę, że będziemy teraz mieli coraz więcej dem na REU ONLY. 16MB w Ultimate to kosmos na przeliczanie tablic, ciurków, danych, etc... Nie do wszystkiego to się nadaje ale kilka ciekawych rzeczy zrobić można a na sporą część nawet jeszcze nikt nie wpadł i wszystko przed nami.

8bit2
Posty: 38
Rejestracja: 15 gru 2015, 21:21

#26 Post autor: 8bit2 »

Tyle ze jednak DMA potrzebuje czasu na zrzucenie i pobranie porcji danych co spowalnia system. Jak dla mnie model bankow po 64 kB jest optymalny, no i praktycznie wszystkie programy zyskuja na urzytecznisci i to nawet bez przerobek programowych, wystarczy ze sa zaladowne do bankow i w kazdej chwili z poziomu nadrzednego systemu moge kazdy uruchomic w "oknie" i go wykozystac, a po zakonczeniu jego pracy powrocic do systemu, a w razie potrzeby ponownie dany program uruchomic bez potrzeby ponownego wczytywania. Tak naprawde to do pelni szczescia wystarczylyby male programiki potrafiace bezposredni przeniesci i skonwertowac dane miedzy roznymi programami (bankami) i jakis uniwersalny sterownik np. Drukarki jeden do wszystkich programow. Tak zrobilem np. z Turbo Asemblerem wersja na 2 komputrry gdzie przerobilem procedure przesylu danych i zamiast do drugiego komp. kod kompiluje sie do zadeklarowanego banku innego niz zrodla i assembler,no i przerobilem 6 i J na wersje miedzyblokowe co pozwala pobrac dane np. Spritow czy ekranu bezposrednko z programow graficznych z pominieciem stacji dyskow. Jak dla mnie to zwieksza mozliwosci tego programu o 100proc. , a wymagalo tylko niewielkiej przerobki

Awatar użytkownika
kmeg
Posty: 468
Rejestracja: 08 wrz 2009, 15:33
Grupa: Albion Crew

#27 Post autor: kmeg »

^^ Tak ale chodzi o to, że Ultimate to już w zasadzie dość popularny standard. Wiadomo, że DMA to nie jest ideał ale przykłady zastosowań np tu:

http://csdb.dk/release/?id=144124

8bit2
Posty: 38
Rejestracja: 15 gru 2015, 21:21

#28 Post autor: 8bit2 »

Po pierwsze moje rozszerzenie nie jest konkurencyjne do Ultimate i co prawda tego nie sprawdzalem (bo nie mam dostepu do Ultimate) ale nie widze powodow dla mtorych nie moznaby miec w komputerze obu naraz. W sumie 32 MB , a i funkcjonalnie DMA daloby nowe mozliwosci np. Przesyl miedzy blokami. W brew pozorom moje rozwiazanie jest zgodne bardziej z idea rozszerzenia pamieci RAM firmy Commodore niz ich produkt (z DMA) niejako wymuszony ograniczeniami PLA w c64. W koncu c128 mial bankowana pamiec, a nie wbudowane DMA. W sposob podobny bylo bankowanie w serii PET II i w c128 czy c+4 . Tak naprawde to wszystkie rozszerzenia BASIC jak i sam BAsic 2.0 latwo jest dostosowc do pracy w kilku bankach 1 na kod,2 na zmkenne i 3 na tablice. Razem 192 kB na jeden program.Mysle ze uruchomienie basica 4.0 na c64 byloby latwe do zrealizowania wiec , a moze i uruchomienie czesci programow z c128 ( po pewnych patchach)

comankh
Posty: 1622
Rejestracja: 08 wrz 2009, 12:10
Kontakt:

#29 Post autor: comankh »

8bit2 pisze: A mozesz uzasadnic dlaczego ?
bo nikt nie bedzie z tego korzystał.

comankh
Posty: 1622
Rejestracja: 08 wrz 2009, 12:10
Kontakt:

#30 Post autor: comankh »

oczywiscie - luźna opinia, jesli to nie bedzie zgodne z niczym powstaną pewnie ze trzy kawalki softu!=profit.

8bit2
Posty: 38
Rejestracja: 15 gru 2015, 21:21

#31 Post autor: 8bit2 »

Maly przyklad procedury mnozenia dwoch liczb 8bitowych (rej A i X ) zwynikiem 16 bitowym (w rejestrach AY) z wykorzystaniem bankowania i gablicowania. Procedura wykozystuje technike ktora na swoja potrzebe nazwalem "przenikaniem" - czyli rozkazy wykonuja sie po kolei z tym ze w pewnym momencie program glowny przechodzi do innego banku i ponownke wraca na .
Mnozenie cpx#0
Beq zero
Sta Bank
;-----------------------
Od tego miejsca procedura wykonuje sie w banku wskzanym przez dana w A , jesli a=00 to przechodzi dalej ,kazda inna wartosc powoduje ze nastepne rozkazy s pobierane z banku wskazanego przez A - czyli przechodzimy do punktu II
;---------------------------
Tax
Rts
Zero txa
Rts
;----------------
Tu mozmy albo dodac puste bajty tak aby wyrownac dlugosc procedury do tej w banku, albo na koncu procedury w banku dodac rozkaz jmp przed
Stx bank
;---------------
Db 0,0,0,0,0,0,0,0
Rts
;------------------------
II
To jest czesc procedury w bankach
Lda tablow,x
Tay
Lda tablhig,x
Ldx#0
Stx bank
Tablow:

Tablhig:

Awatar użytkownika
kmeg
Posty: 468
Rejestracja: 08 wrz 2009, 15:33
Grupa: Albion Crew

#32 Post autor: kmeg »

comankh pisze:oczywiscie - luźna opinia, jesli to nie bedzie zgodne z niczym powstaną pewnie ze trzy kawalki softu!=profit.
Niestety ale sporo w tym racji, pomysł bankowania jest świetny tylko problem jest popularność. Na C64/C128 wszystkie REU (o innych rozszerzeniach nie wspomnę) to była nisza wiec mało kto tego używał. Teraz popularność tego podkręcił Ultimate i w zasadzie większość aktywnej sceny go ma.

8bit2
Posty: 38
Rejestracja: 15 gru 2015, 21:21

#33 Post autor: 8bit2 »

O tym czy cos sie przyjmnie czy nie tak naprawde decyduje rynek a nie nasze gdybanie. Oczywiscie kazdy moze sie wypowiedziec w swoim imieniu bo ma do tego prawo. Nie oszukujmy sie gdy pojawilo sie REU tak naprawde commodore byl juz tylko zabawka wiec i chetnych do inwestowania bylo mniej. Zreszta inoferta oprogramowania byla mala. Dodatkowo REU bylo drogie jak na kieszenie przecietnych urzytkownikow (europawschodnia czy dzieci na zachodzie). Dzis to co innego urzytkownicy maja kase i sa gotowi nawet sporo wydac na swoje hobby. Taka jest prawda. C64 ma duza liczbe entuzjastow na calym swiecie, jest tez mnostwo ludzi ktorzy poprostu potrafia go programowac i uzywac. Scena to nie jest wszystko, wystarczy wejsc na fora zwiazane np. Z atari czy zx spectrum. Moim zdaniem c64 ze swoja baza oprogramowania moglby spokojnie tym osoba zastapic np. Takie rozwiazania jak raspberry Pi wystarczy dodac pare interfejsow ( juz nawet zaczelem nad nimi pracowac i mam ich ogolna koncepcje).
Na razie projekt robie dla siebie i mi to wystarcza i nie mysle o nim w kategoriach biznesowych. Ot robie bo mam takie hobby.
Ale zapytam ciebie kmeg czy np. Rozwarzylbys zakup gdyby byla taka mozliwosc rozszerzenia do wbudowania (bez potrzeby lutowania), albo drozszej gotowej plyty glownej z tym rozszerzeniem ?
Albo czy przerobilbys ( zlecil komus) swoje c64 na wersje free np.z 256 kB ktora moglbym ewentualnie przygotowac i opublikowac ?

Awatar użytkownika
kmeg
Posty: 468
Rejestracja: 08 wrz 2009, 15:33
Grupa: Albion Crew

#34 Post autor: kmeg »

8bit2 pisze: Ale zapytam ciebie kmeg czy np. Rozwarzylbys zakup gdyby byla taka mozliwosc rozszerzenia do wbudowania (bez potrzeby lutowania)
Szczerze? Nie wiem. Z moich zakupów komodorkowych to:
Ultimate leży w szufladzie i jest wyciągane tylko podczas prywatnych zlotów Albionu lub jak pije wódkę z Scarletem a w tle lecą dema lub sidy. C128d bo kiedyś chciałem mieć, stoi na biurku obok peceta - nieużywany.
8bit2 pisze: , albo drozszej gotowej plyty glownej z tym rozszerzeniem ?
Raczej nie.
8bit2 pisze: Albo czy przerobilbys ( zlecil komus) swoje c64 na wersje free np.z 256 kB ktora moglbym ewentualnie przygotowac i opublikowac ?
Raczej nie i tak żałuje dolutowania pararella do swojego oryginalnego C64.

-----------
Ja nie jestem retro maniakiem czy też zbieraczem i trzymaniem tego pod szkłem. Wszystko się może zmienić jak zechce mi się znowu coś pisać na komodore ale na razie się na to nie zanosi...

comankh
Posty: 1622
Rejestracja: 08 wrz 2009, 12:10
Kontakt:

#35 Post autor: comankh »

8bit2 pisze:O tym czy cos sie przyjmnie czy nie tak naprawde decyduje rynek a nie nasze gdybanie
8bit2 pisze: Dzis to co innego urzytkownicy maja kase i sa gotowi nawet sporo wydac na swoje hobby.
tia, pod warunkiem że nie jest to expansion/ gadżet/ etc. w którym wieje tylko wiatr.

8bit2
Posty: 38
Rejestracja: 15 gru 2015, 21:21

#36 Post autor: 8bit2 »

Kmeg - mysle ze gdybys mial szanse zapoznac sie z nim blizej to bys sie zdecydowal. :D
Na razie chce je jeszcze wyposazyc w 65816 dzilajace na czestotliwosci przynajmniej 8 Mhz, a w tedy postaram sie o kilka sampli rozszerzenia, bo zdaje sobie sprawe ze trzeba to puscic do ludzi.;)
Comankh juz ci chyba 100 raz tlumacze ze z zalet tego mozna kozystac nawet bez specjalnego oprogramowania. Zacznij czytac ze zrozumieniem bo jeszcze sobie pomysle ze tak jak ten twoj kolega masz kisiel zamiast mozgu :cry:
Jak chcesz sie przekonac jak to z grubsza dziala to wez uruchom sobie kilka okien vice , na kazdym uruchom inny program np. Asembler, graficzny, muzyczny, do spritow i jakas gre,+ monitor i sprobuj zrobic obrazek, przenies go do kodu zrodlowego w asemblerze, dodaj stworzona w progrmie muzyke i sprita , skompiluj uruchom. I teraz wyobraz sobie ze mozesz spokojnie w kazdej chwili wlaczyc inne okno dokonac zmian i wrocic do edycji, ponownie skompilowac i znow uruchomic i tak w kolko, ani razu nie kozystajac ze stacji dyskow czy SD2iec. A zobaczysz ze komfort pracy bedzie podobny na c64 jak i na PC.

Awatar użytkownika
wegi
Posty: 839
Rejestracja: 14 lip 2009, 01:17

#37 Post autor: wegi »

8bit2 pisze: Jak chcesz sie przekonac jak to z grubsza dziala to wez uruchom sobie kilka okien vice , na kazdym uruchom inny program np. Asembler, graficzny, muzyczny, do spritow i jakas gre,+ monitor i sprobuj zrobic obrazek, przenies go do kodu zrodlowego w asemblerze, dodaj stworzona w progrmie muzyke i sprita , skompiluj uruchom. I teraz wyobraz sobie ze mozesz spokojnie w kazdej chwili wlaczyc inne okno dokonac zmian i wrocic do edycji, ponownie skompilowac i znow uruchomic i tak w kolko, ani razu nie kozystajac ze stacji dyskow czy SD2iec. A zobaczysz ze komfort pracy bedzie podobny na c64 jak i na PC.
Jest tutaj zasadnicza różnica w tym przykładzie:

Na PC te procesy lecą oddzielnie multitaskingiem, a na Twoim rozszerzeniu starasz się freezować proces do momentu kolejnego przełączenia się do (na) niego.

Nie policzysz sobie w tle jakichś przykładowo kluczy etcetera, oraz jak łatwo udowodnić nie ma idealnych freezerów. Bez problemu można programowo zrobić tak, żeby proces się sfreezować nie dał.

8bit2
Posty: 38
Rejestracja: 15 gru 2015, 21:21

#38 Post autor: 8bit2 »

Multitasking na PC to tez tak naprawde podzial czasu procesora czyli jakby takie "frezowanie" :lol:
Prawdziwy multitasking wielkich zadan to akurat na 6510 wyzwanie gdzie najwiekszym ograniczeniem jest predkosc 1 MHz. Wiec moze bez przesdy choc da sie np. Posluchac muzyczki ( przy takiej ilosci RAM nawet sporo) i w tym czasie policzyc cos tam :wink:
Ja glownie widze to w tym ze mam kilka programow pod reka ktore zawsze po zaladowaniu sa dostepne i nie musze zaglowac dyskietkami, a wszystko zarzadzam z poziomu systemu. I bardziej widze to tak ze program jest w pamieci i nawet po reset nie znika wiec zawsze moge go uruchomic , wyjsc do systemu i jak zajdzie potrzeba uruchomic ponownie itd..
A multitasking z podzialem czasu (mozna nawet ten czas ustalic dla kazdego zadania) jest mozliwy dzieki przerwaniom IRQ czy NMI wystarczy tylko ze w zadaniu przechwyci je system.
Co do reszty problemow prosze o konkretny przyklad to bede mogl udzielic konkretnej odpowiedzi.
Pozdrawiam

comankh
Posty: 1622
Rejestracja: 08 wrz 2009, 12:10
Kontakt:

#39 Post autor: comankh »

8bit2 pisze: "frezowanie" :lol:
ze zrozumieniem akhem. btw to o czym piszesz zrobil zephyr 20 lat temu na zwykłym reu.

Awatar użytkownika
wegi
Posty: 839
Rejestracja: 14 lip 2009, 01:17

#40 Post autor: wegi »

8bit2 pisze: A multitasking z podzialem czasu (mozna nawet ten czas ustalic dla kazdego zadania) jest mozliwy dzieki przerwaniom IRQ czy NMI wystarczy tylko ze w zadaniu przechwyci je system.
Co do reszty problemow prosze o konkretny przyklad to bede mogl udzielic konkretnej odpowiedzi.
Pozdrawiam
Multitasking w zadaniach gdzie chociażby głupie FLI pożera 200 linii i innych sztuczkach to raczej czarno widzę.

Wielokrotnie w C64 dla uzyskania jakiegoś efektu wykorzystuje się glitch'e VICa.

Jest wiele efektów, które się synchronizują za pomocą bugów VICa' jak i timerami. Nawet jeżeli oddasz "taska" w dokładnie w tym samym cyklu ramki, kiedy go zabrałeś to i tak nie jesteś w stanie odtworzyć ani np. stanu timerów jakie go synchronizowały, ani ich wartości zliczanych, ani nie jesteś w stanie odtworzyć warunków, które powodowały zsynchronizowanie programu z plamką rastra.

Przykładowo wyświetlanie grafiki na sprajtach przy wyłączonym ekranie ($d011 = #$0b) wiąże się nie tylko z synchronizacją, ale z tym, że w poprzedniej ramce był otworzony dolny i górny border.

Inny efekt to wymuszanie na VICu "krótkich" linii w miejscach linii "długich" - co z tego, że oddasz taska w tym samym miejscu rastra skoro ta linia jest "długa" zamiast "krótka".

Są jeszcze inne metody wyświetlania sprajtów na bocznych borderach, gdzie bazując na błędach VIC'a rozpoczyna się efekt NIE w tym samym miejscu rastra, tylko co ramkę na przemian raz cykl wcześniej, raz cykl później - nie jesteś w stanie się zsynchronizować i odtworzyć warunków panujących w momencie zatrzymania zadania. Nie wspominając o jednoczesnym utrzymaniu komunikacji na IEC, co jest niemożliwe.

Takich rzeczy nie zrobi ani żaden AR, Ultimate czy cokolwiek innego.

Kolejny przykład - programowe wyłączenie NMI - ustawia trwale linię NMI w stanie niskim - w jaki sposób wyzwolisz opadające zbocze potrzebne do przyjęcia NMI skoro linia jest w stanie niskim ? Tu także wykłada się freezer i menu Ultimate.

Naprawdę nie umniejszam Twojemu wynalazkowi - Ty jesteś dobrym elektronikiem i widzisz wszystko od strony hardware'u, ale to jeszcze nie jest wszystko. I jak komancz napisał coś takiego było stworzone 20 lat temu, tylko się po prostu nie przyjęło.

ODPOWIEDZ