C64Power Forum

Software => Programowanie => Wątek zaczęty przez: Skull w 22 Lipca 2009, 07:00

Tytuł: dylemat
Wiadomość wysłana przez: Skull w 22 Lipca 2009, 07:00

Sprawa wyglada tak: mam loader w stacji, a potrzebuje w miare krotkiego algorytmu do zapisania danych bufora (w stacji) do wybranego sektora na dysku (highscore w grze).
Jak to wykonac \"najtanszym\" kosztem (nie musi byc czasowo najkrotszym) - jednorazowe zgranie bufora w stacji na dysk.

Problem w tym, ze zwykle uruchomienie (zgranie) kodu sterujacego buforem $90 nie zadziala bo juz jest \"podmieniona\" petla stacji przez loader (albo jak chwilowo ustawic stacje w standardowy stan).

ps. nie mam zbyt duzego doswiedczenia w programowaniu stacji, wiec moge sie juz mylic w zalozeniach.

Tytuł: dylemat
Wiadomość wysłana przez: wegi w 22 Lipca 2009, 08:10

np. dorabiasz w loaderze dodatkowy kod sterujacy nim, w ktorym podajesz kod operacji, trak i sektor bloku do zapisu oraz posylasz blok danych do stacji, potem w stacji w mainloop wykonujesz kod $90...

Tytuł: dylemat
Wiadomość wysłana przez: Skull w 27 Lipca 2009, 07:13

Wegi dzieki za szybka odpowiedz.
No nie wiem czy Cie dobrze zrozumialem, ale cos tam mi sie udalo zrobic.
Tyle, ze po zapisie glowica mi zawsze zjezdza na sciezke 1 i musze dodawac jsr $d005, zeby inicjowac - czy tak musi byc ?

Drugie pytanie: jak wyglada ta mainloop w stacji ?

Tytuł: dylemat
Wiadomość wysłana przez: wegi w 27 Lipca 2009, 09:19

mainloop to petla przerywana przez irq, to w niej wpisujerz kod operacji w tym wypadku $90 - to ta petla jakby pierwsza, czasami jest ona wystarczajaca i nie trzeba dorabiac obslugi przerwania czasami trzeba, mysle, ze w Twoim przypadku trzeba jezeli jest load i zapis.

Glowica MA Ci zjezdzac tam, gdzie Ty chcesz D005 jest niebezpieczne, bo jak nie uda sie zainicjowac dysku to stracisz kontrole nad programem - predze kod B0. D005 mozesz zabezpieczyc sie przed utrata kontroli - patrz loader z C&A. Poza tym - jak czytasz po trackach to nie potrzebujesz jezdzic nad 18ta sciezke przykladowo - bo nie wiem jak pracuje Twoj program..., Chyba, ze masz pewnosc, ze nastepna operacja bedzie nad 18ta sciezka.

Tytuł: dylemat
Wiadomość wysłana przez: Skull w 27 Lipca 2009, 13:16

Jeszcze pytanie z innej beczki, czy sa jakies rozwiazania odnosnie wysylania rozkazow m-e i m-w do stacji bez uzycia kernala (oprocz oczywiscie kopii samych procedur z kernala) oraz aby nie kolidowalo to z przerwaniami irq ?

Tytuł: dylemat
Wiadomość wysłana przez: Kisiel w 27 Lipca 2009, 13:47

no mozesz sobie napisac procedury komunikacji w stacji i w komciu, ale i tak je musisz wyslac przez procedury kernala (albo podobne). To takie pytanie o jajo i kure

Tytuł: dylemat
Wiadomość wysłana przez: Skull w 27 Lipca 2009, 13:56

heh Kisiel - wlasnie nie koniecznie. Trzeba na poczatku z preparowac te ktore sa w kernalu (oczywiscie w pamieci ram) i z niego juz od poczatku nie korzystac.

Ale pytanie chodzi o (raczej gotowe) rozwiazania - od razu mowie, ze nie przeszkadza mi, ze na poczatku musialbym uzyc romu w kernalu, aby \"cos przerzucic do stacji, ale potem juz niech komunikacja przebiega bez uzycia Kernala - no i co wazne - przerwania irq, nie zaklucaja jej pracy.

Tytuł: dylemat
Wiadomość wysłana przez: wegi w 27 Lipca 2009, 14:04

