Co tu rozumieć?
Widzisz, bo Ty nie rozumiesz właśnie. Wystarcza mu komp z 64kb, choć nie zawsze jest w stanie wrócić do DOSa, ale dokładnie to samo będzie z xBiosem.
Nie jesteś zalogowany. Proszę się zalogować lub zarejestrować.
Nowe firmware - FujiNet 1.6.1 Nowa wersja oprogramowania układowego dla FujiNet przynosi liczne poprawki błędów.
Atari800 6.1.0! Po blisko trzech latach przerwy ukazała się nowa wersja najpopularniejszego emulatora Atari 8-bit.
Atari Floppy Image Toolkit Potężne narzędzie w stylu GEM do obsługi dyskietek Atari ST w przeglądarce internetowej.
Delete Me Hard Nowa, rozbudowana strzelanka arcade dla komputerów Atari XL/XE, NES oraz C64.
HDDRIVER 13.00 Nowa wersja sterownika przynosi olbrzymie zmiany, w tym ramdysk nowej generacji i inne optymalizacje.
atari.area forum » Posty przez Pecus
Co tu rozumieć?
Widzisz, bo Ty nie rozumiesz właśnie. Wystarcza mu komp z 64kb, choć nie zawsze jest w stanie wrócić do DOSa, ale dokładnie to samo będzie z xBiosem.
Jednym zdaniem. "Wszyscy jesteście durniami i nie umiecie wykorzystać sprzętu".
jesli na tym HDD nie bedzie SDX to oczywiscie ze bedzie dzialac. :-D
A to jest dopiero bełkot.... (a jeśli już pominiemy bezsens tego zdania, to czy wspomniany program, jak już zadziała pod xBiosem odczyta wszystkie pliki z muzyczkami, bez modyfikacji, a może nawet nie da się ich tak zapisać?).
Rozumiem, że więcej niż 128 czy 256 plików w katalogu, to jest "ograniczenie" Sparty.
Jeśli tak rozumiesz ograniczenia, to nie mam pytań...
Odpal xBiosem program z podfolderu SDX z HDD. Program ma dodatkowy podfolder a w nim jakieś 1000 muzyczek w oddzielnych plikach, które sobie wczytuje i po kolei odtwarza.
To bardzo przyszłościowe rozwiązanie, bo wyznaczone lata temu :) i działa dziś u wielu użytkowników. Czy działa u Ciebie?
swiat poszedl do przodu :D
Masz rację świat poszedł.... a Ty biedny zostałeś bez obsługi nowocześniejszych standardów.... przykre.
I dlatego pisze się z użyciem wywołań ustandaryzowanego CIO i ma zadziałać pod każdym DOSem (programista nie musi wiedzieć jaki system plików ma "pod spodem").
Jak Ty Sikorku pisałeś swoją grę (z przykładu XbXL) to używałeś zapewne z BASICA: OPEN, CLOSE, GET, PUT itp i nie przejmowałeś się jaki DOS i jaki system plików masz na dyskietce (no może się przejmowałeś, ale nie miało to znaczenia ;) ). Tak napisany program, po skopiowaniu do podfolderu na dysk w formacie Sparty zadziała dokładnie tak samo. I o to w tym wszystkim chodzi.
A co do przeniesienia na Carta, to wystarczy tylko zrobić kawałek DOSa obsługujący Cart i tak samo napisany program zadziała i przy użyciu takiego systemu, na cartridgu.
No i połaczenie xBiosa z handlerem D: i sterownikiem carta (pewnie już w sumie nie tak mały kawałek kodu) jest takim DOSem Oczywiście różne sterowniki dla różnego sposobu bankowania.
Ech taki był "fajny" pomysł, a skończyło się na ułomnym DOSie... :P
Ale jeśli patrzeć na xBiosa jako na DOSa to jest jedna fajna sprawa - podział na 3 moduły, tyle, że pewnie jakby dokończyć ten projekt tak by mał wszystkie podstawowe funkcjonalności DOSa, to przekroczyłby zajętością pamięcie kilka innych DOSów, właśnie dlatego że jest modułowy.
I tak, jestem zagorzałym tradycjonalistą który na co dzień używa MyDOSa i póki co nie zamierzam tego zmieniać.
I dlatego xBios może jest dla Ciebie wygodny, bo nie masz potrzeby stosowania innych DOSów niż MyDOS i działasz na dyskietkach głownie.
Ale dobrze jest jak program/gra jest przenoszalny bez problemów między różnymi systemami plików, może pracować z HDD, itp.
I dobrze napisany program komunikujący się ze światem przez CIO zawsze będzie tak działał.
Nie oglądam filmików. Ale zmusiłem się....
Ha, ha, ha, handler D: napisałeś.... ło matko. xBios miał nigdy nie być DOSem a się nim staje!
DOSem, obsługującym jeden filesystem (oczywiście zaraz dostanę odpowiedź, że obsłuży każdy filesystem do którego ma sterownik :P ) bez możliwości tworzenia plików.
Cudo!
Pecus napisał/a:A może jednak musi zaprogramowane już przez CIO procedury I/O przepisać pod xBiosa?
Co to znowu za zalosna bzdure wyprodukowales :-)
Ustosunkujesz się kiedyś do meritum zamiast błędy pisarskie wytykać? Procedury oczywiście nie są zaprogramowane przez CIO ale przez Rafała, a przez CIO się komunikują. Tak więc Rafał ma już oprogramowane wszystko przez CIO właśnie i co teraz? Przerabiać wszystko pod xBiosa? Po co? By zmniejszyć zgodność? Dodatkową robotę wykonywać..... to jest dopiero bzdura.
Wiesz... i tak już piszę jak do mojego 7-mio letniego syna i nie używam trudniejszych zwrotów :P
Przypomina mi to ostatnią debatę prezydencką..
Pytanie: Czy wie pani z czego piecze się chleb?
Odpowiedź kandydatki: Wczoraj założyłam czerwone trzewiki i to najlepsze trzewiki są!
Czyli mgr_inz_rafal nie musi nic w kodzie gry zmieniać jeśli ma już napisane I/O przez CIO? Odpala pod xBiosem i voila :P i na carta bez problemów jednym ruchem przeniesie - no super!
A może jednak musi zaprogramowane już przez CIO procedury I/O przepisać pod xBiosa?
A jak przepisze procedury I/O na xBiosa to bedą działały przez CIO np. pod SDX?
Tylko do tego, będziesz musiał dobrze napisanego Rzygonia stosującego CIO przerobić tak by chodził pod xBiosem (i tylko pod nim, bo wyklucza to CIO, chyba że całe I/O w grze zrobisz w dwóch wersjach i dasz użytkownikowi opcję wyboru).
I z rozwiązania zgodnego ze standardami będziesz miał ... w sumie nie wiadomo co. Zapomnij wtedy o SDX...
Ja proponuje kompoty z wiśni!
Oczywiście można je stawiać na dowolnej maszynie (aby tylko nie wylać) :)
Wszystkie turba ładujące "loader" (pod jeden z dwóch adresów do wyboru) to Turbo 1050 znane pod tysiącem innych nazw (bo napis w ROMie zmienić łatwo).
Nie będę się kopał z koniem.
Tym bardziej jeśli nie odróżnia on od siebie różnych warstw systemu operacyjnego.
Programista korzystający z CIO też nie ma tego problemu.
Z resztą nie znam nikogo, kto miałby z tym problem... no może poza Tobą.
Dalej mylisz (i mieszasz w głowach innym) warstwę CIO i SIO - ale cóż, niektórym wiedza nie jest widać do życia potrzebna.
Korzystając z warstwy CIO nie ma potrzeby by wiedzieć jakie turbo ma stacja, bo nie komunikuje się ze sprzętem - to warstwa czysto programowa zajmująca się obsługą plików.
Transmisją blokową zajmuje się w komputerach Atari SIO i tyle na ten temat.
A Twoja procedura i tak z SIO korzysta :P więc jest dłuższa i wolniejsza od sprawdzenia prędkości US przez SIO, jest dłuższa o długość xBiosa!, bo to samo doskonale robi się bez niego.
Super! Tyle, że używając przestarzałego CIO nie ma absolutnie potrzeby sprawdzania w jakim trybie pracuje stacja i dlatego nie ma nawet takiej możliwości. Czy sprawdzenie jest szybsze i krótsze od braku potrzeby sprawdzania?? Chyba jednak nie.
Kolega jak zwykle myli pojęcia, CIO to inna warstwa oprogramowania.
CIO po prostu działa z taką prędkością jak trzeba :P
Jak lata temu robiłem to był F :)
Demo jak demo ale to... https://www.youtube.com/watch?v=4WKOFg0vCwc
A może TapaTalk zadziała w końcu....
Jako, że w innym miejscu handlujemy tylko tym co związane Atari, to ja tutaj.. :)
Poszukuję obudowy Welland ME-740PSS (stary model) USB 2.0 GreenStar - dokładnie takiej: http://www.welland.com.tw/html/green/740pss.html ... nowej, używanej, dowolnej (sprawnej).
Kupię lub zamienię dając za nią model nowszy z eSata o taki: http://www.welland.com.tw/html/enclosure/740.html (wersja USB2.0 + eSata).
Kolor czarny lub czerwony do wyboru....
Może ktoś z Was ma....
COLD /N nie działa?
1. wykorzystanie NOTE/POINT w Sparcie w rozumieniu ustawienia się w pliku nad określonym bajtem mija się z celem - z punktu widzenia prędkości (negatyw)
Prędkość jest słaba tylko jeśli pracujesz na dyskach w formacie AtariDOS, jeśli NOTE/POINT pod Spartą operuje na dysku w formacie Sparty, to jest błyskawiczne. Za to działanie jest jednoznaczne (w stosunku do innych DOSow, gdzie po skopiowaniu pliku trzeba przygotować nowe indeksy, bo jak się tego nie zrobi.... to kaszana ;) ).
atari.area forum » Posty przez Pecus
Wygenerowano w 0.053 sekund, wykonano 19 zapytań