26

(24 odpowiedzi, napisanych Bałagan)

Lizard napisał/a:

a dla systemów uniksowych jednoznacznej odpowiedzi nie ma.

W sumie racja. To mi przypomniało, że kiedyś często widywałem na forach pytania o wielkość partycji swap i było zawsze multum teorii. Nie wiem skąd mi się więc wzięła ta dwukrotność, osobiście od lat nie zakładam swap'a (a nie mam jakichś bajońskich ilości RAMu) i nie planuję tego zmieniać.

27

(24 odpowiedzi, napisanych Bałagan)

Sikor napisał/a:

Nie pamiętam już, czy plik wymiany może być 2 lub 4 krotnie większy od RAM, czy mniejszy - dawno to było

O, to trochę dziwnie w tym Windowsie to jest. Na *nix'ach to się "z palca" ustawia wielkość co do megabajta, albo nawet i bajta (choć było zalecane aby właśnie ustawiać dwukrotność pamięci RAM)

28

(6 odpowiedzi, napisanych Zloty)

Spora szansa, że się pojawię.

29

(21 odpowiedzi, napisanych Programowanie - 16/32bit)

Adam Klobukowski napisał/a:

@jury, ale tam nic nie ma o zgodności libcmini w POSIXem. Jest o zgodności MiNTlib z POSIXem, którego libcmini w pełnie nie zapewnia. W swoim początkowym pości pisałeś o narzucie libcmini i do tego ja się odnosiłem w swoim poście.

O widzisz, to się nie zrozumieliśmy. Ja nie pisałem o narzucie libcmini, tylko dowrotenie o kosmicznym narzucie mintlib'a, i, że właśnie libcmini niesamowicie pomaga w zbiciu tego narzutu.

jury napisał/a:

Póki co to właśnie sobie zmontowałem libcmini i zwykła linijka kodu "printf("Hello world\n") kompiluje się zamiast do 125KB (jak przy domyślnej bibliotece standardowej mintlib) do 2,7KB.


Adam Klobukowski napisał/a:

Leśli hodzi o narzut MiNTLiba, to kiedy ostatnio kompilowałem Hello World, to binarka miałą coś koło 600KB

Tak, też pamiętam, że kawał czasu temu hello world kompilował się coś pod sześćset kilo, czyli obecnie ze swoimi 125 kilo to mocno go poprawili :)

30

(21 odpowiedzi, napisanych Programowanie - 16/32bit)

No napisałeś, ze ten narzut nie ma nic wspólnego z POSIX'em

Adam Klobukowski napisał/a:

Narzut jest zapewne spowodowany kodem do obsługi standardu ARGV i startowej inicjalizacji i nic to nie ma akurat wspólnego z POSIXem.

Więc zalinkowałem źródło libcmini które twierdzi, że ten narzut (jak został nazwany "huge") jest związany tylko i wyłącznie z dorzucaną warstwą POSIX'ową

31

(21 odpowiedzi, napisanych Programowanie - 16/32bit)

Adam Klobukowski napisał/a:

libcmini to nie MiNTLib, nie mieszajmy. Narzut jest zapewne spowodowany kodem do obsługi standardu ARGV i startowej inicjalizacji i nic to nie ma akurat wspólnego z POSIXem.

Z githuba libcmini:

"libcmini aims to be a small-footprint C library for the m68k-atari-mint (cross) toolchain, similar to the C library Pure-C came with. Many GEM programs do not need full MiNT support and only a handful of C library functions.

By default, gcc compiled programs on the Atari ST platform link to mintlib. Mintlib aims to implement all POSIX functionality to make porting Unix/Linux programs easier (which is a very good thing to have). For small GEM-based programs, this comes with a drawback, however: program size gets huge due to the underlying UNIX compatibility layer."

32

(21 odpowiedzi, napisanych Programowanie - 16/32bit)

Adam Klobukowski napisał/a:

printf to jest wbrew pozorom całkiem skomplikowana funkcja, 125kb to nie jest dużo w tym kontekście.

To nie printf jest "problemem". Zamieniłem printf'a na "return 0" i to się skompilowało o 0,3KB mniej, czyli nie 125 a 124,7.
Chodzi o to, że mintlib niezależnie co masz w kodzie i tak dodaje cały inwentarz POSIX'owy. I to on zapycha bezsensownie (no bo i tak nie jest używany) binarkę. Po to Marcus stworzył właśnie libcmini, żeby ktoś kto nie potrzebuje POSIXa nie miał nic z niego w binarce.

Adam Klobukowski napisał/a:

Gcc samo z siebie generuja bardzo dobry i zwarty kod - problemem są biblioteki. Ale jeśli twój projekt jest duży (bo raczej na printf sie nie skończy?) to się to 'amortyzuje'

Projekt raczej duży, a printfa (ani nic w podobie) nie będzie najpewnie nawet jednego :) Tak tylko dałem jako przykład klasycznego hello worlda do kompilacji z mintlibem i libcmini, bo potrzebowałem jakiś cyferek.

saulot napisał/a:

gcc + opcja nostdlib / mshort + customowy startup + kilka funkcji i da się żyć (ewentualnie libcmini).. do printfa od jakiegoś czasu używam nanoprintf, ale to jest pod c99/11> ...

Dzięki (o tym mshort dzisiaj gdzieś coś już czytałem, jeszcze nie wiem co to, ale się zagłębię, bo podobno też to warto dodawać)

saulot napisał/a:

Btw PureC to też niezła opcja ze względu na ide / debugger, ale dialekt stary dialekt c może teraz trochę odstraszać... ale działa..

No właśnie to chyba była by najodpowiedniejsza opcja dla 512KB ST, ale właśnie ten stary dialekt ...

33

(21 odpowiedzi, napisanych Programowanie - 16/32bit)

Stripping akurat nie ma tutaj nic do rzeczy. To, że printf("hello world\n") kompiluje się do ponad 100KB, to "normalka", bo "nasza" standardowa biblioteka dla gcc zawsze dodaje bojową gotowość POSIX'a, więc to dlatego. I dlatego właśnie @mfro wytworzył  libcmini aby nie było takiego bezsensu jak ktoś chce tworzyć "zwykłe" rzeczy.
Ale właśnie pytanko mam czy coś jeszcze warto zrobić z gcc żeby to co wypluwa miało jakiś sens dla ST

34

(21 odpowiedzi, napisanych Programowanie - 16/32bit)

Czy używanie takiego potwora jak gcc dla docelowej platformy 512KB ST ma sens?
Póki co to właśnie sobie zmontowałem libcmini i zwykła linijka kodu "printf("Hello world\n") kompiluje się zamiast do 125KB (jak przy domyślnej bibliotece standardowej mintlib) do 2,7KB.
Ale czy kojarzy ktoś czy są jeszcze inne rzeczy które trzeba by zrobić czy może fakczynie używanie gcc dla ST to bezsens jak strzelanie do muchy z armaty i lepiej użyć PureC?

(o matko, jakakolwiek operacja na forum {typu wyświetl "aktywne tematy", wejdź w jakiś wątek, dodaj nowy wpis ...} trwa jakieś pół minuty)

35

(16 odpowiedzi, napisanych Zloty)

Ja to powiedzmy tak 50/50

36

(11 odpowiedzi, napisanych Software, Gry - 16/32bit)

Mupfel coś nie do końca mi działa. To znaczy uruchamia się, ale potem mam tylko komunikaty, że program nie został uruchomiony :/ Coś jeszcze popróbuję, bo ten Mupfel podoba mi się najbardziej ze wszystkiego co póki co testwałem.

sqward napisał/a:

uiptool ma funkcję zdalnego odpalania programów pod TOS i przekierowania wyjścia do peceta.

Fajna opcja, muszę spróbować.

willy napisał/a:

Kiedyś coś takiego lub podobnego raczej nie napisałem ale skompilowałem z jakichś źródeł pod falcona.
Musiałbym tego poszukać.

Strzelam, że chodziło o Gulam:

https://github.com/ggnkua/Atari_ST_Sour … ratt/GULAM

:) dzięki któremu wreszcie działa mi przekierowanie standardowego wyjścia jak powinno.

37

(11 odpowiedzi, napisanych Software, Gry - 16/32bit)

Takie coś też by mnie satysfakcjonowało. Popróbuję.

38

(11 odpowiedzi, napisanych Software, Gry - 16/32bit)

Adam Klobukowski napisał/a:

Nie do końca rozumiem po co shell pod TOSa w okienku - bo to przecież singletask - chcesz go z akcesoriami używać?

Mam binarkę która "wyrzuca" czasem dość spore ilości printf'ów. Dotychczas uruchamiałem ją na Falconie w MiNT w Conholio i najzwyklej przewijałem okienko żeby cofnąć się ekran, dwa czy pięć temu i zobaczyć co zostało wyplute. Czasem też przekierowywałem wyjście do pliku i przeglądałem to w pliku.

Ale wymyśliłem, że zamiast zaprzęgać Falcona, to szybkie testy tych printfów bym robił w Hatari w TOSie
No ale Okami do tego się  nie nadaje, bo to pełny ekran a do tego przekierowanie wyjścia jakby coś nie do końca działało. To znaczy takie "date >plik.txt" działa git, ale jak uruchamiam tą moją binarkę, to tylko tworzy plik ale nic tam nie przekierowuje (to są zwykłe printfy, jak przekompiluję to na linuksa i przekieruję standardowe wyjście na plik to oczywiście wszystko "ląduje" w tym pliku)

Znalazłem jeszcze A Shell. Ale ten to nawet nie tworzy pustego pliku, nie mówiąc o przekierowaniu.
Więc wymyśliłem, że może jest jakiś okienkowy shell, to bym sobie przewijał zawartość jak w Conholio. Stąd zadałem pytanie, bo nie umiem znaleźć nic innego oprócz Okami i Ashell (a wiem, że na pewno więcej tego było, więc po cichu liczę na coś okienkowego [albo z działającym przekierowaniem, choć okienko było by najwygodniejsze])

39

(11 odpowiedzi, napisanych Software, Gry - 16/32bit)

Zgadza się.

40

