Niezalogowany (Zaloguj się)

Jeśli chcesz wziąć udział w dyskusjach na forum - zaloguj się. Jeżeli nie masz loginu - poproś o członkostwo.

Vanilla 1.1.4 jest produktem Lussumo. Więcej informacji: Dokumentacja, Forum.

.lzh

Od 1 do 21 z 21

- 1: CommentAuthormono
- CommentTime4 Jun 2009 23:06 zmieniony
Zastanawiałem się nad takim handlerkiem urządzenia np. Z:, które pozwalałoby na dostęp do archiwum .ZIP/.GZ/.LHA/.LZH. Wydaje mi się, że rzecz byłaby dość przydatna piszącym programy w językach wyższego poziomu.

Na początek chciałbym tylko określić operacje i sposób dostępu do plików zapisanych w archiwum, a nie wnikać w to jakie konkretnie algorytmy obsługiwane byłyby przez taki handler.

Wyobrażam sobie, że taki handler będzie potrafił udostępnić archiwum za pomocą kanału IOCB. Samo archiwum mogłoby być ulokowane na dowolnym dostępnym urządzeniu.
Pełna wersja handlera powinna mieć możliwość:
a) odczytu pliku z archiwum,
b) utworzenia pustego archiwum,
c) dodania pliku do archiwum,
d) zmodyfikowania pliku w archiwum,
e) usunięcia pliku z archiwum,
f) zmiany nazwy pliku w archiwum,
g) utworzenie pustego katalogu w archiwum,
h) usunięcia katalogu z archiwum,
i) zmiany nazwy katalogu w archiwum,
j) odczytu zawartości katalogu z archiwum.
Operacja usunięcia archiwum byłaby raczej delegowana do urządzenia gdzie składowany jest sam plik archiwum, bo najczęściej jest to zwykłe skasowanie pliku.

Zastanawiam się też nad tym, jak powinny się odbywać operacje na archiwum, bo opcji jak zwykle jest kilka.

1. Dostęp za pomocą kilku kanałów IOCB.

Wykorzystanie archiwum wymagałoby otwarcia kanału dla samego pliku archiwum, po czym przekazania jego identyfikatora do kolejnego kanału umożliwiającego dostęp do plików wewnątrz archiwum.

a) odczyt z archiwum

Przykładowy program odczytu pliku INFO>README.TXT z archiwum ulokowanym na D1:ARCHIVE.ZIP wyglądałby tak:

10 OPEN #1,4,0,"D1:ARCHIVE.ZIP"
20 OPEN #2,4,1,"Z1:INFO>README.TXT"
30 DIM L$(255)
40 TRAP 80
50 INPUT #2; L$
60 PRINT L$
70 GOTO 50
80 TRAP 40000
90 CLOSE #2
100 CLOSE #1

Otwieramy najpierw kanał #1 dla dostępu do archiwum, po czym w linii 20 otwieramy kanał #2 podając ścieżkę w archiwum do pliku czyli INFO>README.TXT.
Oczywiście możliwe byłoby użycie też instrukcji GET.

b) zapis do archiwum

10 OPEN #1,12,0,"D1:ARCHIVE.ZIP"
20 OPEN #2,8,1,"Z1:INFO>README.TXT"
30 FOR I=1 TO 100
40 PRINT #2; "A TO jest "; I; "linia tekstu."
50 NEXT I
60 CLOSE #2
70 CLOSE #1

Tutaj otwieramy kanał #1 do odczytu i zapisu równocześnie, po czym kanał #2 do zapisu pliku INFO>README.ZIP.
Możliwe byłoby też użycie instrukcji PUT.
Jeżeli podana ścieżka w archiwum nie istnieje komunikowany byłby błąd.
Podając odpowiedni tryb dla #2 możliwy byłby:
- 8 - zapis
- 9 = 8+1 - zapis z dopisywaniem
- 12 = 8+4 - odczyt/zapis
- 13 = 8+4+1 - odczyt/zapis z dopisywaniem

c) utworzenie pustego archiwum

10 OPEN #1,8,0,"D1:ARCHIVE.ZIP"
20 XIO 254,#2,1,6,"Z1:"
30 CLOSE #1

Drugi parametr wskazuje np. na stopień kompresji (np. dla zip 6=best compression).

d) usunięcie pliku z archiwum

