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.
dylemat
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 ?
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 ?
Bo pecet to zwykły banan...
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ą.
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ą.
-
k.
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.
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.
Bo pecet to zwykły banan...
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...
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)?
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)?
Bo pecet to zwykły banan...
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
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?
Bo pecet to zwykły banan...
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ć
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?
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:
Kod: Zaznacz cały
lda $dd00
bpl *-3
lda $dd00
bmi *-3
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?
Bo pecet to zwykły banan...
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ć
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.
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.
Bo pecet to zwykły banan...
-
k.