Elektroda.pl
Elektroda.pl
X
Elektroda.pl
Advanced Search
Elektroda.pl
Please add exception to AdBlock for elektroda.pl.
If you watch the ads, you support portal and users.

Mikrokomputer COBRA 1

coberr 09 Jul 2021 15:36 211335 1174
Texa Poland
Reply Cool? Ranking DIY | New topic
Notify about new articles
  • #781
    sq2bvn
    Level 15  
    Super, że zadziałało.
    Do pełnego sukcesu brakuje mi:
    - źródła przerwań;
    - by pliki wynikowe SDCC były na prawdę relokowalne, bo nie są.

    Wówczas będzie można odtwarzać muzykę w czasie pracy innego programu.
    A samej muzyki jest pełno, bo nawet 20 000 kawałków zapisanej w formacie PT3.
    Nawet można samemu tworzyć swoją muzykę i odtwarzać na COBRA1.
    Tak jak tu przykładowo:

    https://www.youtube.com/watch?v=fWdxkp9FhTk

    Poniżej poglądowo schemat mojej płytki muzycznej.


    Mikrokomputer COBRA 1

    Myślę też o prawdziwym playerze z podskakującymi paskami FFT... jednakże bólem jest brak obsługi systemu plików, więc utwory będą musiały siedzieć w cartidge....
  • Texa Poland
  • #782
    andrzejlisek
    Level 29  
    sq2bvn wrote:
    Myślę też o prawdziwym playerze z podskakującymi paskami FFT... jednakże bólem jest brak obsługi systemu plików, więc utwory będą musiały siedzieć w cartidge....

    Problem mógłby rozwiązać być kartridż z mikrokontrolerem i gniazdem SD. Coś takiego, jak PowerPak lub Everdrive N8 do konsoli NES. Sama konsola nie obsługuje systemu plików, ale kartridż już tak.
  • #783
    sq2bvn
    Level 15  
    andrzejlisek wrote:
    Problem mógłby rozwiązać być kartridż z mikrokontrolerem i gniazdem SD.

    Kartę SD to podłączy się do szyn CPU. Parę bramek i tryka.

    Martwi mnie obsługa FAT32. Ciekawe czy istnieje jakaś proteza do czytania FAT32 na 8 bitów.
  • #784
    andrzejlisek
    Level 29  
    sq2bvn wrote:
    Martwi mnie obsługa FAT32. Ciekawe czy istnieje jakaś proteza do czytania FAT32 na 8 bitów


    Czy masz doświadczenie w programowaniu Atmega? Bywają projekty na Atmega wykorzystujące SD.

    Nigdy nie miałem z tym do czynienia, nie mam żadnego doświadczenia, ale popatrzyłem i trafiłem na to (sam nic nie wiem o tych projektach):
    https://github.com/nandra/AVR/tree/master/sd_card_uart
    https://www.dharmanitech.com/2009/01/sd-card-interfacing-with-atmega8-fat32.html
    Rodzaj procesora chyba nie ma większego znaczenia, i tak kod pewnie trzeba będzie trochę przerobić, zwłaszcza odczyt i zapis bloków danych na SD, potem dostosować, aby kompilował się przez SDCC czy inny kompilator C na Z80.
  • Texa Poland
  • #785
    sq2bvn
    Level 15  
    andrzejlisek wrote:

    Czy masz doświadczenie w programowaniu Atmega?


    Coś tam robiłem na AVR8. Może udałoby się zrozumieć kod z AVRów.
    https://sourceforge.net/p/burzenin2018-fred2017/code/ci/master/tree/

    Myślę, że w moim publicznym repo umieściłbym CobraSTUDIO bo wstawianie ZIPów jest średnim pomysłem.
    Dodatkowo mogą śledzić zmiany.


    andrzejlisek wrote:
    Rodzaj procesora chyba nie ma większego znaczenia, i tak kod pewnie trzeba będzie trochę przerobić, zwłaszcza odczyt i zapis bloków danych na SD, potem dostosować, aby kompilował się przez SDCC czy inny kompilator C na Z80.


    Kiedyś jak było trzeba obsługiwać jakiś file system to dawało się 80186 i ładowało się tam DOS. Wówczas obsługa systemów plików to była dla wybranych... Nawet proste nazwy typu 1.pt3 2.pt3 rozwiązałyby problem. Bo plik PT3 ma pierwsze 100 bajtów nagłówka i tam jest nazwa twórcy i takie tam...

    Kiedyś śmignął mi projekt SDkarty na Z80, ale nie pamiętam gdzie i nie pamiętam czy dodałem do lików. Sprawdzę to.

    Dodano po 11 [godziny] 57 [minuty]:

    sq2bvn wrote:
    andrzejlisek wrote:

    Czy masz doświadczenie w programowaniu Atmega?


    Coś tam robiłem na AVR8. Może udałoby się zrozumieć kod z AVRów.
    https://sourceforge.net/p/burzenin2018-fred2017/code/ci/master/tree/

    Myślę, że w moim publicznym repo umieściłbym CobraSTUDIO bo wstawianie ZIPów jest średnim pomysłem.
    Dodatkowo mogą śledzić zmiany.


    andrzejlisek wrote:
    Rodzaj procesora chyba nie ma większego znaczenia, i tak kod pewnie trzeba będzie trochę przerobić, zwłaszcza odczyt i zapis bloków danych na SD, potem dostosować, aby kompilował się przez SDCC czy inny kompilator C na Z80.


    Znalazłem takie coś... dość interesujące bo ten SPI wpina się do szyny i obsługuje rozkazami out (c), a... więc karta SPI mogła by działać z demoniczną prędnością COBRA1....
    https://www.reddit.com/r/Z80/comments/aygyws/7_chip_spi_peripheral/


    Kiedyś jak było trzeba obsługiwać jakiś file system to dawało się 80186 i ładowało się tam DOS. Wówczas obsługa systemów plików to była dla wybranych... Nawet proste nazwy typu 1.pt3 2.pt3 rozwiązałyby problem. Bo plik PT3 ma pierwsze 100 bajtów nagłówka i tam jest nazwa twórcy i takie tam...

    Kiedyś śmignął mi projekt SDkarty na Z80, ale nie pamiętam gdzie i nie pamiętam czy dodałem do lików. Sprawdzę to.
  • #787
    Atlantis86
    Level 19  
    sq2bvn wrote:

    Martwi mnie obsługa FAT32. Ciekawe czy istnieje jakaś proteza do czytania FAT32 na 8 bitów.


    W jednym z moich projektów na 6502 (link TUTAJ) udało mi się skompilować kompletną bibliotekę FatFS z obsługą zapisu. Wykorzystałem kompilator CC65, który nie generuje zbyt optymalnego kodu, a zresztą uproszczona architektura 6502 sprawia, że niezbyt nadaje się on do efektywnego korzystania z kompilowanego kodu. Efekt jest taki, że biblioteka zajęła sporą część 32kB EPROM-u, ale w pełni działa. Musiałem tylko wprowadzić kilka drobnych modyfikacji w złożonych konstrukcjach, których CC65 nie chciał zrozumieć.

    Podejrzewam, że w przypadku Z80 powinno pójść łatwiej. To dojrzalszy procesor od 6502, a SDCC jest bardziej dopracowanym kompilatorem od CC65. Poza tym w przypadku tego zastosowania można by kompilować bibliotekę w trybie read only.
  • #788
    sq2bvn
    Level 15  
    Atlantis86 wrote:
    Poza tym w przypadku tego zastosowania można by kompilować bibliotekę w trybie read only.


    6502 jest trudniejszy do programowania, więc podziwiam za wytrwałość.
    Źródło C choć dla tej tego FAT jest dostępne?
  • #789
    Atlantis86
    Level 19  
    sq2bvn wrote:

    6502 jest trudniejszy do programowania, więc podziwiam za wytrwałość.


    Gdy korzysta się z kompilatora nie ma to aż tak wielkiego znaczenia. Tylko parę fragmentów trzeba napisać w asemblerze - chociażby obsługę przerwań.

    Quote:
    Źródło C choć dla tej tego FAT jest dostępne?


    Jest na moim GitHubie (LINK). Jak widać minimalne zmiany w kodzie w stosunku do oryginalnej biblioteki.
    Oczywiście kod FatFS przerobiony jedynie dla aktualnej konfiguracji - pewnie gdyby włączyć jakieś funkcje trzeba by walczyć z kolejnymi błędami kompilacji.
  • #790
    sq2bvn
    Level 15  
    Atlantis86 wrote:


    Gdy korzysta się z kompilatora nie ma to aż tak wielkiego znaczenia


    Spróbuję zrozumieć ten kod, może uda się.

    Ten układ obsługi SPI in/out + obsługa FAT może zrewolucjonizować COBRA1.
  • #791
    Atlantis86
    Level 19  
    sq2bvn wrote:

    Spróbuję zrozumieć ten kod, może uda się.


    Tam tak naprawdę nie ma czego rozumieć. To jest minimalnie zmodyfikowany FatFS - bardzo znana biblioteka, powszechnie wykorzystywana z mikrokontrolerami. Polecałbym nawet, żeby zamiast zajmować się analizowaniem kodu mojego projektu, zacząć od dużo lepszej dokumentacji samej biblioteki, na stronie jej autora.

    Autor napisał ją w ten sposób, żeby była niezależna od sprzętu - użytkownik musi tylko przygotować jeden albo dwa pliki źródłowe, w których zawarte są niskopoziomowe funkcje I/O. Potem biblioteka wywołuje te funkcje, gdy chce korzystać z konkretnego dysku.
    Używałem FatFS wielokrotnie, zarówno z AVR-ami, PIC32, jak i STM32 (narzędzie do automatycznego generowania kodu STM32CubeMX dodaje właśnie bibliotekę FatFS do projektu, gdy chcemy mieć obsługę FAT32). Korzystałem z kart SD, pamięci FLASH jak i nośników USB.

    Podczas eksperymentów z urządzeniami retro postanowiłem spróbować podpiąć tę bibliotekę do projektu na 6502, z wykorzystaniem karty CF. Napisanie niskopoziomowego sterownika karty CF okazało się być banalnym zadaniem. Potem pozostało tylko poprawić niektóre fragmenty głównej biblioteki, bo CC65 jest na tyle prostym kompilatorem, że niektórych złożonych "jednolinijkowców" nie chciał pojąć i trzeba he było porozbijać na sekwencję prostszych instrukcji.

    Niewykluczone, że SDCC poradzi sobie ze skompilowaniem kodu biblioteki z miejsca.

    Bardzo dokładna dokumentacja jest dostępna na stronie głównej biblioteki (Link). Bez problemu znajdziesz też tutoriale tłumaczące w jaki sposób spiąć to z poszczególnymi nośnikami na różnych mikrokontrolerach. Chyba najbardziej skomplikowane będzie napisanie w oparciu o FatFS jakiegoś loadera, który rezydowałby w jednej ze stron Flasha Cobry i po wywołaniu zajął się ładowaniem zawartości plików do pamięci. Moim zdaniem jak najbardziej do zrobienia.

    Podejrzewam zresztą, że ktoś mógł już eksperymentować z FatFS na jakiejś platformie z Z80, z wykorzystaniem kompilatora SDCC.
  • #792
    sq2bvn
    Level 15  
    Atlantis86 wrote:
    STM32CubeMX dodaje właśnie bibliotekę FatFS do projektu


    To jest akurat dobre, bo dzięki temu udało się zrozumieć kilka bibliotek. Inaczej się robi jak już wstępnie coś działa - inaczej jak masz surowe źródło i trzeba zrozumieć, skompilować i uruchomić.
  • #793
    Atlantis86
    Level 19  
    sq2bvn wrote:

    To jest akurat dobre, bo dzięki temu udało się zrozumieć kilka bibliotek. Inaczej się robi jak już wstępnie coś działa - inaczej jak masz surowe źródło i trzeba zrozumieć, skompilować i uruchomić.


    Mnie akurat w CubeMX wkurza fakt, że zmodyfikowali sposób obsługi biblioteki. W "czystym" FatFS masz plik źródłowy diskio.c, w którym trzeba dodać kilka funkcji obsługujących operacje na nośnikach. Funkcje te przyjmują jako pierwszy argument numer dysku, tak więc można w jednym miejscu zaimplementować obsługę kilku nośników za pomocą instrukcji switch/case.

    CubeMX podchodzi do tego inaczej - obsługa nośników "wyklikanych" (USB, SD przez SDIO) w generatorze jest zaszyta gdzieś głęboko. Użytkownik może dodać jeden nośnik "user defined", który trzeba obsłużyć w osobnym pliku diskio.c, ale jest to tylko jeden nośnik.

    Z tego co zdążyłem zrozumieć na podstawie analizy kodu, ta zmodyfikowana wersja biblioteki operuje w oparciu o tablice ze wskaźnikami do funkcji. Można by więc dodać więcej własnych urządzeń, definiując takie tablice i umieszczając w nich wskaźniki do własnych funkcji I/O. Jest to jednak bardzo słabo udokumentowane, jeśli ktoś chciałby wyjść poza to, co oferuje "klikany" interfejs.

    Standardowa biblioteka FatFS jest dużo bardziej przejrzysta i znaczne bardziej przenośna.
  • #794
    sq2bvn
    Level 15  
    Myślę, karta SD zwiększy możliwości muzyczne ale również umożliwiłaby odtwarzania plików w formacie *.FLI. Myślę, że jest to format dopasowany do możliwości COBRA1. Ze względu na wielkość karty, odtwarzanie treści mogłoby trwać i trwać...



    Edycja np. w GIMP.

    Odtwarza to imagen

    Jakieś fajne intro na COBRA1 z muzyczką...
    Attachments:
  • #795
    wieswas
    Level 33  
    Trochę odbiegnę od obecnie dyskutowanego wątku zamieszczając prostą grę zręcznościową: PELOTA, napisaną bezpośrednio w kodzie maszynowym Z-80
    Pierwsze podejście było zbyt ambitne. Piłka poruszała się z rozdzielczością 1/4 znaku i możliwe było 10 kierunków ruchu. Napisałem 70% kodu i okazało się, że doszedłem do granicy wydajności procesora. Analiza różnych kierunków ruchu i odbić spowalniała grę tak bardzo, że zrezygnowałem z kontynuacji.
    Od początku rozpocząłem pisanie prostszej wersji. Rozdzielczość ruchu piłki to jeden znak. Ilość kierunków ruchu 6. Teraz jest jeszcze rezerwa czasowa. (w głównej pętli gry wstawiłem opóźnienie). Używane są tylko podstawowe znaki semigrafiki.
    Adres startowy: 5000hex Długość pliku: od 5000hex do 5666hex
    Mikrokomputer COBRA 1 Mikrokomputer COBRA 1
    Attachments:
  • #796
    sq2bvn
    Level 15  
    O super, będzie co wypróbować na weekend :)


    wieswas wrote:
    Adres startowy: 5000hex Długość pliku: od 5000hex do 5666hex


    Czy klawisze sterujące pokrywają się z dźojstykiem? Właśnie wczoraj popełniłem adapter dżojstyka na PC GAME PORT więc ucieszyłbym się sterowaniem przy pomocy dżoja.


    Też myślałem o zrobieniu jakiejś gry ale w C, takiej z dźwiękiem na AY oraz większymi obiektami animowanymi. Niestery COBRA1 nie ma tych tzw. duszków jak to było w innych maszynach tej klasy :( Nie mniej jednak jak uruchomię COBRA Studio to z pewnością następnym krokiem będzie pisanie gry. Teraz robię playera do odtwarzania muzyki na układzie AY. Trochę utrudnia robotę to programowanie EPROMów, możliwe, że trzeba będzie zrobić bezpośredniego loadera do RAM, dzięki któremu będzie można kolejne programy wgrywać po USB.
  • #797
    andrzejlisek
    Level 29  
    sq2bvn wrote:
    Czy klawisze sterujące pokrywają się z dźojstykiem? Właśnie wczoraj popełniłem adapter dżojstyka na PC GAME PORT więc ucieszyłbym się sterowaniem przy pomocy dżoja.


    W PC klawiatura i dżojstik nie pokrywają się. Dżojstik to jest osobny byt, który ma swoje "klawisze", na które może reagować program. Jak pewne zauważyłeś przy budowie adaptera, w GAME PORT, kierunki nie są wyrażane stanami, tylko wartościami 8-bitowymi w dwóch osiach.

    Cobra1 nie ma innego wejścia niż klawiatura, więc tutaj adapter powinien zapewniać wciskanie klawiszy, inaczej się nie da. Chyba musiałby być programowalny (najłatwiej chyba mały mikrokontroler z pamięcią trwałą i zapisywalną, np. ATTiny), aby można było dowolnie ustawić, jaki klawisz ma wciskać wychylenie drążka lub przycisk na nim. Myślę, że odpowiednio oprogramowany mikrokontroler da się wysterować z linii adresowej i danych Z80, co da możliwość konfiguracji dżojstika z poziomu samego komputera.
  • #798
    sq2bvn
    Level 15  
    andrzejlisek wrote:
    W PC klawiatura i dżojstik nie pokrywają się.


    Zgadza się.
    Kupiłem analogowy od PC bo był tani. Te z blachami są drogie. Dodatkowo analogowy daje więcej możliwości.
    Mój egzemplarz COBRA1 ma wejście dżojstyka. Styki dżojstyka stanowią zrównoleglenie klawiszy klawiatury.
    O które to klawisze chodzi nie pamiętam - trzeba sprawdzić w płytce zdzis_ka.
    Jednak fajnie by było przyjąć jakiś standard przyporządkowania klawiszy do kierunków bo później będą programy co można sterować dżojem i takie co są niezgodne...
  • #799
    andrzejlisek
    Level 29  
    sq2bvn wrote:
    O które to klawisz chodzi nie pamiętam - trzeba sprawdzić w płytce zdzis_ka.

    Albo uruchom ten program w Basic (to był jeden z pierwszych potrzebnych przy opracowywaniu emulatora) i będzie wszystko jasne.
    Code: Expand Select all Copy to clipboard 
    10 CLS
20 I = 1
110 PRINT IN 32767;
120 PRINT IN 49151;
130 PRINT IN 57343;
140 PRINT IN 61439;
150 PRINT IN 63487;
160 PRINT IN 64511;
170 PRINT IN 65023;
180 PRINT IN 65279;
190 PRINT
200 GOTO 110

    Na prawdziwym sprzęcie może wyświetlać zakłócenia obrazu, ale to nie ma znaczenia, powodem jest ciągłe odświeżanie obrazu. Nie pamiętam dobrze, czy ten program z Basic działa dobrze, załączam program w C, który też wyświetla stan klawiatury na ekranie. Ponaciskasz klawisze, potem joystik i będzie wiadomo, którym klawiszom odpowiadają przyciski i wychylenia dżojstika. Pamiętam, że ten drugi program uruchamiał coberr, bo poprosiłem go o mały test dla porównania.
    Attachments:
  • #800
    sq2bvn
    Level 15  
    andrzejlisek wrote:
    Ponaciskasz klawisze, potem joystik i będzie wiadomo, którym klawiszom odpowiadają przyciski i wychylenia dżojstika. Pamiętam, że ten drugi program uruchamiał coberr, bo poprosiłem go o mały test dla porównania.


    OK, jak dostanę PCB i złożę sprawdzę. Adapter i firmware wstawię na forum.
    Jak gry to dżoj musi być obowiązkowo. Nie cierpię gier sterowanych z klawiatury.
    Swoją drogą Win obsługuje dżoje na USB, a GAME PORT nie jest obsługiwany już od Vista. Linux wciąż obsługuje GAME PORT i można z niego korzystać (np. przetworniki ADC).

    Mikrokomputer COBRA 1


    andrzejlisek wrote:
    Na prawdziwym sprzęcie może wyświetlać zakłócenia obrazu, ale to nie ma znaczenia, powodem jest ciągłe odświeżanie obrazu.


    Tutaj aż prosi się, żeby poprawić układ na VRAM dual port i będzie finał z tymi kreskami. Mnie też te kreski dręczą.
  • #801
    andrzejlisek
    Level 29  
    Dlatego też proponuję umożliwić konfigurację mapowania z możliwością zapisu. Jak będzie odpowiednio współpracować, to na pewno da się podpiąć mikrokontroler pod jakiś adres i z samego komputerka będzie można konfigurować, czy to za pomocą programu monitora (oryginalny program chyba miał możliwość wysyłania i odbierania danych z adresów), czy prostego programu w Basic. Przy takim konfigurowalnym joyu będzie można za jego pomocą zagrać we wszystko niezależnie od klawiszy, jakich używa.
  • #802
    sq2bvn
    Level 15  
    andrzejlisek wrote:
    Dlatego też proponuję umożliwić konfigurację mapowania z możliwością zapisu.


    Jest to możliwe do zrobienia. Wymagałoby to np. wpięcie się do szyny systemowej np. przez złącze kartridża. Mój egzemplarz ma wyprowadzone wszystkie wymagane sygnały. Wówczas out(C, A) umożliwiałoby wpisywanie do np. ATMEGA wartości konfiguracyjnych. Można też zrobić po SPI od adaptera karty SD. Wyprowadzić dwa sygnały SS... Karta SD to wciąż przyszłość, nie mam PCB gotowego jeszcze.

    Niestety fizycznie robi się to kłopotliwe bo mam kartridża i adapter AY i podłączenie kolejnej płytki do szyny to może być wyzwanie projektowe...
  • #803
    atmeg8
    Level 12  
    Witam wszystkich forumowiczów.

    Od jakiegoś czasu pracuję nad podsystemem do zarządzania plikami na SD dla Cobry . Projekt oparłem o atmega644 , układ zawiera również zegar na DS1302.
    Komunikacja z Cobrą odbywa się przez port 14h (Q5) poprzez złącze systemowe .

    Mikrokomputer COBRA 1

    Niewielki program (218b) umieściłem pod adresem C770h , jest w pełni relokowalny i można zapisać go w innym miejscu .
    Po wywołaniu programu G:C770 na ekranie pojawia się konsola .
    Zarządzanie odbywa się podobnie jak w DOS , na razie działają komendy : INIT, DIR , CD , LOAD , SAVE , BSAVE (dla Basica) , TIME , DATE , LABEL , DEL , SIZE , MKDIR , FORMAT.
    Nie jest to oczywiście prawdziwy DOS i ma ograniczenia , lecz najważniejsze operacje na plikach można wykonać bez odpalania dużego komputera.

    Oto mały przykład



  • #804
    wieswas
    Level 33  
    W ostatnim czasie tworzę prostą grę TENIS bezpośrednio w kodzie maszynowym Z-80 i mam problem z używaniem rejestrów iY
    Początkowo zakładałem własną pomyłkę w procedurze i wielokrotnie ją analizowałem dochodząc do wniosku, że błędu nie ma, a mimo to nie działa prawidłowo.
    Zrobiłem więc prosty test :
    FD LD IY,4141 wpisz do rejestru IY liczbę 4141 (odpowiednik dwóch znaków A)
    21
    41
    41

    FD LD(F800),IY przepisz tą zawartość do pamięci ekranu (lewy, górny róg)
    22
    00
    F8

    W lewym, górnym rogu ekranu wyświetliły się znaki AA, czyli dotąd jest dobrze

    FD LD IY,(F800) Z powrotem przepisuję z panięci do rejestru IY
    2A
    00
    F8

    I znów przepisuję do pamięci ekranu (F900)

    FD LD(F900),IY
    22
    00
    F9

    spodziewałem się nadal otrzymać wartość początkową a na ekranie wyświatliła się tylko jedna litera A.
    Zarówno sama procedura, jak i wqynik jej działania są widoczne na obrazku.
    I teraz pytanie:
    - czy błąd jest w emulatorze COBRY ?
    - czy tylko u mnie uszkodził się emulator ?
    - czy na hardwarowej COBRZE ten test działa prawidłowo ?
    - czy w moim toku rozumowania tkwi błąd ?

    Mikrokomputer COBRA 1

    [/b]
  • #806
    wieswas
    Level 33  
    Dziękuję za szybkie wyjaśnienie problemu.
    Pozostaje jeszcze pytanie, czy jest to błąd emulatora wyłącznie na moim komputerze, czy także u innych użytkowników
  • #808
    wieswas
    Level 33  
    Miałbym więc prośbę do kol."andrzejlisek", który najlepiej zna ten emulator, czy mógłby sprawdzić emulację rozkazu: LD IY,(nn) czyli FD, 2A, młodszy bajt, starszy bajt liczby.
  • #809
    andrzejlisek
    Level 29  
    Był rzeczywiście błąd w emulatorze, wgrałem poprawkę na https://github.com/andrzejlisek/Cobra1 , poprawka dotyczy rozkazów LD IX,(nn) i LD IY,(nn).

    Takie informacje o istniejących błędach w emulacji procesora są najbardziej cenne, gdyż od tego najbardziej zależy kompatybilność emulatora z rzeczywistym sprzętem.
  • #810
    sq2bvn
    Level 15  
    atmeg8 wrote:
    Witam wszystkich forumowiczów.

    Od jakiegoś czasu pracuję nad podsystemem do zarządzania plikami na SD dla Cobry .


    Bardzo interesujący jest ten projekt COBRA-DOS oraz wciąganie plików. zapewne nieźle się natyrałeś, żeby to zrobić.
    Ja też kombinuję aby podłączyć SD szyny COBRA ale temat jest w fazie przemyśleń. Obecnie więcej robię w zakresie playera, ale trochę męczące jest pracowanie w jakimś notatniku i chyba trzeba będzie brać się za COBRA Studio by działanie było bardziej ergonomiczne.

    Załóżmy, że mam playera w pamięci. Utwór PT3 chciałbym załadować od adresu np. 0x003000. Czy przy pomocy twojego projektu mógłbym ładować utwór? Czy istnieje możliwość odczytania skróconej listy aby np. wypełnić nazwami utworów tabelkę wyboru?
Reply Cool? Ranking DIY | New topic
Notify about new articles
Popular Topics