10 OPEN #1,12,0,"D1:ARCHIVE.ZIP"
20 XIO 33,#2,1,0,"Z1:INFO>README.TXT"
30 CLOSE #1

e) zmiana nazwy pliku w archiwum

10 OPEN #1,12,0,"D1:ARCHIVE.ZIP"
20 XIO 32,#2,1,0,"Z1:INFO>README.TXT INFO>CZYTAJTO.TXT"
30 CLOSE #1

f) utworzenie pustego katalogu w archiwum

10 OPEN #1,12,0,"D1:ARCHIVE.ZIP"
20 XIO 42,#2,1,0,"Z1:INFO"
30 CLOSE #1

g) usunięcie katalogu z archiwum

10 OPEN #1,12,0,"D1:ARCHIVE.ZIP"
20 XIO 43,#2,1,0,"Z1:INFO"
30 CLOSE #1

W przypadku gdy katalog nie jest pusty komunikowany jest błąd.
Kod operacji może być identyczny, jak dla usunięcia pliku z archiwum czyli 33.

h) zmiana nazwy katalogu w archiwum

10 OPEN #1,12,0,"D1:ARCHIVE.ZIP"
20 XIO 32,#2,1,0,"Z1:INFO COSTAM"
30 CLOSE #1

Kod operacji może być identyczny, jak dla zmiany nazwy pliku czyli 32.

i) odczyt zawartości katalogu z archiwum

10 OPEN #1,4,0,"D1:ARCHIVE.ZIP"
20 OPEN #2,6,1,"Z1:INFO>*.*"
30 DIM L$(255)
40 TRAP 80
50 INPUT #2; L$
60 PRINT L$
70 GOTO 50
80 TRAP 40000
90 CLOSE #2
100 CLOSE #1

j) usunięcie archiwum

10 XIO 33,#1,0,0,"D1:ARCHIVE.ZIP"

Może jednak rozsądniej byłoby pozostawić to zadanie handlerowi urządzenia, przez które dostępne jest archiwum (w tym przypadku D:).

Na kanale dającym dostęp do urządzenia składującego plik archiwum (w tym wypadku #1) nie powinno się realizować samemu żadnych operacji, które zmieniałyby położenie wewnętrznego wskaźnika lokacji pliku (dostępny za pomocą NOTE), bo mogłoby to spowodować problemy w poprawnym dostępie do struktury archiwum.

Należy też pamiętać, że z poziomu BASICa mamy dostępne tylko 5 kanałów, bo #0, #6 i #7 są zarezerwowane na urządzenia odpowiednio E: S: i obsługę instrukcji LPRINT, LOAD, SAVE (za "Atari BASIC" Miguta).

2. Dostęp za pomocą jednego kanału IOCB.

Pewnie technika byłaby znacznie prostsza od strony programisty BASICa, a bardziej skomplikowana dla kodera handlera. Dostęp nie wymagałby ręcznego otwierania kanału do archiwum, a specyfikowałoby się go w nazwie pliku np.:

10 OPEN #1,4,0,"Z1:INFO>README.TXT@D1:ARCHIVE.ZIP"

Handler Z: musiałby sam otwierać na pierwszym wolnym kanale IOCB plik (w tym wypadku D1:ARCHIVE.ZIP) w odpowienim trybie i wewnętrznie korzystać z niego.
Może dałoby się to nawet robić na tym samym kanale, co Z: (być może dałoby się jakoś podmieniać struktury ZIOCB/IOCB - taka sobie dywagacja).

Odpowiednie operacje wyglądałyby tak:

a) odczyt z archiwum

10 OPEN #1,4,0,"Z1:INFO>README.TXT@D1:ARCHIVE.ZIP"
20 DIM L$(255)
30 TRAP 70
40 INPUT #1; L$
50 PRINT L$
60 GOTO 40
70 TRAP 40000
80 CLOSE #1

b) zapis do archiwum

10 OPEN #1,8,0,"Z1:INFO>README.TXT@D1:ARCHIVE.ZIP"
20 FOR I=1 TO 100
30 PRINT #1; "A TO jest "; I; "linia tekstu."
40 NEXT I
50 CLOSE #1

c) utworzenie pustego archiwum

10 XIO 254,#1,0,0,"Z1:bufsize=8192@D1:ARCHIVE.ZIP"

