1

(1 odpowiedzi, napisanych Kupię / Sprzedam / Zamienię Atari)

to ja standardowo zacznę od 51,2zł dla równego rachunku.

OK, wygląda na to że nikt więcej nie licytował. Wpłata do zbiórkę dokonana. Szczegóły wyślę via e-mail.

3

(7 odpowiedzi, napisanych Sprzęt - 8bit)

nie tylko "cubeniculosis", w "sky computer 9" (a właściwie to 10), słychac to najbardziej. Zapewne wszystkie kanały L/R we wszystkich utworach są zamienione (przy jednym ze źródeł dźwieku).

EDIT:Nie chciałem tego pisać wcześniej aby tego nie sugerować nikomu w wątku, ale skoro to napisałeś to "już po ptakach" ;-)

4

(7 odpowiedzi, napisanych Sprzęt - 8bit)

Moje typy to:

Cubeniculosis:    A - POKEY,  B - SUB
Cyberpunk    :    A - SUB,    B - POKEY
Draconus     :    A - SUB,    B - POKEY
Extirpator   :    A - SUB,    B - POKEY
IK           :    A - POKEY,  B - SUB
Rewind2      :    A - POKEY,  B - SUB
SkyComputer9 :    A - SUB,    B - POKEY

5

(4 odpowiedzi, napisanych Emulacja - 8bit)

Hej!

Podpowiesz gdzie jest jakiś help/doc do xedisk? zbudowałem sobie go pod Linuxem (gdc, gdmd wrapper) ale próba ./xedisk help daje tylko "no help yet", w repo na github nie widzę też pliku z jakąś bardziej szczegółową dokumentacją. make doc buduje tylko małego html-a który nie zawiera zbyt dużo informacji, a "man" mówi że dokumentacji mam szukać w repo na github, ale chyba jestem ślepy bo znaleźć nie mogę ;)

EDIT: Zajrzałem do źródeł, udało mi się uzyskać to co chciałem:

./xedisk create -f mydos thnd_mydos.atr
./xedisk write-dos -D mydos450t thnd_mydos.atr 
./xedisk add thnd_mydos.atr handler.xex
./xedisk list thnd_mydos.atr 
dos.sys
dup.sys
handler.xex

licytuję zatem 51,2 zł dla równego rachunku! :D

No to wystawiaj ponownie! :D Czekam aż będę mógł zalicytować ;)

8

(3 odpowiedzi, napisanych Kupię / Sprzedam / Zamienię Atari)

Hej!

Wpłata na Emilię poszła! Reszta szczegółów via email.

Dzięki!

9

(6 odpowiedzi, napisanych Kupię / Sprzedam / Zamienię Atari)

Hej!

Wpłata na Emilię poszła! Reszta szczegółów via email.

Dzięki!

10

(3 odpowiedzi, napisanych Kupię / Sprzedam / Zamienię Atari)

na start daję 32zł.

11

(6 odpowiedzi, napisanych Kupię / Sprzedam / Zamienię Atari)

51 zł 2 gr.

12

(6 odpowiedzi, napisanych Kupię / Sprzedam / Zamienię Atari)

na start daję 32zł dla równego rachunku ;)

13

(56 odpowiedzi, napisanych Miejsca w sieci)

Szacunek za masę włożonej w ten projekt pracy! Dzięki!

Hej!

