Elektroda.pl
Elektroda.pl
X
Proszę, dodaj wyjątek www.elektroda.pl do Adblock.
Dzięki temu, że oglądasz reklamy, wspierasz portal i użytkowników.

MOS6502 + układy intela. Program zapisany na EPROM nie działa.

Atlantis86 10 Cze 2018 22:10 438 27
  • #1 10 Cze 2018 22:10
    Atlantis86
    Poziom 19  

    Kontynuuje właśnie swoje eksperymenty z antycznymi mikroprocesorami.
    Po uruchomieniu prostego komputerka na polskim MCY7880, przyszedł czas na kultowego niegdyś MOS6502AD.
    Kilka procesorów tego typu udało mi się kiedyś kupić na Aliexpress, nie byłem więc w 100% pewien co do ich stanu technicznego i oryginalności. Status projektu na chwilę obecną wygląda następująco:

    1) Procesor jest taktowany z 4 MHz generatora kwarcowego na inwerterach. Sygnał ten jest następnie dzielony jeden lub dwa razy (do wyboru zworką) za pomocą 74LS74.
    2) Na płytce znajdują się obecnie 32kB pamięci RAM (układ 62256, adresowana bezpośrednio, dostępna w pierwszej połowie przestrzeni adresowej).
    3) Pamięć EPROM ma 16kB (M27128) i zajmuje ostatnią ćwiartkę przestrzeni adresowej.
    4) Przewidziane jest także miejsce na kolejne 32kB dostępne jako cztery banki po 8kB + port do ich przełączania na 74LS373. Podstawki tych układów nie są jeszcze obsadzone.
    5) Port GPIO to standardowy 8255.
    6) Jest także miejsce pod 8251 oraz 8251, podstawki jeszcze nieobsadzone.
    7) Magistrala adresowa jest buforowana przez dwie sztuki 74LS245.
    8) Sygnały !WR i !RD na potrzeby pamięci oraz intelowskich peryferiów są generowane przez TAKI układ.
    9) Dekoder adresów zbudowany na bramkach NAND i inwerterach z serii TTL-LS.

    Na chwilę obecną wykonałem test pracy "na luzie". Za pomocą rezystorów ułożyłem na szynie danych wartość 0xEA (rozkaz NOP). Szyna adresowa podczas takiej pracy zachowuje się prawidłowo - na kolejnych liniach pojawiają się impulsy dwa razy dłuższe od impulsu na poprzedniej linii. Również dekoder adresów zdaje się wtedy pracować poprawnie - oscyloskop i analizator logiczny pokazują, że kolejne linie CS przyjmują stan niski we właściwe sekwencji.

    To by było jednak na tyle, jeśli chodzi o dobre informacje. Pozytywna passa skończyła się, gdy zabrałem się za odpalanie programu z EPROM-u.

    W tej chwili mam tam coś takiego:

    Kod: x86asm
    Zaloguj się, aby zobaczyć kod


    Program powinien powodować cykliczne machanie linią PA0 8255. Niestety nie ma to miejsca. Oscyloskop pokazuje aktywność na magistrali, linie !RD i !WR są aktywne, za to linia CS milczy. Żeby było ciekawiej, nie widzę aktywności na żadnej linii CS z obszaru I/O. Linie CS RAM-u i EPROM-u są aktywne. Przypominam, że wszystkie linie CS działały, gdy procesor pracował "na luzie".

    Wstępnie "przedzwoniłem" połączenia multimetrem - wydają się być ok. Może coś jest nie tak z kodem? Ktoś może mi podpowiedzieć gdzie powinienem szukać? Jak na razie skończyły mi się pomysły...

    0 27
  • #2 10 Cze 2018 22:43
    BlueDraco
    Specjalista - Mikrokontrolery

    Wrzuć schemat do tych CS.
    2 MHz to może być za dużo dla 6502.
    Nigdy nie rozumiałem, po co ludzie używają 8255. Koszmarny układ, nie do użycia bez buforów, co w praktyce oznacza, że programowanie kierunku linii jest fikcją.

    0
  • #3 10 Cze 2018 23:12
    maciej_333
    Poziom 33  

    Lepiej byłoby wstawić schemat całości. Choćby narysowany odręcznie. Układ 8255 był niegdyś bardzo popularny. Wydajność prądowa jego linii jest niestety bardzo mała. Jednak rzadko kiedy w trakcie pracy programu zmienia się kierunek linii, a jeśli to wtedy nie potrzeba wielkiej obciążalności. Tak byłoby np. w przypadku zastosowania 8255 w programatorze EPROM. Nie wiem dlaczego też ganisz kolego BlueDraco taki fajny grzejnik, jakim jest 8212.

    Odnośnie programu i aplikacji 6502, to widzę problem ze startem tego urządzenia. Skoro EPROM jest pod "wyższymi" adresami, a nie od 0x0000, to jak ten system ma wystartować ? Przecież po zrestowaniu PC zacznie pobierać rozkazy od 0x0000. Pod tym adresem znajduje się RAM. Dojdzie do odczytu przypadkowych wartości i ostatecznie zawieszenia systemu. Trzeba zastosować np. układ jaki zaproponowałem dla 8080.

    0
  • #4 10 Cze 2018 23:39
    Atlantis86
    Poziom 19  

    BlueDraco napisał:
    Wrzuć schemat do tych CS.


    W załączniku.
    Wyjście "IO" jest połączone z wejściem G2A układu 74LS138 (G2B ściągnięte do na stałe do masy, a G1 podciągnięte do VCC przez rezystor 3,3k).
    Układ 74LS138 dzieli przestrzeń 4kB na osiem części po 512 bajtów. Wejścia A, B i C tegoż układu są połączone z liniami adresowymi A9, A10 i A11.

    Cytat:
    2 MHz to może być za dużo dla 6502.


    To wersja MOS6502AD, która powinna sobie radzić z prędkością 2MHz. Zresztą mam zworkę przy dzielniku częstotliwości i w razie czego mogę zmniejszyć taktowanie do 1MHz. Oczywiście próbowałem to zrobić na samym początku. Nie pomogło, to nie tu leży przyczyna.

    Cytat:
    Nigdy nie rozumiałem, po co ludzie używają 8255. Koszmarny układ, nie do użycia bez buforów, co w praktyce oznacza, że programowanie kierunku linii jest fikcją.


    Po prostu mam go pod ręką. No i on raczej służy jako dodatkowe GPIO ułatwiające testy, niż coś faktycznie przydatnego...


    maciej_333 napisał:
    Odnośnie programu i aplikacji 6502, to widzę problem ze startem tego urządzenia. Skoro EPROM jest pod "wyższymi" adresami, a nie od 0x0000, to jak ten system ma wystartować ? Przecież po zrestowaniu PC zacznie pobierać rozkazy od 0x0000. Pod tym adresem znajduje się RAM. Dojdzie do odczytu przypadkowych wartości i ostatecznie zawieszenia systemu. Trzeba zastosować np. układ jaki zaproponowałem dla 8080.


    Właśnie nie. To nie jest błąd. W MOS6502 było to nieco inaczej zrealizowane. Ten procesor nie wykonywał kodu od adresu 0x0000, bo pierwszych 256 bajtów było zarezerwowane dla "strony zerowej" - specjalnego obszaru szybkiego adresowania (rekompensuje to do pewnego stopnia małą liczbę rejestrów ogólnego przeznaczenia). Kolejne 256 bajtów jest przeznaczone na stos.
    Po restarcie procesor pobiera zawartość adresu 0xFFFC i zaczyna wykonywanie programu od zapisanego tam miejsca.

    0
  • #5 10 Cze 2018 23:42
    Ronin64
    Poziom 35  

    @maciej_333
    Wszystko jest ok. Od $0000 do $00FF jest strona zerowa a potem dalsza część RAM. Procesor po resecie odczytuje wartość adresu zapisanego w $FFFC, $FFFD i zaczyna wykonywać umieszczony pod nim kod. Także RAM i ROM są właściwie umieszczone w przestrzeni adresowej :)

    @Atlantis86
    Jak powstaje sygnał R/W dla pamięci RAM?

    0
  • #6 11 Cze 2018 00:07
    Atlantis86
    Poziom 19  

    Ronin64 napisał:

    @Atlantis86
    Jak powstaje sygnał R/W dla pamięci RAM?


    W pierwszym poście podawałem link do schematu, który wykorzystałem. Wklejam go także w załączniku. Ten układ generuje sygnały !WR i !RD na potrzeby pamięci i intelowskich peryferiów.

    Nie wiem czy to ma jakieś znaczenie, ale wrzucam też schemat generatora kwarcowego, na którym się opierałem. Generator pracuje z kwarcem 4 MHz. Za nim jest jeszcze dzielnik przez 2 (lub 4) na 74LS74.

    Tak swoją drogą, mam jeszcze jedno pytanie o EPROM. Mianowicie piny P i VPP mogę bezpośrednio połączyć z plusem zasilania, czy wskazane jest podciągnięcie ich za pomocą rezystora?

    0
  • #7 11 Cze 2018 01:39
    maciej_333
    Poziom 33  

    Ronin64 napisał:
    @maciej_333
    Wszystko jest ok. Od $0000 do $00FF jest strona zerowa a potem dalsza część RAM. Procesor po resecie odczytuje wartość adresu zapisanego w $FFFC, $FFFD i zaczyna wykonywać umieszczony pod nim kod. Także RAM i ROM są właściwie umieszczone w przestrzeni adresowej :)

    Nie zdawałem sobie z tego sprawy. Jednak i tak nie rozumiem końcówki kodu kolegi Atlantis86. Skoro procesor zaczyna startować od 0xFFFC, to dlaczego w ostatnich adresach wstawiono tablicę opartą o dyrektywę DW ? Tablica ta zawiera tylko pewne adresy np. NMI, ale po co ? Powinno być raczej coś w stylu:
    Kod: x86asm
    Zaloguj się, aby zobaczyć kod

    0
  • #8 11 Cze 2018 06:41
    Atlantis86
    Poziom 19  

    maciej_333 napisał:

    Nie zdawałem sobie z tego sprawy. Jednak i tak nie rozumiem końcówki kodu kolegi Atlantis86. Skoro procesor zaczyna startować od 0xFFFC, to dlaczego w ostatnich adresach wstawiono tablicę opartą o dyrektywę DW ? Tablica ta zawiera tylko pewne adresy np. NMI, ale po co ?


    O ile dobrze rozumiem, to procesor nie tyle rozpoczyna wykonywanie kodu od tego adresu, co po resecie szuka pod nim adresu początku programu. Skok pod ten adres jest wykonywany automatycznie, przez hardware. Tam nawet nie ma miejsca na instrukcję skoku, bo do dyspozycji są tylko dwa bajty,

    Konkretnie:
    0xFFFA i 0xFFFB - adres procedury obsługującej NMI
    0xFFFC i 0xFFFD - adres początku programu
    0xFFFE i 0xFFFF - adres procedury obsługującej IRQ


    BTW zapomniałem wspomnieć o jeszcze jednej kwestii. Wątpię jednak, żeby miała ona z tym coś wspólnego. Na wczesnym etapie testów przez pomyłkę odwrotnie podłączyłem zasilanie 8255. Spowodowało to zwiększony przepływ prądu. Jednak nie na tyle duży, żeby bezpiecznik 3A (górna granica możliwości zasilacza) się przepalił. Niemniej drucik się rozżarzył.
    Po tym incydencie na wszelki wypadek podmieniłem CPU i 8255 na inne egzemplarze. Tak czy inaczej - już po tym zdarzeniu układ prawidłowo pracował "na luzie". Problem zaczyna się dopiero wtedy, gdy próbuję uruchomić kod z pamięci EPROM.

    UPDATE:

    Jeszcze jedna obserwacja. Zauważyłem coś dziwnego. Próbowałem wymienić układy TTL-LS w okolicy dekodera adresów i generatora sygnałów WR/RD na inne egzemplarze. W efekcie trafiłem na sytuację, kiedy urządzenie zupełnie przestało startować - to znaczy na liniach adresowych miałem cały czas wysoki, również po resecie. Efekt znikał po wyjęciu EPROM-u i pamięci RAM z podstawek (bez wymuszania NOP na liniach danych) - wtedy miałem losowe impulsy na liniach adresowych.

    Efekt zniknął po ponownym "przemieszaniu" scalaków.

    UPDATE: Chyba znalazłem. Najwyraźniej było to winą procesora. Wygląda to tak, jakby posiadał wadę skutkującą nieprzewidywalnym zachowaniem. Może coś z magistralą danych? Przy podciągniętych liniach działał, ale po podłączeniu rzeczywistych peryferiów zaczynał zachowywać się niestabilnie, a po jakimś czasie zapadała cisza na magistrali.
    Wymieniłem na inny egzemplarz i teraz analizator pokazuje mi zmianę stanu na linii PA0.

    Tak swoją drogą, mam jeszcze dwa pytania:

    1) Czy ktoś zna jakieś zaufane źródło tych CPU, zarówno w technologii NMOS jak i CMOS? NMOS-y zamówiłem z Aliexpress i jak widać nie jest idealnie (z drugiej strony, to trzydziestoletnie układy). Zestaw 65C02 zamówiłem na ebay-u, ale jeszcze nie dotarł.
    2) Jaki kontroler priorytetu przerwań będzie odpowiedni dla 6502? Mam pod ręką intelowskie 8259, jednak czy one przypadkiem nie wymagają do pracy linii potwierdzającej przyjęcie przerwania (INTA)? MOS takowej nie posiada.

    0
  • #9 11 Cze 2018 09:23
    BlueDraco
    Specjalista - Mikrokontrolery

    Dekoder fatalny - 6 bramek w łańcuchu. Jak zwykle przesadziłeś z uniwersalnością i rozwojowością. Weź zwykły 139 lub 138 i podziel przestrzeń adresową na 4 ćwiartki. Trochę czasu upłynie zanim zajmiesz po 16 KiB RAM i ROM. BASIC na 6502 zajmuje tylko 8 KiB ROM. ;)

    W każdym razie zacznij od tego, żeby zadziałały CS.

    0
  • #10 11 Cze 2018 11:40
    maciej_333
    Poziom 33  

    Atlantis86 napisał:
    2) Jaki kontroler priorytetu przerwań będzie odpowiedni dla 6502? Mam pod ręką intelowskie 8259, jednak czy one przypadkiem nie wymagają do pracy linii potwierdzającej przyjęcie przerwania (INTA)? MOS takowej nie posiada.

    Kontrolery Intela 8259 i 8214 absolutnie nie nadają się do 6502. Pierwszy będzie wystawiał rozkaz CALL, drugi RST. Rozkazu RST w 6502 nie ma, zaś CALL ma inny OPCODE niż w 8080/8085/Z80/8086. Zatem nawet jakby jakoś wytworzyć sygnał INTE, to nic z tego. Kiedy dochodzi do odbioru przerwania w 6502 na IRQ, kończona jest aktualna instrukcja, potem wykonywane są odkładania wszystkiego na stos i pobierany jest adres ISR spod adresu 0xFFFE i 0xFFFF. Wprawdzie można jakoś kombinować z wektorowymi przerwaniami, próbując w chwili odbioru przerwania od danego urządzenia "podstawić" zamiast EPROM adres danego urządzenia, jakie zgłasza przerwanie, ale nie widzę wielkiego sensu. Możliwe byłyby jeszcze jakieś inne kombinacje. Jednak zdecydowanie najprościej współdzielić linię IRQ za pomocą bramek z wyjściem OC. W ISR i tak można odczytać ze słów statusów różnych układów który z nich wywołał przerwanie. Poczytaj: przerwania 6502.

    Zobacz kolego BlueDraco jak fatalny dekoder adresów jest w mojej płycie z 8080. Jeszcze nie narysowałem wszystkiego, ale widać jak całość jest rozwiązana.

    0
  • #11 11 Cze 2018 11:58
    BlueDraco
    Specjalista - Mikrokontrolery

    Sensu w tym żadnego nie widzę - skąd i po co te przerwania?

    Pomysł na przerwania w 6502 był taki, że przy wykryciu odczytu 0xfffe/f zamiast pamięci był aktywowany sterownik przerwań, który podawał adres.

    Po co Ci NMOSowy 6502? Fałszywie oznakowane CMOS (tzn. prawdziwe CMOS, ale z fałszywymi oznaczeniami Rockwell) są dość tanie i popularne.
    Na Ali można też tanio (1.40) kupić 65C816. CMOS umożliwia rozciąganie cykli zegara -> pracę krokową.

    0
  • #12 11 Cze 2018 12:14
    maciej_333
    Poziom 33  

    BlueDraco napisał:
    Sensu w tym żadnego nie widzę - skąd i po co te przerwania

    Jeżeli chodzi o moje rozwiązanie, to przerwania będą pochodziły od 8275, 8042, 8251 i może jeszcze od czegoś. Jak na razie uruchamiałem układy przez polling, zaś 8259 testowałem osobno z generatorem funkcji na jednym z wejść. Jeszcze nie podłączałem poszczególnych peryferii pod linie IRQ 8259. W sumie nie widzę w tym nic szczególnie złego. Poszczególne obszary RAM i ROM są różnej wielkości, więc nie bardzo dało się to zrobić np. na jednym 8205.

    0
  • #13 11 Cze 2018 12:33
    Atlantis86
    Poziom 19  

    BlueDraco napisał:

    Po co Ci NMOSowy 6502?


    Nostalgia. ;)

    Cytat:
    Fałszywie oznakowane CMOS (tzn. prawdziwe CMOS, ale z fałszywymi oznaczeniami Rockwell) są dość tanie i popularne.


    Rozumiem, że pomimo fałszywych oznaczeń producenta to wciąż pełnowartościowe 65C02?
    Co sądzisz o TEJ aukcji? Wyglądają na autentyczne układy, czy raczej podróbki?


    Cytat:
    Na Ali można też tanio (1.40) kupić 65C816. CMOS umożliwia rozciąganie cykli zegara -> pracę krokową.


    Są zgodne pinowo/programowo z 65C02? Na ALi niestety nie wyskakuje mi w tej chwili żadna aukcja. Na Ebay'u za to widze kilka aukcji z Chin. Około 18$ za 9 sztuk.

    0
  • #14 11 Cze 2018 12:47
    BlueDraco
    Specjalista - Mikrokontrolery

    To właśnie te - ludzie raportują, że są to CMOS z "lepszym" oznakowaniem.
    65C816 jest zgodny elektrycznie i programowo z 65C02, z paroma ulepszeniami - w pierwszej połowie cyklu na szynie danych jest górny bajt adresu, brak niedokumentowanych instrukcji 65C02 oraz operacji bitowych (których nie było w 6502), za to mamy rozszerzania 16-bitowe. U mnie wykonuje bez zmian programy 6502.

    Tu masz 65C816:
    https://www.aliexpress.com/item/1PCS-W65C816S8P-14/32829957355.html

    0
  • #16 11 Cze 2018 14:41
    nowyARM
    Poziom 21  

    maciej_333 napisał:
    Jeżeli chodzi o moje rozwiązanie, to przerwania będą pochodziły od 8275, 8042, 8251

    Skoro 6502 to układy dla niego dedykowane (np 6526) albo rodziny 68xx np 6522, 6545. W C-64 wszystkie układy peryferyjne podłączone były do jednej linii przerwania (pomijam NMI od przycisku RUN/STOP). Rozstrzyganie o źródle przerwania było zrealizowane programowo.

    0
  • #17 13 Cze 2018 08:06
    Atlantis86
    Poziom 19  

    Swoją drogą, jak wygląda kwestia niezawodności procesorów z tego okresu? Mam tutaj na myśli nie tylko 6502, ale także m.in. 8080, 8085 czy Z80. Obecnie każda Atmega posiada watchdoga, który w przypadku zawieszenia wykonywania programu automatycznie zresetuje MCU. Nie pamiętam, czy kiedykolwiek ta funkcjonalność przydawała mi się po etapie debugowania. Zwykle dodaję do swoich konstrukcji licznik uptime'u, tak więc mogłem zweryfikować, że działały one bez przerwy długimi miesiącami, do zazwyczaj było przerywane dopiero przez przerwę w dostawie prądu. :)

    A jak w przypadku starszych procków? Zakładając, że program jest prawidłowo napisany i nigdy nie wpada w nieskończoną pętlę, można liczyć na to, że urządzenie nie zawiesi się samo z siebie? Pytam, ponieważ nieraz w celach edukacyjnych lubię zbudować coś, co jednak ma jakiś walor praktyczny. Chociaż to co buduję teraz jest raczej zestawem deweloperskim/komputerem ogólnego przeznaczenia, to nie wykluczam, że kiedyś spróbuję zbudować jakieś urządzenie wykorzystując coś w rodzaju 65c02 z przyległościami w roli mikrokontrolera. :)

    Może jednak w takiej sytuacji wskazane będzie jednak zbudowanie z układów logicznych własnego substytutu watchdoga?

    0
  • #18 13 Cze 2018 09:13
    nowyARM
    Poziom 21  

    Atlantis86 napisał:
    zbudowanie z układów logicznych własnego substytutu watchdoga?

    Są gotowe rozwiązania, np DS1232. MAX691 ma nie tylko watchdoga ale tekże układ przełączający zasilanie ram na awaryjne i sterowanie strobem CS.

    0
  • #19 14 Cze 2018 09:48
    Atlantis86
    Poziom 19  

    Tak swoją drogą przyglądam się teraz kompilatorowi cc65 (https://github.com/cc65/cc65).
    Mam jedno pytanie. Jak działa dołączanie bibliotek standardowych języka C do projektu? Bo z tego co widzę, kod źródłowy z dołączonym plikiem (w moim przypadku "string.h") kompiluje się do formy asemblerowej. Kod źródłowy używanych funkcji bibliotecznych nie jest jednak umieszczany w pliku wynikowym, jedynie są one wzmiankowane np. jako ".import _strchr".
    Tak wygenerowany plik asm konwertuje się do formy binarnej za pomocą narzędzia ca65. Jednak jeśli miałem gdzieś wywołanie tej funkcji bibliotecznej (np. "JSR _strchr") to w pliku lst adres tej funkcji występuje jako "rr rr".
    Dobrze rozumiem, że trzeba tutaj jeszcze skorzystać z linkera, aby wygenerować plik binarny zawierający kod samych funkcji? W jaki sposób powinienem to zrobić?

    I druga kwestia: znalazłem następującą stronę. Jest na niej opisany Microsoft Basic, stosowany powszechnie w komputerach na 6502 z epoki. Dostępny jest też kod źródłowy, polecam jednak korzystać z wersji dostępnej na GitHubie, bo ta do ściągnięcia ze strony nie jest kompatybilna z nową wersją asemblera z pakietu cc65.
    Opis jest niestety dość pobieżny. Ktoś z was orientuje się które części kodu powinienem zmodyfikować, aby dostosować projekt do moich ustawień pamięci i adresów I/O, a także zrealizować obsługę przez UART? Projekt jest niestety trochę bardziej skomplikowany od TinyBasica z 8080. :)

    0
  • #20 14 Cze 2018 10:43
    nowyARM
    Poziom 21  

    Atlantis86 napisał:
    Jest na niej opisany Microsoft Basic, stosowany powszechnie w komputerach na 6502 z epoki

    Najgorszy Basic jaki znam, konkretnie na C-64.
    - Nazwa zmiennej może mieć dowolna długość (prawie) ale pod uwagę brane sa dwa pierwsze znaki.
    - Zmienne powoływane automatycznie.
    - Dane trzeba zawsze czytać pod początku.
    - Brak funkcji.
    - Dane tylko dziesiętne.
    Tyle pamiętam ale trzy pierwsze punkty budzą zgrozę.

    0
  • #21 14 Cze 2018 10:54
    Atlantis86
    Poziom 19  

    nowyARM napisał:

    Najgorszy Basic jaki znam, konkretnie na C-64.
    (...)
    Tyle pamiętam ale trzy pierwsze punkty budzą zgrozę.


    Hmm... I tak prezentuje się nieźle na tle TinyBasica, który jest naprawdę ubogi. Brakuje mu przede wszystkim obsługi liczb zmiennoprzecinkowych, a także komend PEEK i POKE. Znasz jakąś alternatywę, która zawierałaby te cechy, a jednocześnie była dostępna w formie kodu źródłowego, nadającego się do modyfikacji i dostosowania do mojego hardware'u?

    W przypadku projektu z MCY7880 TibyBasic był zaledwie przystankiem na drodze do celu, jakim jest odpalenie CP/M. Tutaj jednak Basic jest celem w samym sobie, zależy mi więc na jego funkcjonalności.

    0
  • #22 14 Cze 2018 11:00
    BlueDraco
    Specjalista - Mikrokontrolery

    Wciągnięcie OSI BASIC na nowy komputer wymaga trzech modyfikacji kodu źródłowego - inicjowanie UART, czytanie znaku i pisanie znaku. Da się zrobić w <15 minut - u mnie działa. Ponieważ u mnie całość jest w RAM, musiałem jeszcze dołożyć ograniczenie rozmiaru testowanej pamięci RAM, bo by mi się BASIC sam zamazywał przy teście.
    Zajrzyj na forum 6502.org. Jest tam sekcja nt. lepszego BASICs, powszechnie używanego na komputerkach z 6502.

    0
  • #24 14 Cze 2018 12:22
    nowyARM
    Poziom 21  

    Ronin64 napisał:

    To i napęd dyskowy i drukarkę da się podłączyć :-) Potrzebny tylko CIA (6526). Do C-64 są rozwiązania, na AVR, jak dobrze pamiętam, emulujące napęd dyskowy na karcie SD. Tyle, że wtedy sam BASIC nie wystarczy, potrzebny jeszcze KERNAL.

    0
  • #25 14 Cze 2018 12:30
    Ronin64
    Poziom 35  

    To jest SD2IEC i nawet znośnie działa :)

    0
  • #26 15 Cze 2018 10:11
    Atlantis86
    Poziom 19  

    BlueDraco napisał:
    Wciągnięcie OSI BASIC na nowy komputer wymaga trzech modyfikacji kodu źródłowego - inicjowanie UART, czytanie znaku i pisanie znaku. Da się zrobić w <15 minut - u mnie działa.


    A czy przypadkiem OSI BASIC nie jest właśnie jedną z wersji MS BASIC-a, używanego m.in. w Commodore albo Apple II?

    0
  • #27 15 Cze 2018 11:04
    nowyARM
    Poziom 21  

    Commodore 128 miał całkiem znośny BASIC. Co do Apple II to nie miałem okazji poznać.

    0