Nie jesteś zalogowany. Proszę się zalogować lub zarejestrować.
7th Annual Atari Homebrew Awards Oczywiście nie zabrakło polskich akcentów.
Wyniki FujiCup 2024 Sprawdź, czy były niespodzianki!
Mad Pascal 1.7.2 Optymalizacje, poprawki błędów oraz nowe funkcjonalności.
Tydzień na oddanie głosu w FUJICUP! Głosowanie potrwa tylko do 22 lutego 2025...
TURGEN 9.3.1 Najnowsza wersja oprogramowania TURGEN wprowadza kilka istotnych ulepszeń.
atari.area forum » Posty przez drac030
Jeśli z SDX, to jest szansa, że ustawiłeś złe banki rozszerzonej pamięci i sapemu maże po banku używanym przez SDX. Niestety nie spotkałem się z łatwą metodą sprawdzenia, który to bank
MEM /X z Command Processora, linia "Use: ".
A do programu: http://atariki.krap.pl/index.php/Progra … mi%C4%99ci
mads 1.9.4 dopuszcza taką konstrukcję:
blk reloc extended
kod
bne _hop
kod
kod
blk reloc extended
_hop
kod
kodTymczasem raczej nie powinien, bo nie ma żadnej gwarancji, że blok zawierający adres "_hop" zostanie załadowany blisko poprzedniego. Przeoczenie takiego branchu może spowodować, że w programie będzie trudny do wykrycia błąd, ujawniający się tylko wtedy, kiedy w pamięci extended zabraknie akurat miejsca, w związku z czym ostatni blok programu znajdzie się w pamięci głównej, np. 28 KB od brancha, który w niego celuje ...
Ten problem raczej - na pierwszy rzut oka - nie dotyczy blk reloc main, bo te bloki zawsze są ładowane do pamięci konwencjonalnej.
Ciekawe. Pewien elektronik tłumaczył mi coś innego, i nie miałem powodów mu nie wierzyć. Ale może się mylił, albo ja go źle zrozumiałem. Jeśli tak - zwracam honor.
Aha. I kwarce też są w szarej izolacji.
drac030 napisał/a:sam fakt, że Atari wymyśliło i zaimplementowało PBI (czyli prawdopodobnie pierwsze na świecie plug&play) świadczy o tym, że interfejs SIO uznano za niewystarczający.
po latach zalety interfejs szeregowy zostal zauwazone i dzis np. nie uswiadczysz w sklepie dysku innego niz z interfejscem szeregowym... zreszta wszystko co se wtykasz, chcialbys wtykac lub myslisz o wtykaniu :D w pc ma interfejs szeregowy usb lub sata :D SIO powraca w wielkim stylu :)
Primo: SIO to jest interfejs typu RS-232, z poziomami logicznymi przekazywanymi napięciowo. W świecie PC tego już nie ma. SATA i USB przekazują dane zmianami nie napięć, ale kierunku przepływu prądu, i z SIO mają tyle wspólnego, że liczba drutów do przesyłu danych też jest mniejsza, niż w PATA. Secundo: Tylko co z tego? Ma to tyle wspólnego z SIO na Atari co z plamami na słońcu. Kolejny argument ideolo.
wiele razy padło - nie ma takiej potrzeby, np. że gra potrzebuje pełnych 62 KB RAM-u, nie może z jakichś tajemniczych powodów wpiąć ani kawałka ROM-u ani na ułamek sekundy. Ale trudno doprawdy wymyślić program tego typu,
zapraszam do watku z xbios, nie znasz tematu. nie 62 tylko 61, o wlaczaniu ROMU tez bylo - wymaga pisania programow w narzucony sposob z xbios jest tu dowolnosc. poza tym samo wlaczenie ROM to nie wyszystko ale o tym chyba "zapomniales" ;-) trzeba utrzymywac w pamieci podstawowej sterowniki
"Sterowniki" trzeba utrzymywać w pamięci, tak samo jak xbios, bo w danym momencie to właśnie jest sterownik. 61k powiadasz? To jeszcze lepiej. Obsługa PBI wymaga - jeśli naprawdę ktoś potrzebuje maximum pamięci - tylko dwunastu bajtów na stronie $0300 (DCB) i paru na stronie zerowej ($3x). Doprawdy chciałbym zobaczyć program, który ABSOLUTNIE NIE MOŻE tych miejsc ominąć, albo nie może sobie pozwolić na włączenie ROM-u PBI pod $D800, żeby wywołać obsługę sector i/o. Zatem sorry, DOS może i zajmuje więcej RAM-u, ale jest też o niebo bardziej uniwersalny, a wolnej pamięci i tak zostaje tyle, że wystarczy to dla 95% pisanych obecnie programów.
Tak czy owak, sądzę, że nie ma o co kruszyć kopii, bo sprawa umrze śmiercią naturalną, kiedy do uruchomienia jednej i tej samej gry będzie trzeba mieć wersji xbiosa wg wzoru liczba_urządzeń * liczba_używanych_gęstości_dysków * liczba_używanych_filesystemów. I żeby tę samą grę (niby plikową) skopiować z dyskietki 90k na 720k, jeszcze nie daj Panie Boże do podkatalogu, trzeba będzie wymienić xbios. O tym zresztą już pisał electron.
Pinokio, kto jak programuje Atari, żeby stworzyć kolejną bezcenną grę, która ma nie chodzić na tym, co sobie kto ubrdał jako niewystarczająco koszerne, to mnie osobiście zwisa kalafiorem, tym bardziej, im mniej mnie dotyczy. Najwyraźniej wymyślono jakąś ideologię, którą trzech panów nam tu wciska, posługując się argumentami częściowo demagogicznymi (jak ta tu wyżej, że tak powiem, nieciągłość temporalna w wypowiedzi nosty'ego), a częściowo fałszywymi, oraz przypisując sobie prawo do rozsądzania ex cathedra, co Wielki Nieżywy Wiekuiście Nam Panujący Niemowa (czyli Atari) 30 lat temu traktował poważnie, a co nie. Interesujące, ale może dla psychologa :P
Innymi slowy kompatybilnosc programu z SIO zalatwiala kompatybilnosc z 99.8% uzytkownikow Atari przez 90% jego historii. Czyli w praktyce lepiej jest byc kompatybilnym z SIO a nie obslugiwac urzedzen PBI niz odwrotnie.
Jeśli zgodność (na poziomie sprzętu) z SIO, jak mówisz, załatwiała (czas przeszły) kompatybilność z 99.8% użytkowników Atari przez 90% jego historii, to w praktyce oznacza to nie, że "lepiej jest" (czas teraźniejszy) być kompatybilnym z SIO, tylko że lepiej było.
Istotnie, w latach 80 twarde dyski były piekielnie drogie i przez to mało popularne. Ale teraz są tanie i stosunkowo popularne, zeszło tego pewnie ze 300 sztuk tylko w ostatnim okresie. Chyba, że mowa o przesyłaniu obecnie produkowanego oprogramowania w przeszłość, wtedy nie mam pytań.
Część dyskutantów posługuje się w specyficzny sposób argumentami ideolo, to ja może też dorzucę jeden: sam fakt, że Atari wymyśliło i zaimplementowało PBI (czyli prawdopodobnie pierwsze na świecie plug&play) świadczy o tym, że interfejs SIO uznano za niewystarczający. Nie widzę zatem powodu, żeby trzymać się go z uporem maniaka, o ile - co też w tej dyskusji wiele razy padło - nie ma takiej potrzeby, np. że gra potrzebuje pełnych 62 KB RAM-u, nie może z jakichś tajemniczych powodów wpiąć ani kawałka ROM-u ani na ułamek sekundy. Ale trudno doprawdy wymyślić program tego typu, może oprócz wspomnianych przez tebego portów z innych komputerów.
Trochę obok tematu: rzuciło mi się w oczy, że modulator na tej płycie ma oznaczenie C061619, natomiast na liście części w Atariki "modulator od 800XL" mamy jako C061659. Czy to jest pomyłka na liście, to znaczy wpisane jest 5 zamiast 1, czy też oba numery są OK i oznaczają różne modulatory?
Część numerów spisana jest "z natury", część z różnych źródeł, dużo z internetu (np. z listy Best Electronics), zatem pomyłki mogą być. Czy ktoś mógłby autorytatywnie odpowiedzieć na powyższe pytanie?
Fox, trafne spostrzeżenie. Być może jest to jedna z przyczyn, dla której tak niewiele programów jest od tego uzależnionych. Poprawię opis w Atariki.
wieczor: IDE+, Karinka, i tym podobne, to urządzenia PBI. Dostęp do IDE+ (czy podmapowany jest ATR czy nie) można zrealizować przez SIOV (tzn. skok do tej funkcji OS, która normalnie obsługuje też flopy i wszystko inne) albo PDIOR. Ale IDE+ nie jest sprzętowo przyczepiony do Pokeya, zatem odwołania realizowane przez ingerencję w rejestry Pokeya nic nie dadzą.
Fox: napisane jest to w OS User's Manualu na stronie 79 (link do skanów np. http://www.atariage.com/forums/topic/12 … try1538702, patrz part 2). Zaimplementowane: na pewno DOS 2.0, DOS 2.5, DOS XL, BW-DOS, przypuszczam, że MyDOS też, ale nie chciało mi się zaglądać do źródłówki.
@xxl: tylko tyle: LOL.
Skoro nie odpowiedziałeś na pytanie, powtórzę zatem: pleciesz głupstwa. A raczej, swoim zwyczajem, trollujesz. Jak będziesz miał coś rzeczowego do powiedzenia, będziemy mogli kontynuować.
Pozwoli. No i? To ma być ta sławna "niezgodność formatu", która czyni Spartę dyskową, cytuję, "nie do użytku"?
ale zaraz! SpartaDOS FS plikowej wersji jest niezgodny z werjsa z kardrydza
Pleciesz głupstwa.
4. Przy zachwalaniu Sparta DOS X padło stwierdzenie, że "Turbo Basic XL jest c**y, bo nie działa BGET, BLOAD itp pod tym systemem - nie wiem jak pod XBiosem, ale dla mnie to jest argument, że raczej Sparta jest c**a, bo TB XL jest - o ile mi wiadomo TB XL jest starszy, więc jak dla mnie - to sparta jest niedopracowana.
BGET działa. Natomiast prawdą jest, że nie działa BLOAD/BRUN. Długi czas myślałem, że to wina TBXL. Ale okazuje się, że to jednak wina SDX, która nigdy nie zwraca statusu $03, bo ICD olało w tym jednym punkcie specyfikację Atari (być może po prostu to przegapili). Istnieją dwa programy na krzyż od tego zależne i TBXL jest jednym z nich, a objawem jest niedziałanie - konkretnie wieszanie się - BLOAD (i BRUN). TBXL się zapętla, bo przy odczycie pliku jakże mądrze czeka na Y=$03 zamiast na EOF.
Słowem, jeśli ktoś użył gdzieś takiego argumentu, jak przytaczasz, to nie miał racji. Jestem w tej chwili w trakcie poprawiania driverów SDX i jest nadzieja, że SDX 4.46 będzie miała ten - zbędny moim zdaniem, ale niestety już wymyślony - ficzer.
Tym bardziej, że pod innymi dosami (nie wiem jak pod spartą 3.30 - plikową, pod resztą dosów które próbowałem oprócz MyDOSa) działa bez zarzutu
Pod Spartą plikową TBXL nie działa wcale, bo ten DOS zajmuje pamięć pod ROM-em. Ale gdyby działał, byłoby to samo.
Nie zmienia to faktu, że problem sam w sobie jest łatwo obejść: http://atariki.krap.pl/index.php/BINARY_LOAD
HA! Dodanie SEI pomoglo.
Dodalem juz po inicjalizacji wszystkiego i po wykonaniu pierwszego VBLI, kiedy wszystkie cienie zostaly przepisane.
Dalej w kodzie juz nie uzywam zapisu do cieni wiec dziala.Zjawisko zniknelo.
A to ciekawe. Jest jeszcze jedna możliwość: chwilowa blokada NMI przez IRQ klawiatury http://atariki.krap.pl/index.php/6502#B … zerwaniami Może jeśli wstrzelisz się w odpowiedni moment, to opuszczenie jednego DLI (albo jednego VBL-a) dałoby taki efekt?
Cholera... musze sie jeszcze duzo nauczyc. Nie wiem jakiego VBLI uzywam, nie wiedzialem ze sa rozne :/
Ustawiam jak nizej, inaczej nie umiem:ldy #<vbli
ldx #>vbli
lda #$06
jsr jsetvblv
lda #64
sta NMIEN
To jest OK (VBL natychmiastowe). Tylko że jak dasz SEI, zostaje (oprócz przerwań IRQ) wyłączona jeszcze druga faza VBL, tzw. opóźniona. To ona kopiuje do rejestrów I/O rejestry-cienie. Zgadywałbym, że dlatego ci to nie chce działać po SEI, bo pewnie wpisujesz adres DL do cieni, dajmy na to.
Daj SEI po zainicjowaniu wszystkiego, albo ładuj dane bezpośrednio do rejestrów scalaków.
Ad sei: czy VBL-a używasz tzw. "opóźnionego"? Jeśli tak, to faktycznie, z SEI nie zadziała. Przewieś procedurę VBL na wektor natychmiastowy. Acz problem jest raczej sprzętowy, zatem to tylko tak na wszelki wypadek.
Gdybym miał zgadywać, to pojawiają się jakieś syfy na sygnałach gniazda kartridża, które twój wynalazek interpretuje jako dodatkowe odczyty. Może to znowu nieśmiertelny problem z fi2.
Daj SEI na początku programu, zablokuje to przyjmowanie przerwań klawiatury. Jeśli zjawisko dalej będzie występowało, to znaczy, że nie powoduje go OS.
nosty: a co się stanie, jeśli "pamięć obrazu" przesuniesz z $d500 na $d580? Możesz zrobić taki eksperyment? Czy efekt wtedy też wystąpi?
Poza tym przydałyby się dodatkowe informacje: czy np. gra czeka na naciśnięcie klawisza, czy używa do tego OS-u, czy przerwania IRQ są włączone itp. Tak na oko, to OS sam w sobie przynajmniej nie czyta $d5xx przy obsłudze klawiatury, bo nie ma po co. On tej strony zresztą w ogóle raczej nie dotyka.
No wypadałoby, wtedy twoje "zejdźże" miałoby odpowiednie umocowanie w rzeczywistości.
Ke? Czy ja coś napisałem o "dzonie"?
Uaktualnienie do wersji 1.17:
http://drac030.krap.pl/pl-inne-pliki.php
Wersji 1.16, jak widzę, zapomniałem zaanonsować, przez co połowa użytkowników programu ;) mogła ją przeoczyć. Zaanonsuję teraz: ogólnie poprawiłem dwa błędy w PC-Linku oraz dorzuciłem zwracanie statusu $03 jakże nam wszystkim potrzebnego.
atari.area forum » Posty przez drac030
Wygenerowano w 0.122 sekund, wykonano 14 zapytań