1,976

(19 odpowiedzi, napisanych Sprzęt - 16/32bit)

Adam Klobukowski napisał/a:

Hddriver to cały pakiet który składa się z kilku programów, HD-Util to jego część, tak więc jest to nadal HD-driver. Co do obsługi - nikt wcześniej w wątku nie zająknął się o jaką dokładnie obsługę chodzi, tak więc semantycznie, logicznie i erystycznie jestem w prawie ;D

Zająknął się:

jellonek napisał/a:

jesli to ot to chodzi - to hddriver jest debilnym oprogramowaniem - bo wszelkie opisy formatow jasno podaja kolejnosc bajtow w poszczegolnych polach (tak wiec albo hddriver obsluguje fat, albo obsluguje cos podobnego do fat - nim nie bedacego).

Tak więc semantycznie nie jesteś w prawie, co za tym idzie, logicznie również nie, a co do erystyki, to już się na niej tu jeden przejechał :D Idź i nie grzesz więcej.

1,977

(19 odpowiedzi, napisanych Sprzęt - 16/32bit)

HD-driver też takich partycji nie tworzy. Po prostu mylisz HD-Driver z HD-Utilem, jw. Żeby wszystko było jasne, zainicjowanie FAT-u na dysku to nie jest taka "obsługa", o jakiej tu mowa.

1,978

(66 odpowiedzi, napisanych Sprzęt - 8bit)

No i?

1,979

(19 odpowiedzi, napisanych Sprzęt - 16/32bit)

Adam Klobukowski napisał/a:

HDDriver obsługę FATu ma po części, bo potrafi utworzyć takową partycję.

Adam, sorry, ale mylisz podstawowe pojęcia. To że HD-Util (program aplikacyjny) umie zapisać na partycję bootsektor GEMDOS-u i wyzerować obszar FAT-u oraz directory (czyli że zawiera w sobie coś w rodzaju mkgemdosfs), nie oznacza niestety, jakoby HD-Driver (rezydentny sterownik) miał cokolwiek wspólnego z obsługą FAT-u czy jakiegokolwiek innego systemu plików.

1,980

(19 odpowiedzi, napisanych Sprzęt - 16/32bit)

W zasadzie trudno stwierdzić, kto spartolił. F030 odbiera dane z portu IDE 16-bitowymi move'ami (move.w) i tak to jakoś wychodzi. Przynajmniej nie trzeba byteswapować, żeby odczytać dane z ID (co np. trzeba robić na małym atari, bo inaczej teksty tam widniejące są raczej dziwne).

1,981

(19 odpowiedzi, napisanych Sprzęt - 16/32bit)

Hd-driver nie obsługuje FAT-u, bo w ogóle nie obsługuje filesystemu. Sęk jednak chyba w tym, że odczyt dysku zapisanego na piecu daje na F030 słowa w odwrotnej kolejności bajtów. Nie zgłębiałem tematu, ale opcja kompensująca to w hddriverze jest.

1,982

(19 odpowiedzi, napisanych Sprzęt - 16/32bit)

Problemem może być niejaki "byteswapping", pogmeraj po opcjach hd-drivera, przełącz to i zobacz, czy pomaga (i386 jest little endian, a m68k big endian).

1,983

(19 odpowiedzi, napisanych Sprzęt - 16/32bit)

Sprecyzuj, jaki to Linux, m68k czy i386? Na tym samym kompie czy na dwóch różnych? Czy "jak przygotujesz partycję pod MiNT-em", to jej typ jest ustawiony na LNX?

1,984

(11 odpowiedzi, napisanych Sprzęt - 8bit)

Czytajcie, dziatki, atariki: http://atariki.krap.pl/index.php/XE#Typy_klawiatur

Przecież to to samo.

Tak, jest tzw. "demo bez kodu", tzn. page flipping będzie działał nawet jeśli 6502 będzie zahaltowane. Ale do zmiany trybu na multicolor istotnie CPU się przydaje.

