Użytkownik drutkow1 napisał w wiadomości grup
dyskusyjnych:a7c16e11-3197-47e1-b6d4-c2df74954edd@go
oglegroups.com...
>Przesadzasz z tymi 64kB liniowej przestrzeni.

Nie przesadza.
Ten procesor zgrabnie adresuje obszary do 64KB, a powyzej robi sie
klopot.
Nie RAM - jakies spojne obszary danych.

Np obrazek. Dopoki ma ponizej 64KB - swietnie, mozna sobie adresowac
wszystko w jednym segmencie.
A jak 100KB - to zaraz trzeba normalizowac wskaznik, najpiej przy
kazdej okazji - i kod rosnie, i predkosc spada.

Edytor tekstu - poki tekst ma ponizej 64KB, to fajnie, ale jak
wiecej - znow zabawa.
Takie np wstawienie jednej literki, wyszukiwanie, czy kopiowanie kilku
linii ...

>Było jej w 8086/88 1024kB,

No, gora 640KB :-)
W pierwszych PC to nawet tylko 256KB, a ponoc opcjonalnie byla wersja
64KB.

I wtedy to mialo sens - taki lepszy CP/M.
Nie tak znow duzo lepszy, bo na znacznie lepszy to klienta i tak nie
bylo stac, a jednak duzo ograniczen ... nie znika, ale przynajmniej
sie powieksza.
Mozna np miec 128KB programu i 64KB danych i jeszcze troche na system
zostaje, wiec calosc chodzi znacznie szybciej niz 8-bit CP/M.

A potem pamiec potaniala i taki procek zaczal ciazyc.

>a w 286 doszło jeszcze 64kB bez 16 bajtów - stąd też bramka A20,
>która musiała zostać dodana, żeby mieć bug-compatibility z PC i XT.

Tak w ogole to 286 byl pomyslany jako ambitny procek, ze znacznie
wieksza pamiecia ... ale wtedy tym bardziej musialy byc dane w
segmentach po 64KB lub mniej.
Tryb praktycznie nieuzywany, bo stary DOS wiadomo - niekompatybilny,
ale Windows 3 juz go uzywalo.

>A że nie można było sobie adresować jednym rejestrem, tylko parą - no
>cóż w tym dziwnego, skoro rejestry były 16-bitowe?
>Najdurniejszym pomysłem było to, że strony były zrobione po 16B,
>zamiast po prostu po 64kB.
>Cóż poradzić, IBM padł ofiarą własnego sukcesu.

A to akurat mialbys problem.
Bo wyszukaj np slowo w tekscie, jesli pechowo jest ono na granicy
stron.

Albo wrzuc int32 na stos, jesli wskaznik akurat ma wartosc FFFE.
A nie - moze sztuczny problem, i tak mozemu wrzucac połówkami ... ale
nie, adres powrotu jednak 4 bajty ma.

Nawiasem mowiac - w trybie 286 niemal tak wlasnie bylo.

Niestety - przy malych obszarach danych 86 sobie radzil, przy
wiekszych ... nie ma jak to 32-bit procek (czy juz 64 bit ?:-)

A ze mowimy o komputerze uniwersalnym, z wieksza pamiecia ... 8086 to
za malo, 286 tez.

J.

do góry

On 28/02/2019 14:56, d...@w...pl wrote:
> Przesadzasz z tymi 64kB liniowej przestrzeni.
> Było jej w 8086/88 1024kB

Nie była liniowa. Była podzielona na okna po 64kB przemieszczane
rejestrami segmentowymi. Niewielikie usprawnienie względem Atari czy
Commodore które miały to zrobione w hardware. Atari obsługiwało 1MB po
kilku przeróbkach i kod wyglądał tylko troche bardziej strasznie niż x86.

> A że nie można było sobie adresować jednym rejestrem, tylko parą - no cóż w tym
dziwnego, skoro rejestry były 16-bitowe?

A kto im probił zrobić rejestry adresowe 20 bitowe? Reglamentacje mieli
w korpo? Jakoś 68k nie miał problemu z byciem 16 bitowym hardwareowo,
ale model programistyczny miał 32 bity.

> Najdurniejszym pomysłem było to, że strony były zrobione po 16B, zamiast po prostu
po 64kB.

Nic by to nie dało. Segmentacja bez względu na szerokość to idiotyzm w
czystej postaci.

do góry

On 28/02/2019 02:54, Marcin Debowski wrote:
> Mam/miałem w rodzinie 3 Macbooki i żaden inny laptop nie był tak trwały
> i tak solidnie wykonany.

Obejrzyj więc kanał Louisa Rossmanna na Youtubie. Koleś je naprawia
hurtowo. To co zobaczyłem świadczy o tym że rekrutują inżynierów wśród
bezdomnych w Bostonie. Pewnych błedów elektronikom się nie wybacza i
jakimś dziwnym trafem można je znaleźć w Apple właśnie. Świetny materiał
dlaczego nie należy kopiować rozwiązań Apple.

