RTV forum PL | NewsGroups PL

CP/M i 64kB

NOWY TEMAT

elektroda NewsGroups Forum Index - Elektronika Polska - CP/M i 64kB

Goto page Previous  1, 2, 3, 4, 5, 6, 7, 8, 9

Sebastian Biały
Guest

Mon Mar 04, 2019 7:29 pm   



On 04/03/2019 09:02, Marek wrote:
Quote:
przypadek, bo coraz bardziej nawiedzeni. Są zabawni kiedy sprawadza
się ich ideologie do poziomu podłogi bądź pokazuje elementarne
problemy w logice.
Chętnie tak (w ramach dygresji) bym poczytał o tych ich problemach w
logice i w czym są zabawni.

W tym samym co wszystkie religie i ideologie. Jednak nie zamierzam o tym
rozmawiać na grupie technicznej bo to poniżające nawet jako dygresja.

Sebastian Biały
Guest

Mon Mar 04, 2019 7:41 pm   



On 03/03/2019 22:34, J.F. wrote:
Quote:
A jak mamy 1MB RAM, to znow znacznie latwiej sie to obrabia na 8086 w
malych kawalkach, niz na 6502 z dodatkowym stronnicowaniem.

I tu i tu musisz przestawiać segmenty. W przypadku 8086 masz tylko tą
zaletę że robisz to w cpu.

Quote:
O co innego chodzi. Masz np obrazek 24b/pixel.
Obliczasz adres trzech bajtow pixela w pamieci seg:offset,
i masz w trzech kolejnych bajtach dane. I nie zastanawiasz sie czy
przypadkiem drugi lub trzeci bajt nie leza na innej stronie, i trzeba
ja zmienic.

Zależy jaki duży masz ten obrazek. A jak nie wiesz jaki masz duży to i
tak musisz sprawdzać za każdym razem. Znowu dupa z tyłu.

Quote:
Albo np szukasz slowa w tekscie, i sie nie zastanawiasz czy
przypadkiem "owo" nie jest na nastepnej stronie.

Bo teksty z definicji nie przekraczają 64kB ...

Quote:
Oczywiscie, przy rozsadnym zalozeniu ze normalizujesz wskaznik np co
linie, a linia nie ma ponad 64KB.

Oczywiście przy założeniu że nie będzie padać a i wiać też nie będzie to
jakoś ta prowizorka wytrzyma ...