Co do TBXL, GOTO i GOSUB działają w nim tak samo, jak w Atari BASIC-u, tzn. wolno. Dlatego lepiej jest używać EXEC, które posługuje się adresem podprogramu zapisanym w tablicy zmiennych, a nie numerem linii wyszukiwanym od początku programu.

mono: no właśnie mniej więcej o to mi chodziło, żeby zmieniać GPRIOR a nie przełączać tryb instrukcją GRAPHICS, bo to się nie ma prawa zmieścić (procedura otwarcia ekranu jest długa). Zamiast GOSUB 100 dajesz wzmiankowane wyżej PAUSE 0 albo A=PEEK($14):WHILE PEEK($14)=A:WEND (co jest TBXL-owym odpowiednikiem twojego IF PEEK(20) ... ), bo lepiej dać to dwa razy niż wołać podprogram przez GOSUB (albo nawet przez EXEC), co przy interpretacji jest wolne.

Aha, chodzi o to, żeby jeszcze GPRIOR zmienić? Skompiluj, powinno się wyrobić (TBXL Compler tłumaczy POKE na LDA/STA). Tylko musisz w POKE/DPOKE użyć stałych.

10 DL1=$0400:DL2=$0600:REM adresy obu DL
15 GRAPHICS 24:REM ewentualnie + zapis danych do pamięci obrazu
20 DO:DPOKE $230,DL1:PAUSE 0:DPOKE $230,DL2:PAUSE 0:LOOP

TBXL znasz, to sobie przystosujesz :)

PS. Jeśli PAUSE 0 jest za wolne, to zamiast trzeba dać A=PEEK($14):WHILE PEEK($14)=A:WEND, ale to chyba wyjdzie na to samo, PAUSE 0 czeka 1 ramkę...

1,990

(34 odpowiedzi, napisanych Bałagan)

Sikor napisał/a:

po tym, jak napisałem, że Dely ma dystans do siebie, a KAZ nie

... zostałeś zdiagnozowany jako chory z nienawiści. Proste.

1,991

(60 odpowiedzi, napisanych Sprzęt - 8bit)

bezrobotny napisał/a:

to Ty mi odpowiedz na bitrate w WD279x...

5x ci już na to odpowiadali, ale jeśli nie przyjmujesz tej odpowiedzi do wiadomości, to jest, kolego, twoje zmartwienie.

PS. jellonek, faktycznie, pytanie było za trudne. Albo po prostu za długie.

PS2. Moim zdaniem jest to troll.

1,992

(60 odpowiedzi, napisanych Sprzęt - 8bit)

Panowie, proszę nie rozpraszać kolegi bezrobotnego, jestem ciekaw odpowiedzi na moje pytanie.

1,993

(60 odpowiedzi, napisanych Sprzęt - 8bit)

bezrobotny napisał/a:

... to właśnie jest scena atarowa ... co chwilę Ktoś się czepia za nic ...

"Za nic" - oczywiście. A że tak z czystej ciekawości zapytam, jakiej w zasadzie reakcji oczekujesz na swoje zachowanie?

1,994

(66 odpowiedzi, napisanych Sprzęt - 8bit)

A ja mam takie pytanie do wszystkich, którzy mają dostęp do komputerów z FGTIA (Simius, Sikor, Bitman, Pasiu, Jer, może ktoś jeszcze):

1) z jednej strony mamy informację, że $D014 = $01: http://atariarea.krap.pl/forum/viewtopi … 09#p100909 (ten wątek, post #13, by Simius)

2) dataszit od FGTIA twierdzi to samo (że ma być $01)

3) a z trzeciej strony mamy raport, że $D014 = $00: http://atariki.krap.pl/index.php/Dyskusja:FGTIA (Atariki, by Sikor)