1) dziurawe klawiatury
2) ciągle z generacji na generacje te same błedy w zasilaniu gpu
3) padajace scalaki zupełnie bez powodu
4) wykruszające się kulki pod bga od lat
5) ciągnięcie high power zasilania o ułamek milimetra od danych
6) pierdyliar innych ...

do góry

On 28/02/2019 15:03, d...@w...pl wrote:
>> Nie o możliwości chodzi tylko o przeoczoną ścieżkę w latach 70-tych.
>> Gdyby Sinclair znał ten pomysł ZX spectrum nie miało by CPU z powodu
>> redukcji kosztów ...
> E tam, żadnej redukcji by nie było, miejsce przede wszystkim kosztuje, i od razu
większa obudowa, większe zasilanie, większe chłodzenie i tak w kółko.

Sinclair wsadził by to wszystko do ULA i miałbyś eprom, ram i ULA na
płytce. Całe szczęscie że na to nie wpadł :D

>> A ja nabieram coraz większej ochoty na zrobienie maszyny CP/M na płytce
>> uniwersalnej :D
> To może zamiast Z80 na początek 8085 - ma wbudowany port szeregowy, w sam raz do
podłączenia terminalu.

Ten procesor ma połaczone linie D i A. Nie ma sensu robić na tm
czegokolwiek.

do góry

On 28/02/2019 15:15, d...@w...pl wrote:
> O co chodzi z tym Bytomiem?

Czyżbyś przeoczył naszą dumę narodową:

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

Najszybsza furmanka świata.

> Zaś 8051 i Z80 powinny zostać - pozwolą wyłonić spośród dzieci neostrady takich, co
mają nieuszkodzone mózgi (jak już zaraza BASICowa minęła, to pojawiły się inne).

Nie, oba mają popieprzoną architekturę.

Zwróć uwagę że jedna z najlepszych książek o programowaniu
niskopoziomowym, "Uczta programistów", używa RISCa jak wzorcowej
architektury. Autor zapytany w którymś z wywiadów "dlaczego nie x86"
wybuchnął śmiechem. Nie dziwie mu się, ksiązka była by 2x dłuższa aby
omijać wszelkie debilizmy jakich jest tam od groma.

>> Sprawdzę też czy CMOSowa wersja zaiwania w Harlequinie. Wątpie, ale co
>> szkodzi sprawdzić.
> Może wystarczy inne układy wymienić na CMOSowe odpowiedniki.

Tam większosc scalakó to HC dlatego nie mówie nie, ale wątpie, tak
nazjwyczajniej, pesymistycznie ...

> A może ten Z80 to CMOS, ale z wyjściami kompatybilnymi z TTL - HCT to się nazywało?

Przyjdą to dopiero poniże się do przeczytanai datasheeta :D

do góry

On 27/02/2019 20:33, J.F. wrote:
> -Personal Plotter, $795, compatible z Apple, IBM, Osborne ... and most
> other personal computer.
>  Ciekawe jak  z CP/M ...

Osborne to CP/M.

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

> -Nevada Cobol, Fortran, Pilot, Edit ... na CP/M. ale nie na Spectrum
>  Mozliwosci uzyteczne mysle ze mocno ograniczone przez dostepny RAM.
>  Wlasnie zaliczyly przecene i Cobol np z $199.95 na $29.95 ...
>  klienci przestali kupowac, bo pecety jednak znacznie lepsze ?

Może Cobol stał się nagle znacznie gorszy skoro napisanie poprawnie
gramatycznie 1 linijki kodu zajmowało cały RAM ;)

>  P.S. "Apple CP/M" ... co za cholera ?

Prawie na pewno karty z Z80 wsadzane do Apple ][. Popularne ponoć na
tyle że powstało kilka tańszych klonów.

> -ploter Houston DMP-41 ... porzadny sprzet za jedyne 3 tys $, ale do
> jakich komputerow ?
>  Przeciez nie do Autocada na CP/M

Były jakieś przeznaczone do CADów, często z jakimś wypasionym tabletem
graficznym. Nie wiem na czym to banglało.

do góry

On 2019-02-28, Sebastian Biały <h...@p...onet.pl> wrote:
> On 28/02/2019 02:54, Marcin Debowski wrote:
>> Mam/miałem w rodzinie 3 Macbooki i żaden inny laptop nie był tak trwały
>> i tak solidnie wykonany.
>
> Obejrzyj więc kanał Louisa Rossmanna na Youtubie. Koleś je naprawia
> hurtowo. To co zobaczyłem świadczy o tym że rekrutują inżynierów wśród

To jest masowa produkcja i związane z tym pewne świadome ryzyko
zarządzania produktem w tym jego wadami. Serio sądzisz, że inni nie mają
takich problemów? Wyłącznie w oparciu o własne doświadczenia mogę zrobic
podobną listę o Dellach, które zresztą uważam generalnie za dobre
maszyny.

A akurat Apple od czasu swojej ajfonowej ekspansji jest na cenzurowanym
i jakby było jak sugeruesz, czyli długie kolejki do serwisów, to by
wszystko huczało i po paru latach nikt by tego nie kupował. Dodatkowo w
przypadku maków te linie produktów są dość konserwatywne i w
gadzeciarstwie i w nowinkach (w porównaniu z takimi np. ajfonami), a
jeszcze dochodzi fakt, że to nie łindows (chyba, że zainstalujesz sam).
I teraz się okazuje, że ludzie kupują aby wyłacznie dicking around, w
tym do pracy :)