Quote:
Kompaktacja pamięci pojawił się dopiero w językach w których nie ma
pointerów (z popularnych Java C# i inne). Wiedza o tym że ktoś
przemieszcza mi pointery w programie musi istnieć, program musi być na
to gotowy.
Ale jak wychodzimy z CP/M i zaczynamy robic wielozadaniowy system
operacyjny, to problem wraca.

Jesli procesor ma MMU to nie wraca. Każdy proces ma własną przestrzeń
wirtualną i nic nie wie o innych allokacjach.

Jak nie ma MMU to problem co najwyżej nie jest procesu tylko procesów.
Tak jak w Amidze.

Quote:
Zadania przychodza, koncza sie ...

I pamięc się fragmentuje. Podobnie w ramach procesu allokacje
przychodza, odchodzą a pamiec w kawałkach. Sorry, taki mamy podstawowy
model programowania do dzisiaj.

Quote:
A jak? Żeby program nie wiedział i żebyś nie pomylił segmentacji z
translacją wirtualna->fizyczna MMU.
Bo program ma uzywac dla tej pamieci segmentu nr 3 np.

Para segment:offest to jest dokłądnie to samo co pointer. dokładnością
do kłopotów w relacjach. Nie ma tam nic "leszego" albo rozwiązującego
problemy lepiej niż liniowy adres. Nic. Dorabianie filozofii do tego
konceptu jest naprawdę bolesne dla logiki.

Quote:
Bo to problem segmentacji pamięci i jest obecy w każdej współczesnej
sytuacji kiedy nie ma kompaktacji pamięci. Segmenty nic nie zmieniają
ani nie ułatwiają.
Z segmentami (ale nie takimi jak w 86) by sie dalo.

Nie dało. Program musi wiedzieć że mu pamięc kompaktujesz i wskaźnik
jest iwalidowany. To się da zrobić i robią to niektóre maszyny wirtualne
specjalizowane do poganiania Javi i C# w embedded. Ale tam jezyki nie
mają pointerów.

Quote:
No wlasnie uzyc segmentow ... tylko w stylu 2/386.
Prosisz o duzo, to dostajesz dodatkowy nr segmentu,
a procesor ma gdzies tam zapisane gdzie sie segment zaczyna.

Mylisz segmentacje z wirtualizacją pamięci.

Quote:
Nawiasem mowiac - chcieli lepiej
https://en.wikipedia.org/wiki/Intel_iAPX_432

Nie było zgodne z CP/M i w dodatku potem okazało się że było na tyle
kiepsko zaprojektowane że nie było też wydajne.

Quote:
żąłosną architekturą było nawet to 386 z kilkoma specjalizowanymi
rejestrami, praktycznie zerową ortogonalnością itd itp.
Ta ortogonalnosc nie jest tak znow niezbedna.

Powiedz to kompilatorom. Obecnie tworzy się kod na procesor wirtualny z
masą rejestrów a nastepnie kolejna warstwa stara się to translować na
żałosną przestrzeń rejestrów x86. No, ale Turing-complete, więc o co chodzi.

Quote:
Nie musi tego wiedzieć, skoro podałeś adres to pod nim spodziewadz się
danych. Mówisz o offsecie. Ale nawet wtedy nie o to chodzi. Kod
relokowalny ma TAKIE SAME pointery jak nierelokowalny. Róznica jest
tylko w tym że KOD może być dowolnie umieszczony w RAM.
A tu jest kod i dane.
Np procedura rysowania znakow na ekranie, i dane z fontami.
Font moze byc dowolny, ale jest kilka predefiniowanych w bibliotece.

Ich dane są gdzieś załadowane fizycznie w pamięć. Kod obsługujący albo
ma na stałe offset i w gotowości relokator jak by trzeba było przenosić
albo jest całkowicie relokowalny.

kod x86 ma na tyle duży narzut na całkowitą relokowalność że szbciej
jest kod przerelokować automatycznie niż dodawać masę instrukcji
wydłubujących z żywego kodu PC.

Quote:
I całosc dynamicznie linkowana i nie wiadomo pod jakim adresem sie
znajdzie po załadowaniu.

I dlatego Windows 32 bit zazwyczaj DLLki relokuje po każdym załadowaniu.
Na Win 64 dllki mogą być już za darmo pisane względnie.

Guest

Mon Mar 04, 2019 10:56 pm   



użytkownik Sebastian Biały napisał:

Quote:
Jeszcze takie podumowanie przerażająco dobrej jakości Apple:

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

Think Different!



Dzięki Apple ma robotę, dzięki filmom ze słowami kluczowymi Apple/MacBok/IPhone
też tłucze kesz. Nadmiernie stęka na swojego pracodawcęSmile
OT. Apple chyba zrezygnowało z wykończenia pcb złotem na rzecz tańszego OSP
(selektywnie kładziony topnik czyli przemysłowe gówno zwiększające zawodność)

J.F.
Guest

Tue Mar 05, 2019 11:21 am   



Użytkownik "Sebastian Biały" napisał w wiadomości grup
dyskusyjnych:q5jrg8$8sq$1_at_node2.news.atman.pl...
On 03/03/2019 22:34, J.F. wrote:
Quote:
A jak mamy 1MB RAM, to znow znacznie latwiej sie to obrabia na 8086
w
malych kawalkach, niz na 6502 z dodatkowym stronnicowaniem.

I tu i tu musisz przestawiać segmenty. W przypadku 8086 masz tylko tą
zaletę że robisz to w cpu.

Mam te zalete, ze ten segment jest przesuwny i obejmuje prawie 64KB.

Quote:
O co innego chodzi. Masz np obrazek 24b/pixel.
Obliczasz adres trzech bajtow pixela w pamieci seg:offset,
i masz w trzech kolejnych bajtach dane. I nie zastanawiasz sie czy
przypadkiem drugi lub trzeci bajt nie leza na innej stronie, i
trzeba
ja zmienic.

Zależy jaki duży masz ten obrazek. A jak nie wiesz jaki masz duży to
i tak musisz sprawdzać za każdym razem. Znowu dupa z tyłu.

Nie sprawdzam - wyliczam adres pixela, jego trzy bajty sie w segmencie
zmieszcza.
Przy stronnicowaniu nie moge tego obiecac - musze sprawdzac przy
kazdym bajcie.

Moze nawet wystarczy adres dla poczatku linii policzyc, ale to juz
lepiej sprawdzic ... albo i nie, kto ma takie glupie obrazki, ten moze
miec klopoty :-)

