3,851

(66 odpowiedzi, napisanych Fabryka - 8bit)

Chodzi ci o tryb EXTEND, jak w BASIC-u XE? Raczej nie. W charakterze dodatkowej pamięci planuję wykorzystać po prostu pamięć liniową Warpa, do której załaduje się i sam interpreter i w której będzie przechowywany program, tablice itd.

3,852

(66 odpowiedzi, napisanych Fabryka - 8bit)

Ja w chwili obecnej pracuję nad nowym interpreterem BASIC-a. Ma to być język programowania na Atari wyposażone w Warpa-4 albo Nową Nienazwaną Dopałę Pasia (na Atari z "golym" 65c816 też pójdzie, ale zostawi mało wolnej pamięci). W związku z tym istnieje tylko wersja pod 65c816, a wersja na 6502 nie powstanie, bo na 6502 jest świetny Turbo BASIC XL i to wystarczy (a ci, co nie chcą sobie za bardzo ułatwiać, mają Atari BASIC).

Screenshota nie posiadam, ale niebieski ekran z napisem "Ready" każdy sobie może łatwo wyobrazić. Nie mogę się też podzielić żadą wersją preview na razie, z braku kabelka.

Nazwa b. oryginalna pochodzi od tego, że MultiBASIC ma stanowić połączenie Turbo BASIC-a XL i BASIC-a XE. Zgodność z Turbo BASIC XL jest na poziomie tokenów (do MultiBASIC-a można wczytywac programy TBXL przez LOAD i one będą działać), natomiast zgodność z BASIC XE ma być na poziomie słów kluczowych (do MultiBASIC-a będzie można wczytywać programy BASIC-a XE przez ENTER i one może będą działać).

W opisie poniższym zakładam, że Atari BASIC i Turbo BASIC XL jest wszystkim znany, wyszczególnię więc tylko różnice w stosunku do obydwu.

Przede wszystkim, interpreter działa z linii komend pod SpartaDOS i pod DOS II+/D (za to ostatnie trzeba dziękować Lizardowi, bo to jego parser jest tam wkompilowany, z małymi acz niezbędnymi modyfikacjami). Składnia:

mb [options] [filename.bas]

Program o nazwie 'filename.bas' zostanie automatycznie załadowany. Opcje są następujące:

-R - po załadowaniu program jest automatycznie uruchamiany, a po zakonczeniu albo przewaniu interpreter zgłasza się przez "Ready"
-B - jak wyżej, ale po zakończeniu programu interpreter wraca do DOS-u

Komunikaty BASIC-a są trochę mniej toporne niż w Atari BASIC: jest "Ready" zamiast "READY", "Error 170 at line 15" zamiast "ERROR-  170  AT LINE 15", "Stopped" zamiast "STOPPED". Dodatkowo obsługa błędów jest rozszerzona opcjonalnie o dwie rzeczy:

- słowne komunikaty błędów, dłuższe niż w TBXL, do 12 znaków
- numer błędu jest wypisywany jako liczba ujemna

A więc nie "ERROR-  170 AT LINE 17", tylko "Error -86 NO SUCH FILE at line 17". Obie featury można wyłączyć.

Listing jest wyprowadzany z wcięciami, jak w TBXL. Można to wyłączać i włączać na dwa sposoby, albo jak w TBXL (poleceniem *L) albo jak w BXE (poleceniem SET). Można regulować skok wcięcia, oraz oddzielnie włączyć i wyłączyć wcięcia dla komend REM i --.

Dodatkowo można opcjonalnie włączyć listowanie w stylu BASIC-a XE, czyli słowa kluczowe mają pierwszą literę dużą, a resztę małymi (np. For I=1 To 1000 Step 0.9:Next I itp.).