Parametr z rozmiarem bufora podano w opisie urządzenia a nie jako parametr.

d) usunięcie pliku z archiwum

10 XIO 33,#1,0,0,"Z1:INFO>README.TXT@D1:ARCHIVE.ZIP"

e) zmiana nazwy pliku w archiwum

10 XIO 32,#1,0,0,"Z1:INFO>README.TXT@D1:ARCHIVE.ZIP INFO>CZYTAJTO.TXT"

f) utworzenie pustego katalogu w archiwum

10 XIO 42,#1,0,0,"Z1:INFO@D1:ARCHIVE.ZIP"

g) usunięcie katalogu z archiwum

10 XIO 43,#1,0,0,"Z1:INFO@D1:ARCHIVE.ZIP"

h) zmiana nazwy katalogu w archiwum

10 XIO 32,#1,0,0,"Z1:INFO@D1:ARCHIVE.ZIP COSTAM"

i) odczyt zawartości katalogu z archiwum

10 OPEN #1,6,0,"Z1:INFO>*.*@D1:ARCHIVE.ZIP"
20 DIM L$(255)
30 TRAP 70
40 INPUT #1; L$
50 PRINT L$
60 GOTO 40
70 TRAP 40000
80 CLOSE #1

Zaletą tego podejścia jest:
- możliwość realizowania operacji na archiwum z poziomu DOSa (szczegóły w jednym z postów niżej),
- brak możliwości "zepsucia" kanału dostępu do pliku z archiwum, bo jest on schowany przed użytkownikiem.

Podsumowując:

Handler urządzenia Z: pozwalałby na pełny dostęp do archiwum i implementowałby operacje CIO:

3 - open
5 - input
7 - get
9 - print
11 - put
12 - close
13 - status
6 - directory
32 - rename file/directory entry
33 - delete file
37 - point
38 - note
42 - mkdir
43 - rmdir
254 - format

Możliwe, że warto byłoby też mieć tryb bezpośredniego odczytu/zapisu katalogu jak w Sparta DOS X (tryby 4,8,9,12,13 przy otwarciu kanału), czy też dodatkowe operacje, jak:
- 35 - zabezpieczenie pliku/katalogu,
- 36 - odbezpieczenie pliku/katalogu,
- 39 - możliwość odczytu rozmiaru pliku,
- 49 - ustalanie atrybutów pliku/katalogu
ale chwilowo nie rozpatruję tych opcji.

W nazwach plików można byłoby używać jokerów * i ?. Podkatalogi rozdzielane byłyby znakiem > lub < (poziom w górę).

Na razie pomijam sprawy timestamp'ów plików w archiwum, uprawnień, haseł, blokad, użytkowników i grup.

Handler mógłby mieć dwie wersje:
- wersja pełna do tworzenia użytków,
- wersja okrojona do odczytu plików z archiwum do tworzenia gier.

Warto by też zastanowić się nad kodami błędów dla poszczególnych opcji. Pewnie najlepiej, żeby zachowana była kompatybilność ze Sparta DOS X.

Proszę o komentarze. Może specyfikacja jest niepotrzebnie rozbudowana i wystarczy mniej operacji lub prostsza konstrukcja handlera. Może ktoś coś takiego robił, lub ma swoje przemyślenia?
Zapraszam do dyskusji.
- 2: CommentAuthortebe
- CommentTime5 Jun 2009 00:06
Epi i Fox stworzyli depaker ZIP, GZIP-a itp. dla Sparty X
- 3: CommentAuthormono
- CommentTime5 Jun 2009 00:06 zmieniony
A skąd go można wziąć? Zakłada on jakiś handler dostępny z BASICa czy daje mi tylko funkcje?

Edit: binarka jest na stronie Zenona: ->link<- i u Epiego: ->link<- .
- 4:
  
  CommentAuthorKaz
- CommentTime5 Jun 2009 12:06
Mono - opisywane przez Ciebie rozwiazanie byloby, bez watpienia mala rewolucja w swiecie gier! Dlaczego? Bo dotychczas wszelkie programy, szczegolnie te pisane w "Turbo Basicu" czy "Action!" borykaja sie z mala iloscia dostepnej pamieci. Wiem cos o tym, bo w wielu takich projektach uczestniczylem/uczestnicze. Najswiezszy przyklad to "Sssnake It", gdzie z trudem zmiescilo sie kilka ekranow z grafika.