Dzięki za linka, przetestowałem na nim czy ten mój stary skrypt (python) jeszcze działa, bo nie pamiętałem stanu w jakim go zostawiłem. Okazało się że działa bez większego problemu. W załączniku wynik działania programu (w archiwum wygenerowany plik .XEX oraz .HEX który został poddany konwersji. Z kolei do stworzenia pliku .HEX wykorzystałem a8cas-util autorstwa FUJI-ego.  Zresztą po więcej szczegółów i chyba miarę sensowny opis użycia tego mojego prymitywu można podejrzeć na GitHub, o tutaj: T2K Tools.

Mam nadzieję że się przyda, ja korzystałem z tego własnie przy konwersji do XEX-ów taśm zapisanych w standardowym formacie Turbo KSO/2000F/2001. Narzędzie jest naprawdę prymitywne, bo nie sprawdza poprawności danych zawartych w pliku .HEX, po prostu zakład że dostarczony plik .HEX nie zawiera błędów (uszkodzonych rekordów, rekordów z błędnym CRC). Tworząc go założyłem że "a8cas-util" wykona swoją robotę poprawnie, czyli podczas przetwarzania nie będzie żadnych błędów:

./a8cas-util.pl conv -t turbo2000 hobby_tronic_90.wav hobby_tronic.hex
Starting ecasound... started.
SUMMARY: Data blocks: 28 (0 Errors).
86 HEX blocks stored in file hobby_tronic.hex.

potem można wywowałać extract_t2k.py:

./extract_t2k.py hobby_tronic.hex
nazwa pliku T2K: "HOBBY TRO."

Przetwarzam blok nr 001 o długości 3072 bajtów.
Przetwarzam blok nr 002 o długości 3072 bajtów.
Przetwarzam blok nr 003 o długości 3072 bajtów.
Przetwarzam blok nr 004 o długości 3072 bajtów.
Przetwarzam blok nr 005 o długości 3072 bajtów.
Przetwarzam blok nr 006 o długości 3072 bajtów.
Przetwarzam blok nr 007 o długości 3072 bajtów.
Przetwarzam blok nr 008 o długości 3072 bajtów.
Przetwarzam blok nr 009 o długości 3072 bajtów.
Przetwarzam blok nr 010 o długości 3072 bajtów.
Przetwarzam blok nr 011 o długości 3072 bajtów.
Przetwarzam blok nr 012 o długości 3072 bajtów.
Przetwarzam blok nr 013 o długości 3072 bajtów.
Przetwarzam blok nr 014 o długości 3072 bajtów.
Przetwarzam blok nr 015 o długości 3072 bajtów.
Przetwarzam blok nr 016 o długości 3072 bajtów.
Przetwarzam blok nr 017 o długości 3072 bajtów.
Przetwarzam blok nr 018 o długości 3072 bajtów.
Przetwarzam blok nr 019 o długości 3072 bajtów.
Przetwarzam blok nr 020 o długości 3072 bajtów.
Przetwarzam blok nr 021 o długości 3072 bajtów.
Przetwarzam blok nr 022 o długości 3072 bajtów.
Przetwarzam blok nr 023 o długości 3072 bajtów.
Przetwarzam blok nr 024 o długości 3072 bajtów.
Przetwarzam blok nr 025 o długości 3072 bajtów.
Przetwarzam blok nr 026 o długości 3072 bajtów.
Przetwarzam blok nr 027 o długości 0268 bajtów.

Operacja zakończona, plik 'hobby_tronic.xex' o długości 80140 bajtów zapisano.

Mam nadzieję ze to pomoże w wyłuskiwaniu plików z nagrać zapisanych w standardowym formacie Turbo KSO/2000F/2001. I nie będzie trzeba już walczyć z kopierami, etc. Oczywiście poszukam jeszcze tego handlera "T:", mam nadzieję że gdzieś jeszcze mam źródła to może wrzucę do repo na GitHub, a jak nie to chociaż spróbuję namierzyć samą binarkę.

Miałem jeszcze parę innych prostych bash-owych skryptów do automatyzacji konwersji całych taśm, ale nie mogę tego teraz namierzyć, to było sporo czasu temu i nie sądziłem że komukolwiek to może być potrzebne i przydatne. Jak znajdę bedę wrzucał na GitHUB.

Możecie mi podesłać link do tego "Hobby Tronica '90" w wersji WAV/FLAC, chciałem sprawdzić mój stary skrypt do bezpośredniej konwersji z formatu Turbo KSO/2000/F zapisanego w postaci .HEX (atari8cas-util.pl) do .XEX. Naklepałem go kiedyś w jakimś pośpiechu i jest wręcz prymitywny, ale jeżeli miałby pomóc w konwersji to go oczywiście udostępnię.

Kiedyś o tym chyba gdzieś wspominałem, ale popełniłem handler "T:" który instalował się jako rezydent pod DOS (używałem w tamtych czasach) MyDOS 4.53 który miałem wbudowany w stację Toms 720. Sprawdzało mi się to doskonale, bo standardowe (3kB bloki) w Turbo KSO/2000/F można kopiować porcjami, tzn. czytasz rekord i zapisujesz od razu to od razu do drugiego otwartego pliku (np. na dyskietkę). Muszę tego poszukać, sądzę że gdzieś to przetrwało (o ile już tego kiedyś gdzieś nie wrzuciłem, ale to mogło być dawno temu i już nie pamiętam gdzie i czy w ogóle).

Hej!

Tak na szybko i nieco w biegu... udało się wprowadzić poprawki i dodać dodatkowe opcje:

- optymalizacja pętli czytającej bloki danych, udało się zaoszczędzić trochę cykli! dzięki temu...
- sprawdzane jest przepełnienie bufora (próba wczytania za długiego pliku skończy się błędem $9E (158 dec) - "OUT OF MEMORY"
- dodane sterowanie silnikiem
- w release jest już ATR zawierający BW-DOS w wersji 1.30 wraz z Anty *AJEK.
- poprawiono drobny błąd przy zaokrąglaniu MEMLO do granicy strony.
- drobna poprawka w procedurze wyboru interface z którego program będzie czytał dane

do pobrania tutaj: "Anty *AJEK Copy v.1.5"

bufor dostępny z poziomu BW-DOS wynosi: 53504 bajtów ($D100)
bufor dostępny bez ładowania DOS wynosi: 59658 bajtów ($E900)

ale jak pisałem wcześniej, wielkość bufora oznaczy tylko i wyłącznie ograniczenie maks. wielkości pojedynczego bloku, tzn. jeżeli program będzie się składał z 10 bloków po 50 kB, to nie będzie dla programu problemem, on przetwarza dane sekwencyjnie. Czyta wszystko do momentu wystąpienia kolejnego tonu synchronizującego.

takron27 napisał/a:

jeśli będzie za mało pamięci na dekodowany program, to co, antyajek zgłosi jakiś błąd/komunikat? czy to że nie podsumuje 'kodem 01' zakończenia tworzenia xexa ?

Właśnie mi uświadomiłeś że nie pamiętam czy ja w ogóle sprawdzam przepełnienie bufora, sprawdzę bo naprawdę nie pamiętam :D

EDIT: tak dla uścislenia, bufor programu wyświetlany po starcie, np. MEM: $E800 oznacza maksymalny rozmiar bloku jaki na raz można wczytać do pamięci. Anty *AJEK wczytuje do tego bufora do momentu aż nie wystąpi następny blok poprzedzony tonem "synchronizującym". Gdy tylko taki blok się uda wczytać, program zatrzymuje silnik/odczyt z taśmy i nagrywa zawartość bufora na dysk, po czym wznawia odczyt i tak do końca pliku.

EDIT2: zajrzałem do źródeł, obliczam co prawda długość bloku do wczytania, ale zupełnie ignoruję fakt że dane mogą się w buforze nie zmieścić, efekt przy przepełnieniu bufora będzie taki że gdy ostatni bajt bufora zostanie zapełniony ($FFFF <--- koniec RAM po OS-ROM), to program zacznie mazać od początku pamięci (od adresu $0000) i nastąpi spektakularna klapa i zamazanie istotnych zmiennych na stronie zerowej, jeżeli to jakimś cudem nie spowoduje "zwiechy", to następnym obszarem do zamazania będzie stos ($0100-$01FF) a zamazanie tego obszaru już na pewno doprowadzi do katastrofy i nieuchronnej zwiechy systemu.

Prawdę mówiąc nawet nie mam pomysłu jak sprawdzać dodatkowe warunki, format Speedy2700 daje niewie czasu na operacje ponieważ strumień bitów leci bezustannie i dodawanie nowych instrukcji w trakcie odczytu strumienia (np. sprawdzanie końca bufora) zmienia zależności czasowe pętli odczytującej dane... i może być tak że to co będzie się wczytywało ze standardowym loader-em Speedy2700 nie będzie chciało się czytać w Anty *AJEK. Pomyślę jak to rozwiązać, może coś mi wpadnie do głowy.

Tak naprawdę należałoby wiedzieć jakim buforem dysponował "*AJEK COPY", jest szansa że "Anty *AJEK" uruchomiony bez DOS, z buforem na poziomie $E800 ma większy bufor na dane niż ten którym dysponował "*AJEK COPY".

takron27 napisał/a:

1. czy bw-dos 1.30 jest preferowany, czy może być dowolny?

BW-DOS jest preferowany tylko i wyłącznie tylko przeze mnie ;) Możesz użyć dowolnego DOS-a który Ci odpowiada, wybieraj takiego który ma niskie MEMLO, wtedy "Anty *AJEK" będzie miał większy bufor na swoje dane.

Używam BW-DOS  z kilku powodów, po pierwsze bardzo łatwo mogę sobie stworzyć ATR z dowolną zawartością (używam tego narzędzia pod Linux: Atri ATR disk image tools). Po drugie filesystem (zgodny ze Sparta-DOS) umożliwia bardzo szybki dostęp do dowolnego miejsca pliku. Aby dostać się np. bo bajtu 32767 nie trzeba czytać całego pliku aby zorientować się w którym sektorze są dane o które pytasz, po prostu operacja "seek" działa w tym systemie błyskawicznie. Tę właściwość tego filesystem-u wykorzystuje właśnie narzędzie "offload", które działa błyskawicznie, a o którym poniżej...

takron27 napisał/a:

2. nie znam się: po stworzeniu xexa wychodzisz do bw-dosa i dajesz komendę 'offload gallahad.xex'.
co robi ten offload, czy trzeba to zrobić na stworzonym xex zanim go się uruchomi?

Narzędzie "OFFLOAD" z pakietu BW-DOS służy tylko i wyłącznie do pokazania struktury pliku binarnego, nie musisz go w ogóle uruchamiać, wspominanym filmie używam go tylko po to aby pokazać że po konwersji powstaje plik .XEX o prawidłowej strukturze i że nic nie jest uszkodzone.

takron27 napisał/a:

3. czy z wave trzeba usunąć początek (nagłówek programu w t2000kso i loader ajka) zostawiając samo nagranie w speedy2700 ? ; czy nie trzeba a Twój antyajek po prostu pomiine sobie ten fragment wave'a?

Anty *AJEK oczekuje danych które znajdują się po loaderze, próba wczytania nazwy czy standardowego bloku turbo (np. loader) zakończy się błędem. Mogłem dodać pomijanie loadera, ale to by wydłużyło program o kolejne bajty i zmniejszyło pojemność bufora na dane. W 1992 roku po prostu przewijałem sobie kasetę do właściwego miejsca. Ale w dzisiejszych czasach w dobie emulatorów, no cóż... konieczność pomijania loadera może być nieco upierdliwa. W przypadku gdy używam Altirra, po prostu przestawiam sobie ręcznie pozycję taśmy (menu cassette --> tape control) do odpowiedniego momentu, tak aby ustawić się na tonie pilotującym tuż za loaderem... takie postępowanie wynikało z tego że nie chciało by mi się generować kolejnych plików WAV z usuniętym loader-em. W przypadku Atari800 + FUJI extensions to chyba trochę mniej wygodne (przewijanie taśmy w menu) ale chyba tez do zrobienia, nie pamiętam czy jednak czy tam gradacja przewijania nie była jakaś mocno zgrubna (1 sekunda nagrania?), mogę źle pamiętać.

Twoje pytanie spowodowało że pomyślałem że może warto dodać opcję włączenia silnika na żądanie tuż przed odczytem, tak aby móc "pominąć" loader przez "przeczekanie" pierwszego bloku "na włączonym silniku". Ta funkcjonalność powinna się zmieścić bez zmniejszania bufora, parę bajtów tu i ówdzie pamięci jeszcze pozostało. Dodam to listy "to do".

to tak jeszcze podsumowując sprawę programów kopiujących obsługujących rozszerzoną pamięć, to z tych które znam są to dwa programy "z epoki":

File Copier 130XE  - autor J.Żuk:
https://pigwa.code32.org/aa/copiers/file_copier_130XE.png

Subcopy 1.3 - autor Krzysztof Butowski:
https://pigwa.code32.org/aa/copiers/subcopy_v1.3.png

Ciekawostką jest fakt że wszystkie te programy pochodzą z 1987 roku. Nie wiem skąd ta zbieżność dat wydania tych kopierów :)

