Nie jesteś zalogowany. Proszę się zalogować lub zarejestrować.
Weekend z Borsuk Retro Gry TV Zapraszamy na weekendowe transmisje z udziałem gości, w tym budowę Custom Atari XL i naprawy sprzętu.
AltirraSDL Lobby Przeglądarkowy front-end dla emulatora Altirra z trybem gry wieloosobowej online od Ilmenita.
Test7800 0.8.0 Nowa wersja Test7800 wprowadza wsparcie dla większych kartridży Bankset oraz obsługę Quadtari.
Flob wkracza na Atari ST Platformówka z 8-bitowego Atari zmierza na komputery z serii ST.
Return to Blacktooth dla Atari ST Nowa, izometryczna przygoda w stylu Head Over Heels już dostępna na komputery Atari ST.
atari.area forum » Posty przez drac030
Konwerter może się i da zrobić, ale po pierwsze primo trzeba znaleźć opis albo rozgryźć format tokenizowanego pliku MAC/65, no a potem pisać konwerter. Pisanie teoretycznie zajmuje niewiele czasu, ale z praktyki wiadomo, że to jednak co najmniej parę dni (z testowaniem, wyłapywaniem błędów, poprawianiem itd.).
Juz chyba większy sens by miało napisanie dekompilatora, ale mi się nie chce. Tym bardziej, że wiem, że taki istnieje - program w BASIC-u wspomniany przeze mnie w pierwszym poście.
Magnus;- dlatego poczekam sobie jeszcze na update OS'a
No raczej dema chyba :) Ta tablica nie wróci pod stary adres, nie ma tam na nią miejsca - sam zresztą chciałeś, żeby wycisnąć z tych 16k co się da, no to właśnie to robię. :P
Draco;- twój Last Starfighter faktycznie z '816 działa - Thx! Dziwi mnie tylko to, że mam plik, który działa na 6502 (600XL/64k up), a nie działa na XEGS z 65c816 ADP i XE/XL OS.. dziwne toto.
Ja w tym programie niczego nie dotykałem, zawsze działał po prostu. Pewnie masz fajlówkę zrobioną przez kogoś innego, kto dorzucił trochę kodu z nielegalnymi rozkazami. Na tej zasadzie zresztą podejrzewam, że testując inne wersje kraków (no pun intended :lol: ), albo oryginały, wiele gierek, które mają na mojej liście śliczne NO, dałoby się przesunąć do kategorii "OK". Bo zdaje się, że duży procent problemów z uruchomieniem tego czy owego jest powodowany przez wszelakiej maści czołówki i depakery dodane przez panów supplierów.
Tak w ogóle, to mam kilka gierek spakowanych i chętnie bym je wymienił na wersje nie spakowane - przy twardym dysku to jest bezsens, takie coś wczytuje się sekundę, a potem decrunchuje minutę ...
Ups. No to mogiła, ta tablica nawet nie jest przesunięta, ale jej w bezpośrednio dostepnym ROM-ie nie ma wcale, bo z braku miejsca sporo rzeczy, które są potrzebne tylko przy resecie, poupychałem na miejscu SELF TEST-u.
Skoro już mowa o poprawkach do SDX: w 4.20 jest drobna porażka, jeśli chodzi o funkcję kasowania plików. W przypadku kasowania pliku zaznaczonego jako BOOT powinny zostać wyzerowane bajty 40-41 bootsektora, a to nie dzieje się :rolleyes:
No więc, pobawiłem się tym całym Disasemblerem. Program robi wrażenie, ale jest małe ale.
Po pierwsze, program ma błędy, np. po włączeniu etykietowania z rozkazu JMP (adres), na który trafi, w odtworzonym źrodle robi cuda niewidy - np. DEY (adres) albo jeszcze lepiej PHP (adres).
Po drugie, owszem, generuje pliki w formacie ATMAS-a (którego nie mam) i MAC/65. Te pliki są stokenizowane. Niestety, z programu binarnego o wielkości 12k wychodzi "źrodłówka" takiej długości, że żaden ATMAS ani MAC/65 tego nie łyknie. Z plikiem tekstowym łatwo sobie poradzić, ale czystego tekstu program oczywiście nie zapisuje. Tak więc produkt końcowy nie nadaje się do użytku ...
Krótko mówiąc, ma ktoś namiar na coś innego? Najlepiej byłoby, żeby produkowało listingi w formacie MAC/65, ale nie tokenizowane :rolleyes:
Z Maxflashem jest fajna zabawa, bo nową wersję systemu można sobie od razu na niego nagrać z Atarki :D
No wyobrażam sobie, bo ja mam ROM na flashu, założył mi Jacek. Bardzo fajne, piszę z DOS-u flash xlos.bin i za parę sekund mam to w ROM-ie.
Co do 512b/sektor to zawsze wydawało mi się możliwe, żeby Sparta je obsługiwała z drobnymi zmianami. Co tam jeszcze jedna poprawka...
Niestety, to jest nierozszerzalne w sposób kompatybilny. Czyli jeśli program zależy od wielkości sektora, to choćby się programista wziął i zesikał, to nie będzie to działać z takim rozszerzeniem. Przyczyna: lebiegi zaoszczędzili 1 bajt i zapisali wielkość sektora na jednym. W bootsektorze to jeszcze pestka, ale CHKDSK też zwraca wielkość sektora na 1 bajcie. Jak Sparta po poprawkach będzie w tym bajcie zwracać 2, to mogą być problemy.
Tylko że sparta.sys to aż 7 kilo do deasemblacji :(
Ano.
Eh, no właśnie to jest cały problem ze Spartą X, że jest na karcie - problem z wymianą, problem z testowaniem nowych wersji, problem z zakładaniem poprawek.
Lepiej by było mieć DOS w takiej wersji, żeby całość mieściła się w dodatkowej pamięci. Bo załóżmy, że nawet zeźrodłujemy plik SPARTA.SYS, i wprowadzimy jakieś fajerwerki, to na zwykłej SDX - jak sprawdzić, czy to działa? SPARTA.SYS *musi* się wczytywać z karty.
W sumie, zamiast pisać cały DOS od nowa - a przecież najlepiej, żeby był w miarę zgodny z SDX - lepiej byłoby poprawić Spartę tak, żeby mogła działać z sektorami 512-bajtowymi. Jeśli chodzi o filesystem, można go zachować w całości, jest tylko taki problem, że rozmiar sektora jest zapisany na jednym bajcie, ale to można załatwić w ten sposób, że np. rozmiar $80 znaczy 128 bajtów na sektor, $00 - 256, a np. $02 - 512.
Daje to 32 MB na partycję (16 * 32 MB = 512 MB, z tego 288 MB bezpośrednio dostępne) i pełną prędkość dysku.
Tam, gdzie i poprzednie.
Nowa wersja ROM-u, wiadomo gdzie. ;)
Zależy od napędu. Jeśli napęd nie chce formatować, to mogiła. Może TOMS 720 by formatował takie dyskietki (TOMS ma napęd HD), ale to też nie jest pewne.
Z tego opisu widać, że gość miał więcej szczęścia niż rozumu. Napis "GEM" tam widoczny to nie nazwa systemu operacyjnego, ale typ partycji. Takowa ma o ile mnie pamięć nie myli do 32 MB, więc cięcie pliku na kawałki po 64 MB miało głęboki sens. Uwagi o tym, że SCSI adresuje się liniowo są lekko nie na miejscu, bo IDE na poziomie tablicy partycji - przynajmniej w Atari - także adresowane jest liniowo (kwestia czy CHS czy LBA rozgrywa się dużo później). No i gdzie on widział FAT12 na twardym dysku? :D
Z poziomu programu nic nie musisz robić: to jest zmartwienie tego, kto program odpala, żeby uruchomić "przez X", co "odpina" kartridż. Albo, jeśli ktoś ma truba runext.sys, nazwij plik wykonywalny *.EXE a nie *.COM, to się samo będzie robić.
Właśnie, czy ktoś mógłby sprawdzić, z jaką praktyczną szybkością (ilość znaków możliwa do przesłania/wyświetlenia na sekundę) działa XEP? Myślę, że program zbliżony do tego:
10 A=TIME
20 FOR C=1 to 10
30 FOR Y=0 TO 24:POSITION 0,Y:? "T U J A K I S T E K S T O W I E L K O S C I 7 9 Z N A K O W":NEXT Y
40 NEXT C
50 B=TIME
60 T=(B-A)/50:S=19750/T:? Szapuszczony pod Turbo BASIC-em XL powinien być miarodajny (zakładam, że XEP wyświetla 80x25, jeśli nie, to trzeba poprawić).
Aha, ze Spectrum nie polecam ;)
Nie polecasz? To chyba z litości ;)
Masz rację, ale chodziło mi raczej o to, żeby (jak już dojdzie w ogóle do montowania) próbować -t msdos zamiast -t FAT. U mnie przynajmniej takiego typu jak "FAT" podać nie można (bo nie ma czegoś takiego, jak /sbin/mount_FAT).
[ Dodano: 15.02.2005 13:51:26 ]
PS. A partycje ext2 minta powinien łyknąć jako -t ext2fs - ale jeśli partycji wcale nie widać, to pewnie jest problem ze swapowaniem bajtów, jak ludzie mówią. Rafał, przejrzyj dmesg, może są jakieś komunikaty na ten temat, które wywala kernel przy starcie.
Najwyraźniejsze ograniczenie jest jedno: z twardego dysku (i z Karinki też, i z Blackboxa, i z MIO) nie wczytasz bezpośrednio nic w obszar $D800-$DFFF, bo tam się pojawia ROM urządzenia, a PORTB na to nie ma wpływu. Jeśli jest konieczny zapis w tamto miejsce, trzeba zrobić gdzieś bufor, wczytać do tego bufora, a po wczytaniu przekopiować tam gdzie trzeba.
Poza tym chyba żadnych ograniczeń nie ma, sterownik korzysta minimalnie ze strony zerowej, ale to są miejsca, które i tak normalnie wykorzystuje SIO.
a mount -t msdos /dev... itd. próbowałeś?
Przede wszystkim zalezalo mi na oszczednosci miejsca na bufor dla directory (w przypadku tej motody wystarczy strona pamieci i kazdorazowe odczytywanie wskazanego sektora directory).
Przy odczycie katalogu przez CIO możesz wcale nie użwać żadnego bufora, albo - dla odczytu rekordami - zastosować bufor o rozmiarze np. 20 bajtów.
Zastosowanie do programu, ktory z zaloznia wspolpracowac mial z gora 63 plikami (moze to dziwne, ale pewne ograniczenia przyjalem juz w programie - zastosowane bufory dla danych). Istotny stal sie tez dostep do niektorych innych bajtow wpisu w directory poza sama nazwa pliku, celem obliczenia, moze dosc problematyczny pomysl, "sum kontrolnych", tak aby miec pewna kontrole nad zmianami w directory dysku.
W ten sposób będziesz miał pełną kontrolę nad zmianami w katalogu niepełnym (bo bez uwzględnienia podkatalogów) albo w ogóle poza katalogiem. Przyznaj się, co to za program, może da się to rozwiązać lepiej.
a po co ludzie wspinaja sie na góry ? bo są 8)
Ale nikt normalny nie pcha się w góry, zanim nie nauczy się łazić po płaskim.
Marok:
1) po pierwsze primo, nie ma gwarancji, że katalog znajduje się (albo zaczyna się) w sektorze $169. W szczególności pod SpartaDOS katalog może być gdziebądź; pod MyDOS-em od sektora $169 zaczyna się katalog główny, ale podkatalog może być gdziebądź. Że już o egzotyce (AtariDOS 3.0, AtariDOS 4.0) nie ma co wspominać.
2) po drugie secundo, nie ma gwarancji, że katalog wygląda tak, jak pod DOS-em 2.5. Znowu, pod SpartaDOS katalog jest w zupełnie innym formacie.
3) po trzecie tertio, nie ma gwarancji, że katalog zajmuje 8 kolejnych sektorów - znowu, pod SpartaDOS katalog jest plikiem, który może zajmować bardzo dużą liczbę sektorów rozrzuconych dowolnie po dysku.
4) po czwarte quarto, nawet jeśli katalog zaczyna się od sektora $169 i zajmuje osiem kolejnych sektorów, nie ma gwarancji, że sektory są równo wypełnione danymi katalogu: np. MyDOS używa tylko pierwszych 128 bajtów każdego sektora katalogu (nawet w podwójnej gęstości), a BiboDOS - przeciwnie, zawsze całych sektorów.
To są wszystko rzeczy, o które ma się martwić DOS. Przeto, jeśli naprawdę z jakiegoś powodu nie musisz tego robić w sposób skomplikowany i zawodny, to lepiej jest, wedle sentencji wypowiadającego się tu również tebe, ułatwić sobie życie i skorzystać z funkcji odczytu sformatowanego katalogu, jaką oferuje każdy DOS (via CIO, $E456).
[ Dodano: 15.02.2005 02:37:00 ]
PS. O ile mnie pamięć nie myli, bit 5 pierwszego bajtu statusu oznacza "gęstość MFM", a nie "podwójną gęstość". Nie możesz na tej podstawie wyciągać wniosków o wielkości sektora, bo gęstościami MFM są zarówno gęstość podwójna jak i średnia. Innymi słowy bit ten oznacza owszem "double density", ale w kategoriach scalaka kontrolera WD 1772 (czy kompatybilnego), a nie w terminologii wymyślonej przez Atari.
Poza tym dobrze jest sprawdzać kody błędów, jeśli coś nie działa.
Przepraszam za sformułowanie, ale - gorzej ci? Nie możesz odczytać katalogu po ludzku, to znaczy przez CIO ($E456)?
Owszem, ale ta konwersja chyba nie będzie idealna. W Composite Video masz sygnał wizji i synchronizacji puszczony po jednym drucie, rozdzielanie tego daje zwykle kiepskie efekty - to znaczy dużo gorsze niż gdyby na ten sam monitor puścić sygnały wizji i synchronizacji oddzielnie i nawet po konwersji. Całkiem możliwe, że ten konwerter jest jakości odpowiedniej dla systemu monitoringu, gdzie trzeba odróżnić, czy na ekranie jest złodziej, czy go nie ma, i czy jest grubym brunetem, czy chudym blondynem. Ale obawiam się, że w przypadku konwersji obrazu z Atari odróżnienie LOAD od SAVE może nastręczać trudności ... ;)
No cóż, na takie rzeczy to ja niestety nic nie poradzę.
To nie grzech ułatwiać sobie życie, zgadza się. Ale gierka Blinky Scary School, mimo że może powstawała na ST, nie wymaga jednak od ciebie, żebyś podpinał ST do malucha, kiedy sobie chcesz pograć.
Niemniej, nie o to mi chodzi. Po prostu skutek ułatwiania sobie życia przez kodera akurat w ten sposób jest wyjątkowo łatwy do przewidzenia.
takie rozwiazanie stworzyloby "mega koprocesor" ktorego szybkosc uzalezniona jest od szybkosci przesylu danych
przeslane pliki obrabia PC i zwraca wynik, rownie dobrze moznaby przeslac wierzcholki jakies sceny 3d, PC liczy i zwraca wynik, ogolnie jedynym ograniczeniem takiego rozwiazania bylaby wyobraznia uzytkownika
Oczywiście można to nazywać "mega koprocesorem", ale w rzeczywistości atarynka staje się trwale do peceta uwiązana, jako terminal, bez którego nie jest w stanie wykonywac programów. Oczywiście nie wątpię, że tego typu zabawka mogłaby być fajna, ale to już nie jest, by to tak nazwać, "Atari computing", ale bardziej "PC computing", zwłaszcza, jeśli wszystko wokół programu mającego działać na Atari robi się na pececie, to znaczy na pececie się go pisze, na pececie kompiluje, z peceta wysyła do atarynki celem uruchomienia; a teraz jeszcze to pecet ma wykonywać 3/4 tego programu.
Po prostu nie wiem, po co przy tym całym pececie ci jeszcze potrzebne Atari.
i bedzie mozna pracowac na true Atari, a wykorzystywac szybkosc PC :)
Tak jakby. Ale zważ, że do tego ostatniego wcale w sumie nie jest potrzebne żadne Atari.
atari.area forum » Posty przez drac030
Wygenerowano w 0.143 sekund, wykonano 25 zapytań