Gdyby Sikor mial mozliwosc uzywania handlera, ktory pozwala wczytac na przyklad spakowane graficzki (uzycie LZH jako uniwersalnego formatu dyskutowalismy tutaj: ->link<- ), to nie musialby walczyc o kazdy bajt w swoim programie, zeby zrobic gre jednoplikowa. To samo tyczy sie mnie i Scalaka na przykladzie gry "Dratewka The Shoemaker". Mozna by bylo zrobic o wiele wiecej lokacji niz obecnie, albo uzyc grafiki o wiekszych rozmiarach bez obawy, ze nie zmiesci sie na dyskietce (my wypelnilismy w calosci dysk SD). To samo tyczy sie Larka, ktory pracuje nad gra w Trubo Basicu, gdzie zostanie uzyte wiele grafiki w trybie GR9. To samo dotyczy gry "Kolony2106", ktora moze zmiescila by sie na dysku DD zamiast 360KB.
- 5: CommentAuthormono
- CommentTime5 Jun 2009 12:06 zmieniony
Ale czy taki dostęp do archiwów będzie wygodny?
Powiedzmy, że prędkość algorytmów to drugorzędna sprawa. Ważne chyba byłoby zapotrzebowanie na pamięć, żeby jednak jakiś program w BASICu mógł z tego handlera swobodnie korzystać (dlatego proponowałbym 2 wersje handlera).
Handler urządzenia można by ładować przed samą grą w BASICu (czy innym języku) z jakiegoś AUTORUN.SYS, albo z pliku wsadowego (poza Spartą widziałem kiedyś jakieś rozwiązanie - zdaje się w TA coś na ten temat było) więc to nie powinno nastręczyć problemów.
Czy zajmowanie 2 kanałów IOCB nie ograniczy za mocno programistów? Czy nie okaże się, że nagle kiedy potrzebujemy coś odczytać z kilku źródeł to zabraknie nam kanałów IOCB? Niby w 5 dostępnych kanałach (plus #7 o ile nie używamy róznocześnie LOAD, SAVE, LPRINT itp.) można by mieć dostęp do 3 różnych plików z różnych archiwów (jeśli da się buforować położenie wewnętrznego wskaźnika pliku, to można by mieć dostęp nawet do 5 różnych plików w jednym archiwum naraz).
Zdaję sobie sprawę, że zapotrzebowanie na operacje I/O zależy od rodzaju gry, ale może ktoś mógłby to jakoś oszacować na bazie własnych doświadczeń?
Z drugiej strony podnoszą się czasem głosy, że zamiast kompresować lepiej trzymać wszystko na twardym dysku. Chociaż miejsce na hdd też się czasem kończy...
- 6:
  
  CommentAuthorKaz
- CommentTime5 Jun 2009 13:06
Wskazalem konkretne osoby w mojej wypowiedzi z nadzieja, ze to wlasnie one wypowiedza sie co do Twoich pomyslow. Bo kto jak nie uzytkownicy rozwiazania beda wiedziec, co im jest potrzebne i w jakis sposob ma to dzialac? :)

Larek, Scalak, TDC, Sikor i wszyscy, ktorzy programuja w jezykach wyzszego poziomu - panowie, jest szansa na fajne rozwiazanie problemow, ale okreslcie sie, co Wam potrzebne/niepotrzebne.

PS. Wiadomo, ze tendencją jest odchodzenie od dziewiczego Atari (VBXE, twardy dysk, SIO2SD, etc), ale jednak warto by pomyslec o rozwiazaniach dzialajacych na standardowych sprzetach. Nowe rozwiazania - tak! Ale nie zamiast starych.
- 7: CommentAuthortebe
- CommentTime5 Jun 2009 18:06 zmieniony
depaker ZIP-a, GZIP-a Epi-ego korzysta zapewne z kodu FOX-a (INFLATE.ASM), w takim przypadku aby dekompresja była możliwa depaker musi mieć dostęp do całego spakowanego archiwum (spakowany plik musi znajdować się w pamięci), zdekompresowane dane mogą już być zapisywane dowolnie, np. na ramdysk