Czy mógłby ktoś rozstrzygnąć, czy chodzi tu o różne wartości zwracane przez różne egzemplarze FGTIA (np. z różnych serii) czy też może zachodzi tu jakaś pomyłka. Nr seryjny FGTIA w kompie Sikora to C020120-01 (może ma też jakąś datę produkcji?).

1,995

(11 odpowiedzi, napisanych Programowanie - 8 bit)

Jeśli program ma się ładować pod rozsądnym DOS-em, trzeba przyjąć minimalne memlo = $2000. Natomiast asekuranckie minimalne memlo dla loadera to będzie pewnie $0C00 (ogólnie loader łatwo może mieć mniej, pod warunkiem, że to nie jest format SDX i dysk z 512-bajtowymi sektorami, wtedy zaczyna się problem ze zmieszczeniem wszystkiego pomiędzy $0700 a $0BFF - a dobrze by było móc gierki ładować z takiego dysku, bo to i pojemność większa i szybkość znacznie lepsza).

1,996

(96 odpowiedzi, napisanych Fabryka - 8bit)

xxl napisał/a:

moglbys tez powiedziec gdzie dla sdx/kmk jest w miare bezpiecznie cos ulokowac podczas ladowania?
1. $100-$17f stos
2  $480-$4ff bufor basica
3. $580-$5ff bufor fp
4. $600-$67f
5. $680-6ff

Wszystkie te miejsca są "bezpieczne". BIOS dysku używa paru komórek na stronie zerowej, których przy pracy ze zwykłą stacją dysków używa SIO (adresy $30-$40). Poza tym korzysta tylko ze swojej wewnętrznej pamięci RAM, która, jak już to jest wyżej napisane, podczas transmisji pojawia się pod $DE00.

SDX podobnie. Poza tym bufor magnetofonu i spółka ($0400-$05FF) oraz stos ($0100-$017F) zostanie nadpisany przez formatter, kiedy wywołasz z programu XIO 254 i każesz sformatować dyskietkę, a bufor FP może być nadpisany przy wywołaniu niektórych funkcji specyficznych dla SDX (w rodzaju: otwarcie pliku z poszukiwaniem go wzdłuż ścieżki dostępu). Pobieranie parametrów z linii komend itp. może spowodować podpięcie kartridża na chwilę (pod $A000-$BFFF). To chyba wszystko.

1,997

(14 odpowiedzi, napisanych Software, Gry - 16/32bit)

mono: font jest zapisany w postaci bitmapy (obrazka) o wymiarach oidp 192x8 - co do liczb mogę się mylić, ale ten rozmiar zapisany jest w nagłówku fontu.

PS. font 8x16 wygląda na małym Atari obleśnie, nie wiem dlaczego. Na ST (mono) był OK.

1,998

(96 odpowiedzi, napisanych Fabryka - 8bit)

True. "ROM włączony" nie oznacza, że urządzenie PBI nie podepnie swojego RAM-u w obszar $d800-$dfff. Aczkolwiek na naszym interfejsie próba bezpośredniego I/O pod ten adres powinna dać w tym momencie error 139. Ale tak poza tym to kwestia loadera, powinien taki zapis czy odczyt zbuforować.

1,999

(79 odpowiedzi, napisanych Fabryka - 8bit)

Wszystko jest dla ludzi z głową na swoim miejscu.

2,000

(3 odpowiedzi, napisanych Sprzęt - 8bit)

Lista części w Atariki wzbogaciła się o 45 numerów katalogowych wraz z nazwami bytów elektronicznych, których chwilowo nie umiem do niczego przypisać. Tymczasowo wrzuciłem je jako części niezidentyfikowane:

http://tiny.pl/hxktz

Gdyby ktoś wiedział, jakie to są konkretnie części oraz od czego, to proszę o info tutaj albo wprowadzenie informacji bezpośrednio do hasła. Część tego towaru może być od Atari 1450XLD i tym podobnych wynalazków.