Jakie biblioteki C (AVR) wybrać do zapisu danych na karcie SD z Atmega32?

Kowalski miał wtedy ZX-Spectrum i Commodore C64. I był szczęśliwy,
że ma kontakt z nowoczesną techniką.
Nie, miał w tamtych czasach rownież Amigę.>85 rok.
A wcześniej ZX-81 albo ZX-80. Kontynuacja. Świat nie stoi w miejscu.

Czyli ręcznie zarządzając heapem, pieprząc się z segmentacją itp.
Jasne, bez "ręcznego zarządzania heapem" nie da się nawet pętli napisać.

Kilka razy mi się zdarzyła konieczność dopisania paru linijek kodu, bo
zmienna nie mogła być większa niż 64kB.

Jakoś nigdy mnie specjalnie nie interesowało, w którym rejestrze CPU
trzyma dane gdy mi liczy pętle.

W zasadzie zdecydowana większośc komputerów desktopowych na swiecie
przeraźliwie nudzi sie.
Ale mówimy o, z grubsza, roku 1981.

To wtedy nie liczyli na komputerach tylko kopiowali z lewa na prawą?

Mówimy o latach >85. Dopiero wtedy pojawiły się pierwsze desktopy dla
Kowalskich z wielozadaniowym GUI. Wcześniej nie było nic godnego uwagi
w tym temacie.

Wszystkie te komputery też cierpiały z powodu wolnego hardware.
Cierpieli(by) również ich użytkownicy. Nie wszyscy tak lubią.
Oczywicie niektórzy wolą niebieskie tło i kopiowanie plików,
to zrozumiałe.
Jeśli mają nie cierpiące zwłoki zadania, to wolą.

... odkrywać na nowo zarządzanie heapem, borykać się z segmentacją,
zastanawiać jaką pamięć dzisiaj użyć i tym podobne drobnostki
pozwalające natychmiast zająć się nie cierpiącym zwłoki zadaniem.

Nie, rozsadni ludzie parli na wytworzenie technologii które
pozwalały pracowac komfortowo w trybach graficznych.
Jak parli?

Kupując komputery przyjazne dla ludzi.

Oflagowali się i palili opony przed urzędem d/s trybów graficznych?
Czy może pod zarządem którejś z firm od komputerów? Nie mieli swojej
roboty, że mieli na to czas?

Wiele firm doskonale wiedziało że jesli chce sprzedawać swój soft
przeciętnemu kowalskiemu to *musi* on być wygodny.

Oni wiedzieli że prędzej czy później pokolenie zwoenników CP/M po prostu
zakopią w piach. Co prawda paru niedobitków zostało, ale już nie długo.
A są w ogóle tacy? Nie wiedziałem.

Do dzisiaj można w necie spotkać pokemonów (potrafie to słowo uzasadnić)
którzy przespali lata 80 kopiując pliki pod Nortonem pieszcząc ten swój
"profesjonalizm" do granic możliwości.

Jak ktoś ma peceta z lat 80 do sterowania obrabiarką to może mieć wesoło
kupując teraz PC. Ani jednego złacza ISA. Zaryzykuje więc że to żadna
róznica bo i tak jest w czarnej dupie i bez dużej kasy może być poważny
kłopot.

Kilka lat temu kupowałem PC z ISA, jakieś 486 chyba.

Ze złomu? Ktoś produkuje chipsety i procesory? Nie boisz się 20 letnim
leżakom magazynowym dawać do ręki obrabiarki?

Jasne, bez "ręcznego zarządzania heapem" można napisać *wyłącznie* pętlę.

A bez Amigi można *wyłącznie* kopiować z lewej na prawą i z prawej na
lewą.

Zainteresuj się dodatkowo ile linijek kodu musiał dopisac kompilator
żeby niewidoczne problemy z segmentacją były rozwiązane w tle runtime.
Na ten przykład niech poleci normalizacja wskaźników. Rzecz nie
spotykana poza x86.

Dlaczego mam się tym interesować?

Po to mam kompilator, bym nie musiał
grzebać w kodzie procesora.

Skompilował, nie zużył więcej pamięci niż
trzeba, więc na miskę elektronów zasłużył.

W praktyce to ta szybkość zależy bardziej od piszącego program (żeby
użył odpowiedniego algorytmu) niż od optymalizacji kodu mikroprocesora.