(11 odpowiedzi, napisanych Software, Gry - 16/32bit)

Jest pod TOSa może jakiś shell w okienku?
Dotychczas używałem Okami i służył doskonale do czego potrzebowałem, ale przydałby mi się teraz właśnie jakiś shell okienkowy.

41

(63 odpowiedzi, napisanych Software, Gry - 16/32bit)

Wątpię aby coś z tego wyszło na ośmiomegahercowej maszynie, ale do odważnych świat należy :)
Tu masz poradnik na temat zmiany MiNTa na unix'oida:

https://sites.google.com/site/probehous … t-on-atari

42

(19 odpowiedzi, napisanych Zloty)

Raczej być powinienem.

43

(63 odpowiedzi, napisanych Software, Gry - 16/32bit)

Kroll napisał/a:

Easymint korzystał ze strony spareminta, ale ona chyba jest juz nie aktywn, czy ktos wie gdzie mozna teraz znaleźc reszte pakietów jak chociazby "awk" ?

Jeśli dobrze kojarzę, to MiKRO kiedyś zrobił mirrora tego portalu Sparemint'owego, który wyglądał dokładnie 1:1 jak oryginał.
Ale za chiny go nie mogę teraz znaleźć, za to znalazłem takie coś:

https://github.com/freemint/sparemint/t … mint/SRPMS

Wygląda jak zbiór rpm'ów spareminta. Ewentualnie jak podczas instalacj Easyminta na którejś swojej maszynie nie zaznaczyłeś opcji aby kasował rpm'y po instalacji (ja np zawsze sobie je zostawiam) to stamtąd też możesz je wziąć

44

(63 odpowiedzi, napisanych Software, Gry - 16/32bit)

Rozumuję, że tak.

Kroll napisał/a:

@Cyprian OK sprawa sie rozwiazala w pakiecie easymint jest starsza wersja nadpisałem zarówno find jak i bash i teraz juz na dysku /c/ jest OK i juz zagłebia sie bardziej :)

No kurde, to nie rozumiem. Gdyby find nie szukał nigdzie indziej a tylko w bieżącym katalogu, to nie miałby zupełnie sensu. Bash też do tego nie powinien mnieć nic do rzeczy, do tego Conholio chyba korzysta też właśnie z basha (mój Falcon czeka na nowy zasilacz, więc nie sprawdzę tego, ale jestem tego bardzo mocno przekonany)
A do tego ja też mam Easyminta bez praktycznie żadnych aktualizacji i u mnie find na pewno "leciał" po całym systemie plików, może miałeś po prostu uszkodzone archiwum finda czy coś. Nic to, dobrze, że już działa.

45

(63 odpowiedzi, napisanych Software, Gry - 16/32bit)

Poka co zwróci:

find / -type f | grep -i -e ".prg$" -e ".tos$"

Amen. A co do tego kto jak poświęca swój czas, jest fajnie wyartykułowane w wywiadzie z Yerzmyey'em dla amigaone.pl Tylko nie mogę tego teraz na szybko znaleźć a muszę na kilka godzin wyjść. Jak wrócę zalinkuję, bo Yerzu, jak to Yerzu, ładnie to wyartykułował :D

_tzok_ napisał/a:

to bawmy się w retro, a nie próbujmy robić z naszych retro-zabawek współczesnych komputerów i zmuszać je do robienia czegoś, czego w swoich czasach robić nie mogły

Nie wypowiadam się odnośnie a8, bo temat jest poza moim zainteresowaniem, przez co niewiele o nim wiem, ale już atari 16-bit jak i 32-bit, w jak to nazwałeś "swoich czasach" miało kosmiczą ilość rozszerzeń. Na rynku 16-bit była niesamowita ilość dopałek jeśli chodzi o czystą moc procesora, od 68000 z podbitą częstotliwością do 68030 (np PAK). Kart rozszerzających możliwości graficzne też było mnóstwo. Plus "rozszerzalniki" wszystkich innych możliwych podsystemów komputera. W tamtych czasach też patrzyłeś się na takich, grożąc im paluszkiem, że zmuszają swoje maszyny do robienia czegoś co nie powinny? :P

48

(6,077 odpowiedzi, napisanych Kolekcjonowanie)

O, nawet nie zauważyłem :)

AS... napisał/a:
Pin napisał/a:

@As - przestań pić alkohol, to będziesz kumał co się dzieje :)

Pin, Lamusie, Co Ty masz z tym alco?
Randka mi się dziś udała!
Daruje sobie :)

Znaczy, że masz już tak na trzeźwo? :]

50

(6,077 odpowiedzi, napisanych Kolekcjonowanie)

Amiga 500 w cenie prawie Falcon'owej :)

https://www.olx.pl/d/oferta/amiga-500-p … on=ip%7Ccf

Edit:
Nie znam się specjalnie na Amigach, ale na tym samym portalu chyba dokładnie taka sama pięćsetka jak powyższa, do tego w pudle (i wg opisu możliwe że jedyna taka w pudle w Europie! :) ) za połowę ceny powyższej:

https://www.olx.pl/d/oferta/amiga-500-t … tem_to_vec