dylemat

Szukasz drobnej pomocy przy kodowaniu, albo chcesz przedstawić światu swoją gotową lub w trakcie realizacji produkcję? To właściwy dział.
Wiadomość
Autor
Awatar użytkownika
skull
Posty: 760
Rejestracja: 15 wrz 2008, 08:18
Grupa: samar

dylemat

#1 Post autor: skull »

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.
Bo pecet to zwykły banan...

Awatar użytkownika
wegi
Posty: 839
Rejestracja: 14 lip 2009, 01:17

#2 Post autor: wegi »

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...

Awatar użytkownika
skull
Posty: 760
Rejestracja: 15 wrz 2008, 08:18
Grupa: samar

#3 Post autor: skull »

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 ?
Bo pecet to zwykły banan...

Awatar użytkownika
wegi
Posty: 839
Rejestracja: 14 lip 2009, 01:17

#4 Post autor: wegi »

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ą.

Awatar użytkownika
skull
Posty: 760
Rejestracja: 15 wrz 2008, 08:18
Grupa: samar

#5 Post autor: skull »

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 ?
Bo pecet to zwykły banan...

k.

#6 Post autor: k. »

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ę ;)

Awatar użytkownika
skull
Posty: 760
Rejestracja: 15 wrz 2008, 08:18
Grupa: samar

#7 Post autor: skull »

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.
Bo pecet to zwykły banan...

Awatar użytkownika
wegi
Posty: 839
Rejestracja: 14 lip 2009, 01:17

#8 Post autor: wegi »

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...

Awatar użytkownika
skull
Posty: 760
Rejestracja: 15 wrz 2008, 08:18
Grupa: samar

#9 Post autor: skull »

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)?
Bo pecet to zwykły banan...

Awatar użytkownika
wegi
Posty: 839
Rejestracja: 14 lip 2009, 01:17

#10 Post autor: wegi »

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 :wink:

Awatar użytkownika
skull
Posty: 760
Rejestracja: 15 wrz 2008, 08:18
Grupa: samar

#11 Post autor: skull »

wegi pisze: Uff - pochwal mnie chociaż za cierpliwość do Ciebie :wink:
:-) 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...

Awatar użytkownika
wegi
Posty: 839
Rejestracja: 14 lip 2009, 01:17

#12 Post autor: wegi »

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ć

Awatar użytkownika
skull
Posty: 760
Rejestracja: 15 wrz 2008, 08:18
Grupa: samar

#13 Post autor: skull »

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:

Kod: Zaznacz cały

		lda $dd00
		bpl *-3
		lda $dd00
		bmi *-3
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?
Bo pecet to zwykły banan...

Awatar użytkownika
wegi
Posty: 839
Rejestracja: 14 lip 2009, 01:17

#14 Post autor: wegi »

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ć

Awatar użytkownika
skull
Posty: 760
Rejestracja: 15 wrz 2008, 08:18
Grupa: samar

#15 Post autor: skull »

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 :P


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.

#16 Post autor: k. »

@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 :)

Awatar użytkownika
skull
Posty: 760
Rejestracja: 15 wrz 2008, 08:18
Grupa: samar

#17 Post autor: skull »

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ś :wink:
Bo pecet to zwykły banan...

ODPOWIEDZ