A w teorii zwiększanie liczby rejestrów (liczby niewielkiej, skończonej,
rosnącej liniowo) nie może być receptą na złożoność algorytmów.

na nowo. Programy pracujące w CP/M robiły dokładnie to - wynajdywały na
nowo: heap, gui, multitasking, user input, itd.
Jeśli tym kołowynajdującym programem jest kompilator

, jeśli są tam równe
szprychy i obręcz gładka, to mnie ta sytuacja odpowiada. Gdy chcę liczyć.

Bo profesjonaliści interesują się takimi rzeczami.
Profesjonaliści od kompilatorów i problemów z segmentacją. Nie każdy
nim jest.

W praktyce kończą się optymalizacje wysokopoziomowe i pozostaje zejście
do kodu. Mozna ugrać sporo bo kompilatory nie sa perfekcyjne, a wtedy
tym bardziej nie były.
Nie wiem jaka była praktyka liczenia na Amidze

Nadmiarowy kod obsługujący segmentację i swapowanie rejestrów jest
zbedny gdyby procesor nie był projektowany przez merketoidów.
A niech sobie maleństwo swapuje, co mi tam.

To wtedy nie liczyli na komputerach tylko kopiowali z lewa na prawą?
Z kopiowaniem musieli poczekać na Petera Nortona. Więc liczyli. Liczący
komputer nie nudzi się.

Strasznie wąski zakres zastosowań, znaczy się ...

IBM/PC nie był projektowany z myślą o zastosowaniach kowalskich.
Kowalski miał wtedy ZX-Spectrum i Commodore C64. I był szczęśliwy,
że ma kontakt z nowoczesną techniką.

Nie, miał w tamtych czasach rownież Amigę. >85 rok.

A to nie byla zabawka jesli chodzi o OS.

OS był boski w porównaniu z resztą świata a tym bardziej blaszanym
pudłem z procesorem ze średniowiecza i CP/M.

... odkrywać na nowo zarządzanie heapem, borykać się z segmentacją,
zastanawiać jaką pamięć dzisiaj użyć i tym podobne drobnostki
pozwalające natychmiast zająć się nie cierpiącym zwłoki zadaniem.
...przekształcając macierze w Fortranie, licząc korelacje w Basicu,
wyliszając wartości funkcji w C. Czasem pisząc jakiś artykuł.

Czyli ręcznie zarządzając heapem, pieprząc się z segmentacją itp.

Pozazdrościć architektury i OS. I tego że do końca obliczeni nie sposób
było nawet napisać abstraktu artykulu ...

Kowalski miał wtedy ZX-Spectrum i Commodore C64. I był szczęśliwy,
że ma kontakt z nowoczesną techniką.
Nie, miał w tamtych czasach rownież Amigę.>85 rok.
A wcześniej ZX-81 albo ZX-80. Kontynuacja. Świat nie stoi w miejscu.

Za wyjątkiem MS-DOSa. Tylko cyferki się zmieniały. Choć oczywiście nie,
dodali przecież BASICa.

Czyli ręcznie zarządzając heapem, pieprząc się z segmentacją itp.
Jasne, bez "ręcznego zarządzania heapem" nie da się nawet pętli napisać.

Zauważalna częśc programów nie składa się *wylacznie* z pętli.

Kilka razy mi się zdarzyła konieczność dopisania paru linijek kodu, bo
zmienna nie mogła być większa niż 64kB.

Zainteresuj się dodatkowo ile linijek kodu musiał dopisac kompilator
żeby niewidoczne problemy z segmentacją były rozwiązane w tle runtime.
Na ten przykład niech poleci normalizacja wskaźników. Rzecz nie
spotykana poza x86.

Jakoś nigdy mnie specjalnie nie interesowało, w którym rejestrze
CPU trzyma dane gdy mi liczy pętle.

Jesli liczysz to zapewne zalezy Ci na szybkości. Jeśli zalezy Ci
na szybkosci to poniżej pewnego progu optymalizacji zaczyna być
interesujące w jakim rejestrze co jest i dlaczego tych rejestrów
jest tak mało.

Jasne, bez "ręcznego zarządzania heapem" można napisać *wyłącznie* pętlę.
Nie. Bez zarzadzania systemowego nalezy za kazdym razem wynajdywać koło
na nowo. Programy pracujące w CP/M robiły dokładnie to - wynajdywały na
nowo: heap, gui, multitasking, user input, itd.

