2,201

(4 odpowiedzi, napisanych Programowanie - 8 bit)

http://www.atari.org.pl/forum/viewtopic.php?id=5685

2,202

(10,041 odpowiedzi, napisanych Bałagan)

gepard napisał/a:

Za jakiś czas dowiemy się, jak to dosłownie rozpętaliśmy II WŚ.

No, film już jest - "Jak rozpętałem 2 WŚ" ;>

2,203

(14 odpowiedzi, napisanych Programowanie - 8 bit)

Dzięki epi.

Wynik jest zwracany przez USR lub może być odczytany z 203..204.

2,204

(14 odpowiedzi, napisanych Programowanie - 8 bit)

W przypadku braku symbolu zwraca zero.

2,205

(14 odpowiedzi, napisanych Programowanie - 8 bit)

Kod zwracający adres dowolnego symbolu:

fr0 = $d4
FSYMBOL = $7eb
pla
pla
tax
pla
jsr FSYMBOL
sta fr0
stx fr0+1
rts

oczywiście symbol MUSI istnieć, MUSI być w pamięci podstawowej, bo ignorowane są wszystkie błędy.
Wywołanie z BASICa za pomocą:

X=USR(ADR("kodprogramu"),ADR("CURDEV  "))

Edit: Załącznik

2,206

(14 odpowiedzi, napisanych Programowanie - 8 bit)

Heh. Cały ten kawał kodu, co spłodziłem można zawrzeć jednym prostym XIO: http://atariki.krap.pl/index.php/GET_CURRENT_DIRECTORY (niestety nie da się użyć z BASICa).

Okazało się natomiast, że problem pina nie polega na zmianie bieżącego KATALOGU, ale że chciałby on jakoś zmienić bieżący DYSK. A do tego nie ma funkcji... Może w przyszłości dałoby się to robić XIO 44 z jakimś parametrem w icaux?
A tymczasem można to chyba osiągnąć za pomocą:

lda #numer dysku
sta CURDEV

2,207

(14 odpowiedzi, napisanych Programowanie - 8 bit)

XIO 44,#n,0,0,"Dx:path"

?

2,208

(42 odpowiedzi, napisanych Fabryka - 8bit)

Piękny.

2,209

(14 odpowiedzi, napisanych Programowanie - 8 bit)

U_SFAIL smb 'U_SFAIL'
U_XFAIL smb 'U_XFAIL'
CURDEV smb 'CURDEV'
PATH = $7a0

  lda CURDEV
  and #$f
  ora #'A'
  sta cwd
  lda #<?err
  ldx #>?err
  jsr U_SFAIL
  lda #<cwd
  ldx #>cwd
  sta FILE_P
  stx FILE_P+1
  jsr GETCWD
  jsr U_XFAIL
  ldy #-1
?loop:
  iny
  lda PATH,y
  sta cwd+2,y
  bne ?loop
?err:
  rts
cwd .db '?:',0
  .ds 63

W cwd masz ścieżkę z nazwą urządzenia.

2,210

(57 odpowiedzi, napisanych Fabryka - 8bit)

Ja również poproszę IOBoard i SimpleStereo.

2,211

(4 odpowiedzi, napisanych Software, Gry - 8bit)

U Ciebie to jednak czas płynie w drugą stronę...

Edit: A w takim razie może powinieneś zaczynać od postu w stylu: "Wielkie dzięki za pomoc - problem okazał się trywialny, a z Waszą pomocą został rozwiązany", po czym następowałyby nasze posty wyrażające uprzejme zainteresowanie o co właściwie chodziło.

2,212

(4 odpowiedzi, napisanych Software, Gry - 8bit)

A co się dzieje Pin? Nic nie napisałeś - może to simdrv (oprogramowanie)?

2,213

(61 odpowiedzi, napisanych Fabryka - 8bit)

No kod by można wsadzić (369 bajtów). Bo co do ekranu (200 bajtów) i dlisty (86 bajtów) to już nie ma jak zagwarantować, żeby zawsze włączony był ten sam bank extramu (dla ANTICa).