nie jestem pewien ale jeśli Sparta X udostępnia komendę SEEK (ustawia odczyt danych od konkretnego bajtu w pliku) wówczas możliwe byłoby dokonanie dekompresji czytając tylko z dysku, zwykły Atari DOS tego nie obsłuży, to musi byś profesjonalny DOS :)

p.s.
w dokumentacji do Sparty znalazłem FTELL i FSEEK, tak że jeśli to działa tak jak myślę to pewnie Epi skorzystał z tej właściwości aby dokonać dekompresji czytając tylko z dysku bez zajmowania dodatkowo pamięci, Wasz handler także musiałby korzystać z tej właściwości SpartyX
- 8: CommentAuthormono
- CommentTime5 Jun 2009 19:06 zmieniony
Dzięki Tebe za podpowiedź.
Póki co nie analizowałem jeszcze kodu inflate, ale zdaje się, że w lzw (publikowanym w TA przez Mathnoida) budowany był słownik, który po przekroczeniu założonego rozmiaru był resetowany i tworzony na nowo co pewnie umożliwiałoby strumieniową (albo prawie) dekompresję.
Kwestia algorytmu kompresji jest otwarta, choć jeśli wymagałby seek i tell to na pewno łatwiej wyjść od dos'a, który to już ma, niż implementować na własną rękę łatki.
- 9: CommentAuthortebe
- CommentTime6 Jun 2009 00:06
cytat wypowiedzi Epi-ego:

"Tia, mono pisał do mnie sam. xunzip działa z dowolnym DOSem (a przynajmniej nie znaleźliśmy takiego, z którym nie działa), potrzebuje (oprócz miejsca na kod i tablice) 32kB na bufor wyjściowy i to wystarczy do rozpakowania plików o dowolnej długości (testowane do prawie 16MB) przy pełnej szybkości inflate. Fseek i ftell są używane tylko do pomijania plików pod Spartą (o ile dobrze pamiętam, dyskową też, nie tylko X - w innych DOSach zamiast tego jest po prostu odczyt odpowiedniej liczby bajtów). Xunzip czyta archiwum sekwencyjnie, stąd fseeki są tylko w przód.
Sam algorytm inflate potrzebuje całego bufora 32kB do kopiowania z niego powtórzonych fragmentów (głębiej nie sięga). Zrobienie krótszego bufora będzie wymagało zaaplikowania któregoś z ograniczeń:
1) zastosowanie deflate z krótszym zakresem sięgania wstecz - czyli będzie można stosować tylko do specjalnie przygotowanych zipów,
2) sprawdzanie przy każdym kopiowaniu ciągów z już rozpakowanego fragmentu, czy mamy odpowiedni kawałek bufora jeszcze w pamięci, czy już został z niej wyrzucony i jest tylko w pliku - wtedy trzeba doczytać odpowiedni fragment,
3) ograniczenie od góry długości plików w archiwum do mniej niż 32kB.

Więcej szczegółów udzielić może 0xF.

Możesz też wkleić do wątku to co napisałem powyżej."
- 10: CommentAuthormono
- CommentTime6 Jun 2009 09:06 zmieniony
Tak, ten bufor 32k to jest niestety dość duży limit :( 8kB mamy pod BASICem, 14kb pod OSem co daje łącznie 22kB i brakuje 10.
W aplikacjach Atari BASIC nie korzystających ze Spart w wersji przed X (np. moja "ulubiona" 3.2d) można by próbować ten obszar wykorzystać, ale co z ACTION!, BASIC XL, BASIC XE? Stare Sparty zakładają pod ROMami swoje bufory dla sektorów co przyspiesza dostęp np. do zawartości katalogów więc tego obszaru tam nie da się wykorzystać. Z drugiej strony niewykluczone, że w tych buforach znalazłyby się dane potrzebne do dekompresji a więc sięgając bezpośrednio do pliku (a nie do RAM) dostalibyśmy szybko co trzeba bez fizycznego czytania dysku. W innych DOSach stacja pewnie zajechałaby się na śmierć podczas dekompresji :).
Można by też szukać rozszerzenia RAM lub VBXE :), a na pewno warto byłoby dowiedzieć się jakiego DOSa właśnie używamy (choćby po to, żeby wiedzieć czy i jak użyć point czy też poczytać sobie z pliku ile trzeba).
Pomysł ze specjalnie preparowanym archiwum na potrzeby algorytmu o mniejszych wymaganiach pamięciowych nie jest taki zły jeśli przyjąć, że programista ma możliwość manipulacji wielkością bufora do dekompresji np. w jakiejś konfiguracji, albo w narzędziu do generowania pliku handlera. Albo może np tak:
10 XIO 240,#1,0,0,"Z:bufsize=8192"