Masz jakieś osobiste doświadczenia z tymi maszynami?

--
Marcin

do góry

Dnia Thu, 28 Feb 2019 22:30:53 +0100, Sebastian Biały napisał(a):
> On 27/02/2019 20:33, J.F. wrote:
>> -Personal Plotter, $795, compatible z Apple, IBM, Osborne ... and most
>> other personal computer.
>>  Ciekawe jak  z CP/M ...
> Osborne to CP/M.
> https://www.youtube.com/watch?v=h6PUWZ0FOZM

Hm, to czemu nie napisali "CP/M" ?
No chyba ze napisali - "most other" ...

Interfejs ? RS-232 ?

>> -Nevada Cobol, Fortran, Pilot, Edit ... na CP/M. ale nie na Spectrum
>>  Mozliwosci uzyteczne mysle ze mocno ograniczone przez dostepny RAM.
>>  Wlasnie zaliczyly przecene i Cobol np z $199.95 na $29.95 ...
>>  klienci przestali kupowac, bo pecety jednak znacznie lepsze ?
>
> Może Cobol stał się nagle znacznie gorszy skoro napisanie poprawnie
> gramatycznie 1 linijki kodu zajmowało cały RAM ;)

- hm, nagle ? A wczesniej nie zajmowal ?

- powiedzialbym raczej, ze pamieci w systemach z CP/M przybylo, bo
wczesniej nie wszystkie musialy miec 64KB.

-obnizyli wszystkie produkty, Fortran tez ...

>> -ploter Houston DMP-41 ... porzadny sprzet za jedyne 3 tys $, ale do
>> jakich komputerow ?
>>  Przeciez nie do Autocada na CP/M
>
> Były jakieś przeznaczone do CADów, często z jakimś wypasionym tabletem
> graficznym. Nie wiem na czym to banglało.

Chyba na jakims unixie ...

hm ... sam AutoCad powstal w 1982 na CP/M
https://en.wikipedia.org/wiki/AutoCAD#History


https://en.wikipedia.org/wiki/History_of_CAD_softwar
e


J.

do góry

Dnia Thu, 28 Feb 2019 21:05:17 +0100, Sebastian Biały napisał(a):
> On 28/02/2019 14:56, d...@w...pl wrote:
>> Przesadzasz z tymi 64kB liniowej przestrzeni.
>> Było jej w 8086/88 1024kB
>
> Nie była liniowa. Była podzielona na okna po 64kB przemieszczane
> rejestrami segmentowymi. Niewielikie usprawnienie względem Atari czy
> Commodore które miały to zrobione w hardware. Atari obsługiwało 1MB po
> kilku przeróbkach i kod wyglądał tylko troche bardziej strasznie niż x86.

Bez przesady ... 1MB na 8 bit procesorze i stronnicowany 8 czy 4K ...
to musialo byc straszne :-)

>> A że nie można było sobie adresować jednym rejestrem, tylko parą - no cóż w tym
dziwnego, skoro rejestry były 16-bitowe?
>
> A kto im probił zrobić rejestry adresowe 20 bitowe? Reglamentacje mieli
> w korpo? Jakoś 68k nie miał problemu z byciem 16 bitowym hardwareowo,
> ale model programistyczny miał 32 bity.

te 16 bit to chyba tylko szyna zewnetrzna i multiplikator.
Reszta byla 32-bit.

20-bitowe rejestry bylyby raczej trudne w obsludze.

>> Najdurniejszym pomysłem było to, że strony były zrobione po 16B, zamiast po prostu
po 64kB.
> Nic by to nie dało. Segmentacja bez względu na szerokość to idiotyzm w
> czystej postaci.

No, tak w ogolnosci ma pare zalet.
Np. pozwala zmniejszyc fragmentacje przestrzenii adresowej.
Wyobraz sobie, ze uzywasz w programie kilku duzych tablic,
o zmiennym rozmiarze. Czyz nie byloby wygodnie, gdyby kazda z nich
byla w osobnym segmencie, adresowanym od zera ?