Nie slyszalem o takich i nie wiem czy jest mozliwe takie stworzyc. Jak popychasz sobie z ATN i czekasz okreslony czas na odpowiedz to chyba nie chcesz z kolei, zeby IRQ Ci przerwalo oczekiwanie i zliczanie czasu, zeby czegos nie przegapic? Nie wydziwiaj - dlatego wlasnie na starcie programu uruchomialo sie program w stacji (przed inicjacja IRQ) i dalej on sam sobie przesylal swoim protokolem kody sterujace. Jaki problem jest miec krociutka procke pod $0150, co laduje Ci bloki danych pod wskazany adres i zrobi JMP pod wskazany adres? Bedzie to jednym z kodow sterujacych Twojego programu - takie opcje dorabiane moga byc jak masz duzo roznych procedur - wtedy robisz sobie np. jeden blok obslugujacy sekwencje sterujace i wszystkie uniwersalne procedury, a inne dane doczytujesz w trakcie. Zdeassembluj sobie ram stacji po load i po format z actiona - to, ze nie robi tego w IRQ to tylko kwestia drobnych przerobek ale masz przyklad. Zobacz sobie MS-Crunchera jak wybierasz urzadzenie po inicjacji IRQ - wtedy szarpnie - byla mozliwosc, zeby:

1. Nie szarpnelo i nie bylo tej opcji
2. Szarpnelo i byla opcja
3. Udawac, szurum buru przez 15 sekund wyciszac muzyke, pomrugac paskami, zrobic blank screena, wylaczyc IRQ i od nowa - to by pewnie design sie nazywalo

Natomiast jak chcesz korzystac tylko z tego urzadzenia do ktorego sie juz wczesniej\"dobiles\" - nie ma problemu z m-e czy m-w

Gotowe rozwiazanie przykladowo masz w loaderze MS-crunchera, ktory moze:

1. przeslac zadany sektor
2. przeslac zadana sciezke
3. przeslac zeskanowana sciezke
4. przejsc w tryb \"watch and wait\"
5. odlaczyc sie - zakonczyc prace

Wszystko dosc obszernie skomentowane i nazwy etykiet sa znamienne
Nie ma tam 6tej opcji na zapis bloku i 7mej na odtworzenie loadera ale chodzi o przyklad...

Tytuł: dylemat
Wiadomość wysłana przez: Skull w 27 Lipca 2009, 16:52

Ogladalem tylko procedure zapisu, dalej sie nie zaglebialem, ale sprawdze. Z tego co piszesz, najbardziej pewnie mnie bedzie interesowac \"watch and wait\".
Chodzi o to, ze chocbym nie wiem jaki sobie system zaprogramowal w stacji i tak musze dac mu znac z komputera co ma zrobic. A tu problemem jest - jak przeslac chociaz jeden bajt poprawnie (niezwoadnie), przy roznych \"warunkach\" w tle.



ps.gdzie mozna znalezc dane odnosnie np. czasu oczekiwanego czasu odpowiedzi na rejestrze $dd00 itp. (najlepiej w cyklach)?

Tytuł: dylemat
Wiadomość wysłana przez: wegi w 27 Lipca 2009, 18:39

Dobra odwrocmy sprawe - jezeli w tle jak twierdzisz co chwile zmieniaja sie warunki to:

1. STWARZASZ warunki do tego, zeby odbierac dane i potem odtwarzasz poprzednie warunki - robisz to np jak juz jest tak trudno gdzies w okolicach borderu gornego albo dolnego
(fenkowi zostaly 4linie rastra i nie widzi problemu, zeby komunikowac sie ze stacja)
2. Albo robisz sobie transmisje jednobitowa, gdzie warunkiem jest widoczne I/O a bity mozesz sobie odbierac chocby co rok co nie powinno byc problemem, bo na I/O czesto operujesz wiec masz je widoczne.

hmm... no raczej po to piszemy wlasne programy, zeby niezawodnie sie komunikowac

LICZYC CYKLE - z przykladu otwierania borderow JETBOY\'a zrobic procedure, ktora pokaze Ci ile cykli zajmuje dany rozkaz - bo w ksiazkach sa bledy i niedopowiedzenia.

