c64scene.pl

Sprawa wygląda tak: mam loader w stacji, a potrzebuję w miarę krótkiego algorytmu do zapisania danych bufora (w stacji) do wybranego sektora na dysku (highscore w grze).
Jak to wykonać "najtańszym" kosztem (nie musi być czasowo najkrótszym) - jednorazowe zgranie bufora w stacji na dysk.

Problem w tym, że zwykłe uruchomienie (zgranie) kodu sterującego buforem $90 nie zadziała bo już jest "podmieniona" pętla stacji przez loader (albo jak chwilowo ustawić stację w standardowy stan).

ps. nie mam zbyt dużego doświedczenia w programowaniu stacji, więc mogę się już mylić w założeniach.

np. dorabiasz w loaderze dodatkowy kod sterujący nim, w którym podajesz kod operacji, trak i sektor bloku do zapisu oraz posyłasz blok danych do stacji, potem w stacji w mainloop wykonujesz kod $90...

Wegi dzięki za szybką odpowiedź.
No nie wiem czy Cię dobrze zrozumiałem, ale coś tam mi się udało zrobić.
Tyle, że po zapisie głowica mi zawsze zjeżdża na scieżkę 1 i muszę dodawać jsr $d005, żeby inicjować - czy tak musi być ?

Drugie pytanie: jak wygląda ta mainloop w stacji ?

mainloop to pętla przerywana przez irq, to w niej wpisujerz kod operacji w tym wypadku $90 - to ta pętla jakby pierwsza, czasami jest ona wystarczająca i nie trzeba dorabiać obsługi przerwania czasami trzeba, myślę, że w Twoim przypadku trzeba jeżeli jest load i zapis.

Głowica MA Ci zjeżdżać tam, gdzie Ty chcesz D005 jest niebezpieczne, bo jak nie uda się zainicjować dysku to stracisz kontrolę nad programem - prędze kod B0. D005 możesz zabezpieczyć się przed utratą kontroli - patrz loader z C&A. Poza tym - jak czytasz po trackach to nie potrzebujesz jeździć nad 18tą ścieżkę przykładowo - bo nie wiem jak pracuje Twój program..., Chyba, że masz pewność, że następna operacja będzie nad 18tą ścieżką.

Jeszcze pytanie z innej beczki, czy są jakieś rozwiązania odnośnie wysyłania rozkazów m-e i m-w do stacji bez użycia kernala (oprócz oczywiście kopii samych procedur z kernala) oraz aby nie kolidowało to z przerwaniami irq ?

no możesz sobie napisać procedury komunikacji w stacji i w komciu, ale i tak je musisz wysłać przez procedury kernala (albo podobne). To takie pytanie o jajo i kurę

heh Kisiel - właśnie nie koniecznie. Trzeba na początku z preparować te które są w kernalu (oczywiście w pamięci ram) i z niego już od początku nie korzystać.

Ale pytanie chodzi o (raczej gotowe) rozwiązania - od razu mówię, że nie przeszkadza mi, że na początku musiałbym użyć romu w kernalu, aby "coś przerzucić do stacji, ale potem już niech komunikacja przebiega bez użycia Kernala - no i co ważne - przerwania irq, nie zakłucają jej pracy.

Nie słyszałem o takich i nie wiem czy jest możliwe takie stworzyć. Jak popychasz sobie z ATN i czekasz określony czas na odpowiedź to chyba nie chcesz z kolei, żeby IRQ Ci przerwało oczekiwanie i zliczanie czasu, żeby czegoś nie przegapić? Nie wydziwiaj - dlatego właśnie na starcie programu uruchomiało się program w stacji (przed inicjacją IRQ) i dalej on sam sobie przesyłał swoim protokołem kody sterujące. Jaki problem jest mieć króciutką prockę pod $0150, co ładuje Ci bloki danych pod wskazany adres i zrobi JMP pod wskazany adres? Będzie to jednym z kodów sterujących Twojego programu - takie opcje dorabiane mogą być jak masz dużo różnych procedur - wtedy robisz sobie np. jeden blok obsługujący sekwencje sterujące i wszystkie uniwersalne procedury, a inne dane doczytujesz w trakcie. Zdeassembluj sobie ram stacji po load i po format z actiona - to, że nie robi tego w IRQ to tylko kwestia drobnych przeróbek ale masz przykład. Zobacz sobie MS-Crunchera jak wybierasz urządzenie po inicjacji IRQ - wtedy szarpnie - była możliwość, żeby:

1. Nie szarpnęło i nie było tej opcji
2. Szarpnęło i była opcja
3. Udawać, szurum buru przez 15 sekund wyciszać muzykę, pomrugać paskami, zrobić blank screena, wyłączyć IRQ i od nowa - to by pewnie design się nazywało

Natomiast jak chcesz korzystać tylko z tego urządzenia do którego się już wcześniej"dobiłeś" - nie ma problemu z m-e czy m-w

Gotowe rozwiązanie przykładowo masz w loaderze MS-crunchera, który może:

