e, to i tak dla mnie cenna informacja, wiem przynajmniej że jest sens szukać, dziękować :)

ale ja to jakiś czas temu trochę programowałem w Devpac'u na STE i myślę że nie przestawię się na nic innego, a do tego Devpac i tak jest chyba najlepszym narzędziem asm na duże atari, niektórzy jeszcze twierdzą że lepszy jest Turbo Assembler ( szybciej kompiluje ), a pozatym to chyba nic innego się nie liczyło wtedy w tym segmencie.

edit:
w zeszłym roku próbowałem trochę działać w pure c, fajne narzędzie, ale c jest dziwne :) assembler jest prostszy i bardziej logiczny niż ansi c :)

Ostatnio edytowany przez jury (2010-05-10 18:34:52)

a ja myślałem że miker tym linkiem mi proponuje jakieś zastępstwo za Devpaca :)

hmm, już lepiej bo nie krzyczy że nie ten procesor ale po uruchomieniu się, zaraz się zamyka, do tego to jest amon a nie mon, kurcze nie pamiętam czym się różniły, a właśnie przeczesałem wszystkie atari magazyny ( jak jak kochałem to dużo-atarowe pismo :) moje polskie ulubione ) bo tam jest opis srodowiska Devpac'a, ale nic nie znalazłem o amon'ie. Ale miker wielkie dzięki !!!

sqward, przy okazji, czy na Outline Nature prezentowało SuperVidel'a?, bo nie mogę znaleźć informacji na ten temat, no i przedewszystkim nie ma nic na youtube'ie :)  hehehehe

Ostatnio edytowany przez jury (2010-05-06 20:10:52)

jury: amon się różni tym, że to debuger od innego projektu. Pozatym szczegółowych różnic nie pamiętam, poza tym, że kiedyś używałem go zamiast monsta i miałem ku temu jakiś powód (jaki teraz już nie wiem).

SuperVidela widziałem. Działa. Widziałem na dwóch monitorach obraz z orginalnego videla i sklonowany obraz z super videla na drugim. Wszystko działało super. Teraz chłopcy pracują nad super blitterem, który pomoże to wszystko jakoś napędzić w rozdzielczościach rozszerzonych (bo skrolowanie okien w 1680x1200-cośtam i 32 bitach było bardzo powolne).
Tak więc teraz tylko czekać (Zresztą jak zawsze).

e tam, dhs'i chyba wszystko robią w Devpac'u, a na pweno taki Derealization jest całkowicie w tym zrobiony i zrobili to przed emeryturą :)
taki przykładowo system operacyjny MagiC z tego co kojarzę też był zrobiony kompletnie w assemblerze przez jedną osobę ( jak się mylę to
proszę o sprostowanie )
a ogólnie to nie mówie wogóle nie dla c :), tyle że narazie to zaczynam z czymś co znam a c nie jest czymś takim, tylko asm.
Faktycznie to w c też równolegle będę działać, tyle że to będzie nauka a nie przypominanie sobie :)

Ostatnio edytowany przez jury (2010-05-09 11:07:53)

Ale czego to ma dowodzić ? Moje wspomnie z magic-a to jedna wielka zwiecha. Z tego co pamiętam to Draco też miałby coś do powiedzenia na ten temat ;)

"Niestabilność" MiNT-a wynika z dwóch TOS-owych zaszłości, które przekładają się na dwie wielkie dziury w ochronie pamięci:

1) ochronie nie podlega pamięć BIOS-u, sterownika twardego dysku i wszystkich programów załadowanych z AUTO przed MiNT-em. Każda (przypadkowa) ingerencja w ten obszar może się skończyć tragicznie.

2) jeden proces - konkretnie AES - ma specjalny przywilej bezkarnego zapisu danych do pamięci aplikacji, nawet jeśli ta pamięć jest chroniona. AES natomiast nie jest stuprocentowo odporny na nieprawidłowe parametry zawarte w global array w chwili jego wywołania - z czego wynika, że przy odrobinie szczęścia (pecha) można skłonić AES do zapisu danych w chroniony obszar i uwalić system.

To drugie można rozwiązać na dwa sposoby:

1) przenosząc AES całkowicie do userspace i likwidując jego odrębność od wywołującej go aplikacji. AES działałby wtedy jako zwykła biblioteka (dzielona) a wszystkie jego operacje wykonywane byłyby "w imieniu" procesu użytkownika (czyli w imieniu aplikacji GEM). W przypadku naruszenia ochrony pamięci uwaleniu ulegałaby aplikacja, a system pozostawałby nienaruszony.

To był mój pomysł, którego Frank chyba nawet nie był w stanie zrozumieć (nie znał się zupełnie na GEM-ie).

2) przenosząc AES całkowicie do kernelspace i likwidując jego odrębność od kernela. AES działa "w imieniu" procesu użytkownika (w imieniu aplikacji GEM). W przypadku naruszenia ochrony pamięci uwalana jest aplikacja, a system pozostaje nienaruszony - niestety, AES w tym przypadku działa z prawami kernela (nie wiadomo, po co), więc śmiecie w global array ciągle mogą spowodować zniszczenie całego systemu.

To jest to, co zostało zrobione w postaci modułu kernela XaAES.

MagiC natomiast jest niestabilny sam z siebie, przypuszczalnie z powodu błędów w kernelu i spółce, i jest sobie w stanie sam tak namieszać w swoim własnym wnętrzu, że się wywróci po zadaniu mu np. kopiowania pliku jego własnym desktopem.

Ostatnio edytowany przez drac030 (2010-05-09 16:19:09)

to nie tylko chodzi o porty dem TBLow, bo praktycznie wszystko co mamy na CT6x to są porty, które praktycznie były możliwe właśnie dzięki temu że były w c, czyli: quake, duke nuken 3d, open TTD, flashback ... Praktycznie wszystko pod CT6x to porty, a nawet lepiej, większość stuff'u pod MiNTa to porty. Mimo że nigdy nie programowałem w c, mnie nie trzeba przekonywać o mocy c, ja ją z teorii bardzo dobrze znam :)

no a to akurat kwestia gustu, bo dla mnie zadno demo TBLów nie dorównuje klimatem do Derealization :p

Ostatnio edytowany przez jury (2010-05-09 20:11:47)

piętro wyżej napisałem o c nabardziej pochlebnie jak się chyba tylko da, że dzięki niemu ZAWDZIĘCZAMY WSZYSTKO :) co mamy na CT6x i prawie wszystko co mamy pod MiNTa, większego uznania dla języka c chyba już nie może być, więc nie rozumiem powyższego ?

Ostatnio edytowany przez jury (2010-05-10 08:49:07)