Są takie programy kopiujące które używają EXT RAM jako bufora, jednak jest ich niewiele. Dlaczego? Sądzę że to dlatego że w czasach kiedy dominującym nośnikiem była kaseta, mało kto miał komputer dysponujący rozszerzoną pamięcią RAM. Ja sam długo, długo miałem gołe 65XE bez żadnych dodatków. Mam wrażenie że w pewnym momencie "sportem narodowym" stało się pisanie wszelakiej maści programów kopiujących które to byłby jak najbardziej kompaktowe i miałby jak największy bufor (bez wykorzystania rozszerzonej pamięci).

Podsumowując, jak najbardziej się da, napisanie takiego programu jest nawet prostsze niż wyciskanie ostatnich soków podstawowej pamięci RAM. Dodatkowo w przypadku formatów takich jak Turbo 2000/F/KSO gdzie występował standardowy format zapisu danych (podział na bloki) można było po prostu wykorzystać RAMDISK i dowolny program kopiujący który umożliwiał wyspecyfikowanie urządzenia do odczytu/zapisu, można było przetwarzać taki plik po kawałku.

Problem pojawiał się w nietypowych formatach, takich jak np. Speedy2700/*AJEK, bo tutaj strumień danych leci ciągle ledwie starcza czasu na pakowanie tego w podstawowy RAM, gdy pisałem Anty *AJEK to nie miałem do dyspozycji zbyt dużej programów zapisanych w tym formacie, a to co miałem bez problemu mieściło się w podstawowej pamięci RAM, więc nawet nie myślałem aby korzystać z rozszerzenia pamięci, prawdę mówiąc to nawet nie pamiętam czy w 1992 roku, w chwili gdy pisałem ten soft, to czy miałem już rozszerzoną pamięć w swoim 65XE.

Jeżeli chodzi natomiast o kopiowanie programów zapisanych w standardzie, to tutaj już odczyt musiał następować bez przerw i całość nagrania (lub bloku danych poprzedzonych tonem pilotującym) musiała na raz trafić do RAM, przy standardowych przerwach międzyrekordowych (IRG) nie było mowy o tym że zatrzymamy sobie silnik magnetofonu (gdy skończy się bufor) i zapiszemy sobie dane gdzieś indziej. Krótkie przerwy i duża bezwładność mechaniki powodowało że po ponownym włączeniu silnika taśma była już poza początkiem rekordu i poprawny odczyt nie był dalej możliwy. Wykorzystanie pamięci dodatkowej oczywiście wchodziło w grę, jednak jak pisałem wcześniej gros ludzi nie posiadało dodatkowego RAM, a w dodatku jedynym urządzeniem I/O był magnetofon, często również nie był to magnetofon "firmowy", tylko jakiś inny kaseciak + dodatkowy interface. Część z tego typu rozwiązań nie posiadała również możliwości sterowanie silnikiem zew. magnetofonu. Wspominałem już o tym nie raz, ale ja np. początkowo używałem magnetofonu szpulowego do przechowywania programów.

To były czasy w których programy kopiujące "taśma <--> taśma" publikowano w prasie, np. słynny "Buldoger Copy", więc siłą rzeczy takie programy były bardzo minimalistyczne i miały działać na każdym komputerze, nikt wtedy nie myślał o wykorzystaniu dodatkowej pamięci.

TLDR: dało się, ale większości przypadków nie było to potrzebne ;-)

Połatana na szybko wersja 1.4 --> "Anty *AJEK Copy v.1.4".

Zmiany:
- załatany błąd z zapisem śmieci z bufora (bufor programu jest po prostu wyrównywany do początku pierwszej wolnej strony pamięci)
- dodane możliwość wyboru urządzenia H: lub D: przy zapisie pliku wyjściowego
- dodana (dość dawno) opcja wyjścia do DOS (ale zapomniałem tego opublikować, przynajmniej na GitHUB, stąd przeskok od raz do wersji 1.4)

ps) ja naprawdę nie sądziłem że po 1992 roku będe kiedykolwiek wracał do poprawiania tego programu :D

jeżeli chodzi o ustawienia emu, metod dekodowania, etc. to macie w tym o wiele większe doświadcznie niż ja! :D Ja dawno się tym nie zajmowałem, bo na głowie miałem inne rzeczy, także na pewno przewyższacie mnie doświadczeniem w tej kwestii. Na pewno jeżeli baktra o czymś mówił to na pewno racja jest po jego stronie, bo ma o wiele większe doświadcznie z walką z różnymi systemami turbo. Oczywiście używam też atari800 z modyfikacjami od FUJI-ego, ale akurat ostatnio pod ręką inny komputer niż zwykle więc miałem do dyspozycji tylko Altirrę odpaloną z pomocą wine.

takron27 napisał/a:

powiem, że sam bym wziął na siebie ,już nie sprawdzanie obliczanie co pasuje co nie do obliczonego X, a powyciągał xexy z moich ripów taśm.  jak tylko ogarnę 'jak to zrobić' (mając tylko emu, bez zabawy czy testu na realnym sprzęcie).

Jeżeli mówisz o nagraniach *AJEK/Speedy2700 to można użyć "Anty *AJEK" (źródła i release jest na GitHUB). Ale poczekaj chwilę, zrobię poprawkę wrzucę wersję 1.3. Myślę jednak intensywnie aby po prostu napisać cały dekoder odpalany na PC, aby nie męczyć się z emulacją czy też prawdziwym sprzętem.

takron27 napisał/a:

altirra ma inną swoja korekcję błędów, ma na stałe jakiś filtr górnoprzepustowy włączony, nie zawsze jej odpowiada głośność nagrania.

HPF (high pass filter) w przypadku Altirra można wyłączyć w opcjach Configure System-->Peripherals-->Cassette-->Turbo Decoder na "SLOPE".

Jeżeli chodzi o głośność to ja przed wczytywaniem do jakiegokolwiek emulatora to zawsze sobie wcześniej nagranie "obrabiam" chociażby w audacity, czyli normalizuję głośność i czasami jak widzę że jest jest źle to robię "usunięcie składowej stałej" (tzw. "DC Removal").

@takron27: no można określić które są uszkodzone, jeżeli poznamy ustawienie MEMLO w MyDOS którego używał Piguła, a tego sam nie okreslę, bo MEMLO zmienia się w zależności od konfiguracji DOS-a. Jeżeli Piguła zobaczy jakie MEMLO ma MyDOS którego używał z Anty AJKIEM, i obliczy sobie X=$B800-MEMLO, to wszystkie pliki dłuższe niż liczba X wynikająca z obliczeń, będą miały uszkodzony kawałek danych w miejscu pliku wskazywanym przez obliczony X. Jeżeli plik wynikowy jest krótszy niż X bajów, wszystko jest w porządku.

Błąd który wprowadziłem do kodu spowodowany był chęcią przyspieszania operacji zapisu danych. Optymalizacja polegała na zamianie zapisu przez put_byte() za zapis porcjami po 256 bajtów, jednak przyspieszając kolejne fragmenty kodu i robiąc uproszczenia, doprowadziłem do sytuacji że operacja kopiowania porcji danych do bufora zapisu, błędnie sprawdza zakresy obszarów które musi ominąć (sprawdzam tylko starszy bajt) i stąd całe zamieszanie.

Hej!

Sprawdziłem, w moim kodzie jest faktycznie błąd w procedurze zapisu odczytanych bloków, ujawnia się on gdy program jest na tyle długi że przestaje się mieścić w buforze znajdującym się w konwencjonalnej pamięci RAM, procedura odczytu działa poprawnie umieszczając odczytywane dane pod pamięcią OS-ROM. Niestety wygląda na to że procedura zapisu bufora na dysk ma błąd i koniec końców program zamiast pominąć obszar w którym się sam znajduje, zapisuje kawałek siebie zamiast odczytanych danych. Dodałem do listy poprawek, więc będzie na pewno nowa wersja programu.

EDIT: a dokładniej rzecz ujmując to problem występuje wtedy gdy MEMLO jest niewyrównane do granicy strony... ehhh... testowałem z memlo wyrównanym do granicy strony, no i miałem co chciałem. Mam nadzieję że konwersje które robiłeś mieściły się w buforze pomiędzy MEMLO a obszarem $B7FF, bo w przeciwnym wypadku "Anty *AJEK", w wersji 1.2 na pewno uszkodził dane przy zapisie. Część programów może się uruchamiać po takiej konwersji i można nie być świadomym uszkodzenia "kawałka" zapisanego zbioru.

Można to szybko zweryfikować, MyDOS 4.55 Beta 4, w ustawieniach które mam, ma MEMLO równie $1F9F, a więc $B800-$1F9F = 39009, jeżeli wyjściowy plik .XEX jest dłuższy niż ta liczba to jest na 100% uszkodzony po potraktowaniu "Anty *AJEK v. 1.2", z tym że ta liczba może się różnic w zależności od tego jakie MEMLO miał Twój MyDOS (ustawiona liczba buforów, ilość aktywnych napędów, RAMDISK, etc.).

Gdy uruchamiasz program bez DOS, i używasz pod emulatorem z opcją emulowanego dysku H: to domyślnie OS ustawia MEMLO na $700, i w takim wypadku wszystko będzie OK!

Postaram się na dniach zrobić jakąś szybką łatę. Na myśl przychodzi mi po prostu zaokrąglenie MEMLO w górę do granicy najbliżej strony. Pewnie tak zrobię a większe zmiany w programie zostawię sobie na później.