12.10.2013 16:47
[#1]
dysk RAD: i system
Mam takie pytanie, czy jest możliwość żeby przy botowaniu stworzyć dysk RAD: i skopiować do niego system tak żeby z niego botowało ?
biorąc pod uwagę że mam 128MB ramu w aca tak mi się pomyślało że mogło by to przyśpieszyć system
biorąc pod uwagę że mam 128MB ramu w aca tak mi się pomyślało że mogło by to przyśpieszyć system
12.10.2013 17:45
[#4]
Re: dysk RAD: i system
@QUAD, post #3
Kopiowanie to pryszcz, bo można poczekać trochę dłużej. Ale pytanie, czy cała Twoja pamięć przeżyje reset? Chip nie jest czyszczony, stąd np. po resecie można szukać obrazków, sampli, modułów itp. Ale nie wiem jak jest z fastem.. No i czy RAD: czasem nie żre cennego chip-ram?
12.10.2013 18:25
[#6]
Re: dysk RAD: i system
@Norbert, post #5
Tyle że tworzenie RADu a potem kopiowanie na niego i wreszcie uruchamianie nie przyśpieszy a zwolni start systemu. Był kiedyś taki dziwny programik do przyspieszania startu, zgrywał zawartość pamięci na dysk a potem przy starcie zamiast wszystko po kolei wczytywać i uruchamiać wczytywał tylko zapisana zawartość pamięci. Faktycznie przyspieszało to start ale w przypadku problemów lub zmian w sekwencji startowej czy WBS wieszało system.
Pozdrawiam
Pozdrawiam
12.10.2013 20:02
[#8]
Re: dysk RAD: i system
@Norbert, post #7
Dokładnie jest tak jak piszesz, chciałem sobie wieczorkiem pogrzebać i zobaczyć jak to będzie działać, właściwie system wstaje mi szybko z dysku i działa bardzo ładnie na ACA, system jest 3.1 kickstart jest zmapowany tak że pierwszy start i tak jest troszeczkę dłuższy bo kicka sobie zrobiłem 3,9, mam wiele rzeczy do zrobienia na A1200 ale po o ją mam żeby się bawić w wolnej chwili :)
a od klikania wiedza się poszerza
Ostatnia aktualizacja: 12.10.2013 20:03:05 przez QUAD
a od klikania wiedza się poszerza
Ostatnia aktualizacja: 12.10.2013 20:03:05 przez QUAD
12.10.2013 20:52
[#10]
Re: dysk RAD: i system
@QUAD, post #1
Możesz też użyć LhA/Lzx do tego, zamiast nagrywać obraz - to może być nawet szybsze od nagrywania obrazu na RAD:, o ile masz wolny HD - bo rozpakowywanie z HD do pamięci odbywa się w czasie rzeczywistym/w locie, bo HD jest tu wąskim gardłem, a skoro archiwum lha/lzx jest mniejsze od obrazu dysku, to jego odczyt będzie trwał krócej od odczytu obrazu.
Warto tylko pamiętać o dodaniu parametru a by zachować bity protekcji plików.
składnia dla lzx do rozpakowania archiwum:
lzx -a -bi8000 -bo8000 -m -P3 -q x <ścieżka dostępu do archiwum> RAD:
składnia dla lha
lha -a -b64 -P3 -q x <ścieżka dostępu do archiwum> RAD:
Choć na początku zabawiłbym się z poleceniem copy - dzięki buforom, można je troszkę przyśpieszyć, no i na początku, gdy "dopieszczasz" system, nie męczysz się z ciągłym robieniem obrazu/archiwum. Składnia
Copy SYS: RAD: ALL QUIET BUF 8000
Dodatkowo warto by zrobić sobie jakiś skrypt zamykający "sesję" -sprawdzający, czy jakieś pliki na RAD: nie uległy zmianie i w razie potrzeby kopiujący je na HD/tworzący archiwum/obraz. Jak to rozwiązać - np dla COPY:
SCENARIUSZ I
1. Kopiujemy zawartość partycji systemowej (SYS:) do RAD: - polecenie wyżej (nada kopiowanym na RAD: plikom aktualną datę i czas)
2. kopiujemy na RAD: jakiś plik (np. Disk.info, zamieniając ten z partycji systemowej - będzie to najnowszy plik na RAD:)
3. po skończonej pracy, gdy coś zmieniliśmy - albo na wszelki wypadek, odpalamy nasz skrypt zamykający sesję, który porówna daty utworzenia wszystkich plików z plikiem Disk.info i jeżeli jakiś plik będzie nowszy od niego - to taki zaktualizowany plik zostanie skopiowany z RAD: na SYS:
SCENARIUSZ II
1. Kopiujemy zawartość partycji systemowej (SYS:) do RAD: - polecenie wyżej (nada kopiowanym na RAD: plikom aktualną datę i czas)
2. dodajemy do wszystkich plików na RAD: bit protekcji a składnia:
Protect RAD:#? ADD a ALL QUIET
3. przed wyłączeniem Ami odpalamy skrypt, który sprawdzi, czy jakiś plik nie stracił bitu protekcji a (Amiga OS usuwa ten bit, gdy w pliku zaszły jakieś zmiany) i jeżeli tak się stało, to kopiuje go z RAD: do SYS:
----------------------
Co warte wspomnienia metody z obrazem/copy/archiwum można mieszać (a nawet powiedziałbym, że dla naszej wygody - trzeba).
Powiedzmy, że masz obraz lub archiwum, który/e nagrywasz na RAD: do tego przed zamknięciem Ami zapuszczasz jeden z wyżej wspomnianych skryptów i kopiujesz zaktualizowane pliki gdzieś na dysk (np. w katalogu Update). Przy następnym uruchomieniu nagrywasz obraz na RAD: lub rozpakowujesz na niego archiwum i "aktualizujesz" zawartość RAD: kopiując zawartość katalogu Upgdate na RAD:
Nic też nie stoi na przeszkodzie, żeby bazowy system trzymać w obrazie a aktualizację robić za pomocą Lzx/LhA (aktualizacja za pomocą lha/lzx jest chyba najłatwiejsza w realizacji - szczególnie przy scenwriuszu 2 - z bitami protekcji i nawet całkiem szybka - Protect, to jedno z najszybszych poleceń ADOSu, Lzx {który polecałbym do tego zadania} też daje radę, przy dodawaniu plików bez bitu protekcji a).
Przykład składni dla Lzx przy tworzeniu archiwum aktualizacji:
Lzx -a -bi8000 -bo8000 -q -Qf -r -s u DH1:Update/upd.lzx RAD:
Teraz małe wytłumaczenie opcji:
-a zachowuje bity protekcji archiwizowanych plików
-bi8000 -bo8000 -Qf - skoro masz kupę pamięci, to czemu jej nie wykorzystać do przyśpieszenia lzxa
-q - żeby lzx siedział cicho (dzięki temu jest ciut szybszy)
-s - dodaje do archiwum wyłącznie pliki bez bitu protekcji a (czyli pliki, które uległy aktualizacji)
Przy okazji polecenie u sprawdzi, czy archiwizowane z RAD: pliki czasem nie są już w archiwum aktualizacji (żeby nie tracić czasu na ponowną archiwizację już zarchiwizowanych plików, wcześniej rozpakowanych do RAD: z tego archiwum - oczywiście, jeżeli plik w archiwum istnieje, ale w RAD: jest nowszy, to taki plik zostanie w archiwum zamieniony na nowszą wersję z RAD: )
Jeżeli znasz Lzxa, to zapewne zauważyłeś, że nie używam opcji -M - robię tak, bo opcja ta wprawdzie zmniejsza rozmiar archiwum, ale odbywa się to kosztem spowolnienia pracy archiwizera.
Się rozpisałem.
Warto tylko pamiętać o dodaniu parametru a by zachować bity protekcji plików.
składnia dla lzx do rozpakowania archiwum:
lzx -a -bi8000 -bo8000 -m -P3 -q x <ścieżka dostępu do archiwum> RAD:
składnia dla lha
lha -a -b64 -P3 -q x <ścieżka dostępu do archiwum> RAD:
Choć na początku zabawiłbym się z poleceniem copy - dzięki buforom, można je troszkę przyśpieszyć, no i na początku, gdy "dopieszczasz" system, nie męczysz się z ciągłym robieniem obrazu/archiwum. Składnia
Copy SYS: RAD: ALL QUIET BUF 8000
Dodatkowo warto by zrobić sobie jakiś skrypt zamykający "sesję" -sprawdzający, czy jakieś pliki na RAD: nie uległy zmianie i w razie potrzeby kopiujący je na HD/tworzący archiwum/obraz. Jak to rozwiązać - np dla COPY:
SCENARIUSZ I
1. Kopiujemy zawartość partycji systemowej (SYS:) do RAD: - polecenie wyżej (nada kopiowanym na RAD: plikom aktualną datę i czas)
2. kopiujemy na RAD: jakiś plik (np. Disk.info, zamieniając ten z partycji systemowej - będzie to najnowszy plik na RAD:)
3. po skończonej pracy, gdy coś zmieniliśmy - albo na wszelki wypadek, odpalamy nasz skrypt zamykający sesję, który porówna daty utworzenia wszystkich plików z plikiem Disk.info i jeżeli jakiś plik będzie nowszy od niego - to taki zaktualizowany plik zostanie skopiowany z RAD: na SYS:
SCENARIUSZ II
1. Kopiujemy zawartość partycji systemowej (SYS:) do RAD: - polecenie wyżej (nada kopiowanym na RAD: plikom aktualną datę i czas)
2. dodajemy do wszystkich plików na RAD: bit protekcji a składnia:
Protect RAD:#? ADD a ALL QUIET
3. przed wyłączeniem Ami odpalamy skrypt, który sprawdzi, czy jakiś plik nie stracił bitu protekcji a (Amiga OS usuwa ten bit, gdy w pliku zaszły jakieś zmiany) i jeżeli tak się stało, to kopiuje go z RAD: do SYS:
----------------------
Co warte wspomnienia metody z obrazem/copy/archiwum można mieszać (a nawet powiedziałbym, że dla naszej wygody - trzeba).
Powiedzmy, że masz obraz lub archiwum, który/e nagrywasz na RAD: do tego przed zamknięciem Ami zapuszczasz jeden z wyżej wspomnianych skryptów i kopiujesz zaktualizowane pliki gdzieś na dysk (np. w katalogu Update). Przy następnym uruchomieniu nagrywasz obraz na RAD: lub rozpakowujesz na niego archiwum i "aktualizujesz" zawartość RAD: kopiując zawartość katalogu Upgdate na RAD:
Nic też nie stoi na przeszkodzie, żeby bazowy system trzymać w obrazie a aktualizację robić za pomocą Lzx/LhA (aktualizacja za pomocą lha/lzx jest chyba najłatwiejsza w realizacji - szczególnie przy scenwriuszu 2 - z bitami protekcji i nawet całkiem szybka - Protect, to jedno z najszybszych poleceń ADOSu, Lzx {który polecałbym do tego zadania} też daje radę, przy dodawaniu plików bez bitu protekcji a).
Przykład składni dla Lzx przy tworzeniu archiwum aktualizacji:
Lzx -a -bi8000 -bo8000 -q -Qf -r -s u DH1:Update/upd.lzx RAD:
Teraz małe wytłumaczenie opcji:
-a zachowuje bity protekcji archiwizowanych plików
-bi8000 -bo8000 -Qf - skoro masz kupę pamięci, to czemu jej nie wykorzystać do przyśpieszenia lzxa
-q - żeby lzx siedział cicho (dzięki temu jest ciut szybszy)
-s - dodaje do archiwum wyłącznie pliki bez bitu protekcji a (czyli pliki, które uległy aktualizacji)
Przy okazji polecenie u sprawdzi, czy archiwizowane z RAD: pliki czasem nie są już w archiwum aktualizacji (żeby nie tracić czasu na ponowną archiwizację już zarchiwizowanych plików, wcześniej rozpakowanych do RAD: z tego archiwum - oczywiście, jeżeli plik w archiwum istnieje, ale w RAD: jest nowszy, to taki plik zostanie w archiwum zamieniony na nowszą wersję z RAD: )
Jeżeli znasz Lzxa, to zapewne zauważyłeś, że nie używam opcji -M - robię tak, bo opcja ta wprawdzie zmniejsza rozmiar archiwum, ale odbywa się to kosztem spowolnienia pracy archiwizera.
Się rozpisałem.
12.10.2013 20:57
[#11]
Re: dysk RAD: i system
@Norbert, post #7
Wolniej będzie tylko za pierwszym razem.
Za pierwszym razem po każdorazowym włączeniu. I nie jestem pewny czy aby nie za każdym, coś mi się kołacze w pamięci z czasów pluskwy że RAD był obsługiwany przez trackdisk.device które było bardzo wolne bo napisane tylko do obsługi flopa. Na pewno transfery z/do RAD były sporo wolniejsze niż te do RamDysku. Ale chętnie poczytam opinie kogoś kto to sprawdzi osobiście.
Pozdrawiam
12.10.2013 22:05
[#16]
Re: dysk RAD: i system
@APC74, post #14
Taki mały offtop bo ciekawość mnie zżera. Do CDTV były karty pamięci, prawie że niedostępne. Karty te w zamierzeniu miały służyć do zapisywania highscore lub save'ów z gier uruchamianych z CD, na którym rzecz jasna nie można było nic zapisać. Karty te posiadały bateryjkę, która je podtrzymywała. Można podobno też było na nie także wgrać system i bootować z nich. Ktoś od nas z forum stworzył rozszerzenie pamięci wpinane w port czytnika kart, które mogło być przypisane jako pamięć fast. Pytanie moje jest nastepujące - czy teoretycznie byłoby to możliwe, żeby w obszarze tej pamięci wgrać składniki systemu, pamięć podtrzymywać bateryjnie i potem przy uruchomieniu komputera montować ją jako dysk RAD i z niej uruchamiać system? Oczywiście mówimy o jakimś skromnym systemie, na 512kb wiele nie zmieścimy ;)