Najszybciej jestes w stanie co 8 cykli wysylac i odbierac bity - pomimo, ze wydaje sie, iz mozna wejsc w transmisje pomiedzy 1szym i 8mym cyklem, to tak nie jest bo odchylki na kwarcu w gore i w dol ma i komputer i stacja. Jezeli odbierasz 1 bajt to musisz wejsc pomiedzy 2gim a 7mym cyklem, jezeli odbierasz cztery bajty  bez potwierdzenia, to musisz wejsc pomiedzy 3cim a 6tym cyklem i potem sie synchronizowac - zobacz MS-Cruncher, Action.
Kiedys na jednej stacji testowalem transmisje, wyobraz sobie, ze wszystko bylo dobrze przez kilka nieraz kilkanascie MINUT, a potem BUMS - verify error - a na drugiej stacji wszystko gra !!?? Trzeba bylo zmienic cyklowanie i dobrze, ze mialem druga stacje, bo bym tego nie wykryl !!
Powyzsze nie dotyczy transmisji jednobitowej gdzie masz obustronne potwierdzenie (handshake - po polsku handszaking:) - uscisk dloni) odbioru i nadania bitu.
Pomijam NTSC - bo sam dopiero wirtualnie to obsluzylem, wiec sie nie bede wymadrzal - 1bitowa gdyby co

Uff - pochwal mnie chociaz za cierpliwosc do Ciebie  

Tytuł: dylemat
Wiadomość wysłana przez: Skull w 27 Lipca 2009, 19:11

                   

wegi napisal:

Uff - pochwal mnie chociaz za cierpliwosc do Ciebie

Chwale i puki jeszcze masz - nawijam dalej:

W sumie dykusja moze i ciekawa, ale caly czas mam wrazenie ze omija temat ktory mnie najbardziej interesuje.

Wiec tak:
1) nie interesuje mnie transmisja \"wycyklowana\", albo dwubitowa, albo najszybsza, albo jakas inna genialna, czy tam jakies triki - mam w programie loader jednobitowy ktory mi w zupelnosci wystarcza.
2) Problem sie pojawia przy odwolaniach przed transferem \"wlasciwym\" - przekazaniu stacji np. sektora i sciezki i zwyklym wywolaniu w niej rozkazu m-e.
Poniewaz nie korzystam z kernela (bo korzystam caly czas z pamieci pod nim) skopiowalem sobie wybrane procedury (listen itd) wyrzucajac z nich jakies odwolania do magnetofonu i jeszcze pare innych zbednosci, oraz usunalem przelaczenia przerwan IRQ. I...
to dziala - nawet calkiem ladnie, ale... nie zawsze (chodzi o same rozkazy wywolujace kontakt ze stacja - potem to juz idzie).
Oczywiscie przyczyna tej sytuacji sa przerwania vica - ktore wykorzystuje np. do efeku w trakcie ladowania plikow - i zalezy to od losowosci, tzn. w ktorym dokladnie momencie akurat zacznie sie procedura komunikacji.
 
Program sie kladzie przy procedurze przesylania 8 bitow do stacji. Wszystko jest ok jak tylko na tej procedurze ustawie SEI - ale niestety potrafi ona mi zezrec czasem tak duzo, ze zniszczy caly efekt graficzny ( i nie wierze w te 4 linie rastra zeby skutecznie skomunikowac sie ze stacja - jesli juz nastapila synchronizacja to i owszem, ale przed to mzonki). Czastkowanie tej procedury tzn wylaczanie przerwan tylko w okreslonych momentach nie daje nadal zadowalajacego efektu. Moze gdybym znal czasy odstepu w jakich mam dobierac sie do DD00 to moze nabralo by to sensu.
Nie wiem czemu, ale gubi to polaczenie handshake.
Moze jakies inne pomysly?

Tytuł: dylemat
Wiadomość wysłana przez: wegi w 28 Lipca 2009, 06:34

Krecisz motasz i robisz sobie pod gorke...

Skad mam wiedziec ile cykli, jak nie widze Twojej procedury, ponadto co Ci po cyklach jak masz przejscie z sektora na nastepny to jak mozesz to uzalezniac od cykli jak nie wiesz kiedy stacja odczyta nastepny blok?

Sluchaj raz na zawsze zapamietaj - czytaj co powyzej : z kernala korzystasz na poczatku programu tylko raz do poslania programu i m-e i KONIEC KERNALA. Po co Ci kopiowac procedury i takie tam niepotrzebne cuda na kiju. Reszte sztuczek MA obslugiwac TWOJ program.

Nie widze twojego programu - zgaduje, ze mieszasz bankami i $01 - w takim przypadku zrob sobie SEI nie przed oczekiwaniem na bajt tylko w koniecznych momentach - przykladowo:

jezeli masz caly czas widoczne IO - to wystarczy np. oczekiwanie na komunikacje:

BIT $DD00
BMI *-3

albo:
BIT $DD00
BPL NOTNOW

TRANSMIT
...
...


NOTNOW...


Jak mieszasz $01 i bankami VICA to musisz podobnie jak nizej:

PHP
SEI
LDA $01
PHA
LDA #$35
STA $01

i teraz LDA $DD00
          STA $02
PLA
STA $01
PLP

I teraz sprawdzasz - BIT $02 (oczywiscie w przerwaniu niech nic Ci nie podmienia $02 tzn. nie uzywaj $02 przez INNE procki to wtedy Twoje zdublowane DD00

w podobny sposob wszelkie odwolania do $dd00

w stylu
LDA $DD00
ORA #$20
STA $DD00

to w miejscu jak poprzednio LDA $DD00
STA $02

w taki sposob opoznisz przerwanie o kilkanascie cykli (policz ile) - (w razie czego ustaw sobie 1 linie wczesniej przerwanie) ale uchronisz sie przed przelaczaniem widocznosci I/O i zmiana bankow VICA.

Dobra teraz juz musisz skumac

Tytuł: dylemat
Wiadomość wysłana przez: Skull w 28 Lipca 2009, 17:55

no rejestry mam caly czas widoczne i nie musze, az tak kombinowac.

Ale znalazlem przyczyne \"zwiechow\", przy nawiazywaniu kontkow ze stacja  - w procedurze przesylania bajtu (orginalnie $ed40 w Kernalu) jest w pewnym momencie podwojne odniesienie do $dd00 - jest to pobranie znaku synchronizacji ze stacji. Wyglada to mniej wiecej tak:
                   

Kod:

:  : :  :lda $dd00  :  : :  :bpl *-3  :  : :  :lda $dd00  :  : :  :bmi *-3

Wystarczy wlasnie ta czesc zabezpieczyc od przerwan i dziala bezproblemowo (zajmuje to okolo kilkunastu linijek rastra, a wiec da sie gdzies upchac miedzy przerwaniami).

Tu juz problem rozwiazany.
Zostal jeszcze ten poczatkowy od zapisu - po zapisie (kod $90) bloku z $0300-$03ff, glowica spieprza mi na sciezke 1 (jakby kod $c0), i jak przy wyjsciu z procedury nie zainicjuje jej wlasnie tym jsr $d005, to loader potem bye bye.

W kernalu stacji sie slabo orientuje i ciezko mi bedzie cos temu zaradzic - Wegi ratuj
Moze przesle Ci ta czesc kodu?

Tytuł: dylemat
Wiadomość wysłana przez: wegi w 28 Lipca 2009, 23:22

Albo ja pisze co innego i czytam co innego albo Ty nie czytasz co ja pisze :

PRZESTAN CUDACZYC Z TYM KERNALEM - NIE TWORZ KOLA OD POCZATKU ! KERNAL TYLKO RAZ! TYLKO PRZED PRZERWANIAMI POTEM WLASNE PROCKI!

To, ze gdzies Ci ucieka glowica - tak nie powinno byc - musisz to dobrze oprogramowac i wiedziec co sie dzieje ze stacja, nie ma takich cudow jak tu wypisujesz, bo jak cos nie wiesz i to wypuscisz, to zgodnie z prawem Murphi\'ego... wiesz co.

Pomoge Ci z tym loaderem, tylko zeby nie wyszlo, ze wegi Ci powalil gre jak bedziesz tak cudaczyc

Tytuł: dylemat
Wiadomość wysłana przez: Skull w 29 Lipca 2009, 00:00

hehe nie krzycz

No nic, sprobuje zaadoptowac Twoje procedury senddrv i getblk z MS-Crunchera, jesli pozwolisz ? Z lezka w oku, wytne swoj zamiennik kernala.
Potem przesle zrodla, loader jest stworzony na podstawie kursu z C&A (czyli Twojego), a wiec nic nowego nie bedzie


O gre sie nie martw, jest juz zrobiona, teraz walcze z cala \"otoczka\". Jak tak nie pojdzie to sie wymysli co innego.

Tytuł: dylemat
Wiadomość wysłana przez: Kisiel w 29 Lipca 2009, 15:03

@skull

                   

kisiel napisal:

no mozesz sobie napisac procedury komunikacji w stacji i w komciu, ale i tak je musisz wyslac przez procedury kernala (albo podobne). To takie pytanie o jajo i kure

Teraz pytanie: po co tyle pisac mieszac jak w koncu zrobisz po staremu jak napisalem

Tytuł: dylemat
Wiadomość wysłana przez: Skull w 30 Lipca 2009, 18:41

po co, po co...
Bo tylko tak umialem...

Zreszta, teoretycznie, program uruchomilby sie nawet na komputerze z uszkodzonym Kernalem - a to juz cos