On 06/11/2023 16:02, J.F wrote:
>>> A w czym jest gorszy Z80 od x86 czy ARM?
>> Niczym, jesli wszystko co masz, to program napisany w asm przez
>> brodatego embedowca. Wtedy najzwyczajniej, nie masz wyboru.
> Jak chcesz miec ethernet, internet, wyswietlacz graficzny,
> usb, karty pamieci, bzy danych czy dostęp do nich - to duzo gorszyc.

Z przygód kolegi pracującego w firmie robiącej sterowanie: jesli chcesz
mieć *jakąkolwiek* zmianę, to soft nadaje się do przepisnia od nowa, tym
bardziej, że autor poprzedniej wersji właśnie łowi ryby na emeryturze.

Systemy oparte o Z80 to guano pisane niskopoziomowo. Ich się nie
rozwija, tylko łata. I tylko przez chwilę, zanim się rozlecą. To samo z
8051. Dodanie tutaj C niewiele pomaga, bo ludzie piszą w nim jak w
asemblerze, często nieprzenośnie.

>> Jam masz kod napisany w czymś przenośnym, to Z80 jest gorszy we wszystkim.
>> Ale zazwyczaj nie masz.
>> To jest np. powód, dla którego współczesne telefony dalej mają jakiegoś
>> kolna 8051 do obsługi GSM. Za dużo asemblera powoduje uzależnienie.
> Mówisz?
> Technologia sie rozwija, trzeba stale i program unowoczesniac.

O najszybszej furmance świata nie słyszałeś?

https://mlodytechnik.pl/news/10647-najszybszy-proces
or-na-swiecie-z-bytomia

Agrumentacja, nie pamiętam już gdzie zasłyszana, ale chyba od pracownika
firmy, była taka, że "8051 ciągle jest używane w modemach gsm".

Czyli, jesli czytać między wierszami, jakośc tego kodu jest poniżej
wszelkich metryk, skoro go jeszcze nie przepisali na cokolwiek innego.
Najwidocznie nie da się przepisać, bo sieczkę można co najwyżej
zaemulować albo dokładać gigazhertzów.

Innymi słowy, doczekałem czasów, kiedy hardware łata dziadowski
software. Nie, żeby nie było też czasem i w drugą stronę.

>>>> Mała uwaga: prawie wszystkie wyświetlacze z hcync wcale nie musiały by
>>>> go mieć. Wszak po wsadzeniu x bitów do rejestru mógłby on automatycznie
>>>> zmienić wiersz.
>>> Ale wtedy byłaby sztywna liczba pixeli w linii.
>> A są jakieś wyświetlacze z elastyczną ilościa pixeli w lini?
> Wyswietlacze to moze nie, ale narobiło się, ze obslugujemy różne
> formaty. i "wyswietlacz"/monitor/"ekran" sobie przetwarza..

To nie wyjasnia obecniści HSYNC we współczesnych wyświetlaczach, bo
problem rozmiaru jest w takim protokole wyłacznie softwareowy. A jednak
produkuje się je na potęgę.

>>> Po co DVI ma blanking periods?
>> Bo koszt zmiany myslenia, szczególnie w komitetach za zielonym suknem,
>> jest czasami równy zastępowalności pokoleniowej. Tu masz odpowiedź, po
>> co komu iface do LCD przypomianający jak żywo CRT.
> No ale DVI było troche uniwersalne. Analogowy sygnał też gdzieś tam
> był.

I kto mu bronił być i być generowany innym elementam hardware, innym
sterowaniem i w ogóle wszystkim innym?

DVI to taka hybryda, gdzie wartości analogowe zamieniono na cyfrowe, ale
"zapomniano" o całej masie innych zbędnych elementów.

To się tylko wyjaśnić brodaczami za zielonym suknem, zmiana myślenia
jest możliwa wyłacznie na poziomie zastepowalności pokoleń.

Jak już masz to wejscie cyfrowe i LCD, to po ch... komu blanking? ba, ja
bym się nawet zastanowiło po co komu wyścig z VSYNC. Taki iface powinien
na spokojnie przyjąc piksel na sekundę, jesli trzeba.

> Ale to jak rozumiem dlatego, ze sterownik wyswietlacza ma sprzetowy
> dekoder MPEG i pomocniczy kanał OSD. Pomocniczy, wiec może być
> powolny. Szczególnie, jak komus sie nie chce zrobic w assemblerze,
> tylko wyciąga jakąs ambitną bibliotekę graficzną :-)

I nikomu, poza mna, nie przeszkadzało. Lduzie mają naprawdę prymitywne
potrzeby.

>> Tym bardziej operatorowi tokarki.
> No to w czym problem ? Wszyscy sa zadowoleni.

W niczym. Taka moja konkluzja. Bez znaczenia jak żałosne i prymitywne
GUI dostarczasz. Przeciętny suweren nie jest w stanie odróznić dobrego
od złego. Nie ma potrzeby sterowania wyświetlaczem dla tokarza, czy
Krystyny @50Hz. Nie zauważą róznicy.