Rozszerzenie 16MB RAM dla c64.
Wegi.komancz pisze brednie w rodzaju ze poco mlotek skoro gwozdzie mozna wbijac obcasem, dlatego go ignoruje i nawet tego co pisze nie czytam.
Co do reszty to np. przeciez amiga od samego poczatku miala multitasking i tez wiele programow (gier , dem) nie dzialala z nim. To zaden problem.
Inny przyklad w romie apple II byl monitor i miniasembler ktory mozna bylo uruchomic z monitora , ale powrot do monitora nastepowal poprzez przycisk reset. U mnie tez jest przycisk reset czescia systemu ,tak jak kombinacja alt-ctrl-del w PC jesli jakis program przejmie kontrole to bardzo dobrze widocznie tak chcial jego autor , aby przerwac jego zadanie wystarczy [reset] uruchlmic menager zadan i ten program wyzucic z kolejki a reszta zadan bedIe mogla dzialac nadal. Tak zreszta dzialaja wszystkie systemy operacyjne stosujace multitasking wiec co w tym dziwnego ?
Wegi czy gdybys pisal demo na REU to tez najwiekszym twoim problemem bylaby synchronizacja z dyskietka 170 kB (
Co do FLI i multitaskingu otoz da sie,ba mozna nawet otrzymac nieosiagalne na golym c64 efekty animacji
https://www.youtube.com/watch?v=yxZ7Idi2Bi4
Wszystko zalezy od pomyslowosci i umiejetnosci programisty.
Tylko trzeba spojrzec na to ze swierzej strony. Ja ci daje dodatkowo 16MB szybkiej pamieci RAM a ty chcesz uzywac wolnej stacji dyskietek 170 kB. Daj spokoj mam nadzieje ze to tylko przez dlugi weekend,slonce i piwo
To co ty chcesz uzyskac to monitor aby mozna bylo debugowac program jak w monitorze emulatora vice. Jest to wykonalne i byc moze dolacze to do systemu, ale nie jest to niezbedne dla systemu operacyjnego. Co doblokady NMi sa przynajmnie 2 (3) sposoby jego rozwiazania. W sumie moge nawet dodac je do systemu tylko ze w tej chwili naprawde to nie stanowi problemu i w niczym nie przeszkadza.
Co do reszty to np. przeciez amiga od samego poczatku miala multitasking i tez wiele programow (gier , dem) nie dzialala z nim. To zaden problem.
Inny przyklad w romie apple II byl monitor i miniasembler ktory mozna bylo uruchomic z monitora , ale powrot do monitora nastepowal poprzez przycisk reset. U mnie tez jest przycisk reset czescia systemu ,tak jak kombinacja alt-ctrl-del w PC jesli jakis program przejmie kontrole to bardzo dobrze widocznie tak chcial jego autor , aby przerwac jego zadanie wystarczy [reset] uruchlmic menager zadan i ten program wyzucic z kolejki a reszta zadan bedIe mogla dzialac nadal. Tak zreszta dzialaja wszystkie systemy operacyjne stosujace multitasking wiec co w tym dziwnego ?
Wegi czy gdybys pisal demo na REU to tez najwiekszym twoim problemem bylaby synchronizacja z dyskietka 170 kB (
Co do FLI i multitaskingu otoz da sie,ba mozna nawet otrzymac nieosiagalne na golym c64 efekty animacji
https://www.youtube.com/watch?v=yxZ7Idi2Bi4
Wszystko zalezy od pomyslowosci i umiejetnosci programisty.
Tylko trzeba spojrzec na to ze swierzej strony. Ja ci daje dodatkowo 16MB szybkiej pamieci RAM a ty chcesz uzywac wolnej stacji dyskietek 170 kB. Daj spokoj mam nadzieje ze to tylko przez dlugi weekend,slonce i piwo
To co ty chcesz uzyskac to monitor aby mozna bylo debugowac program jak w monitorze emulatora vice. Jest to wykonalne i byc moze dolacze to do systemu, ale nie jest to niezbedne dla systemu operacyjnego. Co doblokady NMi sa przynajmnie 2 (3) sposoby jego rozwiazania. W sumie moge nawet dodac je do systemu tylko ze w tej chwili naprawde to nie stanowi problemu i w niczym nie przeszkadza.
Problemem jest to, że na REU produkcji jest garstka, a samych dem i gier na dyskietkach są dziesiątki tysięcy, które ludzie chcą i będą oglądać czy grać, a do tego celu będą potrzebowali synchronizacji z IEC i co najmniej wysokiej klasy emulacji drive (1541U, UK1541).8bit2 pisze: Wegi czy gdybys pisal demo na REU to tez najwiekszym twoim problemem bylaby synchronizacja z dyskietka 170 kB (
Co do FLI i multitaskingu otoz da sie,ba mozna nawet otrzymac nieosiagalne na golym c64 efekty animacji
https://www.youtube.com/watch?v=yxZ7Idi2Bi4
Wszystko zalezy od pomyslowosci i umiejetnosci programisty.
Zatrzymaj procesy:
- dema Quissa np. Radio napalm w trakcie distorterów, kiedy do zoom4 synchronizował się timerami.
- Edge of disgrace po starcie dyskietki 1 na szachownicy
- Fogyish zaraz po uruchomieniu.
W ostatnich dwóch przypadkach do poprawnej pracy musisz ramkę wcześniej otworzyć dolny i górny border, inaczej będzie blanc screen - sprawdzone na 1541U.
Żeby było śmieszniej w $d011 jest wartość #$0b (wyłączony ekran), więc jak tu otwierać bordery skoro ich nie ma ? Trzeba by najpierw włączyć ekran, poczekać 1 ramkę, w kolejnej wyłączyć bordery i wpisać do $d011 #$0b, a następnie oddać sterowanie do zadania w idealnie tym samym cyklu, co je przerwałeś, z odtworzonymi rejestrami, stosem, wskaźnikiem stosu, rejestrem stanu, z timerami z idealnie tą samą wartością w nich, jak i zaprogramowaną w nich wartością zliczającą, oraz wraz z ich ustawieniem jako źródła przerwań... O synchronizacji z IEC nie wspominam, bo jeżeli coś "kliknąłeś" w $dd00, $dd02 (ba - czasem wystarczy że nie kliknąłeś tego, czego potrzeba w przeciągu kilkunastu cykli !!!) to z 99% prawdopodobieństwem na zadaniu możesz postawić krzyżyk.
Istota jest taka, że musisz wiedzieć o tym, że podczas zatrzymywania procesu były otwarte top i bottom border, że jest to niezbędne do poprawnej pracy efektu, do czego nie ma sprzętowych "wykrywaczy".
Więc zatrzymaj te procesy, a potem je uruchom...
edit:
Byłbym zapomniał - ostatnie 2 efekty od linii 0 rozciągają w pionie w nieskończoność jedną linię sprajta, więc jeżeli nie robiłeś tego od początku (czyli od linii 0 ekranu) - również zadanie się nie uruchomi.
Ale co ma do tego synchronizacja z IEC. Wszystkie programy moga dzialac tak jak dzialaly. Ja nie staralem sie budowac systemu stricte multitask, tu idea polega ze programy dzialaja jak dzialaly tyle ze mozesz je miec w bankach i wywolywac najlepiej jeden po drugim kiedy masz potrzebe, bez ciaglego przeladowywania RAM bo to jest najdluzszy proces.Jak chcesz miec programy dzialajace rownolegle to musisz je sobie odpowiednio przygotowac, a najlepiej napisac. No nieda sie zbudowac windows NT na 1MHz , bez przesady. A juz puszczanie 2 dem wymagajacych tak glebokiej ingerencj w sprzet to jakies nieporozumienie, przeciez nawet jesli by sie udalo puscic dwa to jak mialyby kozystac z ekranu? Przelaczac sie co 50 Hz ?wegi pisze:
Problemem jest to, że na REU produkcji jest garstka, a samych dem i gier na dyskietkach są dziesiątki tysięcy, które ludzie chcą i będą oglądać czy grać, a do tego celu będą potrzebowali synchronizacji z IEC i co najmniej wysokiej klasy emulacji drive (1541U, UK1541).
Zatrzymaj procesy:
- dema Quissa np. Radio napalm w trakcie distorterów, kiedy do zoom4 synchronizował się timerami.
- Edge of disgrace po starcie dyskietki 1 na szachownicy
- Fogyish zaraz po uruchomieniu.
W ostatnich dwóch przypadkach do poprawnej pracy musisz ramkę wcześniej otworzyć dolny i górny border, inaczej będzie blanc screen - sprawdzone na 1541U.
Żeby było śmieszniej w $d011 jest wartość #$0b (wyłączony ekran), więc jak tu otwierać bordery skoro ich nie ma ? Trzeba by najpierw włączyć ekran, poczekać 1 ramkę, w kolejnej wyłączyć bordery i wpisać do $d011 #$0b, a następnie oddać sterowanie do zadania w idealnie tym samym cyklu, co je przerwałeś, z odtworzonymi rejestrami, stosem, wskaźnikiem stosu, rejestrem stanu, z timerami z idealnie tą samą wartością w nich, jak i zaprogramowaną w nich wartością zliczającą, oraz wraz z ich ustawieniem jako źródła przerwań... O synchronizacji z IEC nie wspominam, bo jeżeli coś "kliknąłeś" w $dd00, $dd02 (ba - czasem wystarczy że nie kliknąłeś tego, czego potrzeba w przeciągu kilkunastu cykli !!!) to z 99% prawdopodobieństwem na zadaniu możesz postawić krzyżyk.
Istota jest taka, że musisz wiedzieć o tym, że podczas zatrzymywania procesu były otwarte top i bottom border, że jest to niezbędne do poprawnej pracy efektu, do czego nie ma sprzętowych "wykrywaczy".
Więc zatrzymaj te procesy, a potem je uruchom...
edit:
Byłbym zapomniał - ostatnie 2 efekty od linii 0 rozciągają w pionie w nieskończoność jedną linię sprajta, więc jeżeli nie robiłeś tego od początku (czyli od linii 0 ekranu) - również zadanie się nie uruchomi.
Toz to droga do epilepsji. To co ty proplnujesz nie nadaje sie na system wielozadaniowy poniewaz przelaczanie zadan trwaloby wiecznosc, co najwyzej to mialoby sens jako frezeer do debugowania programu, a nie uruchamiania ich rownolegle.
Zreszta nawet systemy 32 bitowe nie pozwalaja na bezposrednia ingerencje w obszar I/o ja takich ograniczen nie robie.
Multitasking jest tylko dodatkiem nie celem, z ktorego dobry programista moze skozystac, majac mozliwosc blyskawicznego przelaczania zadan, ale musi rozumiec ze nie wszystko da sie zrobic na tak slabym sprzecie.
A co do budowy frezera to mam pewien pomysl i pewnie go zrealizuje, z tego co sie dowiedzialem to tak naprawde jedyna przeszkoda jest brak mozliwosci odczytu wartosci poczatkowej Timerow CIA, mam na to pomysl, nalozyc AVR i niech przechwytuja wpisy do timerow, a pozniej udostepniaja je w wolnym obszarze I/o , opracowalem tez lepszy uklad freezer, ktory reaguje nie tylko na przycisk ale wogole na kazde przerwanie z brk wlacznie.
http://forum.6502.org/viewtopic.php?f=4&t=3452
Na zwyklym c64 taka sytuacja tez jest mozliwa, ale nie slyszalem aby ktos mial z tym problemcomankh pisze:/Ale co ma do tego synchronizacja z IEC./
More than nops...
pyta laik - dwa programy używające różnych turboloaderów?
A na powaznie to z poziomu systemu mozesz zgrac cala pamiec 16MB bez problemu.
Z reszta stacje 1541 nalezy w tym systemie uwazac za urzadzenie do uruchamiania starszego softu. Ja zalecam i glownie stosuje polaczenie przez USB z PC, a docelowo opracowuje stacje kart SD z szybka transmisja handshake co daje ok. 70 kB/sek. Bo tylko takie rozwiazanie zapewni komfortowa prace.
Te transmisje wykozystuje uklad do laczenia poprzez USB, ale z powodu ograniczenia konwertera usb/rs daje sie wyciagnac jedynie ok 12 kB/sek.
Czasem nie naduzywasz kisielucomankh pisze:/uruchamiania starszego softu/
/back to troll mode/ a jaki jest tzw. nowy?
Jako nowy mozna uzyc np. kompilacji starszego, mozna tez latwo tworzyc na swoje potrzeby nowy kozystajac z Basica i wielkiego RAM.
A przede wszystkim jest to propozycja dla kogos kto chce urzywac prawdziwego c64 czy to w formie zabawy czy do powazniejwzych zastosowan ,a nie osob ktore zamykaja c64 w szafie i jedynie ogladaja dema lub graja w gry na emulatorze
To jest dla osob chcacych przedluzyc zycie c64 i znalezc mu nowe zastosowania , czyli raczej nie dla ciebie comankh
Urzywałem C64 do poważnych zastosowań (typu pisanie sprawozdań na laborki w technikum w pierwszej połowie lat 90-tych), praca dyplomowa tamże również powstała przy użyciu C64 (programator Epromów, emulator itp były do niego podpięte). Wiesz co, mam z tamtych czasów Edytor PL na cartridge'u, do niego była dyskietka ze słownikiem. Mogę Ci sprezentować, bo słownik to jest chyba rzecz której najbardziej w tej chwili potrzebujesz.8bit2 pisze: A przede wszystkim jest to propozycja dla kogos kto chce urzywac prawdziwego c64 czy to w formie zabawy czy do powazniejwzych zastosowan ,a nie osob ktore zamykaja c64 w szafie i jedynie ogladaja dema lub graja w gry na emulatorze
- konto nieaktywne -
Kolego - żeby nie było niejasności - nie ma nic przeciwko Twojemu wynalazkowi, a nawet Cię podziwiam za wiedzę i umiejętności. Rób go sobie i rozwijaj, może się coś fajnego wykluje.
Zarzucasz mi szafowanie multitaskingiem, kiedy to ja zwróciłem Ci uwagę, że Ty w błędny sposób pokazujesz założenie działania Twojego rozszerzenia (poczytaj ten wątek jeszcze raz i upewnij się kto wyskoczył z multitaskingiem). Ty pokazałeś jak niby to pracuje na zasadzie wielu okien otwartych z VICE, co według mnie jest błędem w założeniu, bo tak to nie działa.
Dalsze Twoje wywody są propozycją sposobów na jak najlepsze "zamrażanie" programu - a ja ci udowadniam, że NIE MA IDEALNYCH "zamrażarek" i NIGDY NIE BĘDZIE.
Usiłujesz rozwiązać problem przechwytywania wartości początkowych timerów, co jeżeli Ci się uda - jest tylko częścią problemu - MUSISZ ZROZUMIEĆ ŻE CZĘŚĆ EFEKTÓW OPIERA SIĘ NA GLITCH'ACH VIC'a I NIE JESTEŚ W STANIE ICH PRZERWAĆ I KONTYNUOWAĆ, BO NAWET NIE WIESZ CZY TO BAZOWANIE EFEKTU NA GLITCH'u VIC'A MIAŁO MIEJSCE I NA JAKIM GLITCH'u BYŁ PROWADZONY EFEKT !!!!!!!!!!!!!!!!
Skąd możesz wiedzieć że ramkę wcześniej PRZED twoim zamrożeniem programu był dla "poprawnego" działania efektu na glitch'u otwarty dolny border, a potem (ale jeszcze w POPRZEDNIEJ ramce) grafika była WYŁACZONA ???
Skąd możesz wiedzieć, że przez ileś linii rastra był software'owo rozciągany sprajt ?
Jeżeli nie odtworzysz tych warunków - przykładowo od linii rastra 30 wyświetlasz cały czas 1szą linię sprajta a jesteś już przykładowo w lini 90 ! NO SKĄD MOŻESZ TO WIEDZIEĆ ? Więc jeżeli nie odtworzysz tych warunków - ucieknie synchronizacja programu z rastrem i będzie blanc screen, bo nie wyświetlisz sprajtów tak jak były wyświetlone i nie będą one kradły cykli jak zakładał to program który się z rastrem zsynchronizował.
Zarzucasz mi szafowanie multitaskingiem, kiedy to ja zwróciłem Ci uwagę, że Ty w błędny sposób pokazujesz założenie działania Twojego rozszerzenia (poczytaj ten wątek jeszcze raz i upewnij się kto wyskoczył z multitaskingiem). Ty pokazałeś jak niby to pracuje na zasadzie wielu okien otwartych z VICE, co według mnie jest błędem w założeniu, bo tak to nie działa.
Dalsze Twoje wywody są propozycją sposobów na jak najlepsze "zamrażanie" programu - a ja ci udowadniam, że NIE MA IDEALNYCH "zamrażarek" i NIGDY NIE BĘDZIE.
Usiłujesz rozwiązać problem przechwytywania wartości początkowych timerów, co jeżeli Ci się uda - jest tylko częścią problemu - MUSISZ ZROZUMIEĆ ŻE CZĘŚĆ EFEKTÓW OPIERA SIĘ NA GLITCH'ACH VIC'a I NIE JESTEŚ W STANIE ICH PRZERWAĆ I KONTYNUOWAĆ, BO NAWET NIE WIESZ CZY TO BAZOWANIE EFEKTU NA GLITCH'u VIC'A MIAŁO MIEJSCE I NA JAKIM GLITCH'u BYŁ PROWADZONY EFEKT !!!!!!!!!!!!!!!!
Skąd możesz wiedzieć że ramkę wcześniej PRZED twoim zamrożeniem programu był dla "poprawnego" działania efektu na glitch'u otwarty dolny border, a potem (ale jeszcze w POPRZEDNIEJ ramce) grafika była WYŁACZONA ???
Skąd możesz wiedzieć, że przez ileś linii rastra był software'owo rozciągany sprajt ?
Jeżeli nie odtworzysz tych warunków - przykładowo od linii rastra 30 wyświetlasz cały czas 1szą linię sprajta a jesteś już przykładowo w lini 90 ! NO SKĄD MOŻESZ TO WIEDZIEĆ ? Więc jeżeli nie odtworzysz tych warunków - ucieknie synchronizacja programu z rastrem i będzie blanc screen, bo nie wyświetlisz sprajtów tak jak były wyświetlone i nie będą one kradły cykli jak zakładał to program który się z rastrem zsynchronizował.
i ja się podpiszę.Nitro pisze:To ja się pod tym podpisze.podziwiam za wiedzę i umiejętności. Rób go sobie i rozwijaj, może się coś fajnego wykluje.
Chociaż nie wiem po co to rozwlekane przekonywanie o sensie lub nie - zrób i już.
Co do idealnego freeza, nie jest ważne odtworzenie wszystkich warunków - rozciąganie sprites, zamykanie ramek itd. - ważne jest "odcyklowanie" warunków dla restartu. Mało mnie obchodzi czy restartowa klatka będzie idealna, bo będzie to trwało najwyżej 1/50 sekundy - i tak nie zauważę.
Ale.. ważne żeby następna już była poprawna.
No ale taki poprawny restart będzie zależał do skrupulatnie wykonanej procedury wejścia do freeza - wyliczanie warunków cyklowych nawet przez kilka kolejnych rastrów po freezie i porównanie z rejestrami vica. Tak aby przy restarcie stworzyć programową protezę odcyklowania [po prostu aby program nie zaliczył zwisa].
A stacja, no co ma być ze stacją, przecież to zewnętrzne urządzenie - kij z nią - albo frezee sprzęgnięty na podobnych zasadach w elektronice stacji (ale to już łabędzi śpiew). Ew. takie pisanie loaderów aby były przygotowane na przerwy.
No ale po co przełączać "okienka" jak leci demo?
Bo pecet to zwykły banan...
Jeszcze raz powtarzam ze nie buduje frezera. Z kilku powodow 1 to tak jak tu napisaliscie bylby bardzo trudny w realizacji, a po drugie nawet gdyby te warunki dalo sie odtworzyc to zajeloby to w kazdym cyklu tak duzo czasu ze multitasking stracilby sens. Dla mnie wazniejsze sa nowe mozliwosci jakie mozna uzyskac dzieki duzej ilosci RAM i przy okazji zgodnosci z calym oprogramowaniem c64 a wiec i latwosci w jego pisaniu.
Prosty przyklad dobry menager plikow z turboloaderm na c64 cos podobnego do norton commandera. Na 64 kB praktycznie nie do zrobienia,dlaczego ?
Bo program musi zajmowac malo RAM, co w konsekwencji ogranicza ilosc funkcji, a i tak znajdzie sie sporo programow ktore i tak nie beda z nim dzialac chocby z powodu nadpisywania sie pamieci.
A dzieki bankowaniu taki program jest jaknajbardziej mozliwy, nie mam ograniczen co do RAM dla programu, a i sam program nawet w jednym bajcie nie bedzie kolidowal z ladowanym programem wiec nadpisywanie jest praktycznie niemozliwe.
Prosty przyklad dobry menager plikow z turboloaderm na c64 cos podobnego do norton commandera. Na 64 kB praktycznie nie do zrobienia,dlaczego ?
Bo program musi zajmowac malo RAM, co w konsekwencji ogranicza ilosc funkcji, a i tak znajdzie sie sporo programow ktore i tak nie beda z nim dzialac chocby z powodu nadpisywania sie pamieci.
A dzieki bankowaniu taki program jest jaknajbardziej mozliwy, nie mam ograniczen co do RAM dla programu, a i sam program nawet w jednym bajcie nie bedzie kolidowal z ladowanym programem wiec nadpisywanie jest praktycznie niemozliwe.
> restartowa klatka będzie idealna, bo będzie to trwało najwyżej 1/50 sekundy - i tak nie zauważę.
Nie nie wróci do normy po jednej ramce - bo choćby dlatego, że przy WYłączonej grafice jak chce pokazywać sprajty to musi najpierw 1 ramkę wcześniej WŁączyć grafikę, potem ją WYłączyć - inaczej blanc screen
Nie pojawi się poprawna next ramka jak się rozsynchronizował program w pętli migający za rastrem bo już nie ma kolejnej synchronizacji, ponieważ synchronizacją była PĘTLA - pętla, która przewidywała, że w lini 90 przykładowo sprajty kradły 10 cykli, ale sprajtów już NIE MA bo zostały w linii 30 i nie były rozciągnięte. Nie ma synchronizacji co ramkę z rastrem bo jest pętla na 19656 cykli ...
Nie nie wróci do normy po jednej ramce - bo choćby dlatego, że przy WYłączonej grafice jak chce pokazywać sprajty to musi najpierw 1 ramkę wcześniej WŁączyć grafikę, potem ją WYłączyć - inaczej blanc screen
Nie pojawi się poprawna next ramka jak się rozsynchronizował program w pętli migający za rastrem bo już nie ma kolejnej synchronizacji, ponieważ synchronizacją była PĘTLA - pętla, która przewidywała, że w lini 90 przykładowo sprajty kradły 10 cykli, ale sprajtów już NIE MA bo zostały w linii 30 i nie były rozciągnięte. Nie ma synchronizacji co ramkę z rastrem bo jest pętla na 19656 cykli ...