Tym bardziej, że przy równoczesnym dostępie do kilku plików w archiwum, lub kilku archiwów może się okazać, że dla każdego trzeba będzie trzymać osobny bufor.
- 11: CommentAuthormono
- CommentTime6 Jun 2009 10:06 zmieniony
Rozmyślam nad drugą metodą dostępu do archiwów czyli za pomocą jednego IOCB i przyszła mi do głowy taka myśl, że w ten sposób można by łatwo tworzyć archiwa za pomocą dowolnego DOSu.
Bo też i utworzenie archiwum to sformatowanie Z:
```
D1:init Z1:@D1:atari.zip
```
Utworzenie katalogu gry:
```
D1:mkdir Z1:gry@D1:atari.zip
```
Dalej skopiowanie pliku:
```
D1:copy H1:atari>fred.xex Z1:gry>@D1:atari.zip
```
Pokazanie katalogu archiwum:
```
D1:dir Z1:*.*@D1:atari.zip
```
Zmiana nazwy pliku:
```
D1:rename Z1:gry>fred.xex@D1:atari.zip kosz>smiec.xex
```
Usunięcie pliku:
```
D1:erase Z1:kosz>smiec.xex@D1:atari.zip
```
Zmiana nazwy katalogu:
```
D1:rename Z1:gry@D1:atari.zip smieci
```
Usunięcie katalogu:
```
D1:rmdir Z1:smieci@D1:atari.zip
```
Usunięcie archiwum:
```
D1:erase atari.zip
```
Problem z przekazywaniem parametrów np. do kompresji lub formatowania można by rozwiązać rezygnując z parametrów operacji XIO (aux1, aux2) na rzecz zapisania ich w opisie urządzenia:
10 XIO 254,#1,0,0,"Z:bufsize=8192@D1:ATARI.ZIP"

i analogicznie z poziomu DOSa:
```
D1:init Z1:bufsize=8192@D1:atari.zip
```
albo też:
```
D1:copy H1:atari>fred.xex Z1:gry>fred.xex;compression=best@D1:atari.zip
```
No i oczywiście w drugą stronę:
```
D1:copy Z1:gry>fred.xex@D1:atari.zip H1:atari>fred.xex
```
Przy podejściu opisanym pierwszą metodą, a więc z wykorzystaniem 2 kanałów IOCB nie dałoby się użyć DOSu do tych operacji.

Edit: Opisałem w pierwszym poście operacje w podejściu 2.
- 12:
  
  CommentAuthorsikor
- CommentTime6 Jun 2009 13:06
A propo pakowania w Turbo Basicu - można skorzystać z Super Packera, jednak muszę się dopytać Mikera o szczegóy. Wbrew pozorom nie jest to jakoś super trudne (trzeba bodajże pominąć kilka bajtów nagłówka, przepisać odpowiednie dane w odpowiednie miejsce oraz skorzystanie z depakera pod odpowiednim adresem). Tej metody nie mogłem zastosować tylko i wyłącznie ze względu na założone "efekty" w grafice.
Co do handlera: trzeba by go "wkopiować" w program, aby móc użyć w file-u. Poza tym - nie wiem, czy to nie byłaby skórka za wyprawkę (tracimy sporo miejsca na implementację).
- 13: CommentAuthormono
- CommentTime6 Jun 2009 15:06 zmieniony
@Sikor:
Jeśli mówisz o file'u uruchamialnym (.xex) to można program główny poprzedzić handlerem i na inicie go zainstalować. Jeśli chodzi o sam plik .bas, to jedyny sposób, jaki mi przychodzi do głowy to zaszycie kodu handlera w sekcji DATA lub w zmiennej tekstowej i zrelokowanie na górę dostępnej pamięci + obniżenie RAMTOPa.
Masz rację - handler zajmie trochę pamięci na struktury wymagane przez system i implementację odpowiednich procedur CIO. Może faktycznie w gotowych produkcjach (grach) używać zwykłego kawałka kodu w DATA albo w zmiennej tekstowej i odpalać go przez USR podając odpowiednie parametry.
Z tego co piszesz rozumiem, że SuperPacker kompresuje dowolny plik i można sobie go potem rozkompresować procedurą we własnym programie. Nie wiem, czy czyta on z archiwum znajdującego się na dysku, czy trzeba je sobie najpierw załadować do pamięci? Zaletą mojego rozwiązania byłoby właśnie to, że dostałbyś od razu strumień danych rozkompresowanych nie potrzebując wczytywać do pamięci samego archiwum, które niepotrzebnie by ją wtedy zajmowało. Jak działają dostępne procedury depakujące?
Czy SuperPacker kompresuje kawałek pamięci i tworzy plik binarny z programem uruchamiającym się zaraz po wczytaniu i rozkompresowującym dane po czym skaczącym w konkretne miejsce pamięci (zdaje się crunchery tak działały)?
- 14: CommentAuthortebe
- CommentTime6 Jun 2009 15:06
kiedy skończy się Wasze "dyskietkowe" myślenie, jest SpartaX + HDD, przy takiej konfiguracji nie musicie przejmować się pakowaniem i depakowaniem czegokolwiek, założycie sobie katalog z Waszą grą + kilka tysięcy plików z grafiką, muzyką itp. Waszym jedynym zmartwieniem będzie wyobrażenie sobie jak to wykorzystać w Waszej produkcji
- 15:
  
  CommentAuthorKaz