Nawiasem mowiac - gdzies w TIFF jest "chunk size", ktos przewidzial,
ze moze byc dobrze podzielic obrazek na kawalki nie wieksze niz np
8KB.
I to nie tylko w 8086 sie sprawdza - np te "memory mapped" pliki w
unixie.

Quote:
Albo np szukasz slowa w tekscie, i sie nie zastanawiasz czy
przypadkiem "owo" nie jest na nastepnej stronie.
Bo teksty z definicji nie przekraczają 64kB ...

W CP/M byc moze, ale my tu o lepszym systemie :-)

Quote:
A jak? Żeby program nie wiedział i żebyś nie pomylił segmentacji z
translacją wirtualna->fizyczna MMU.
Bo program ma uzywac dla tej pamieci segmentu nr 3 np.

Para segment:offest to jest dokłądnie to samo co pointer.
dokładnością do kłopotów w relacjach. Nie ma tam nic "leszego" albo
rozwiązującego problemy lepiej niż liniowy adres. Nic. Dorabianie
filozofii do tego konceptu jest naprawdę bolesne dla logiki.

https://en.wikipedia.org/wiki/Memory_segmentation

I nie zaczyna sie od "8086 ..."

Quote:
Bo to problem segmentacji pamięci i jest obecy w każdej
współczesnej
sytuacji kiedy nie ma kompaktacji pamięci. Segmenty nic nie
zmieniają
ani nie ułatwiają.
Z segmentami (ale nie takimi jak w 86) by sie dalo.

Nie dało. Program musi wiedzieć że mu pamięc kompaktujesz i wskaźnik
jest iwalidowany.

Nie musi wiedziec, bo wskaznik sie nie zmienia.
3:1500 pozostaje, i tylko system wie, ze segment 3 jest teraz
polozony gdzie indziej.

Quote:
Nawiasem mowiac - chcieli lepiej
https://en.wikipedia.org/wiki/Intel_iAPX_432

Nie było zgodne z CP/M i w dodatku potem okazało się że było na tyle
kiepsko zaprojektowane że nie było też wydajne.

Ale przede wszystkim rynek nie chcial.
To co beda ulepszac :-)

Nawiasem mowiac - mimo niewatpliwych zalet, zobacz jak dlugo sie 68k
przebijala.
Za droga byla, czy zabraklo takiej lokomotywy jak IBM ... i CP/M?
Tego CP/M to bym nie przecenial, bo niedawno wystartowal, a pisanie np
kompilatora w assemblerze ... musialo byc ciekawe :-)

A moze jednak tak ogolnie 68k kiepska byla ?
Albo unix byl za malo "user friendly" i za drogi ?

Quote:
żąłosną architekturą było nawet to 386 z kilkoma specjalizowanymi
rejestrami, praktycznie zerową ortogonalnością itd itp.
Ta ortogonalnosc nie jest tak znow niezbedna.

Powiedz to kompilatorom. Obecnie tworzy się kod na procesor wirtualny
z masą rejestrów a nastepnie kolejna warstwa stara się to translować
na żałosną przestrzeń rejestrów x86. No, ale Turing-complete, więc o
co chodzi.

No i mowisz kompilatorom, one kompiluja, rezultat jest dobry i co cie
to wiecej obchodzi ?

A i tak nie wiadomo, czy tak trzeba, czy tworcy kompilatorow poszli w
takim kierunku, aby RISC obsluzyc.
Borland kompilowal bezposrednio na x86.

Quote:
Nie musi tego wiedzieć, skoro podałeś adres to pod nim spodziewadz
się
danych. Mówisz o offsecie. Ale nawet wtedy nie o to chodzi. Kod
relokowalny ma TAKIE SAME pointery jak nierelokowalny. Róznica
jest
tylko w tym że KOD może być dowolnie umieszczony w RAM.
A tu jest kod i dane.
Np procedura rysowania znakow na ekranie, i dane z fontami.
Font moze byc dowolny, ale jest kilka predefiniowanych w
bibliotece.
Ich dane są gdzieś załadowane fizycznie w pamięć.

Sa w bibliotece, razem z kodem procedury.

