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

sd2iec - stacja dysków do Commodore 64 na Arduino MEGA 2560

28 Gru 2018 13:31 906 7
  • Poziom 36  
    Witam.

    Zmontowałem sobie stację dysków do C64 zgodnie z opisem:
    http://uczymy.edu.pl/wp/blog/2018/09/18/sd2ie...-karta-sd-zamiast-magnetofonu-z-arduino-mega/

    Jak doczytałem na:
    https://github.com/Larswad/sd2iec_mega2560

    Cytat:
    The default assumption of the MEGA2560 is that no LEDs or extra push-buttons has been added to the board.
    This however can be easily added by simply changing the commented-out suggested GPIO's in the archconfig.h
    for this purpose. That way, drive activity and error LED's can be functional, same goes for a floppy switching
    button for M2I or D64 disks.


    Znalazłem zatem plik:
    sd2iec_mega2560/src/avr/arch-config.h

    i odnalazłem sekcję:

    Kod: c
    Zaloguj się, aby zobaczyć kod


    Ale... Nie w tym rzecz...

    Chodzi mi po głowie zastąpienie modułu karty SD modułem ethernet. Chciałbym by "stacja dysków" była klientem nie karty SD tylko wybranego zasobu samby na maszynie o wybranym IP. Innymi słowy, by była klientem domowego NAS-a (serwera Samby na domowym NASie).

    Moduły Ethernet dla Arduino niby są... Pisał ktoś klienta Samby na Arduino / w C?
  • Poziom 1  
  • Poziom 36  
    Jedna rzecz mnie zastanawia. Powstało co prawda Pi1541:

    https://cbm-pi1541.firebaseapp.com/

    Ale to wymaga (aż) Raspberry Pi 3B, 3B+ lub 3A+, czyli dosyć potężnego hardware-u. Inna sprawa, że to pełny emulator stacji 1541 (zdaje się, że zapewniający 100% kompatybilności). Może do tego dorobić klienta samby wystarczy? Chociaż nie, bo to zdaje się nie śmiga (niestety) na Linuksie (tam bodajże firmware napisany bezpośrednio dla ARM-a jest), więc tak prosto, jakbym chciał, nie będzie niestety.
  • Poziom 15  
    Wymaga potężnego (delikatnie mówiąc, ja bym powiedział superpotężnego) hardware'u, bo, za przeproszeniem, (zbyt niecenzuralne na publikację na forum). Jeżeli potrzebujemy near-real-time-scheduling, nie można pisać takich rzeczy w user-space, a co najmniej w kernel-space, najlepiej w kernelu z obsługą real-time, lub nawet na bare-metal... RPi (nawet 1 czy Zero) jako bare-metal jest naprawdę POTĘŻNĄ maszyną, użyłem nawet RPi Zero bare-metal jako automatykę do sterowania maszyną wymagającą ogromnej precyzji, drogie rozwiązania rzekomo Real Time sobie nie radziły a RPi Zero za 5$ (!!!!!) bez problemu. Arduino na ARM jest dostępne, wymagałoby niewielkich zmian aby umiało np. zaadresować porty GPIO w RPi i w taki sposób na pewno wydajności nie zabraknie :)

    Potem pożal-się-boże inżynierowie się dziwią, że dwie połączone w klaster superpotężne maszyny na Pentiumach pod kontrolą Windowsa NT nie potrafią poradzić sobie z sterowaniem osprzętem, z którym stary polski mainframe Odra radził sobie bez problemu, jak czytałem w jakimś niby poważnym pisemku :) Moc obliczeniowa to nie wszystko, jest jeszcze przepustowość i latency, a to ostatnie zależy w większości od oprogramowania.
  • Poziom 37  
    No tak, trochę po bandzie już idzie ta retro scena. RPi3 z RetroPie emuluje całego C64 z obsługą obrazów taśmy i dysku, z bajerami jak reu itp. Ten sam RPi3 emuluje wyłącznie samą stację dla oryginalnego C64 :) Coś mnie się wydaje, że emulacja 1MHz 6502 oraz 2x VIA 6522 nie powinna wymagać 4 rdzeni po 1.4GHz
  • Poziom 31  
    Temat do ogarnięcia na większości ARM. Na AVR dużo roboty. W RPi para idzie w gwizdek, trzeba dobrze kumać w temacie Linuxa.
    Dla kumatych ARM z min 32kB RAM, dla "niekumatych" ESP, w miarę łatwo da się zrobić ale... długa lista tych ale. Na "Ardunino" czyli w domyśle AVR nie polecam, mało RAM i przez to komplikuje się życie (prację).

    Poparcie moich wywodów to nie szybkość uC, tu AVR spoko da radę ale:
    - ETH, ramka to ok 1,5kB, warto j trzymać w uC, jest ramka nadawcza, jest i odbircza, i już wymagane min to 3kB. Stos, sterta (racej w Bascom się nie pisze, czy w ASM) i min 4kB. Jakieś bufory do USB czy USART do debugowania i bez 8 kB nie podchodź.
    Porównując ceny AVR i ARM, wybór jest jeden (albo dwa arm ALBO NIE ROBIĆ).
    - DMA: AVR (poza Xmega) go nie mają, nawet jeśli, to mało RAM na bufory!
    - Szybkie SPI w AVR to iluzja (brak DMA, mało RAM). Niby w niektórych AVR można dodać zewnętrzy RAM (10 razy drożej niż ARM z takowym na pokładzie).
  • Poziom 15  
    A kto każe koledze używać Linuxa, skoro go nie "kuma"? RPi sobie bardzo dobrze radzi również bez niego, chociaż to prawda, obsługa Ethernetu (protokół USB) bez niego będzie dość skomplikowana, chociaż można sobie pożyczyć kilka plików .c z Linuxa i zobaczyć, jak to jest tam zrobione :)

    Dodano po 1 [minuty]:

    Zawsze można sobie dołożyć coś prostszego na SPI.
  • Poziom 31  
    szy_mat napisał:
    chociaż można sobie pożyczyć kilka plików .c z Linuxa i zobaczyć, jak to jest tam zrobione :)

    Łatwo napisać, trudniej zrobić :-)

    Aby ogarnąć szybko, trzeba się wspomóc softem innych (byle nie M$, nie dość, że płatny, to kiepski, wsparcia w praktyce brak). Naturalnie mozna "rzeźbić" na jakimś AVR czy ESP, samemu pisać USB, ETH ale ile to zajmie? Pisałem ETH od podszewki na AVR, trwało ok 6 miesięcy, teraz mamy net, może w 3 dałoby się zrobić. Używając 5 razy większego ARM, będzie on trochę albo dwa razy tańszy! i libs do niego pewnie w miesiąc mamy TCP/IP.
    Komercja, ok, cjak np procek w całym projekcie bedzie tańszy o 2 centy, a prace potrwają nie 6 a 26 miesięcy, przy 10e6 szt zysk jest. W domowym zaciszy już go nie ma chyba, że czas = 0zł.