1. przesłać żądany sektor
2. przesłać żądaną ścieżkę
3. przesłać zeskanowaną ścieżkę
4. przejść w tryb "watch and wait"
5. odłączyć sie - zakończyć pracę

Wszystko dość obszernie skomentowane i nazwy etykiet są znamienne
Nie ma tam 6tej opcji na zapis bloku i 7mej na odtworzenie loadera ale chodzi o przykład...

Oglądałem tylko procedurę zapisu, dalej się nie zagłębiałem, ale sprawdzę. Z tego co piszesz, najbardziej pewnie mnie będzie interesować "watch and wait".
Chodzi o to, że choćbym nie wiem jaki sobie system zaprogramował w stacji i tak muszę dać mu znać z komputera co ma zrobić. A tu problemem jest - jak przesłać chociaż jeden bajt poprawnie (niezwoadnie), przy różnych "warunkach" w tle.



ps.gdzie można znaleźć dane odnośnie np. czasu oczekiwanego czasu odpowiedzi na rejestrze $dd00 itp. (najlepiej w cyklach)?

Dobra odwróćmy sprawę - jeżeli w tle jak twierdzisz co chwilę zmieniają się warunki to:

1. STWARZASZ warunki do tego, żeby odbierać dane i potem odtwarzasz poprzednie warunki - robisz to np jak już jest tak trudno gdzieś w okolicach borderu górnego albo dolnego
(fenkowi zostały 4linie rastra i nie widzi problemu, żeby komunikować się ze stacją)
2. Albo robisz sobie transmisję jednobitową, gdzie warunkiem jest widoczne I/O a bity możesz sobie odbierać choćby co rok co nie powinno być problemem, bo na I/O często operujesz więc masz je widoczne.

hmm... no raczej po to piszemy własne programy, żeby niezawodnie się komunikować

LICZYĆ CYKLE - z przykładu otwierania borderów JETBOY'a zrobić procedurę, która pokaże Ci ile cykli zajmuje dany rozkaz - bo w książkach są błędy i niedopowiedzenia.

Najszybciej jesteś w stanie co 8 cykli wysyłać i odbierać bity - pomimo, że wydaje się, iż można wejść w transmisję pomiędzy 1szym i 8mym cyklem, to tak nie jest bo odchyłki na kwarcu w górę i w dół ma i komputer i stacja. Jeżeli odbierasz 1 bajt to musisz wejść pomiędzy 2gim a 7mym cyklem, jeżeli odbierasz cztery bajty bez potwierdzenia, to musisz wejść pomiędzy 3cim a 6tym cyklem i potem się synchronizować - zobacz MS-Cruncher, Action.
Kiedyś na jednej stacji testowałem transmisję, wyobraź sobie, że wszystko było dobrze przez kilka nieraz kilkanaście MINUT, a potem BUMS - verify error - a na drugiej stacji wszystko gra !!?? Trzeba było zmienić cyklowanie i dobrze, że miałem drugą stację, bo bym tego nie wykrył !!
Powyższe nie dotyczy transmisji jednobitowej gdzie masz obustronne potwierdzenie (handshake - po polsku handszaking:) - uścisk dłoni) odbioru i nadania bitu.
Pomijam NTSC - bo sam dopiero wirtualnie to obsłużyłem, więc się nie będę wymądrzał - 1bitowa gdyby co

Uff - pochwal mnie chociaż za cierpliwość do Ciebie

wegi pisze: Uff - pochwal mnie chociaż za cierpliwość do Ciebie

Chwale i puki jeszcze masz - nawijam dalej:

W sumie dykusja może i ciekawa, ale cały czas mam wrażenie że omija temat który mnie najbardziej interesuje.

Więc tak:
1) nie interesuje mnie transmisja "wycyklowana", albo dwubitowa, albo najszybsza, albo jakaś inna genialna, czy tam jakieś triki - mam w programie loader jednobitowy który mi w zupełności wystarcza.
2) Problem się pojawia przy odwołaniach przed transferem "własciwym" - przekazaniu stacji np. sektora i sciezki i zwykłym wywołaniu w niej rozkazu m-e.
Ponieważ nie korzystam z kernela (bo korzystam cały czas z pamięci pod nim) skopiowałem sobie wybrane procedury (listen itd) wyrzucając z nich jakieś odwołania do magnetofonu i jeszcze parę innych zbędności, oraz usunąłem przełączenia przerwań IRQ. I...
to działa - nawet całkiem ładnie, ale... nie zawsze (chodzi o same rozkazy wywołujące kontakt ze stacją - potem to już idzie).
Oczywiście przyczyną tej sytuacji są przerwania vica - które wykorzystuję np. do efeku w trakcie ładowania plików - i zależy to od losowości, tzn. w którym dokładnie momencie akurat zacznie się procedura komunikacji.

Program się kładzie przy procedurze przesyłania 8 bitów do stacji. Wszystko jest ok jak tylko na tej procedurze ustawie SEI - ale niestety potrafi ona mi zeżreć czasem tak dużo, że zniszczy cały efekt graficzny ( i nie wierzę w te 4 linie rastra żeby skutecznie skomunikować się ze stacją - jeśli już nastąpiła synchronizacja to i owszem, ale przed to mżonki). Cząstkowanie tej procedury tzn wyłączanie przerwań tylko w określonych momentach nie daje nadal zadowalającego efektu. Może gdybym znał czasy odstępu w jakich mam dobierać się do DD00 to może nabrało by to sensu.
Nie wiem czemu, ale gubi to połączenie handshake.
Może jakieś inne pomysły?