I teraz trzeba podzielic biblioteke na dwie czesci, zaladowac osobno
do pamieci,
zrelokowac wskazniki w kodzie programu ... albo uzywac w programie
adresowania wzgledem PC i po zaladowaniu absolutnie nie przesuwac.

J.

Sebastian Biały
Guest

Tue Mar 05, 2019 8:48 pm   



On 05/03/2019 11:21, J.F. wrote:
Quote:
I tu i tu musisz przestawiać segmenty. W przypadku 8086 masz tylko tą
zaletę że robisz to w cpu.
Mam te zalete, ze ten segment jest przesuwny i obejmuje prawie 64KB.

Algorymika kopiąca w tyłek rejestr segmentowy jak sie nie mieścisz jest
bardzo podobna. Dupa zawsze z tyłu.

Quote:
Zależy jaki duży masz ten obrazek. A jak nie wiesz jaki masz duży to i
tak musisz sprawdzać za każdym razem. Znowu dupa z tyłu.
Nie sprawdzam - wyliczam adres pixela, jego trzy bajty sie w segmencie
zmieszcza.

Adres jest na 67kB. I co teraz? Masz szklaną kulę kiedy to robić bądź
kiedy tego nie robić? Nie, masz if. Czyli cykle. Czyli dupa z tyłu jak
zwykle. Rozmiar segmentu ma tylko znaczenie kiedy znasz rozmiar danych,
wtedy można robić jakieśtam optymalizacje. Jak masz user input to nie.

Quote:
Moze nawet wystarczy adres dla poczatku linii policzyc, ale to juz
lepiej sprawdzic ... albo i nie, kto ma takie glupie obrazki, ten moze
miec klopoty Smile

Stronicowanie niczego nie rozwiązuje, jest tak samo durne jak
przepinanie RAMu w Atari czy Commodore.

Quote:
Nawiasem mowiac - gdzies w TIFF jest "chunk size", ktos przewidzial, ze
moze byc dobrze podzielic obrazek na kawalki nie wieksze niz np 8KB.
I to nie tylko w 8086 sie sprawdza - np te "memory mapped" pliki w unixie.

Memory mapped pliki mają jakiś związek z ogranizacją danych w pliku Wink?
Coś nowego :D

Quote:
https://en.wikipedia.org/wiki/Memory_segmentation
I nie zaczyna sie od "8086 ..."

Intel tego nie wymyślił, oni to tylko użyli. Oczywiście bez sensu może
poza fake kompatybilnością z 8080.

Quote:
Bo to problem segmentacji pamięci i jest obecy w każdej współczesnej
sytuacji kiedy nie ma kompaktacji pamięci. Segmenty nic nie zmieniają
ani nie ułatwiają.
Z segmentami (ale nie takimi jak w 86) by sie dalo.
Nie dało. Program musi wiedzieć że mu pamięc kompaktujesz i wskaźnik
jest iwalidowany.
Nie musi wiedziec, bo wskaznik sie nie zmienia.
3:1500  pozostaje, i tylko system wie, ze segment 3 jest teraz polozony
gdzie indziej.

To mówisz o pamięci wirtualnej z translacją adresów. Ma się to nijak do
8086 gdzie adres jest adresem fizycznym i fizycznej pamieci ram i nie ma
żadnego OSa. Wirtualizacja pojawiła się później. Segmentacja do tego nie
jest w ogóle potrzebna, np. 68k ma wirtualizację a nie ma segmentacji.

Quote:
Nawiasem mowiac - mimo niewatpliwych zalet, zobacz jak dlugo sie 68k
przebijala.

Trudno oceniać co to znaczy przebijała. 68k to cholerne popularna
architektura, niezliczona ilosć komputerów i urządzeń poganiana była tym
procesorem z powodu tego że zaprojektowano go nie po pijaku, jak 386,
był znacząco łatwiejszy.

Quote:
Za droga byla, czy zabraklo takiej lokomotywy jak IBM ... i CP/M?
Tego CP/M to bym nie przecenial, bo niedawno wystartowal, a pisanie np
kompilatora w assemblerze ... musialo byc ciekawe Smile

CP/M na 68k był ale w roku 85 Commodore Amiga pokazała że nawet na 68000
można zrobić system z preemptive multitaskingiem, okienkami i całkiem
współczesnym OSem. Patrzenie na mozliwosci Amigi i na CP/M powoduje
kłopot jak porównywanie samochodu z gwoździem.

Quote:
A moze jednak tak ogolnie 68k kiepska byla ?