Program można wpisywać dużymi lub małymi literami, bez różnicy (można przełączyć na wyłącznie duże litery, zgodnie z BASIC XE). Interpreter akceptuje wszystkie słowa kluczowe napisane małymi literami, a nie, jak TBXL, tylko te, które zaczynają się od litery, a więc małymi literami można wpisać również -MOVE albo %GET i nie będzie błędu.

Rozszerzenia słów kluczowych Atari BASIC i Turbo BASIC XL:

1) polecenia POKE, DPOKE, MOVE, -MOVE, oraz funkcje ADR(), DPEEK(), PEEK() operują na 24-bitowych adresach.

2) funkcja VAL() opcjonalnie konwertuje liczy HEX, tak jak w BASIC-u XE.

3) wszystkie konwersje HEX<>DEC są 24-bitowe. DEC() konwertuje także liczby napisane małymi literami, w inwersie, poprzedzone spacjami (co w TBXL nie zachodzi).

4) funkcja USR() działa jak w BASIC XE, to znaczy opcjonalnie może nie wstawiać na stos liczby parametrów. USR() działa tylko na banku 0 (pierwsze 64k).

5) błąd procedury kontroli składni dla poleceń DIM i COM został poprawiony.

6) CLOSE może być bez parametru, jak w Turbo BASICu XL

7) STATUS zwraca ujemny kod błędu, jeśli takowe są włączone

7,9) POINT akceptuje stałe, a nie tylko zmienne (to jak w TBXL)

9) Rozszerzona instrukcja SOUND:

- SOUND bez parametru, jak w TBXL
- SOUND z dodatkowym parametrem:

SOUND #n
SOUND #n,chn,freq,pitch,vol

gdzie "#n" może być #0 albo #1 i oznacza kanał lewy i prawy dla komputerów ze stereofonicznym Pokeyem. Tak samo DSOUND.

10) rozszerzone instrukcje NEW/LOAD/SAVE/RUN:

NEW "filename.bas"

definiuje domyślną nazwę dla nowego programu. Wpisanie SAVE bez parametrów spowoduje zapis pod tą właśnie nazwą. LOAD bez parametrów ładuje program o takiej nazwie, LOAD "filename.bas" ładuje program o wskazanej nazwie i ustawia ją jako domyślną (a więc działa jak NEW "filename.bas" / LOAD). RUN "filename.bas" działa tak samo, ale jeszcze oczywiście uruchamia wczytany program. SAVE z podaną nazwą zapisuje program pod tą nazwą, ale NIE ZMIENIA nazwy domyślnej.

11) jeszcze jedno rozszerzenie do RUN:

RUN 100
RUN "filename.bas",100

Pierwsze uruchamia program od linii 100, drugie ładuje najpierw plik "filename.bas", a potem odpala go od linii 100. Co do numeru linii, działa to jak LIST 100,200, to znaczy program odpalany jest od linii 100, a jeśli jej nie ma, to od najbliższej następnej.

Wszystko to jest już zaimplementowane i działa. Jest też zaimplementowana spora garść komend Turbo BASIC-a XL, to jest w chwili obecnej:

- komendy: DPOKE, MOVE, -MOVE, *F, *B, *L, REPEAT, UNTIL, WHILE, WEND, IF, ELSE, ENDIF, BPUT, BGET, FILLTO, DO, LOOP, EXIT, DIR, LOCK, UNLOCK, RENAME, DELETE, PAUSE, TIME$, FCOLOR, --, BLOAD, BRUN, CLS, DSOUND

- operatory i funkcje: DPEEK, &, !, EXOR, %0, %1, %2, %3, HEX$,DEC,DIV,MOD,FRAC,TIME,RND,RAND,TRUNC,ERR,ERL

Z BASIC-a XE napisałem dopiero:

- komendy: SET
- operatory i funkcje: SYS, %

'%' to to samo co EXOR w TBXL.