- CommentTime6 Jun 2009 16:06
"Dyskietkowe" myslenie pozwoli odpalic program zarowno posiadaczowi stacji dyskow, SIO2SD jak i twardego dysku. Zas "twardodyskowe" myslenie wyklucza tych, ktorzy twardego dysku nie maja.
- 16: CommentAuthortebe
- CommentTime6 Jun 2009 16:06
pobawcie się Tym, skończą się Wasze problemy z pamięcią

->link<-
- 17: CommentAuthormono
- CommentTime8 Jun 2009 08:06 zmieniony
Dyskietkowe, nie dyskietkowe. Chodzi o wygodę korzystania z archiwów z poziomu BASIC'a lub innego języka wysokiego poziomu.
Ja wiem, że mamy dzisiaj sd, hdd, sio2pc, pamięci której nie jesteśmy w stanie zapełnić danymi (hehe), karty ale ciągle są oldskoolowcy, którzy będą chcieli coś fajnego zrobić na gołej 800xl :) po to, żeby dało się to odpalić z dyskietki, albo na gołym emulatorze bez supportu odpowiedniego karta. I m.in. dla nich taki handler może i byłby użyteczny (?). Np. w kontekście dyskusji o uniwersalnym formacie graficznym, którą przywołał Kaz ( ->link<- ).
- 18:
  
  CommentAuthorWolfen
- CommentTime8 Jun 2009 11:06
jedno malutkie pytanie... czy zip nie spowoli zanadto transmisji w jedna czy druga strone ? pytam tylko zebysmy nie doszli do absurdu kiedy odczyt danych z archiwum bedzie wolniejszy niz z kasety (podejzewam ze standardowe 600 bodow bedzie mozna na pewno przescignac ale czy mamy szanse z turbo blizzard? ;)
- 19: CommentAuthormono
- CommentTime8 Jun 2009 14:06
Tego nie wiem, bo to zależy od implementacji (np. algorytmu 0xF'a, który prawdopodobnie zostanie użyty). Jak dotąd skupiałem się raczej nad wygodą dostępu do archiwów, a nie zastanawiałem się nad prędkością działania dekompresora :)
- 20:
  
  CommentAuthorWolfen
- CommentTime8 Jun 2009 14:06
chyba ze mozna przerzucic na cos obliczenia zwiazane z kompresja/dekompresja ? (nie mowie tu o osobnym chipie i kabelkologii jakiejs ale rozwiazaniu bezingerencyjnym... chociaz patrzac czasem na nowinki ktore nasi spece-elektronicy tutaj wynajduja nie zdziwie sie jak ktos wpadnie na pomysl przerzucenia obliczen na silniczek od magnetofonu :)
- 21: CommentAuthormono
- CommentTime8 Jun 2009 15:06
Albo na generator liczb pseudolosowych :)

Od 1 do 21 z 21