Strona 3 z 3

: 02 maja 2016, 10:29
autor: KB777
"Solution looking for a problem"... Niestety.

: 02 maja 2016, 11:55
autor: 8bit2
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 ( :shock:
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.

: 04 maja 2016, 10:44
autor: wegi
8bit2 pisze: Wegi czy gdybys pisal demo na REU to tez najwiekszym twoim problemem bylaby synchronizacja z dyskietka 170 kB ( :shock:
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.
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.

: 04 maja 2016, 14:20
autor: comankh
8bit2 pisze:Wegi.komancz pisze brednie w rodzaju ze poco mlotek skoro gwozdzie mozna wbijac obcasem, dlatego go ignoruje i nawet tego co pisze nie czytam..
no kurwa wspaniale, a potem wklejasz animację którą zrobiłem.

mocno doceniam.

: 04 maja 2016, 14:45
autor: comankh
wegi pisze:a samych dem i gier na dyskietkach są dziesiątki tysięcy, które ludzie chcą i będą oglądać czy grać
proste.

: 10 maja 2016, 15:47
autor: 8bit2
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.
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 ? ;)
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

: 10 maja 2016, 16:48
autor: comankh
/Ale co ma do tego synchronizacja z IEC./

More than nops...

pyta laik - dwa programy używające różnych turboloaderów?

: 10 maja 2016, 17:20
autor: 8bit2
comankh pisze:/Ale co ma do tego synchronizacja z IEC./

More than nops...

pyta laik - dwa programy używające różnych turboloaderów?
Na zwyklym c64 taka sytuacja tez jest mozliwa, ale nie slyszalem aby ktos mial z tym problem ;)
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.

: 10 maja 2016, 19:20
autor: comankh
/uruchamiania starszego softu/

/back to troll mode/ a jaki jest tzw. nowy?

: 13 maja 2016, 12:55
autor: 8bit2
comankh pisze:/uruchamiania starszego softu/

/back to troll mode/ a jaki jest tzw. nowy?
Czasem nie naduzywasz kisielu :?:
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 :D

: 13 maja 2016, 16:07
autor: KB777
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 ;)
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.

: 13 maja 2016, 16:51
autor: wegi
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ł.

: 13 maja 2016, 17:25
autor: comankh
8bit2 pisze:mozna tez latwo tworzyc
fajnie, ilu aktywnych koderów jest na tym forum?

nowe zastosowania? wymysl mi prosze taki software na c= któremu wiadro ramu będzie niezbędne do życia.

: 13 maja 2016, 22:45
autor: Nitro
podziwiam za wiedzę i umiejętności. Rób go sobie i rozwijaj, może się coś fajnego wykluje.
To ja się pod tym podpisze.

: 14 maja 2016, 09:03
autor: skull
Nitro pisze:
podziwiam za wiedzę i umiejętności. Rób go sobie i rozwijaj, może się coś fajnego wykluje.
To ja się pod tym podpisze.
i ja się podpiszę.
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?

: 14 maja 2016, 11:45
autor: 8bit2
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.

: 14 maja 2016, 12:56
autor: wegi
> 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 ...

: 16 maja 2016, 13:52
autor: 8bit2
Zastanawiam sie jak mozna by spozytkowac czas procesora i wolna pamiec.
Majac w jednym banku dane do wyswietlenia i program obslugi ekranu (przelaczajac na niego procesor jedynie na czas wyswietlania) i rezygnujac z obslugi stacji dyskow ;)