SET i SYS() służą do regulacji parametrów pracy interpretera i włączania i wyłączania różnych opcji. Docelowo (tego jeszcze nie ma) interpreter będzie tuż po starcie ładował plik ustawień z katalogu domyślnego (czyli z tego, z którego został załadowany, albo z bieżącego). Plik ustawień będzie normalnym programem BASIC-a z poleceniami SET w środku, oczywiście będzie mógł też zawierać dowolne inne.

Słowa kluczowe nowe dla MultiBASIC-a:

1) AUTO, włączenie automatycznej numeracji linii, jak w Microsoft BASIC:

AUTO
AUTO start
AUTO start,step

Defaultowo "start" (numer linii od której zaczyna się numeracja) jest 10, a step jest 5. Po pierwszym użyciu komenda zapamiętuje ostatnio wypisany numer linii i za drugi razem startuje od niego. Reset przez NEW albo przez AUTO 0,0.

2) FILE, przypisuje wskazanej zmiennej numerycznej numer pierwszego wolnego kanału IOCB. Użycie:

K=FILE:OPEN #K,4,0,"D:fname":GET #K,A:? A:CLOSE #K

3) SEEK:

SEEK #n,var
SEEK #n,num

Robi seek na wskazanym pliku "n" do pozycji wskazanej zmienną albo stałą numeryczną.

4) TELL - odwrotność SEEK, przypisuje wskazanej zmiennej bieżącą pozycję we wskazanym pliku.

TELL #1,var

5) FLEN - przypisuje wskazanej zmiennej długość pliku:

FLEN #n,var

Oczywiście, żeby skorzystać z komend SEEK, TELL i FLEN, trzeba mieć SpartaDOS  ;)

6) WAIT - wstrzymuje CPU do chwili wystąpienia jakiegokolwiek przerwania.

7) VOID:

VOID expression

Oblicza wyrażenie numeryczne 'expression' i ignoruje wynik  ;) Jest to w zasadzie komenda dla przyszłego kompilatora MultiBASIC-a, ale w interpreterze też się przyda, np.:

VOID USR(adres)

7,9) PI - pseudozmienna o wartości 3,14159265

To na razie tyle. W planach jest jeszcze wiele rzeczy, ale nie są jeszcze do końca ustalone. Z planów: listę tokenów instrukcji można rozszerzać w zasadzie w nieskończoność, a konkretnie może być ich 256 bez specjalnego trudu (zajęte jest ok. 120). Dlatego stopniowo można zaimplementować wszystkie komendy BASIC-a XE i Microsoft BASIC-a, o ile nie będzie specjalnych konfliktów co do składni albo znaczenia (przykładowo EXIT w TBXL i Exit w BASIC-u XE - raczej trudno jest je pogodzić).

Gorzej natomiast jest z tokenami funkcji, tych może być tylko 128, z czego obsadzonych jest 114. Pozostają dwa tokeny "normalne" oraz 12 zarezerwowanych na oznaczanie typów zmiennych i tym podobne. Jeśli uda mi się wykorzystać jeden z tokenów rezerwy na prefix dla dodatkowych operatorów i funkcji, to stopniowo zaimplementuję wszystkie funkcje z BASIC XE i Microsoft BASIC. Jeśli nie - to tylko najciekawsze minimum.

3,853

(36 odpowiedzi, napisanych Zloty)

Ok, środa godzina 17.00. Jak mi coś nagle nie wypadnie (a nie zanosi się), to będę.

3,854

(74 odpowiedzi, napisanych Sprzęt - 8bit)

Tak, Jacek mi przerobił na nową. 3k ROM-u to wypas  ;)

3,855

(69 odpowiedzi, napisanych Software, Gry - 8bit)

   ldx #$00
   lda #$0c
   sta iccmd,x
   jsr jciomain
   lda #$03
   sta iccmd,x
   lda #<ename
   sta icbufa,x
   lda #>ename
   sta icbufa+1,x
   lda #$0c
   sta icax1,x
   lda #$00
   sta icax2,x
   jsr jciomain
   ...