Zainteresuj się dodatkowo ile linijek kodu musiał dopisac kompilator
żeby niewidoczne problemy z segmentacją były rozwiązane w tle runtime.
Na ten przykład niech poleci normalizacja wskaźników. Rzecz nie
spotykana poza x86.
Dlaczego mam się tym interesować?

Bo profesjonaliści interesują się takimi rzeczami.

Po to mam kompilator, bym nie musiał grzebać w kodzie procesora.

Jesli *liczysz* to musisz mieć świadomość wielu rzeczy. W tym jaki kod
jest generowany. Przykro mi, ale musisz wiedzieć czy lepiej użyć float
czy double i czy w ogóle są szybsze od fixed-point.

Skompilował, nie zużył więcej pamięci niż trzeba, więc na miskę
elektronów zasłużył.

Pomijasz dużo innych aspektów.

W praktyce to ta szybkość zależy bardziej od piszącego program (żeby
użył odpowiedniego algorytmu) niż od optymalizacji kodu mikroprocesora.

W praktyce kończą się optymalizacje wysokopoziomowe i pozostaje zejście
do kodu. Mozna ugrać sporo bo kompilatory nie sa perfekcyjne, a wtedy
tym bardziej nie były.

A w teorii zwiększanie liczby rejestrów (liczby niewielkiej, skończonej,
rosnącej liniowo) nie może być receptą na złożoność algorytmów.

Nadmiarowy kod obsługujący segmentację i swapowanie rejestrów jest
zbedny gdyby procesor nie był projektowany przez merketoidów.

Programy pracujące w CP/M robiły dokładnie to - wynajdywały na
nowo: heap, gui, multitasking, user input, itd.
Jeśli tym kołowynajdującym programem jest kompilator

Nie jest.

jeśli są tam równe szprychy i obręcz gładka, to mnie ta sytuacja
odpowiada. Gdy chcę liczyć.

Nie wszyscy chcą liczyć. Niektórzy chcą rysować, drukować, pisać.

Bo profesjonaliści interesują się takimi rzeczami.
Profesjonaliści od kompilatorów i problemów z segmentacją.
Nie każdy nim jest.

Więc nie każdy powinien programować. Nawet zwykłe liczenie.

Nie wiem jaka była praktyka liczenia na Amidze

Optymalizacje sa wszędzie takie same w sensie ich istoty. Zawsze masz
taki etap że albo już olewasz albo musisz zejśc do kodu. W przypadku x86
musiałes się wtedy babrać w gównie.

UWAGA!

Ponieważ wątek zaczyna mi wychodzić poza kolumnę w thunderbiridzie
niniejszym dokonuje EOT z mojej strony. Gadajcie sobie dalej

Pan Marcin Wasilewski napisał:

Ile on właściwie potrafił pokazać pikseli? (Macintosh miał
512x324 na 9 calach, brr...).

W zasadzie 640x512 z interlacem, bo tak był przecież kreślony
sygnał PAL.

Jaką rolę w tym zdaniu pełni słowo "przecież"? Przecież mówimy
o komputerze, a nie o magnetowidzie czy innym sprzęcie telewizyjnym.
I to o tak zdefiniowanym komputerze, że ZX-Spectrum się nie łapie.

Jak już zadałem pytanie, to coś mnie podkusiło i spróbowałem samemu
się dowiedzieć jak jest z tą grafiką Amigi. Wszędzie w opisach pomija
się podanie liczby pikseli, jest zwykle tylko coś o "full-scren geaphics"
i o liczbie kolorów (jakby to miało znaczenie, czy będę próbował
zmusić telewizor do pokazania tysiąca kolorów, czy miliona). To jest
wstydliwy temat, od razu widać. Dlaczego nikt mi tu wcześniej nie
powiedział, że ten sprzęt w ogóle nie miał ambicji wyświetlania czegoś
na normalnych monitorach?

Wygląda to tak, jakby producent nastawił się na odbiorców związanych
z rynkiem wideo. Ten rynek się naonczas szybko rozwijał, jak ktoś miał
pomysł i parę groszy oszczędności, mógł na nim zaistnieć. Dla takich
ten komputer mógł być skarbem.

W czasach Amigi 1200 wszystko się trochę skomplikowało, bo
i rozdzielczości były wyższe i monitor SVGA dało się podłączyć.

