To niemozliwe - dobrze wygenerowane inity i bloki odpalaja pod kazdym dosem:) A jak te naglowki wygladaja binarnie? Bo cos mi tu smierdzi...

Oczywiście problem musi być w źle wygenerowanym pliku, tylko nie miałem pomysłu jak to ugryźć.
O ile na starość nie skapcaniałem i kod inita mam poprawny (mam teraz wątpliwość, czy wychodzenie z niego jest przez RTS czy może trzeba zrobić jakiś magiczny jmp), to wydaje mi się, że może chodzić o problem #2, bo kod inita w krótszym programie woła tylko putline (a właściwie jciomain piszące do kanału zerowego). W sumie dziwne, bo prawie każdy mój prosty programik zaczyna się od $2000, a ten problem wyszedł dopiero teraz. Jaki w takim razie jest bezpieczny adres ładowania, żeby nie przeszkadzać MyDosowi?

1) RTS jak najbardziej OK, to jedyna dopuszczalna metoda wyjścia z INIT-a... mam nadzieję że nie zostawiasz po INIT nic na stosie.

2) $2000 jest jak najbardziej OK...  przy My-DOS (4.53/4) skonfigurowanym z 4-rema buforami... memlo wynosi $1FE8... więc Twój kod ładowany od $2000 jest bezpieczny.

Niech Pasiu sprawdzi jakie ma Mem-LO,   ew. jak jest powyżej $2000 niech wywoła opcję "O" z menu My-DOS, potem RETURN i dalej jak na screen-ie poniżej...

po tej operacji Mem-LO powinno wynosić $1DE8.

Ostatnio edytowany przez seban (2015-01-07 22:22:45)

Tu nie chodzi o wydajność DOS-a, tylko o tak jak napisałeś ilość jednocześnie otwartych plików przez CIO. Teoretycznie masz do dyspozycji kanały #1...#7 dla siebie, ale jeżeli masz dwa bufory ustawione w configu DOS-a to po otwarciu 3-ciego kanału dostaniesz ERROR#161 (TOO MANY OPEN DISK FILES).

Gdy dostałem stację dysków, w ROM stacji był MY-DOS, skonfigurowany tak że MEM-LO było poniżej $2000. Więc mi to nie przeszkadzało, jednak gdy pytasz o zastosowanie większej ilości buforów... to owszem korzystałem...

np. dość często używałem tego przy generowaniu różnych tablic i zapisywania ich do plików... np.

OPEN #1,6,0,"D:*.DAT" i czytałem sobie kolejne wpisy i z Directory (INPUT #1,NAME$)

potem:

OPEN #2,4,0,NAME$

następnie operacje typu

OPEN #3,8,0,"D:TABL.BIN"
OPEN #4,8,0,"D:TABH.BIN"

więc 4 bufory to było minimum dla takiej operacji.

Gdy trzeba było przekonwertować  jakąś masę plików z jednego formatu na drugi, (np. arty do Barymaga) to pisało się taki mega konwerter który tylko orał po dysku lub ramdysku generując odpowiednie pliki.

Jak zacząłem się bawić w kompresje danych to generowałem różne pliki wynikowe, np. używając innej metody kodowania bitowego do oznaczenia długości sekwencji i zapisywałem sobie 4 pliki jednocześnie, każdy używający różnych metod kodowania prefixowego.

Gdy liczyłem różne statystyki lub analizowałem sektory na dysku, otwierałem wiele plików i zapisywałem sobie informacje w różnych plikach na ramdysku. No dużo by takich przykładów mnożyć :)

Może nie było to szybkie i wydajne, ale nie miałem wtedy peceta (po prostu nie było mnie na niego stać) i wykorzystywałem to co miałem pod ręką, czyli stację... podręcznik do My-DOS, QA... Turbo BASIC XL, oraz Atari 130XE z 192KB RAM :)

Ostatnio edytowany przez seban (2015-01-07 22:47:10)

Jeszcze jedno mi się przypomniało ... pisałem jeszcze jakieś narzędzia do grzebania w plikach binarnych... część nie mieściła się w na raz w pamięci, więc napisałem coś co się zwało "FILE DIGGER", otwierało toto plik binarny do odczytu... potem analizowało poszczególne segmenty i pytało się co z nimi robić... zapisać na wyjście, olać... zapisać do oddzielnego pliku, etc.  przy pracy z różnymi rzeczami powstała cała masa jakichś pomniejszych narzędzi, linkerów i programów generujących pliki binarne... wszystko to korzystało z możliwości otwarcia wielu plików jednocześnie wraz z odczytywaniem kolejnych wpisów z "directory".

EDIT:

Wcześniej zanim mnie SoTe spacyfikował i mnie przestawił na QA... używałem MAC/65 i on podczas kompilacji potrafił otwierać kilka plików jednocześnie z dysku jak miał dyrektywy include w kodzie. Często robiłem tak że w ramdysku miałem jakieś biblioteki swoje, potem include na początku programu... i miałem większy bufor na swój głowny kod. MAC/65 był i tak nie do pobicia jeżeli chodzi o ilość kodu która mieściła mu się w pamieci... tokenizował to co się pisało... kompilator był ultra-szybki, ale edytor był koszmarny (jak w Atari BASIC)... do tego pliki które generował ... ojć... ich struktura była pomyłką... generował segmenty po 253 bajty...

Przez to musiałem napisać specjalnego tool-a do scalania takiej binarki aby zamiast np. czterdziestu 253-bajtowych segmentów został wygenerowany jeden ciągły :D

ps) Laoo... mega sorry za giga offtopic :)

Ostatnio edytowany przez seban (2015-01-07 22:55:51)

pojęcia o tym nie miałem :) jednak prawdą jest coraz okrutniejszą że człowiek uczy się przez całe życie :) dzięki temu offtopic-owi... dowiedziałem się czegoś nowego :D dzięki! :D

Ostatnio edytowany przez seban (2015-01-07 23:03:29)

nie miałem pojęcia że MAE również tak robi... (za późno odkryłem MAE i byłem zbyt "uwiązany" do QA), ale zawsze się zastanawiałem dlaczego MAC/65 generuje w ten sposób plik wynikowe, ale jakoś nie zdołałem zglebić tematu skąd taki mechanizm i po co. Wydaje mi się że np. Atari Assembler Editor ( Atari Macro Assembler) również generował tego typu nagłówki.

Gdy ja używałem MAC/65 to nie było mowy o flash-packu... czy innych narzędziach o których wspominasz :)
Wczytywałem MAC/65 z kasety w standardzie, lub gdy miałem już Turbo2000 to z kasety w turbo :) Potem gdy udało mi się zostać szczęśliwym posiadaczem stacji dysków do czasu poznania SoTe używałem nadal MAC/65 :)

Asembler zapisując plik wynikowy sekwencyjnie (bez cofania się) musi pamiętać końcówki wszystkich bloków z pierwszego przebiegu. Np.

 org $600 ; ten blok kończy się na $601
 cld
 nop
 org $2000 ; do $2002
 dex
 and $0f,x

Te końcówki bloków trzeba trzymać gdzieś w pamięci, co może być problemem, gdyby org-ów były tysiące.

Tnąc bloki na mniejsze kawałki wystarczy trzymać bufor na program wynikowy - gdy bufor się zapełni, uzupełniamy adres końcowy i zapisujemy cały bufor do pliku.

edit: ZTCP Atari Macro Assembler nie ciął bloków.

Ostatnio edytowany przez Fox (2015-01-08 15:03:40)

Wróćmy możne jednak na chwilę do sedna sprawy i tematu tego wątku.

Szczerze mówiąc nie mam pojęcia jak sprawdzić memlo pod MyDosem (używam 4.53). Dla 2 oraz 4 buforów program w czasie ładowania zachowuje się identycznie. Odkryłem jednak ciekawą rzecz, bo gdy próbuję wczytać go z innego dysku aniżeli D1:, to po załadowaniu pierwszego bloku ładuje się DUP.SYS wyrzucając błąd 139. Nadmieniam, że transmisja idzie po sio2pc, z którym nie mam problemów.

@Draco & Fox: dzięki za oświecenie, faktycznie ma to sens! :) teraz to jasne i logiczne

a to przepraszam, mogłem pomylić z EASMD... za dużo tych nazw assemblerów :)

@pasiu: możesz spróbować mojego prymitywnego programu: mem_inf.xex

u mnie to wygląda np. tak:

Ostatnio edytowany przez seban (2015-01-08 20:22:02)

Krótszy program ma dwa inity. Pierwszy testuje obecność 65c816 (modyfikując tylko rejestry CPU) i wypisuje linijkę tekstu za pomocą skoku do jciomain pisząc do kanału zerowego, a drugi nie robi nic (składa się tylko z RTS), więc o ile MyDOS nie jest wrażliwy na wołanie CIO dla kanału edytora, to nie wiem co innego mogłoby sprawiać problemy.
Dłuższy już jest bardziej skomplikowany, bo program poza pisaniem po ekranie na kolejnych initach dekompresuje wczytane bloki za pomocą inflate, więc tutaj pamięć zerowa jest w jakimś stopniu wykorzystywana.
Mogę przygotować specjalne wersje programów, które odpalą się bez Rapidusa, jeżeli ktoś byłby chętny odpalić to u siebie.

No i cieszę się, że mój post wywołał całkiem ciekawą dyskusję :)

Ostatnio edytowany przez laoo/ng (2015-01-09 12:12:02)

No i wszystko jasne. Twoje przypuszczenia się potwierdziły, bo gdy to uwzględniłem, wszystko pięknie się zładowało.