ename .by "E:",$9b

Ewentualnie:

   jsr eopen
   ...
eopen lda $e401
   pha
   lda $e400
   pha
   rts

Ale ten drugi sposób nie jest za bardzo dobry, bo będzie włączał standardowy tryb nawet jeśli ktoś ma zainstalowany np. sterownik edytora 64-kolumnowy albo coś takiego.

3,856

(74 odpowiedzi, napisanych Sprzęt - 8bit)

Mój interfejs już ma dwa banki, prace nad handlerem v. 2.0 trwają  ;)

3,857

(36 odpowiedzi, napisanych Zloty)

Postaram się być. Łatwiej mi znaleźć czas we środę niż w sobotę, ale zdaje się, że tę sobotę (21. maja) mam akurat wolną...

3,858

(15 odpowiedzi, napisanych Software, Gry - 8bit)

Dema można pisać i w wersji bez CLI, nie? :) Wersja CLI ma to dodatkowo, że może robić jako interpreter skryptopodobny.

3,859

(15 odpowiedzi, napisanych Software, Gry - 8bit)

No, na tym polega plan. Na Amidze może być AREXX jako język "systemowy" (nb. wynalazek IBM-a, miałem kiedyś do czynienia z komputerem, w którym wszystko było w języku REXX, nawet objecty wychodzące z kompilatora C), to w Atari może być Turbo BASIC. Bardzo wygodna sprawa, ostatecznie nie wszystko trzeba pisać w asmie, coś w rodzaju skryptów też jest do życia potrzebne.

3,860

(15 odpowiedzi, napisanych Software, Gry - 8bit)

Pin: źrodeł TBXL szukają od paru lat dwie osoby co najmniej, to jest ja oraz niejaki Lonny Pursell (lp2 na ircu). Skoro do tej pory nie znaleźliśmy, to raczej ich nie ma, ale z drugiej strony wiadomo, że na świecie są rzeczy, o których się filozofom nie śniło, oraz najciemniej jest pod latarnią.

xxl: pisałem na ten adres i ja i LP jeszcze jakieś 4 czy 5 lat temu. Zero odpowiedzi. Może trzeba napisać po niemiecku :>

[ Dodano: 13.05.2005 02:29:59 ]
PS. Będzie i kompilator, wszystko po kolei. ;)

3,861

(39 odpowiedzi, napisanych Sprzęt - 8bit)

Uwzględnić resztę świata poza QMEG-iem. W KMK/JŻ IDE kombinacja SHIFT/RESET odłącza twardy dysk, a SELECT/RESET (ale nie we wszystkich wersjach) powoduje zimny start. W DracOSie SELECT/RESET robi to samo.

3,862

(15 odpowiedzi, napisanych Software, Gry - 8bit)

Poczekaj moment, ja mam już interpreter działający z linii komend, na razie jest w testach i bugfixach ;)

3,863

(36 odpowiedzi, napisanych Programowanie - 8 bit)

Jeśli zamierzasz robić coś w rodzaju GEOS-a (a zdaje się, że pamiętam taką wzmiankę), to możesz pójść na kompromis. To znaczy, zachować możliwość korzystania na raz z paru programów ale bez wywłaszczania. Nie wiem, jak się to nazywa po polsku, ale po angielsku to jest cooperative multitasking. Dobrym przykładem jest np. Geneva na Atari ST. Działa to całkiem dobrze i daje bardzo duże złudzenie rzeczywistego multitaskingu, póki, oczywiście, nie zapuścisz pętli w rodzaju

jmp *

Działa to na zasadzie pętli zdarzeń, która jest w środku managera aplikacji. Zakłada się, że każdy program czeka na jakieś zdarzenie (w rodzaju: naciśnięcie klawisza, kliknięcie na element okna, upływ określonej ilości czasu, wybranie czegoś z menu, określone ruchy myszą - wejście w zdefiniowany obszar albo wyjście z niego - itp.), reaguje na nie, a potem z powrotem wraca do czekania.

