25.09.2013 10:41
[#38]
Re: fdcemu
@glichtanski, post #37
No nijak by nie patrzył jest to tylko płyta prototypowa.
I na dodatek mam problemy z kartą sd. Tak się złożyło, że nigdy nie miałem potrzeby współpracować z kartą SD.
I powiem krótko " co za niewdzięczna bestia", koniecznym staje się bufor najlepiej na całą ścieżkę.
Która notabene zajmuje około 15kB, wydłubałem jakieś kości z pamięci cache dla 486 ale tam jest 16bit adres i 8 dane.
Trzeba to multipleksować bo skąd wezmę tyle końcówek z obudowy dip40 mikrokontrolera.
Ech szkoda że od razu nie zabrałem się za pamięć CF nie potrzebował bym pamięci cache.
Bajt w CF mogę sobie odebrać w praktycznie dowolnym momencie.
I na dodatek mam problemy z kartą sd. Tak się złożyło, że nigdy nie miałem potrzeby współpracować z kartą SD.
I powiem krótko " co za niewdzięczna bestia", koniecznym staje się bufor najlepiej na całą ścieżkę.
Która notabene zajmuje około 15kB, wydłubałem jakieś kości z pamięci cache dla 486 ale tam jest 16bit adres i 8 dane.
Trzeba to multipleksować bo skąd wezmę tyle końcówek z obudowy dip40 mikrokontrolera.
Ech szkoda że od razu nie zabrałem się za pamięć CF nie potrzebował bym pamięci cache.
Bajt w CF mogę sobie odebrać w praktycznie dowolnym momencie.
25.09.2013 10:48
[#39]
Re: fdcemu
@Tom3k, post #33
Wiesz, mnie historia amigi średnio interesuje - może zainteresować historyków a ja humanistą nie jestem. Mnie projekt Kamikadze interesuje z czysto technicznego punktu widzenia. Jeśli ktoś buduje interfejs FDD to znaczy, że o Amidze (technicznie) wie wystarczająco dużo. Wiedza historyczna może tylko zaszkodzić, że znowu przywołam przykład Majsta - to że wszyscy wkoło twierdzą, że coś nie ma sensu, będzie za drogie czy nie da się zrobić (bo nikt tego nie próbował) nie oznacza, że się nie da.
I akurat w sprawie niekompatybilności flopów nie ma co dyskutować bo były niekompatybilne. OK, Amigowy był komaptybilny z pecetowym a pecetowy z amigowym nie, ale to nic nie zmienia bo przenoszenie danych i tak było upierdliwe - na Amidze dało się nagrać 720kB czytelne dla PC, na PC nie dało się nagrać amigowej gry tak, żeby od strzału się na Amidze uruchomiła ani odczytać amigowej dyskietki 880kB. Na PC królowały napędy 1,44 (nie oszukujmy się - 720kB był równie rzadko spotykany jak HD lub 5,25" na Amidze, ewolucja napędów w PC przebiegała mniej więcej tak: 360kB->1,2MB->1,44MB) a na amigowym "rzadkim" flopie najbardziej popularnej pecetowej dyskietki 1,44 już odczytać się nie dało (amigowy napęd HD był cholernie drogi). To że jest Catweasel tak naprawdę niczego nie zmienia bo to po pierwsze w miarę świeży projekt i w XX wieku niczego podobnego nie było a po drugie flopy nieuchronnie odchodzą/odeszły do lamusa. O ile płyty główne, karty pamięci, turbo jeszcze długo pożyją to dyskietki niestety zdychają. Ostatnio zrobiłem porządek we flopach i 30% poszło do śmieci. Za parę lat dyskietka formatująca się bez badów będzie warta swojej wagi w złocie ;)
A do Kamikadze - czy będziesz kombinował, żeby ten interfejs obsługiwał bezpośrednio ADF/DMS? To byłoby idealne rozwiązanie, z pewnością wolałbym to od HxC, który wymaga konwersji obrazów.
I akurat w sprawie niekompatybilności flopów nie ma co dyskutować bo były niekompatybilne. OK, Amigowy był komaptybilny z pecetowym a pecetowy z amigowym nie, ale to nic nie zmienia bo przenoszenie danych i tak było upierdliwe - na Amidze dało się nagrać 720kB czytelne dla PC, na PC nie dało się nagrać amigowej gry tak, żeby od strzału się na Amidze uruchomiła ani odczytać amigowej dyskietki 880kB. Na PC królowały napędy 1,44 (nie oszukujmy się - 720kB był równie rzadko spotykany jak HD lub 5,25" na Amidze, ewolucja napędów w PC przebiegała mniej więcej tak: 360kB->1,2MB->1,44MB) a na amigowym "rzadkim" flopie najbardziej popularnej pecetowej dyskietki 1,44 już odczytać się nie dało (amigowy napęd HD był cholernie drogi). To że jest Catweasel tak naprawdę niczego nie zmienia bo to po pierwsze w miarę świeży projekt i w XX wieku niczego podobnego nie było a po drugie flopy nieuchronnie odchodzą/odeszły do lamusa. O ile płyty główne, karty pamięci, turbo jeszcze długo pożyją to dyskietki niestety zdychają. Ostatnio zrobiłem porządek we flopach i 30% poszło do śmieci. Za parę lat dyskietka formatująca się bez badów będzie warta swojej wagi w złocie ;)
A do Kamikadze - czy będziesz kombinował, żeby ten interfejs obsługiwał bezpośrednio ADF/DMS? To byłoby idealne rozwiązanie, z pewnością wolałbym to od HxC, który wymaga konwersji obrazów.
25.09.2013 11:08
[#40]
Re: fdcemu
@Jenot, post #39
Nie wiem czy będę kombinował z czystymi ADF.
Tak się składa, że HxC korzysta z programu który konwertuje ADF na pełny obraz zawartości dyskietki.
O ile mikrokontroler którego używam, posiada namiastkę koprocesora matematycznego, jednakże nie jest wstanie wyrobić się z wyliczeniem CRC.
Przerwa na pozycjonowanie głowicy też nie może trwać wiecznie.
Do takiego zadania musiał bym użyć, co najmniej mikrokontrolera z rdzeniem ARM.
Cała ścieżka musi być transmitowana bez przerwy, powoli bo powoli ale bez przerwy.
Dla tego HxC używa przetwarzania obrazu ADF na PC a nie w urządzeniu.
Tak się składa, że HxC korzysta z programu który konwertuje ADF na pełny obraz zawartości dyskietki.
O ile mikrokontroler którego używam, posiada namiastkę koprocesora matematycznego, jednakże nie jest wstanie wyrobić się z wyliczeniem CRC.
Przerwa na pozycjonowanie głowicy też nie może trwać wiecznie.
Do takiego zadania musiał bym użyć, co najmniej mikrokontrolera z rdzeniem ARM.
Cała ścieżka musi być transmitowana bez przerwy, powoli bo powoli ale bez przerwy.
Dla tego HxC używa przetwarzania obrazu ADF na PC a nie w urządzeniu.
25.09.2013 11:55
[#41]
Re: fdcemu
@Kamikadze, post #40
Jeszcze muszę sprostować sprawę z czystym ADF.
Istnieje pewna możliwość, dzięki elastyczności rozwiązania interfejsu FDD w amidze.
Jednakże wymaga to już uruchomionej amigi (Workbench) oraz dedykowanych sterowników.
Nie da się wystartować amigi z czystego ADF.
Cokolwiek się da, będę wiedział lepiej jak uruchomię swoją amigę i rozejrzę się po niej od środka.
Tak na sucho to sobie mogę gdybać.
Istnieje pewna możliwość, dzięki elastyczności rozwiązania interfejsu FDD w amidze.
Jednakże wymaga to już uruchomionej amigi (Workbench) oraz dedykowanych sterowników.
Nie da się wystartować amigi z czystego ADF.
Cokolwiek się da, będę wiedział lepiej jak uruchomię swoją amigę i rozejrzę się po niej od środka.
Tak na sucho to sobie mogę gdybać.
28.09.2013 11:17
[#50]
Re: fdcemu
@Kamikadze, post #48
Trzeba to multipleksować bo skąd wezmę tyle końcówek z obudowy dip40 mikrokontrolera
No tak wygląda standardowy równoległy SRAM. Chcesz inaczej? Oszczędniej? Szukaj SRAM szeregowego, [link=http://www.tme.eu/pl/katalog/polprzewodniki_112140/#id_category=112868&page=1&s_field=artykul&s_order=ASC]link[/link]
Trzeba jednak zdać sobie sprawę z "powolności" takiego rozwiązania.
Swoją drogą co to za mikrokontroler? Jeśli atmega to może warto zainwestować w atxmega z serii A (ebi, dma) - prawda, 3.3V ale masz sprzętowe SPI, które możesz wykorzystać do transferu danych z karty SD, do tego kontroler pamięci EBI gdzie jak w 8051 możesz mieć multipleksowane adresy więc używasz 8 linii na adresy, 8 linii na dane, 1 pin na ALE, 1 na RD/WR (i ewentualnie 1 na chip enable). 3 odpadają na SPI. Resztę możesz wykorzystać do interfejsu FDD. UStawisz sobie kanały DMA do transferu z karty do ram i vice versa (4 kanały) i procek może spokojnie dekodować to co w RAM i wysyłać do amigi, cała reszta jest sprzętowo zarządzana.
28.09.2013 12:15
[#51]
Re: fdcemu
@abcdef, post #50
To Pic18f4550 1spi/ic2 1uart, myślę nad tym by do obsługi SD wykorzystać cpld.
Wówczas będę otrzymywał dane kiedy zechcę i jak zechcę bez sram, pic ma wystarczająco pamięci na bufor. U mnie w sklepie koleś ma tanie cpld. Pomyślę nad tym. Cokolwiek mogę zrobić programowo to tylko w przerwach pomiędzy ustawianiem i zerowaniem wyjścia danych, daje to jakieś 110 cykli maszynowych. Problem w tym, że transmije mam na przerwaniach zrealizowaną. Przy karcie sd jest problem z przerwaniami, cpld będzie tanim rozwiązaniem i skutecznym.
Wówczas będę otrzymywał dane kiedy zechcę i jak zechcę bez sram, pic ma wystarczająco pamięci na bufor. U mnie w sklepie koleś ma tanie cpld. Pomyślę nad tym. Cokolwiek mogę zrobić programowo to tylko w przerwach pomiędzy ustawianiem i zerowaniem wyjścia danych, daje to jakieś 110 cykli maszynowych. Problem w tym, że transmije mam na przerwaniach zrealizowaną. Przy karcie sd jest problem z przerwaniami, cpld będzie tanim rozwiązaniem i skutecznym.
29.09.2013 00:14
[#53]
Re: fdcemu
@Malin, post #52
4X wolniej czego? Nie widzę za specjalnej różnicy między produktami Atmel i Microchip do każdego zastosowania coś się znajdzie, tak u jednych jak u drugich. Co mam to pcham. Co ci po 5% większej mocy obliczeniowej. jak peryferia masz taktowane niską częstotliwością. Atmegę w każdej chwili mogę kupić i jakoś nie lecę do sklepu. Bo mam kilka STM32 ale żeby z armaty do muchy walić. Core2DUO też leży. Hihi 
Mam nadzieję, że programy w asemblerze piszesz, skoro rozprawiasz o takich drobnych różnicach mocy obliczeniowej.
Mam nadzieję, że programy w asemblerze piszesz, skoro rozprawiasz o takich drobnych różnicach mocy obliczeniowej. 29.09.2013 01:16
[#54]
Re: fdcemu
@Kamikadze, post #53
4 a 1 cykl zegara na instrukcję to nie taka drobna różnica, na pewno nie 5%. Patrząc na te ceregiele z bankami to będzie lekko z 50% 
. SPI w avr jest taktowane CK/2, nie wiem jak w picu
Robiłem parę miesięcy temu aplikację z mcu taktowanym na 12MHz, z obsługą karty SD i fat32. 8-mio bitowy pic odpadłby w przedbiegach, atmega dała radę. 48MHz do tego to dopiero byłaby armata na muchę :D. Pisałem w asmie avr i trochę w picowym, ten drugi to jakaś katorga. Naprawdę nie rozumiem dlaczego komuś chce się babrać z tym szrotem, kombinowanie z programatorem wymagającym +13V i ten pokraczny asm. Jest na to w ogóle jakiś darmowy kompilator C? Wydaje mi się że jeszcze niedawno był z tym problem, nie wiem jak teraz. Nie wiem czy ktoś się odważył pisać w C na 12fxxx.
Cortex-M ładnie wygląda na papierze, cenowo też nieźle.
Ostatnia aktualizacja: 29.09.2013 01:24:32 przez Malin
. SPI w avr jest taktowane CK/2, nie wiem jak w picuRobiłem parę miesięcy temu aplikację z mcu taktowanym na 12MHz, z obsługą karty SD i fat32. 8-mio bitowy pic odpadłby w przedbiegach, atmega dała radę. 48MHz do tego to dopiero byłaby armata na muchę :D. Pisałem w asmie avr i trochę w picowym, ten drugi to jakaś katorga. Naprawdę nie rozumiem dlaczego komuś chce się babrać z tym szrotem, kombinowanie z programatorem wymagającym +13V i ten pokraczny asm. Jest na to w ogóle jakiś darmowy kompilator C? Wydaje mi się że jeszcze niedawno był z tym problem, nie wiem jak teraz. Nie wiem czy ktoś się odważył pisać w C na 12fxxx
.Cortex-M ładnie wygląda na papierze, cenowo też nieźle.
Ostatnia aktualizacja: 29.09.2013 01:24:32 przez Malin
29.09.2013 06:48
[#55]
Re: fdcemu
@Malin, post #54
Heh, co do kompilatora to kolega chyba o SDCC zapomniał ;) Jeśli chodzi o możliwości - owszem z tego samego powodu PICe mnie nie interesowały, ale przynajmniej tych 35 do 80 instrukcji łatwo się nauczyć. Jeśli chodzi o Cortexy to znowu mamy sytuację... 3.3V (Mega do 5V, Xmega też 3.3V), trochę inne podejście do GPIO. Wysokie taktowania (48MHz w standardzie na M0, 120 chyba na M3) i 32 bit architektura (więc ładowanie i modyfikowanie wordów czy integerów nie zabiera wielu cykli). Ale w PIC czy dsPIC jednak dużo projektów się robi więc czymś się tam muszą wyróżniać ;) U mnie w zakładzie PIC siedzi na płytce wyzwalacza modułu tyrystorowego, na karcie pomiarowej w testerze siedzi dsPIC, mega16 jest w wyświetlaczu vfd, mega2560 w driverze do modułów tyrystorowych, kupę 6800 (nie zjadłem zera) w innych urządzeniach, a nawet coldfire v2 na karcie komunikacyjnej. 89c51re2 w innym (ewentualnie 87c51rd2), jeszcze gdzie indziej STM32F207Z, są też Renesasy H8/30xx i H8S, a nawet 80188!!
Do czego zmierzam? Każdy procek ma swoje dobre strony i zasadniczo od projektanta i programisty zależy czy będzie spełniał dobrze swoje zadanie, a nie od ciągłych porównań z technicznymi danymi innych rodzin dostępnych na rynku. Jak komuś PIC pasuje, ma go w domu i nie widzi sensu kupować aktualnie czegoś innego to po co go zniechęcać? Zachęcić do czegoś innego owszem, ale zniechęcać do obecnego?
Do czego zmierzam? Każdy procek ma swoje dobre strony i zasadniczo od projektanta i programisty zależy czy będzie spełniał dobrze swoje zadanie, a nie od ciągłych porównań z technicznymi danymi innych rodzin dostępnych na rynku. Jak komuś PIC pasuje, ma go w domu i nie widzi sensu kupować aktualnie czegoś innego to po co go zniechęcać? Zachęcić do czegoś innego owszem, ale zniechęcać do obecnego?
29.09.2013 12:00
[#57]
Re: fdcemu
@abcdef, post #55
I masz race. Ale zawsze się znajdzie mądrala który porównuje najlepsze produkty jednej firmy do najgorszych drugiej. Ja osobiście mam gdzieś czy to pic, atmel, cortex, motorolla, czy intel. mam coś zrobić wybieram najodpowiedniejszy do zadania i go męczę. Kolejną ważną rzeczą jest dostępność, niektóre rzeczy wykonane przeze mnie to tylko, pomysł i realizacja. Ten wątek po to założyłem by uzyskać informacje na temat amigi. I co? Żadnych konkretnych informacji tylko jakieś bezsensowne pierdoły. - bo atmega lepsza - bo to - bo tamto. Gdybym widział jakieś konkretne walory w atmedze do wykonania danego zadania to była by atmega. Ale jest PIC i będzie PIC to co realizuje jest z palcem w d.... do wykonania na PIC18F4550 nie ważne czy fat16 czy fat32 bo już oba mam zaimplementowane. Problem w tym że nie chce mi się bawić z tą kartą SD ale muszę. Szukam jednak alternatywnych rozwiązań danego problemu. Da się to rozwiązać na pamięci spi, tylko leniwy jestem i chciał bym mieć dane podane na złotej tacy. Oczywiście nie jest to już moim priorytetem i potrwa trochę dłużej, gdyż mam już workbench. Nie mniej jednak jest to przydatna rzecz i co najważniejsze lubię taką zabawę, inni grają w szachy.
29.09.2013 12:23
[#59]
Re: fdcemu
@Papier79, post #56
Koto fajne jest, sporo wspomnień. 
Amigę 500 kupiłem po to by się bawić elektroniką i programowaniem.
Więc wiele rzeczy zrobię na amigę. Już fast ram wcisnąłem, kombinuje teraz z IDE.
Zastanawia mnie czy amiga 500 jest wstanie wykorzystać DMA czy programowo trzeba implementować.
Odciążyło by to leciwego 68000. Oczywiście DMA do fastu. Muszę się wgryźć w kickstart. Tam są odpowiedzi.
Amigę 500 kupiłem po to by się bawić elektroniką i programowaniem.
Więc wiele rzeczy zrobię na amigę. Już fast ram wcisnąłem, kombinuje teraz z IDE.
Zastanawia mnie czy amiga 500 jest wstanie wykorzystać DMA czy programowo trzeba implementować.
Odciążyło by to leciwego 68000. Oczywiście DMA do fastu. Muszę się wgryźć w kickstart. Tam są odpowiedzi.