Kręcisz motasz i robisz sobie pod górkę...

Skąd mam wiedzieć ile cykli, jak nie widzę Twojej procedury, ponadto co Ci po cyklach jak masz przejście z sektora na następny to jak możesz to uzależniać od cykli jak nie wiesz kiedy stacja odczyta następny blok?

Słuchaj raz na zawsze zapamiętaj - czytaj co powyżej : z kernala korzystasz na początku programu tylko raz do posłania programu i m-e i KONIEC KERNALA. Po co Ci kopiować procedury i takie tam niepotrzebne cuda na kiju. Reszte sztuczek MA obsługiwać TWÓJ program.

Nie widzę twojego programu - zgaduję, że mieszasz bankami i $01 - w takim przypadku zrób sobie SEI nie przed oczekiwaniem na bajt tylko w koniecznych momentach - przykładowo:

jezeli masz cały czas widoczne IO - to wystarczy np. oczekiwanie na komunikację:

BIT $DD00
BMI *-3

albo:
BIT $DD00
BPL NOTNOW

TRANSMIT
...
...


NOTNOW...


Jak mieszasz $01 i bankami VICA to musisz podobnie jak niżej:

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

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

I teraz sprawdzasz - BIT $02 (oczywiście w przerwaniu niech nic Ci nie podmienia $02 tzn. nie używaj $02 przez INNE procki to wtedy Twoje zdublowane DD00

w podobny sposób wszelkie odwołania do $dd00

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

to w miejscu jak poprzednio LDA $DD00
STA $02

w taki sposób opoźnisz przerwanie o kilkanaście cykli (policz ile) - (w razie czego ustaw sobie 1 linię wcześniej przerwanie) ale uchronisz się przed przełączaniem widoczności I/O i zmianą banków VICA.

Dobra teraz już musisz skumać

no rejestry mam cały czas widoczne i nie muszę, aż tak kombinować.

Ale znalazłem przyczynę "zwiechów", przy nawiązywaniu kontków ze stacją - w procedurze przesyłania bajtu (orginalnie $ed40 w Kernalu) jest w pewnym momencie podwójne odniesienie do $dd00 - jest to pobranie znaku synchronizacji ze stacji. Wygląda to mniej więcej tak: Wystarczy właśnie tą część zabezpieczyć od przerwań i działa bezproblemowo (zajmuje to około kilkunastu linijek rastra, a więc da się gdzieś upchać między przerwaniami).

Tu już problem rozwiązany.
Został jeszcze ten początkowy od zapisu - po zapisie (kod $90) bloku z $0300-$03ff, głowica spieprza mi na ścieżkę 1 (jakby kod $c0), i jak przy wyjściu z procedury nie zainicjuję jej własnie tym jsr $d005, to loader potem bye bye.

W kernalu stacji sie słabo orientuje i ciężko mi będzie coś temu zaradzić - Wegi ratuj
Może prześlę Ci tą część kodu?

Albo ja piszę co innego i czytam co innego albo Ty nie czytasz co ja piszę :

PRZESTAŃ CUDACZYĆ Z TYM KERNALEM - NIE TWORZ KOŁA OD POCZĄTKU ! KERNAL TYLKO RAZ! TYLKO PRZED PRZERWANIAMI POTEM WŁASNE PROCKI!

To, że gdzieś Ci ucieka głowica - tak nie powinno być - musisz to dobrze oprogramować i wiedzieć co się dzieje ze stacją, nie ma takich cudów jak tu wypisujesz, bo jak coś nie wiesz i to wypuścisz, to zgodnie z prawem Murphi'ego... wiesz co.

Pomoge Ci z tym loaderem, tylko żeby nie wyszło, że wegi Ci powalił gre jak będziesz tak cudaczyć

hehe nie krzycz

No nic, spróbuję zaadoptować Twoje procedury senddrv i getblk z MS-Crunchera, jeśli pozwolisz ? Z łezką w oku, wytnę swój zamiennik kernala.
Potem prześle źródła, loader jest stworzony na podstawie kursu z C&A (czyli Twojego), a więc nic nowego nie będzie


O grę się nie martw, jest już zrobiona, teraz walczę z całą "otoczką". Jak tak nie pójdzie to się wymyśli co innego.

@skull

kisiel pisze:no możesz sobie napisać procedury komunikacji w stacji i w komciu, ale i tak je musisz wysłać przez procedury kernala (albo podobne). To takie pytanie o jajo i kurę

Teraz pytanie: po co tyle pisać mieszać jak w końcu zrobisz po staremu jak napisałem

po co, po co...
Bo tylko tak umiałem...

Zresztą, teoretycznie, program uruchomiłby się nawet na komputerze z uszkodzonym Kernalem - a to już coś