W takim układzie zadanie podziału czasu pomiędzy "procesy" może spełniać pętla zdarzeń. W chwili, kiedy program zadaje jej oczekiwanie na np. naciśnięcie klawisza, a żaden klawisz naciśnięty nie jest, pętla spokojnie może oddać czas do innego programu, który czeka na inne wydarzenie, a to w międzyczasie wystąpiło (np. upływ zadanej ilości czasu).

Efektem jest, jak napisałem powyżej, dość dobre złudzenie wieloprocesowości, a przy tym łatwiejsza jest synchronizacja wszystkich zadań, no i scheduler powieszony na przerwaniu VBL nie zabiera czasu, bo go nie ma wcale.

3,864

(36 odpowiedzi, napisanych Programowanie - 8 bit)

z ta emulacja Konop ma racje, moze zbyt doslownie go zrozumieliscie

Dobrze zrozumieliśmy, taki system to czyste zawracanie głowy.

3,865

(36 odpowiedzi, napisanych Programowanie - 8 bit)

Przestańcie sobie jeździć wzajemnie po ambicji oraz nie łapcie się wzajemnie za słowka - wyjdzie to na lepsze merytorycznemu poziomowi dyskusji.

Dyskusja się skończyła dwa dni temu  :P

3,866

(36 odpowiedzi, napisanych Programowanie - 8 bit)

O mnie prosze się nie martwić.

Zmartwieniem bym tego nie nazwał.

Na początek wystarczy brak tonu moralizatorskiego i osobistych wycieczek.

Ton moralizatorski? Osobiste wycieczki? Raczysz żartować. Ja po prostu byłem ciekaw, czy masz cos w omawianej materii wartościowego do powiedzenia.

Uważam kwestię wydajności za istotną, a samo zadanie jako sztukę dla sztuki. Moim zdaniem większym wyzwaniem jest zrobić to w dziedzinie takiej jaką dysponujemy, czyli standardowe Atari z procesorem 6502, aniżeli iść na łatwiznę

Tak, masz rację, niewątpliwie większym wyzwaniem jest skok z wysokości kilometra bez spadochronu, niż ze spadochronem. Tyle, że niektórzy potrafią przewidzieć konsekwencje, a niektóorzy muszą spróbować na własnej skórze. Jak dla mnie EOT.

3,867

(36 odpowiedzi, napisanych Programowanie - 8 bit)

Do tego nie było potrzebne zadawanie pytania, które nic nie wnosi do Pańskiej wiedzy

Do mojej nie. Ale miałem nadzieję, że wniesie coś do twojej.

Myli się Pan - wystarczą trzy. :>

Cóż, pozostaje stwierdzić, że o budowie stabilnych stołów masz takie samo pojęcie, jak o budowie stabilnych systemów wielozadaniowych.

Jeżeli Pan nie ma ochoty na dyskusję merytoryczną ze mną z dowolnych powodów - niech Pan tego tutaj nie robi.

Dla jasności: wyrażałem swoje uwagi, a motywacja ich wprowadzania przeze mnie jest moją indywidualną sprawą, o ile nie narusza ogólnych zasad panujących na forum. Nie sądzę, abym je naruszył.

Na rzeczową dyskusję mam ochotę prawie zawsze. Rzecz w tym, że niczego rzeczowego w twoich postach nie widzę. Masz oczywiście zupełne prawo do wygłaszania dowolnych opinii, ale - wybacz porównanie - jeśli do dyskusji o całkach będziesz się na trzeciego wtrącał co 5 minut z mantrą: "ale proszę pamiętać, że dwa razy dwa to cztery", to nie możesz się spodziewać poważnego potraktowania.

Nie wiem czy zdaję sobie sprawę ze wszystkich konsekwencji, ale z tych które uznaję za istotne - tak.