Edit: Co do sterownika to nie wiem - możliwe, że wystarczy zmienić .COM na .SYS, ale to przecież nie jest sterownik tylko jakaś popierdółka.

2,214

(61 odpowiedzi, napisanych Fabryka - 8bit)

No z VBXE nie działa :) W kolejnej wersji będzie wyłączanie XDLISTy.

Edit: A w ogóle to od jakiegoś czasu jest dostępna wersja 1.06.
Z /D ilość_sekund podaje się okres bezczynności ale tylko w SDX.

A ja styropiany.

2,216

(163 odpowiedzi, napisanych Fabryka - 8bit)

Leniwy ziom - dodajmy. Bardzo.

2,217

(47 odpowiedzi, napisanych Scena - 16/32bit)

Genialny pomysł! Biorę 3 sztuki :D Pin - będziesz bogaty!

2,218

(47 odpowiedzi, napisanych Scena - 16/32bit)

A kojarzycie sarkofag?

2,219

(1,754 odpowiedzi, napisanych Fabryka - 8bit)

Raczej:

ldy end_adr_lo
lda end_adr_hi
cpy load_adr_lo
sbc load_adr_hi
bcs ladujemy_dalej_URAAaa

2,220

(1,754 odpowiedzi, napisanych Fabryka - 8bit)

Marek Konopka napisał/a:

Jeśli odnosisz się do mojej wypowiedzi, to z niej nie wynikało, że sygnatura ($FF FF) może występować tylko w pierwszym segmencie - wręcz przeciwnie.

Nie odnoszę się - przypadkowe podobieństwo niezamierzone :)

Marek Konopka napisał/a:

To jedynie Nasze założenie powodujące, że taki plik zostałby prawidłowo załadowany.

Racja.

2,221

(1,754 odpowiedzi, napisanych Fabryka - 8bit)

Komplikujesz. Jeśli sygnatura jest opcjonalna to oznacza, że może istnieć plik, w którym każdy blok ma sygnaturę. Jeśli $FF$FF oznacza sygnaturę bloku po której następuje adres początku i adres końca, to blok z adresem początku $FFFF ale bez sygnatury jest po prostu błędnie wygenerowany.

Edit: Nic mi natomiat nie wiadomo o tym, że sygnatura ma występować tylko w pierwszym bloku, a w następnym jej nie ma. Nawet w Atariki pisze, że w pierwszym jest obowiązkowa, a w kolejnych opcjonalna.

Plik taki ma strukturę blokową, tzn. składa się z jednego, bądź więcej bloków, czy też segmentów, przy czym pierwszy z nich musi zaczynać się sygnaturą w postaci słowa $FFFF. Pozostałe bloki mogą zawierać tę sygnaturę, ale nie jest to warunek konieczny - wszystkie natomiast muszą zawierać nagłówek.

Edit 2: usystematyzowanie pojęć

2,222

(1,754 odpowiedzi, napisanych Fabryka - 8bit)

No to akurat jest chyba proste :) Sygnatura jest wymagana w pierwszym bloku pliku - jeśli jej nie ma DOS raportuje error 152 (not binary format). Kolejne bloki MOGĄ jej nie mieć. Ale MOGĄ mieć więc nie ma problemu.

2,223

(1,754 odpowiedzi, napisanych Fabryka - 8bit)

Jednym z ograniczeń standardowego formatu pliku binarnego jest to, że bloki ładują się pod STAŁY adres. A w OS istnieje przecież coś takiego, jak MEMLO które jest olewane przez DOS podczas ładowania pliku binarnego (no AtariDOS chyba sprawdza czy nie próbuje się go nadpisać). Dopiero Sparta potrafi sobie blok załadować na MEMLO, ale ma już zupełnie inny format pliku niekompatybilny z resztą DOSów.
xBIOS xxla ma tę zaletę,  że zajmuje pamięć między $700..$BFF i wiadomo gdzie na 100% się nie ładować. I ta granica jest STAŁA (póki co ;>).
Założenie, że "porządny" DOS zajmuje pamięć poniżej $2000 jest sztuczne i jest konsekwencją stosowania formatu binarnego - gdyby chcieć na serio traktować MEMLO (a DOS nie ma do tego żadnego supportu) to trzeba by pisać programy relokowalne i własnoręcznie sobie je relokować. Inną opcją jest wykorzystanie ACX i wykrywanie czy mamy do czynienia z XL/XE oraz użycie relokatora, który jest UKRYTY w systemie i używany jedynie do ściągania driverów z urządzeń SIO. Dlaczego DOS z tego nie korzysta? Do w serii 400/800 nie ma? Zawsze można było rozpoznać rodzaj OSu i go sobie doładować.

