forum speccy.pl
Komputery z Z80 => AMSTRAD => Wątek zaczęty przez: Abrimaal w 2013.02.18, 18:14:52
-
Oglądając listingi programów, które Zbyniu zamieścił w temacie Tricki (link) (http://speccy.pl/forum/index.php/topic,844.msg10144.html#msg10144), zauważyłem, że CPC ma bardzo rozbudowany Basic.
Czy ma ktoś listę instrukcji, wraz z parametrami i krótkim opisem, co robią.
Czym różni się INK od PEN?
Dlaczego BORDER 2 to inny kolor niż PAPER 2?
Zaskoczyło mnie jak niezwykle szybko CPC wypełnia całą pamięć ekranu 640x200 przez FOR...POKE...NEXT.
-
Parametr w BORDER to kolor wybrany z całej palety czyli od 0 (czarny) do 26 (biały). Lista kolorów jest na obudowie stacji w 6128. Podając 2 parametry sprawimy że będzie mrugała tymi kolorami. Komendą INK wybieramy które kolory z tej pełnej palety chcemy mieć w tej chwili do dyspozycji. Zależnie od trybu ekranu możemy wybrać 2, 4 lub 16 kolorów z palety 27iu. np. -> MODE 2:INK 0,0:INK 1,18 <- przełączy na tryb dwukolorowy z czarnym tłem i zielonym penem. Pierwszy parametr w INK to 0 do max 15 w MODE 0, a drugi to kolor z tej palety tak jak w BORDER, dodając trzeci zbędny będzie mrugać. Odpowiednio zmieniając INKi można np zmienić kolor czegoś co już jest na ekranie bez modyfikowania pamięci ekranu, np sprawić by zniknęło nadając mu taki sam kolor jak ma tło, albo w kilku krokach (bo nie ma więcej odcieni) rozjaśniał się itp. Jeszcze komenda SPEED INK ustala jak długo wyświetla 1szy i 2gi kolor w mruganiu, konieczne 2 parametry czas 1go i 2go koloru, parametr 50 trwa 1ą sekundę. :)
A w PEN i PAPER wybierasz którymi kolorami chcesz bazgrać, podajesz jeden parametr 0 do max 15 odpowiadający pierwszemu parametrowi z INK a nie nr koloru z pełnej palety. Czyli jeśli wcześniej ustalisz że np. INK 2,6 to PEN 2 da czerwony a jak INK 2,13 to PEN 2 jest szary. :)
PEN graficzny ustalasz podając 3ci zbędny parametr przy komendach PLOT i DRAW lub w kilku innych. Dwa wcześniejsze to współrzędne pozioma i pionowa. Domyślne współrzędne 0,0 to lewy dolny róg a 320,200 to środek ekranu i to niezależnie od wybranej rozdzielczości. :)
Sorry jestem dziś rozkojarzony i nie wiem gdzie w najczytelniejszej wersji jest opis komend.
Tu są jakieś manuale: ftp://babel.no-ip.pl/CPC-6128/
Szczerze, nigdy nie posługiwałem się innymi Basicami więc nie mam porównania, ale słyszałem że w Spectrum najszybszy nie jest.
Sorry że tyle trwało zanim odpisałem. Zwykle sprawdzam tylko wątki na których już byłem, teraz ten już też do nich należy to następnym razem powinienem zareagować szybciej. :)
-
Tu są jakieś manuale: ftp://babel.no-ip.pl/CPC-6128/
- strona wymaga hasła.
Do tej pory uważałem Basic ZX Spectrum jako jeden z mocniejszych, porównując go do C64 i Atari XE,
ale ilość słów kluczowych i parametrów w CPC (oglądając Twoje listingi) bardzo pozytywnie mnie zaskoczyła.
Chyba jedynie SAM Coupe ma bardziej rozbudowany, ale nie ma co porównywać 1984 do 1990.
-
To stronka jednego z tubylców nawet nie pamiętam którego (oby mi to wybaczył) a sam ten kod na forum podawał.
http://cpcwiki.eu/index.php/Locomotive_BASIC że też od razu na to nie wpadłem. :) Jeśli kojarzysz angielski to tu masz wszystko.
CPC 464 jako jedyny ma Basic 1.0 a pozostałe mają 1.1 bogatszy o kilkanaście komend i nieco inną składnię w kolejnych kilku.
ze 20 lat temu dużo pisałem w Basicu i z 1/3 komend nigdy nie potrzebowałem, za to często korzystałem z tzn. RSX-ów czyli dodatkowych komend doczytywanych z małego binarnego pliczku. Istnieje masa takich dodatków od 1ej do jakiś 20 nowych komend w zestawie, na wszelkie okazje. np.: Do wczytywania digitalizowanego dźwięku z taśmy, do wymawiania podanego tekstu, odczytu i zapisu pojedynczych sektorów i/lub całych plików, do przełączania banków pamięci albo używania ich jako RamDysku, do sprajtów, obiektów 3d, wyświetlania zegarka w rogu ekranu, wypełniania ekranu wzorami, do kompresji, do sortowania, do robienia menu i okienek, no po prostu cuda. ;) Szkoda że nie mam już tych kolekcji. :(
Co do porównania prędkości Basiców to pamiętam że w Atari XE był niewiele wolniejszy od CPC, a co do ilości rozkazów to chyba tylko w C128 i ZX+3 oraz GW Basic w PC czy jakieś Amosy w Amidze miały masę komend do wszystkiego, np. takie wynalazki jak pętle WHILE - WEND albo do obsługi przerwań AFTER i EVERY. Nie wydaje mi się by te przykłady z tej dyskietki były jakimś popisem Basica, obecnie jestem leniwym i niedouczonym typkiem nie to co kiedyś. :) Zazdroszczę Spectrumowi że ma krzywe Beziera, a w CPC pojęcia nie mam jakby coś takiego zrobić.
-
W linku trzeba umiescic login i haslo:
ftp://speccy:[email protected]/CPC-6128/ (ftp://speccy:[email protected]/CPC-6128/)
-
Krzywe Beziera? W BASICu? Na Spectrum??? Gdzieś ty to wyczytał? ;)
-
W opisie komendy DRAW w ZX Basic, bodajże 3ci parametr.
-
Eeee... To słabo czytałeś ;) Trzeci parametr to podany w radianach kąt łuku jaki ma być wyrysowany. Prosty fragment okręgu a nie żadne Beziery ;) Krzywej Beziera nie da się opisać jedynym dodatkowym parametrem dodanym do odcinka :)
-
Tak, trzeci parametr DRAW na Spectrum rysuje łuki np, jeśli jest równy PI, to rysuje półokrąg, jeśli 2*PI, to koło.
Wiem, że jakoś rysowało się gwiazdę, ale to chyba w pętli FOR - NEXT - STEP (?)
-
DEG:PLOT x,y+r:FOR k=0 TO 720 STEP 144:DRAW x+SIN(k)*r,y+COS(k)*r:NEXT
Tak się robi gwiazdę. :) Współrzędne i średnica jakie tam chcecie.
A czy w DRAW na ZX nie ma już 4go parametru? - Był kiedyś w Bajtku listing dla ZX do krzywych Beziera korzystający z tych łuków i nie wiedziałem jak to przetłumaczyć na CPC. Widocznie coś źle zinterpretowałem, taki błąd myślowy lub jak wolicie syntax error. ;)
Mea Culpa. :)
-
DRAW nie ma czwartego parametru a gwiazdy o których pisze Abrimaal to błąd w procedurze rysonia łuków - o ile pamiętam przy odpowiednio dużych wartościach kąta (rzędu zbliżonego do 100*pi) algorytm głupieje i kolejne punkty "łuku" wypadają w różnych punktach na obwodzie koła - łączone odcinkami dają w efekcie "gwiazdy".
edit: Doczytałem - nie "duże wartości" tylko "nieparzyste wielokrotności pi". I zasadniczo też duże - przy małych efekt jest taki sobie. Przykładowy programik demonstrujący ten efekt znalazłem oczywiście w "Przewodniku po ZX Spectrum"
10 FOR i=51 TO 254 STEP 4 : CLS
20 PLOT 60,40 : DRAW 128,88,PI*(2*i-1)
30 NEXT i
-
Tak, to jest to. Załączam snapshot.
Miałem kiedyś krótkie programiki w Basic (też na ZX) rysujące wielokąty w perspektywie, a także wykresy funkcji 3D,
listingi pojawiały się w Bajtku i podobnych pismach.
Ok, ale wracajmy do Amstrad Basic.
-
A tak było takie coś. :) Wolno się rysowało ale było piękne. Przerobiłem tak by odcień linii się zmieniał zależnie od tego czy się wznosiła, opadała lub była płaska, co wyglądało jakby te góry i fałdki jakie rysował były oświetlone z boku. Albo tak by linie miały różne kolory zależnie od wysokości na jakiej były, co w odpowiednio dobranej palecie przypominało mapę hipsometryczną. Pobawiłbym się w przekształcanie tego, gdybym miał podstawowy programik. Zwłaszcza że emulator pozwala przyspieszać. hehe Mniej cierpliwości miałem do czekania aż narysuje fraktala. Ale widziałem kiedyś w niemieckiej Amstradowej gazecie screeny z programu co je rysował w 16 kolorach w 3D. Piękne to było, ale nigdy mi nie wpadł w łapki.
-
Czy ma ktoś linka do spisu komend Basica do Sama Coupe albo do Commodore 128 ?
-
Co dokładnie robi instrukcja CALL &4000,&5000 ?
Czy to jest wywołanie procedury pod &4000 z wartością &5000 w rejestrze (którym?)
-
Co dokładnie robi instrukcja CALL &4000,&5000 ?
Czy to jest wywołanie procedury pod &4000 z wartością &5000 w rejestrze (którym?)
Hmmm... http://bfy.tw/2qqC ;)
Pierwsze dwie pozycje to ogólny i bardziej szczegółowy opis Locomotive BASICa a trzecia to techniczny opis jak wywołuje się kod maszynowy z tegoż i jak przekazywane są parametry.
-
Pierwszy parametr to adres spod jakiego binarkę ten CALL uruchamia, a drugi to już musi wynikać z tej binarki. Użycie tej komendy sprawia że w rejestrze A pojawia się liczba parametrów jakie są w listingu wpisane po tej komendzie i nic więcej bezpośrednio podane parametry nie zapełniają w rejestrach procka. W ROMie jest procedurka która pozwala pobierać parametry do binarki z listingu Basica i kod musi z niej korzystać by coś robić z kolejnymi parametrami.
Zgaduję że w tym przypadku drugi parametr to adres pod jakim powinny być jakieś dane z którymi coś robi kod spod &4000, np muzyczka którą odtwarza, albo adres pod którym ma umieścić skompresowany obrazek który tworzy ten kod, lub coś podobnego. ;)
-
You don't have to google that for me. Bez powodu bym nie pytał, CPC Wiki podaje jedynie taki przykład użycia CALL
CALL 0 :REM resets the computer completelyInteresuje mnie, jak ten konkretny przypadek CALL adres,parametr wywołać z assemblera.
-
Ale czytałeś trzeci wynik tego wyszukiwania? http://www.cpcwiki.eu/index.php/Technical_information_about_Locomotive_BASIC
Tam jest wyraźnie napisane, że kolejne parametry są adresowane przez IX - ostatni parametr to IX+2/IX+3 a wcześniejsze to kolejne przesunięcia do IX - przedostatni +4/+5 itd. Może to trochę nieintuicyjne, ale opis jest moim zdaniem jasny.
Jeśli procedura oczekuje jednego parametru to w A należy przekazać 1 a parametr zapisać pod adresem IX+2 i IX+3.
-
Assembler Z80 też ma polecenie CALL czyli szesnastkowo &CD + 2 bajty z adresem. Trudniej będzie przekazać tam ten parametr, bo jeśli ta procedura korzysta z tej o której wspomniałem w poprzednim wpisie to szuka tego parametru w listingu Basica. Trzeba by ją przeanalizować by zobaczyć co z tym parametrem robi i od razu wpisać w tym miejscu LD w wersji wciskającej to &5000 pod właściwy rejestr, a resztę bajtów z fragmentem kodu pobierającym ten parametr wyzerować. Zakładam że odwołuje się do ROMu przez tablicę skoków więc odwołuje się do adresu między &BB00 a &BD80. Po tym można by namierzyć gdzie jest ten fragment. Albo z okazji że mamy tylko 3 możliwości gdzie wcisnąć tą 16-bitową liczbę (HL,BC,DE), to wypróbować każdą i może któraś zadziała. Tzn wpierw wysłać ten parametr do pary rejestrów a potem wywołać tego CALL. Jeśli masz szczęście to pobranie tego parametru jest na samym początku tego kodu czyli od &4000 i to tam trzeba tego LD wstawić. A właściwa procedura która rusza już po przekazaniu tego parametru zaczyna się parę/naście bajtów dalej.
Sorry za takie amatorskie tłumaczenie, nie jestem specem, ale sam przed laty tak kombinowałem na chłopski rozum by zmodyfikować parę bajtów w gotowych binarkach. ;)
-
No ręce mi opadają... W jakim listingu BASICa? Oczywiście, że tak też się da, ale po co skoro "system" do kodu maszynowego przekazuje podane po CALL parametry a wskaźnikiem do nich jest IX?
Nie wiem czy i jak dokładnie to działa w praktyce, bo Amstrada dotykałem ostatnio prawie 30 lat temu a to, co robiłem w asmie nie wymagało przekazywania parametrów, ale cytowany artykuł wygląda moim zdaniem całkiem sensownie i nie widzę powodu, żeby ten mechanizm nie miał działać tak jak jest opisany.
-
Ale czytałeś trzeci wynik tego wyszukiwania? http://www.cpcwiki.eu/index.php/Technical_information_about_Locomotive_BASIC
A ty sam to czytałeś Mat? Czy tylko pochwaliłeś się znajomością obsługi Google'a?
Bo ja przed chwilą próbowałem to czytać i nic z tego nie rozumiem:
Both RSX and CALL commands works (are!) similar from BASIC command line and invokes a machine code - the only difference is: with the help of a RSX command you don't need to know the exact access address. You can pass up to 32 parameters with a CALL or RSX command. Possible parameters could integer, floating points and strings. Just store the parameter into a variable: Passing for integer:
CALL &4000,32,34,&5E,&x10101010
|RSX-command,32,34,&5E,&x10101010
No zajebiście, mogą być 32 parametry i czym jest każdy z nich?
-
Wydaje się, że parametry mogą być dowolnymi zmiennymi dla elastycznej procedury, która wielokrotnie odczytuje dane z tej tabeli adresowanej przez IX. Tylko, czy wartość samego IX (lokalizacja tabeli) w momencie przejścia z Basic do procedury jest zawsze stała, czy przypadkowa, czy definiowalna z poziomu Basic, tego już chyba nikt nie wie.
Najlepiej taką procedurę zacząć od PUSH IX, aby nie zgubić adresu bazowego. Gorzej jeśli to gotowy kod i bez instrukcji na papierze czy głębokiej disasm nie wiemy, jakich parametrów oczekuje.
-
Co dokładnie robi instrukcja CALL &4000,&5000 ?
Czy to jest wywołanie procedury pod &4000 z wartością &5000 w rejestrze (którym?)
Jest to wywolanie procedury pod &4000 z parametrem &5000, wskazywanym przez rejestr IX. Rejestr A zawiera liczbe parametrow.
-
No zajebiście, mogą być 32 parametry i czym jest każdy z nich?
Ależ w opisie - nie wprost - jest napisane. Parametry są "dowolne" co oznacza, że są zależne od tego, czego spodziewa się procedura. To jest przecież wywołanie kodu maszynowego - to autor tego kodu decyduje jakie parametry jego procedura ma dostać i stosownie do potrzeb traktuje to, co dostaje z zewnątrz. A jak użytkownik takiego kodu poda niewłaściwe parametry to już jego problem.
@Abrimaal Jak rozumiem IX w BASICU CPC adresuje jakiś wewnętrzny "stos" i prawie na pewno wartość jest dynamiczna. Jeśli więc chcesz taką procedurę wywołać "z zewnątrz" z innej procedury w kodzie maszynowym (albo np. z emulatora w odtwarzaczu plików AY) to prawdopodobnie wystarczy jak ustawisz IX tak, żeby wskazywał na odpowiednie parametry zgodnie z opisem, potem A na 1 i po prostu wywołasz procedurę.
-
Jest to wywolanie procedury pod &4000 z parametrem &5000, wskazywanym przez rejestr IX. Rejestr A zawiera liczbe parametrow.
A co to znaczy 5000 wskazywane przez IX? Że wartość z dwóch komórek (IX+0)+ 256*(IX+1)=5000?
Czyli czy dobrze rozumiem że takie polecenie CALL z Basica gdzieś tam do pamięci wstawia sobie te parametry a potem tak ustawia IX by wskazywał na początek tej tablicy parametrów?
-
Jest to wywolanie procedury pod &4000 z parametrem &5000, wskazywanym przez rejestr IX. Rejestr A zawiera liczbe parametrow.
A co to znaczy 5000 wskazywane przez IX? Że wartość z dwóch komórek (IX+0)+ 256*(IX+1)=5000?
Moim zdaniem tak, tylko nie do końca...
A register holds the number of parameters. IX points to each parameter. IX+0/IX+1 is the last parameter. Each parameter is a 16-bit value.
...
Hint: the first two bytes at the end of stack shows the internal return address from BASIC interpreter where it was executed.
Dlatego (IX+2)+ 256*(IX+3)=5000
Czyli czy dobrze rozumiem że takie polecenie CALL z Basica gdzieś tam do pamięci wstawia sobie te parametry a potem tak ustawia IX by wskazywał na początek tej tablicy parametrów?
Mam wrażenie, że raczej jest tak, że albo wewnętrznie BASIC używa IX do adresowania dna stosu albo ustawia w ten sposób IX na potrzeby BASICowego CALL, a parametry są po prostu zrzucane na stos.
-
To może ja bym miał pytanie do Zbynia - jaka jest najprostsza, oficjalna, podstawowa książką/instrukcja dla początkujących o Basicu na Amstradzie?
Coś jak ta nasza czarna, kolorowa instrukcja do Spectruma
http://www.worldofspectrum.org/infoseekid.cgi?id=2000446
albo podręcznik Basica Vickersa:
http://www.worldofspectrum.org/infoseekid.cgi?id=2000438
-
I sprawdziłem... Znalazłem disassemblację ROMu CPC - http://www.cpcwiki.eu/index.php/ROM-Listing_CPC_464/664/6128
Niestety jest po niemiecku i w bitmapach więc słabo się szuka, ale da się znaleźć istotne informacje.
Obsługa CALL siedzi (w 464, bo to przeglądałem, ale reszta powinna być chyba zbliżona) pod adresem F1BA. Najpierw pobiera adres wywołania (czyli pierwszy parametr) i zapisuje go pod adres AE72. Potem zapamiętuje stos do zmiennej a następnie w pętli pobiera kolejne parametry - za każdym razem używa procedury CE91, która parsuje wyrażenia i zwraca wartość w DE (zachowując pozostałe rejestry). Tak pobrana wartość zrzucana jest na stos a na zakończenie pętli do A zapisywana jest faktyczna liczba odczytanych parametrów i wykonywany jest kod:
ld ix,0
add ix,sp
rst 18
dw ae72
Restart 18 to procedura "dalekiego wywołania" z ewentualnym przełączaniem banków itp. Procedura nie rusza IX tylko pobiera parametr podany za RST do DE przestawiając równocześnie na stosie adres powrotu o dwa bajty. Pobrany parametr traktowany jest jako wektor skoku - spod tego adresu pobierany jest jeszcze raz do DE adres - tym razem właściwy adres wywoływanej przez BASICowy CALL procedury i następuje skok do niego poprzez kombinację PUSH DE/RET.
Oczywiście w samej procedurze dzieje się więcej, ale zasadniczo nie ma to znaczenia dla meritum sprawy. Istotne jest to, że na wejściu do wywoływanej procedury w IX znajduje się kopia SP tuż sprzed RST czyli IX wskazuje na ostatni parametr więc jednak jeśli wywołujemy procedurę z jednym parametrem to znajduje się on pod (IX+0)+ 256*(IX+1).
Jakby ktoś chciał sprawdzać głębiej, to obsługa CALL w PDFie znajduje się na stronie 554, RST 18 na stronie 217 a sama procedura obsługi skoku na stronie 233.
-
Dzięki za research.
To jest chyba troszkę bardziej skomplikowane, bo tam jako parametry mogą być nie tylko dwubajtowe liczby ale i jednobajtowe a także ułamkowe i stringi. Wówczas pewnie zajmują odpowiednio różną ilość bajtów pamięci i musimy to uwzględnić w naszej procedurze.
Na koniec mam uwagę natury ogólnej ;) Zawsze miałem wrażenie że mieszanie Basica i assemblera jest dość zagmatwane i jest tam wiele miejsc w których coś może pójść źle . Chyba wolę czyste sytuacje - albo 100% w Basicu, albo 100% w assemblerze :)
-
No więc z tego co widzę w kodzie to wywoływana procedura (CE91, str. 451) parsuje wyrażenia, ale zwraca zawsze tylko szesnastobitowego integera. Wewnętrznie procedura woła najpierw (CEFB, str. 452) parsowanie wyrażenia do jakiejś wewnętrznej struktury (FAC) a następnie konwersję tej wartości do HL (FEC2, str. 596) - ta procedura jest opisana jako "Basic-funktion UNT" i robi konwersję - najpierw sprawdza, czy liczba jest integerem i jeśli tak to ją zwraca, jeśli jest floatem to wywołuje procedury konwersji do integera i zwraca tegoż.
Mimo szczerych chęci nie widzę tu miejsca na parsowanie czegokolwiek innego a z tego mi wynika, że chyba jednak CALL bierze wyłącznie parametry numeryczne konwertowane zawsze do 16 bitów. Być może inne typy parametrów potrafi przyjąć obsługa RSXów a być może po prostu nie umiem w tym niemieckim tekście znaleźć konwersji/parsowania innych typów parametrów dla CALL.
Co do mieszania kod maszynowy/BASIC to zasadniczo się z tobą zgadzam, ale oczywiście są sytuacje, gdy osoba pisząca w BASICu po prostu nie zna assemblera a potrzebuje jakiejś procedurki (gotowej przygotowanej przez kogoś innego) do zrobienia czegoś szybciej (albo zrobienia w ogóle). Sam wiesz, że nie wszystko co da się zrobić w assemblerze da się zrobić - sensownie - w BASICu ;)
-
No i jeszcze doszukałem jak to jest z tymi floatami i stringami - jeśli dobrze rozumiem to, co znalazłem to nie ma możliwości przekazania bezpośrednio parametru innego niż integer a przekazywanie innych typów uzyskuje się używając operatora/funkcji @ czyli np CALL 32768,@a$ co przekazuje do wywoływanej procedury wskaźnik do wyniku wyrażenia albo zmiennej. Nie jestem pewien czy można zrobić np. @(a$+"xx") albo @"napis" - prawdopodobnie nie. Mechanizm ten można za to wykorzystać do przekazywania danych z powrotem do BASICa - adres przekazywany jako @zmienna to chyba adres fizycznego miejsca gdzie w pamięci znajduje się ta zmienna i zapisanie tam danych z kodu maszynowego przenosi się "w górę" do BASICa.
Nadal nie wiem jak to dokładnie wygląda w wypadku RSXów - tam można podawać teksty jako parametry. Procedura parsowania musi być chyba inna niż dla CALL.
-
Ok. Zrobiłem ostatni etap researchu - odpaliłem emulator i popatrzyłem co się dzieje jak się przekaże stringa do CALL. Dzieje się dokładnie to, co jest opisane na CPC Wiki - parametr, który otrzymujemy kieruje nas do opisu stringa, który to opis w pierwszym bajcie ma długość stringa a w kolejnych dwóch adres w pamięci przydzielony przez system.
Wiem już wszystko co chciałem wiedzieć i dalej nie drążę i nie zawracam wam głowy ;) Zwłaszcza, że CPC to dla mnie ten ze starych komputerów do którego mnie całkiem nie ciągnie ;)
-
Rafał - User Guide dodawany do każdego CPC ma bardzo przystępne i szczegółowe omówienie każdej komendy + przykłady. W latach 80ych ukazał się niewielki nakład polskiego tłumaczenia tejże ale z tego co słyszałem to większość trafiła do szkół oficerskich. Ze 3 lata temu pojawiły się 2ie sztuki tej książki na Allegro. Dziś w necie łatwo znaleźć angielskie PDF ze skanami. Krążą w różnych wersjach, polecam tą 15.8MB bo ma działające hiperlinki ze spisu treści. A skoro nie ma wyszukiwania tekstem to dobre i to. Za kilka € można też kupić papierową w paru językach ale bez PL.
https://www.google.co.uk/search?client=opera&q=AmstradCPC6128-hypertext-en-Sinewalker+pdf&sourceid=opera&ie=UTF-8&oe=UTF-8
Niezła też jest stronka której link już tu padł kilka postów wcześniej, można wyszukiwać tekstem, ale tu opisy są dość zdawkowe.
http://www.cpcwiki.eu/index.php/Locomotive_BASIC
Przypominam też te dialekt Basica w 464 jest nieco inny, brak w nim kilku komend i jest nieco inna składnia w kilku kolejnych, oraz sposób podawania parametrów do tzw RSX-ów. W 6128 działa składnia z 464, ale listingi do niego często nie stosują się do tych ograniczeń bo tak jest wygodniej, więc trzeba je troszkę przerabiać by działały także na 464.
-
Matofesi - jak ktoś tu wcześniej cytował nie ma różnicy w podawaniu parametrów do CALL i do RSXów, obie metody służą do uruchamiania procedur binarnych, tyle że w RSX podajemy jej nazwę zamiast adresu startowego.
Ale jest różnica między tym jak można podawać parametry w 464 a w 6128. W tym pierwszym musimy to robić pośrednio tzn wpierw podstawić ją pod zmienną np.: a=2345:a$="tekst":|RSX,@a,@a$
A w 6128 można tak samo, ale także bez tych @ czyli |RSX,a,a$ lub bez pośrednictwa zmiennej podawać parametry od razu przy komendzie: |RSX,2345,"tekst"
Ta małpka oznacza że chodzi nam nie o samą zmienną, ale o jej adres pod jakim się ona znajduje. Tyle że ten adres to ilość bajtów poniżej względem ruchomego adresu HIMEM, a nie adres jak przy np. POKE.
-
Ech... Skończyłem już z tym tematem, ale jakbym nie skończył to bym ci powiedział, że poza tym, że nie chce mi się porównywać ROMów 464 i 6128 (zwłaszcza po niemiecku) żeby obejrzeć i opisać jak to dokładnie działa i czym się różni. Powiedziałbym też, że już wiem, że parsowanie parametrów dla CALL i RSXów system robi tak samo. A poza tym powiedziałbym ci, że rozumiem co robi operator/funkcja @ i, że jakbym chciał to wiedzieć dokładnie jak to robi to pewnie bym sobie sprawdził ;)
Ale jak już napisałem - dla mnie temat jest zamknięty i nie chce mi się go dalej drążyć. :)
-
Jest to wywolanie procedury pod &4000 z parametrem &5000, wskazywanym przez rejestr IX. Rejestr A zawiera liczbe parametrow.
A co to znaczy 5000 wskazywane przez IX? Że wartość z dwóch komórek (IX+0)+ 256*(IX+1)=5000?
Czyli czy dobrze rozumiem że takie polecenie CALL z Basica gdzieś tam do pamięci wstawia sobie te parametry a potem tak ustawia IX by wskazywał na początek tej tablicy parametrów?
Dokladnie tak. Tylko ze IX wskazuje na koniec tej tablicy (ostatni parameter w linii wywolania)
-
You don't have to google that for me. Bez powodu bym nie pytał, CPC Wiki podaje jedynie taki przykład użycia CALL
CALL 0 :REM resets the computer completelyInteresuje mnie, jak ten konkretny przypadek CALL adres,parametr wywołać z assemblera.
ld IX, data
ld a,1
call &4000
...
data:
dw &5000