Rozumiem z tego, że wydajność emulatora na poziomie 5% (a raczej mniej) mocy oryginalnego procesora jest kwestią, którą uznajesz za nieistotną. Bardzo ciekawe podejście, ale raczej mało realistyczne.

3,868

(36 odpowiedzi, napisanych Programowanie - 8 bit)

Z całym szacunkien dla Pańskiej osoby, ale odnoszę wrażenie, że dyskusja zbacza z tematu.

Nie. Chciałem się tylko dokładnie przekonać, czy masz coś wartościowego do powiedzenia na ten temat. Bo widzisz, ktokolwiek zabiera się do budowy stołu, świetnie wie, i nie będzie o tym toczył dysput, ze stół, zeby był stabilny, potrzebuje czterech punktów podparcia co najmniej. TeBe, który rzucił pomysł implementacji multitaskingu, jest koderem, i jak wszyscy koderzy tutaj, świetnie wie, jak działa BRK, że jest to przerwanie IRQ i gdzie ma wektor. Zanim więc zarzucisz mi osobiste wycieczki, zastanów się proszę przez moment, o czym tu w zasadzie rozmawiasz i z kim.

Tak samo jak na warstwie sprzętowej, tylko zasymulowane programowo.

Widzę, że jesteś bardzo przywiązany do koncepcji dosłownie pojmowanej maszyny wirtualnej, to znaczy do emulowania 6502 na 6502. Pozwól mi niniejszym wyrazić wątpliwość, czy zdajesz sobie do końca sprawę ze wszystkich konsekwencji wdrożenia takiego czegoś na Atari.

3,869

(36 odpowiedzi, napisanych Programowanie - 8 bit)

Na 6502 to się w ogóle nie da, bo nie zaimplementujesz ochrony pamięci.

Nie prawda - jest to możliwe do realizacji.

Co mianowicie? Ochrona pamięci?

Wybacz, ale nie wiem co jest w tym apokaliptycznego i przesadzonego.

Przede wszystkim przymiotniki, których używasz. API wcale nie musi być "wyczerpujące" ani "obszerne", natomiast z drugiej strony jego "zoptymalizowanie pod względem szybkości działania" nie jest niemożliwe.

Nie można puścić na żywioł przerwań. Jeżeli dowolne zadanie miałoby możliwość całkowitej kontroli nad przerwaniami, oznaczałoby to skuteczną destabilizację systemu.

A to z kolei jest zupełny banał. Widziałeś kiedyś porządny system wielozadaniowy, gdzie przerwania są "puszczone na żywioł"?

PMMU sprzętowe mnie nie interesuje, tak jak napisałem na początku mojej wypowiedzi. Software'owe jest możliwe do realizacji.

Bardzo mnie to ciekawi; może napisz dokładniej, jak to miałoby działać.

3,870

(36 odpowiedzi, napisanych Programowanie - 8 bit)

Myślałem o implementacji tego na zwykłym 6502...

Na 6502 to się w ogóle nie da, bo nie zaimplementujesz ochrony pamięci.

Co do API, to owszem, może i jest jakaś baza, ale z pewnością nie pełna. Dostęp do pełnego ekranu w trybie ekskluzywnym należałoby dopisać, pewnie na podobnej zasadzie wiele innych elementów związanych ze sprzętem, jak dźwięk, klawiatura.

Muszę stwierdzić, że wypowiadasz się dość mgliście. Czy to, że trzeba napisać od nowa handlery urządzeń, nie było już w tym wątku poruszane?

Teoretycznie gdyby zaprojektować coś w stylu bajt-kodu na odpowiednim poziomie integracji z wystarczająco szerokim API systemowym, całość miałaby sens, tyle, że to API musiałoby być naprawdę wyczerpujące, obszerne, zoptymalizowane pod kątem prędkości wykonywania.