Doczytałem też o jakichś hackerskich sztuczkach przy podłączaniu
monitora VGA -- programowa zmiana czegoś w komputerze, by wytworzyć
sygnał zbliżony do VGA (czyli o wyższej częstotliwości odświeżania
i większej rozdzielczości). Najbadziej zdumiało mnie uzasadnienie
tej sztuczki -- żeby mieć możliwość skorzystania z *tańszych*
monitorów (VGA) w miejsce oryginalnego sprzętu (PAL), który miał
już cenę rzadkiego zabytku techniki.

A jeśli chodzi o edytory tekstu, to zaufaj, że potrafił.

Niestety, w tym momencie moje zaufanie sie skończyło. Edytowanie tekstów
na ekranie telewizora z odświeżaniem 50 Hz w przeplocie, w dodatku
w okienkach -- nie, nie, nie... Sam bym tego nie wymyślił. Brr...

No popatrz topowa wtedy VGA miala odswierzanie 60 Hz. Czyli tyle samo co

No właśnie, nikt rozsądny nie traktował poważnie możliwości pracy z tymi
rozdzielczościami w środowisku graficznym z okienkami. A w przypadku
Amigi było to (zdaje się) koniecznością.

Większość programów (a edytory tekstu to chyba wszystkie) pozwalały
przejść w tryb pełnoekranowy.
Ale wciąż realizowany w trybie graficznym, z jasnym migoczącym tłem.

A jeśli chodzi o edytory tekstu, to zaufaj, że potrafił.

Niestety, w tym momencie moje zaufanie sie skończyło. Edytowanie tekstów
na ekranie telewizora z odświeżaniem 50 Hz w przeplocie, w dodatku
w okienkach -- nie, nie, nie... Sam bym tego nie wymyślił. Brr...

No popatrz topowa wtedy VGA miala odswierzanie 60 Hz. Czyli tyle samo co
Amiga w NTSC.

Inne karty z tego okresu tez wygladaja blado:

Hercules 720x350 50 Hz
CGA 640x200 60 Hz
EGA 640x350 60 Hz
VGA 640x480 60 Hz

O ilosci kolorow w stosunku do Amigi przez grzecznosc nie wspomne.

Taki byl wtedy standart i gotow jestem sie zgodzic iz tryb tekstowy byl
bywal wygodniejszy. Ale jesli chodzi o mulitasking - to bez przesady.

W latach osiemdziesiątych widziałem taką, że w graficznym, gdy monitor
był "zasilany" danymi wprost z pamięci RAM układu graficznego, to nie
mógł uzyskać odpowiedniej ostrości. Zwłaszcza jeśli po drodze był
jeszcze przetwornik D/A.

A tu proszę -- od razu tysiące czy miliony kolorów, a tylko rok później.
Innowatorzy, mistrzowie świata. Ale ponieważ to i tak sie gdzieś gubiło
po drodze w torze analogowym marnego monitora czy telewizora, więc nikt
nie zauważył.

No właśnie, nikt rozsądny nie traktował poważnie możliwości pracy z tymi
rozdzielczościami w środowisku graficznym z okienkami. A w przypadku
Amigi było to (zdaje się) koniecznością.

Typowa rozdzielczość pracy na Amidze na monitorach PAL wynosiła
640x256 i pracowało się w niej naprawdę spoko.

Większość programów (a edytory tekstu to chyba wszystkie) pozwalały
przejść w tryb pełnoekranowy.

640x512 mało kto używał poza zastosowaniami dot. obróbki grafiki,
gdyż z powodu interlace-u trzeba było mieć albo dobry monitor, albo
flicker-fixer, który był montowany seryjnie bodajże w Amidze 3000.

Tylko zapominasz, że w czasach Amigi 1200/4000 (być może nawet w A500+)
bez problemu można było pracować na monitorach VGA i jedyne co było do
tego potrzebne to przejściówka na wtyk VGA

(być może były tam jakieś bramki, czy rezystory) ale pamiętam, że
zrobienie tego zajmowało 15 minut i nie był to jakiś high-tech.

Większość programów (a edytory tekstu to chyba wszystkie) pozwalały
przejść w tryb pełnoekranowy.
Ale wciąż realizowany w trybie graficznym, z jasnym migoczącym tłem.

LOL. Tło to sobie mogłeś i czarne zrobić. Co ma piernik do wiatraka?
Albo raczej jaką widzisz różnicę między trybem graficznym, a tekstowym?