Dzielnie do 68060 walczyła z 486 czy wczesnymi Pentium.

Quote:
Albo unix byl za malo "user friendly" i za drogi ?

Co może być mniej user friendly niż gówniany CP/M? Chyba że chodziło o
to słynne "uproszczenie" co zazwyczaj oznacza prostactwo.

Quote:
No i mowisz kompilatorom, one kompiluja, rezultat jest dobry i co cie to
wiecej obchodzi ?

Cykle obchodzą. Jak musisz co dwie instrukcje poświęcać cykle na
przerzucanie rejestrów na stos i z powrotem to nie jest to zupełnie nie
Twoja sprawa.

Quote:
A i tak nie wiadomo, czy tak trzeba, czy tworcy kompilatorow poszli w
takim kierunku, aby RISC obsluzyc.

Gdzie by nie poszli w przypadku x86 dupa zawsze z tyłu.

Quote:
Borland kompilowal bezposrednio na x86.

To że można nie oznacza niczego.

Quote:
I teraz trzeba podzielic biblioteke na dwie czesci, zaladowac osobno do
pamieci,
zrelokowac wskazniki w kodzie programu ... albo uzywac w programie
adresowania wzgledem PC i po zaladowaniu absolutnie nie przesuwac.

I tutaj x86 pokazuje swoją moc niemożności posiadania wydajnego i
relokowalnego kodu na raz. Znowu ... a już się nie będę powtarzał.

J.F.
Guest

Tue Mar 05, 2019 9:58 pm   



Użytkownik "Sebastian Biały" napisał w wiadomości grup
dyskusyjnych:q5mjqq$qnm$1_at_node2.news.atman.pl...
On 05/03/2019 11:21, J.F. wrote:
Quote:
I tu i tu musisz przestawiać segmenty. W przypadku 8086 masz tylko
tą zaletę że robisz to w cpu.
Mam te zalete, ze ten segment jest przesuwny i obejmuje prawie
64KB.

Algorymika kopiąca w tyłek rejestr segmentowy jak sie nie mieścisz
jest bardzo podobna. Dupa zawsze z tyłu.

Zależy jaki duży masz ten obrazek. A jak nie wiesz jaki masz duży
to i tak musisz sprawdzać za każdym razem. Znowu dupa z tyłu.
Nie sprawdzam - wyliczam adres pixela, jego trzy bajty sie w
segmencie zmieszcza.

Adres jest na 67kB. I co teraz?

Nie, skoro juz sie spodziewam duzych obrazkow, to wylicze sobie adres
S:O, gdzie O bedzie nie wieksze niz 15.

Quote:
Masz szklaną kulę kiedy to robić bądź kiedy tego nie robić?

Tu akurat mam - obrazki duze z natury, wiec zawsze :-)

Quote:
Nawiasem mowiac - gdzies w TIFF jest "chunk size", ktos
przewidzial, ze moze byc dobrze podzielic obrazek na kawalki nie
wieksze niz np 8KB.
I to nie tylko w 8086 sie sprawdza - np te "memory mapped" pliki w
unixie.

Memory mapped pliki mają jakiś związek z ogranizacją danych w pliku
Wink? Coś nowego Very Happy

W pewnym okresie moze i nie mialy, ale - jest w mmap parametr dlugosci
okna.
Czyli masz dostep tylko do kawalka. I
- dokumentacja sugeruje skromne rozmiary, np 4KB, to nawet gorzej niz
na 86 :-)

- teraz dyski duze i pliki duze - jakbys chcial sobie kilka plikow po
1GB otworzyc, to sie 32-bitowa przestrzen skonczy :-)

Quote:
https://en.wikipedia.org/wiki/Memory_segmentation
I nie zaczyna sie od "8086 ..."

Intel tego nie wymyślił, oni to tylko użyli. Oczywiście bez sensu
może poza fake kompatybilnością z 8080.

Sensowny ruch dla 16-bitowego uP.
Tylko czy powinni robic 16-bitowy uP ...

Quote:
Bo to problem segmentacji pamięci i jest obecy w każdej
współczesnej
sytuacji kiedy nie ma kompaktacji pamięci. Segmenty nic nie
zmieniają
ani nie ułatwiają.
Z segmentami (ale nie takimi jak w 86) by sie dalo.
Nie dało. Program musi wiedzieć że mu pamięc kompaktujesz i
wskaźnik jest iwalidowany.
Nie musi wiedziec, bo wskaznik sie nie zmienia.
3:1500 pozostaje, i tylko system wie, ze segment 3 jest teraz
polozony gdzie indziej.