Wizja apokaliptyczna. Ale jednak trochę przesadzona. "Wyczerpujące API" sprowadza się do interfejsu pozwalającego na komunikację ze sprzętem poprzez sterowniki poszczególnych urządzeń. Sterowników może być wiele, ale ich rodzaje są zasadniczo dwa (znakowe i blokowe), a co za tym idzie, wszystkie urządzenia obsługuje się tak samo. Tak więc nie jest to aż tak totalitarne, jak to przedstawiasz.

Co więcej, w Atari są te dwa rodzaje sterowników, bo urządzenia znakowe obsługuje CIO, a blokowe SIO. Ale ta implementacja niezupełnie nadaje się dla systemu wielozadaniowego.

Co do BRK i przerwań, to widzę to po prostu jako problem sam w sobie.

A mógłbyś jakoś detalicznie (i konkretnie przede wszystkim) objaśnić, na czym ten sam w sobie problem polega?

Istnieje wiele powodów, które mogłyby spowodować destabilizację całego systemu podczas wykonywania dowolnego zadania (zawierającego błąd, ale niekoniecznie)

Poczytaj sobie to, co pisałem wyżej o PMMU.

3,871

(33 odpowiedzi, napisanych Software, Gry - 8bit)

Prawdopodobnie dlatego, że częstotliwość typu 19200 Hz jest niesłyszalna. Nie wiem, jak z magnetofonem. Ale tak ogólnie, można byłoby zrezygnować z tego "wyciszania" na pewno w sytuacji, kiedy dźwięk transmisji jest wyłączony. Natomiast kiedy jest włączony, wyciszać trzeba tylko jeden kanał (który SIO i tak ustawia po swojemu przed transmisją).

3,872

(15 odpowiedzi, napisanych Software, Gry - 8bit)

Znowu DEC?  :D

3,873

(36 odpowiedzi, napisanych Programowanie - 8 bit)

Specjalne API w sumie już dawno jest, to są handlery urządzeń i punkty dostępu do nich (SIO i CIO). Poza tym jednak potrzebny jest jeszcze układ, który będzie w stanie sprzętowo zablokować dostęp do wybranych obszarów przestrzeni adresowej, o czym pisałem powyżej (nie tylko do sprzętu, ale też do np. niezaalokowanej pamięci). Oczywiście od razu pojawia się następny problem, który trzeba byłoby rozwiązać sprzętowo, tj. poziomy uprzywilejowania. Ogólnie sporządzenie systemu wielozadaniowego spełniającego wymogi XXI wieku nie jest łatwe na procesorze w rodzaju 65c816.

Co do BRK, pewnie masz na myśli, że program jest w stanie wywołać to przerwanie na żądanie, a wobec tego wektor BRK musi stanowić składnik kontekstu. Zgadza się, ale przy całej reszcie problemów jest to doprawdy drobiazg nie wart wzmianki.

3,874

(3 odpowiedzi, napisanych Software, Gry - 8bit)

Posiadają, jest to chyba nawet po prostu przerobione z SIO2PC (albo inspirowane). Tylko że serial w C-64 jest tragicznie wolny, ten komputer nie ma zdaje się żadnego UART-a.

3,875

(33 odpowiedzi, napisanych Software, Gry - 8bit)

Zonk polega na tym, ze w romie jest w jakims przerwaniu/procedurze kombinacja w stylu:

lda #0
sta $pokey

ktora powoduje takie smieszne pykanie podczas grania i odczytu. Ze wzgl. na moja szeroka wiedze programistyczna, OS z romu zostawal przepisany do ramu, kombinacja zmieniona na nop nop nop (kto tam?). [Po co to jest w oryginalnym romie?]

To wycisza kanały po transmisji. Potrafię sobie wyobrazić po co (mianowicie: dla porządku), ale nie bardzo wiem, dlaczego ROM wycisza wszystkie cztery kanały, mimo że do transmisji uzywa tylko dwóch.