Problem z kompilacją IRQ Loadera Sensei'a w DreamAssie

Szukasz drobnej pomocy przy kodowaniu, albo chcesz przedstawić światu swoją gotową lub w trakcie realizacji produkcję? To właściwy dział.
Wiadomość
Autor
DJ Gruby

Problem z kompilacją IRQ Loadera Sensei'a w DreamAssie

#1 Post autor: DJ Gruby »

W Turbo Assemblerze kod IRQ Loadera Sensei'a kompiluje się bez problemów, natomiast DreamAss nie radzi sobie z taką konstrukcją:

Kod: Zaznacz cały

DRIVE    = *

         *= $0300

         .OFFS DRIVE-*
Czy istnieje jakiś "dreamassowy" odpowiednik powyższego zapisu, który byłby dla niego zrozumiały? W tej chwili przy próbie kompilacji tak skonstruowanego kodu zgłaszany jest błąd:

Kod: Zaznacz cały

init.src:171: error:unknown pseudoopcode or undefined macro
Z góry dziękuję za pomoc!

Awatar użytkownika
Nitro
Posty: 1551
Rejestracja: 03 wrz 2008, 20:23
Grupa: Black Sun

#2 Post autor: Nitro »

Chyba chodzi o tzw. komendę pseudo pc, która assembluje kod, tak jakby znajdował się on pod podanym adresem, tu $300, potem zostanie przesłany do napędu i pod tym adresem będzie wykonywany.
Poszukaj takiej komendy w opcjach assemblera.

DJ Gruby

Zaskakujący feature (bug? ;)) IRQ Loadera Sensei'a

#3 Post autor: DJ Gruby »

Przy okazji pracy z tym IRQ Loaderem odkryłem niecodzienny feature (bug? ;)). Otóż jeżeli mamy na dysku plik o nazwie identycznej jak plik, który chcemy załadować (chodzi dokładnie o dwie pierwsze litery nazwy, bo tylko one brane są pod uwagę w trakcie wskazywania nazwy pliku do załadowania), przy czym został on wcześniej skasowany, ale w katalogu dysku występuje przed plikiem, który wydawałoby się, że powinien zostać załadowany, to wczytane zostaną dane z tego usuniętego pliku, czyli najprawdopodobniej jakieś śmieci. :) Nie mogłem długo dojść, dlaczego plik o podanej nazwie nie chce mi się załadować, podczas gdy pozostałe ładują się poprawnie i znalazłem taką oto przyczynę.

Awatar użytkownika
Reiter
Posty: 64
Rejestracja: 18 lis 2008, 20:36

#4 Post autor: Reiter »

Czyżby Loader nie sprawdzał typu pliku? Tak mi to wygląda. Chodzi o jeden bajt, który mówi o statusie pliku. Kiedyś pamiętałem który.

Awatar użytkownika
skull
Posty: 760
Rejestracja: 15 wrz 2008, 08:18
Grupa: samar

#5 Post autor: skull »

No wiadomo, że im więcej sprawdzania tym wolniej to działa. Rzeczywiście wygląda to na, pobieranie z ścieżki katalogu dwóch pierwszych liter nazwy, a potem bezpośrednio linka do pierwszego bloku pliku - resztę "znaczników" zwyczajnie ignoruje.
Ale ja... np. podczas kompilacji kodu, również tworzę nowy obraz dyskiteki (d64) na którym kod ma pracować - a więc problem z plikami typu stretch/del nigdy nie zaistniał.
Bo pecet to zwykły banan...

ODPOWIEDZ