To mówisz o pamięci wirtualnej z translacją adresów. Ma się to nijak
do 8086

O segmentacji mowie, a jeszcze nie o pamieci wirtualnej.
Ale segmentacji nie takiej jak w 8086.

Quote:
gdzie adres jest adresem fizycznym i fizycznej pamieci ram i nie ma
żadnego OSa. Wirtualizacja pojawiła się później. Segmentacja do tego
nie jest w ogóle potrzebna, np. 68k ma wirtualizację a nie ma
segmentacji.

Bo to dwa niezalezne mechanizmy, choc moga wystepowac razem.

Pamiec wirtualna pojawila sie wczesniej, ale w duzych komputerach.

Quote:
Nawiasem mowiac - mimo niewatpliwych zalet, zobacz jak dlugo sie
68k przebijala.

Trudno oceniać co to znaczy przebijała. 68k to cholerne popularna
architektura, niezliczona ilosć komputerów

Ale jakos tak latwiej bylo o peceta na 8086 niz na 68k.
I "profesjonalne programy" byly na CP/M :-)

Choc np programy do projektowania plytek i schematow elektronicznych
byly na unixowe workstation.

Quote:
Za droga byla, czy zabraklo takiej lokomotywy jak IBM ... i CP/M?
Tego CP/M to bym nie przecenial, bo niedawno wystartowal, a pisanie
np kompilatora w assemblerze ... musialo byc ciekawe :-)

CP/M na 68k był ale w roku 85 Commodore Amiga pokazała że nawet na
68000 można zrobić system z preemptive multitaskingiem, okienkami i
całkiem współczesnym OSem. Patrzenie na mozliwosci Amigi i na CP/M
powoduje kłopot jak porównywanie samochodu z gwoździem.

Ale tez popatrz na lata - kto jeszcze uzywal CP/M ?
Jakas biedota :-)

Quote:
A moze jednak tak ogolnie 68k kiepska byla ?
Dzielnie do 68060 walczyła z 486 czy wczesnymi Pentium.

Ale to juz 6-ta wersja, a gdyby byla taka dobra, to by Intel 386 nie
dozyl :-)

Quote:
Albo unix byl za malo "user friendly" i za drogi ?
Co może być mniej user friendly niż gówniany CP/M? Chyba że chodziło
o to słynne "uproszczenie" co zazwyczaj oznacza prostactwo.

Przyjemnie sie korzystalo z TurboPascala.

A jak patrzylem na znajomego bieglego w Unixie, ktory naprawde biegle
wpisywal te komendy po 40-80 znakow, zeby kompilacje uruchomic ...

Quote:
No i mowisz kompilatorom, one kompiluja, rezultat jest dobry i co
cie to wiecej obchodzi ?

Cykle obchodzą. Jak musisz co dwie instrukcje poświęcać cykle na
przerzucanie rejestrów na stos i z powrotem to nie jest to zupełnie
nie Twoja sprawa.

Z rzadka, czesto wystarczaja te rejestry co sa.
Za to jak musisz co przerwanie odkladac tych 30 rejestrow na stos ...
i potem sciagac ...

Quote:
I teraz trzeba podzielic biblioteke na dwie czesci, zaladowac
osobno do pamieci,
zrelokowac wskazniki w kodzie programu ... albo uzywac w programie
adresowania wzgledem PC i po zaladowaniu absolutnie nie przesuwac.

I tutaj x86 pokazuje swoją moc niemożności posiadania wydajnego i
relokowalnego kodu na raz. Znowu ... a już się nie będę powtarzał.

Przeciez prawie na jedno wychodzi, skoro i tak trzeba zaladowac,
poprawic adresy, i juz nie ruszac.

J.

ń
Guest

Tue Mar 19, 2019 9:00 pm   



Próbowałeś choć z jednego zrobić Frankenpada?


-----
> A ja mam 3x t61.

Goto page Previous  1, 2, 3, 4, 5, 6, 7, 8, 9

elektroda NewsGroups Forum Index - Elektronika Polska - CP/M i 64kB

NOWY TEMAT

Regulamin - Zasady uzytkowania Polityka prywatnosci Kontakt RTV map News map