Czy np problem C i innych podobnych jezykowi i unixow/innych systemow.
Program ma swoj kod.
I wymaga pamieci danych, stosu na adresy powrotow i zmienne funkcji,
oraz sterty pamieci do alokacji.
Gdzie je ustawic, jesli wstepnie nie wiadomo ile tego stosu i sterty
trzeba ?

A do tego program uzywa kilku bibliotek, ktorych pewnie beda uzywac
tez inne programy/procesy.
Gdzie je zaladowac do pamieci, jesli procesor nie pozwala na kod w
pelni relokowalny ?

J.

do góry

On 01/03/2019 05:08, J.F. wrote:
>> Nie była liniowa. Była podzielona na okna po 64kB przemieszczane
>> rejestrami segmentowymi. Niewielikie usprawnienie względem Atari czy
>> Commodore które miały to zrobione w hardware. Atari obsługiwało 1MB po
>> kilku przeróbkach i kod wyglądał tylko troche bardziej strasznie niż x86.
> Bez przesady ... 1MB na 8 bit procesorze i stronnicowany 8 czy 4K ...
> to musialo byc straszne :-)

No było straszne na 8086. 8-bit procesor wsadzony w udawane 16 bitów z
adresacją prawie z Atari :D

Ultimate 1MB w Atari jest używane głównie przez demoscene, ale takie np.
Atari 130XE miało własnie przepinany dodatkowy RAM i było to niejako
wbudowane w hardware. Taka segmentacja, prawie jak w 8086 :D

>> A kto im probił zrobić rejestry adresowe 20 bitowe? Reglamentacje mieli
>> w korpo? Jakoś 68k nie miał problemu z byciem 16 bitowym hardwareowo,
>> ale model programistyczny miał 32 bity.
> te 16 bit to chyba tylko szyna zewnetrzna i multiplikator.
> Reszta byla 32-bit.

Model programistyczny był 32 i to się liczyło. Jak już zaczynać jakąś
architekturę to wydaje się że idiotyzmem jest to robić od 8 bitów a tu
się okazuje że Intel dał radę ...

> 20-bitowe rejestry bylyby raczej trudne w obsludze.

12 bitów na górze mogło by być fake. Nie widzę problemu.

>>> Najdurniejszym pomysłem było to, że strony były zrobione po 16B, zamiast po
prostu po 64kB.
>> Nic by to nie dało. Segmentacja bez względu na szerokość to idiotyzm w
>> czystej postaci.
> No, tak w ogolnosci ma pare zalet.
> Np. pozwala zmniejszyc fragmentacje przestrzenii adresowej.
> Wyobraz sobie, ze uzywasz w programie kilku duzych tablic,
> o zmiennym rozmiarze. Czyz nie byloby wygodnie, gdyby kazda z nich
> byla w osobnym segmencie, adresowanym od zera ?

Nie ponieważ powoduje to powstawanie dziur na końcach obszarów i nic nie
daje bo procesory od wieków potrafią indeksować od dowolnego adresu. No,
oczywiście poza 8086 który niewiele potrafi w temacie liniowego dostępu.

Innymi słowy segmentacja nie ma żadnej zalety. Ma za to absurdalny
overheat w kodzie i absurdalny wpływ na języki programowania takie jak
farptr i inne debilizmy wypływające w kodzie źrodłowym.

> Czy np problem C i innych podobnych jezykowi i unixow/innych systemow.
> Program ma swoj kod.
> I wymaga pamieci danych, stosu na adresy powrotow i zmienne funkcji,
> oraz sterty pamieci do alokacji.
> Gdzie je ustawic, jesli wstepnie nie wiadomo ile tego stosu i sterty
> trzeba ?

Segmentacja tego problemu nie rozwiąże, to jest fragmentacja typowa dla
nawet współczesnych procesorów tylko mniej bolesna z powodu warstwy
abstrakcji na pamięć. Jak mówie każdy procesor potrafi adresować
względnie, względem byleczego i liniowo. Poza 8086. 8086 jak zwykle
dzielnie rozwiązywał problemy niespotykane nigdzie indziej.

> A do tego program uzywa kilku bibliotek, ktorych pewnie beda uzywac
> tez inne programy/procesy.
> Gdzie je zaladowac do pamieci, jesli procesor nie pozwala na kod w
> pelni relokowalny ?

A czemu nie pozwala? Przypomne że 8086 to taki g... że aby napisać
program z fetchem względnym trzeba robić wygibasy rodem z hackingu aby
odczytać PC. Znowu walczymy z debilizmami architektury która
najzwyczajniej była jedną z najgorszych w historii informatyki. I
segmenty tego nie rozwiązują.

do góry