@MarekKonopka: Przecież można załadować blok pod $FFFF - taki blok wygląda np. tak:

$FF $FF $FF $FF $FF $FF dana

Wiele loaderów pozwoli na adres końca mniejszy niż początkowy, co pozwoli od razu załadować dane na zpg, ale załóżmy że jest to niepolityczne bo a nuż w przyszłości Atari będzie mieć liniową pamięć poza 64k - kończmy więc na $FFFF.

Edit: Innym ograniczceniem podczas korzystania z extramu zgodnego z rambo jest nie umieszczenie pamięci ekranu/dlisty w $4000..$7FFF. Kolejnym jest cartridge z DOSem $A000..$BFFF. Obszar od $C000..$FFFF jest niedostępny, no bo to ROM a DOS nie potrafi tam niczego załadować. Więc aby ładować program w zgodzie ze sztuką należałoby używać w pliku binarnym dwóch obszarów:
- $2000..$3FFF,
- $8000..$9FFF (odpada kiedy mam karta 16K).
16K (8K przy bardziej wymagającym karcie) - hmmmm ciekawe, który z projektantów gier się tym przejmował?

2,224

(36 odpowiedzi, napisanych Software, Gry - 8bit)

Jeśli masz na myśli tę chmurę, to zbija się ją "całuskiem".

2,225

(66 odpowiedzi, napisanych Bałagan)

Mnie się też "jeż mode" włącza jak widzę mistrzów świata (z jednym takim pracowałem w firmie 6 lat). Miał jeszcze kilka innych nieprzyjemnych właściwości jak donosicielstwo, ukrywanie własnych błędów i całkowita nieumiejętność autoweryfikacji. Szefowie hołdują często zasadzie, że "człowiek z zewnątrz jest ZAWSZE lepszym specjalistą" niedoceniając ludzi, których mają u siebie.
Jeśli idzie o wizualne projektowanie - dawno temu Intel (i pewnie nie tylko) wypuszczał kity do takiego klockowego projektowania sterowników na bazie '51. Można było sobie tam wyklikać różne rzeczy, tylko potem okazywało się, że prosta aplikacja z pomiarem temperatury i transmisją RS-232 (co można było bez problemu zrobić na 8-nogowym Microchipie z 512 słowami wbudowanego ROM) i za znacznie niższą cenę wymagała 64K zewnętrznego ROMu i kosmicznego mcu. Nie spotkałem się wtedy żeby ktoś poważnie takie narzędzia traktował. Chyba tylko w celach edukacyjnych czy szybkiego prototypowania. Ale być może czas zrobił swoje.
Ogólnie zgadzam się, że cena tego proca może i jest wysoka, ale to przecież zależy od rynku na którym zostanie zastosowany. Może tam gdzie cena elementów nie jest istotnym składnikiem, a raczej czas poświęcony na napisanie i przetestowanie oprogramowania odnalazłby się doskonale. Cena to tylko cena. W playerach do mp3 pewnie za wysoka, w urządzeniach medycznych czy sterownikach procesów przemysłowych być może pomijalna.
Rynek na pewno zweryfikuje firmę Gryf bardzo szybko - póki co od 2 lat sobie radzą, a ponoć 2 lata to dobry moment na pierwszy kryzys.
Dokąd to prowadzi? Do gigabajtów RAMu i narzędzi w których "hello world" zajmuje 1mb ram :D.