876

(46 odpowiedzi, napisanych Programowanie - 8 bit)

Rozpoznanie bojem :)

877

(46 odpowiedzi, napisanych Programowanie - 8 bit)

Mniej więcej. W bajcie jest tu 8 bitów, więc w trybe hires masz 8 pikseli na bajt, a w multicolor 4 piksele na bajt.

878

(46 odpowiedzi, napisanych Programowanie - 8 bit)

To teraz ja może zdam kilka pytań:
1. Ile pikseli znajduje się w bajcie w trybie 2?
2. Ile pikseli znajduje się w bajcie w trybach 4 i 5?
3. Dla jakiego trybu przygotowany jest standardowy generator znaków, którego używasz?
Wszystko wyświetla się poprawnie.

Edit: http://atariki.krap.pl/index.php/ANTIC_ … by_znakowe

879

(364 odpowiedzi, napisanych Fabryka - 8bit)

Artu2tu napisał/a:

Reasumujac: jest moc.  Ciekawe,  czy kolejna wersja emulatora ZX działająca na Rapidusie i VBXE będzie wspierała Sonari?

Ależ wspiera. Należy mu tylko skonfigurować adres.

Edit: W pliku ZX.CFG należy dodać linijkę:

AY=$D560

880

(364 odpowiedzi, napisanych Fabryka - 8bit)

Na filmie @Artu2tu zauważyłem, że są problemy z generatorem szumów. Podczas prób z prototypem SONari od Torimana zdarzyło mi się użyć kiedyś wadliwego AY, który nie generował szumów. Tak więc problem może leży w wadliwym układzie.

881

(219 odpowiedzi, napisanych Fabryka - 8bit)

1. ZuluGula - 1szt.
2. pancio.net - 1szt.
3. Cobol - 1 szt.
4. atarixegs - 1 szt.
5. Sikor - 2 sztuki
6. Pin - 1szt - ale raczej pod warunkiem, że będzie to cart z przelotem
7. Mono - 2 szt.

882

(46 odpowiedzi, napisanych Programowanie - 8 bit)

http://www.virtualdub.org/downloads/Alt … Manual.pdf

ad.1. czas który zabiera antic jest uzależniony od trybu dl
ad.2. licznik danych antica jest 12-bit 
ad.3. wystarczy o ile nie wyłączasz przerwań vblk
ad.4. nie widziałem

883

(364 odpowiedzi, napisanych Fabryka - 8bit)

Mq napisał/a:

@Mono, nie wiem na ile tam ten Twój soft już jest gotowy, ale może dał byś jakiś kawałek testowego programiku, który zrobi cokolwiek, żeby chłopaki mogli posprawdzać jak już złożą?

http://mono.atari.pl/psgplay/psgplayh.atr
Odpalamy:

PSGPLAYH /A $D560 SPEJS

884

(364 odpowiedzi, napisanych Fabryka - 8bit)

Mq napisał/a:

@Mono: czy w takim razie dla wygody użytkowników Twoje programiki mogły by jako domyślny przyjmować adres bazowy $D560 zamiast obecnego $D500?

Ma się rozumieć - jak zwykł mawiać Miś Uszatek.

885

(364 odpowiedzi, napisanych Fabryka - 8bit)

Mq napisał/a:

Adres żeby ustawić, to trzeba zlutować _tylko_jedno_ z połączeń na tej "drabince". Moja sugestia jest taka, żeby poprosić Mono o wytyczne, bo to on pisze soft. Mono jak czytasz, to proszę, wypowiedz się tu:-)

Moje programiki można konfigurować podając adres karty za pomocą /A adres, więc docelowy adres urządzenia nie jest wielkim problemem. Domyślnie przyjmowany jest adres bazowy $D500.
Jeśli dobrze widzę adres bazowy SONari może być skonfigurowany za pomocą jumperów SJ3..10 (wg schematu http://raven1.magix.net/sonari/SONari_stereo.pdf) co $20 bajtów. Ponieważ SlightSID siedzi sobie w obszarze $D500..$D542, to może niech adres bazowy SONari byłby w $D560? To będzie Y3 (czyli SJ6) zwarty?

Edit: Pamiętajcie jeszcze o SJ1 i SJ2 jak nie chcecie żeby programy wypisywały Wam że znalazły AY a macie wsadzone YM :)

886

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

@Impuls: Zerknij na kolejną odsłonę rodziny 65 czyli na 65C816 i od razu humor Ci się poprawi. Tego procesora możesz używać z Rapidusem.

seban napisał/a:

EDIT2: sprawdziłem wersję XEX, po 28 levelu który ma "?" jako układ bloków do rozbicia... następuje level 29 z dwoma rzędami klocków u góry, po czym odpala się level 30 i to jest już kaszana i śmiecie na ekranie. sprawdzę zatem oryginał na carcie. Sprawdziłem oryginał na carcie, odpalony na real sprzęcie. Gra zachowuje się dokładnie tak samo... sieczka na 30-levelu.

Czyżby autor założył że nikt nie dotrze tak daleko?

EDIT3: LOL... autor popełnił błąd w kodzie ;) zakładał że poziomów będzie 49... jednak poziomów w grze umieścił 29... poziom 30 faktycznie nie istnieje... po poprawce w kodzie gry po przejściu 29 poziomu... gra po prostu startuje od nowa tzn. od poziomu nr 1 :) nie ma żadnego zakończenia, nawet napisu "congratulations" :D

Niesamowite - Nexuss na carcie, choć też zepsuty. Ale odkrycie jest fajne - wielkie dzięki za podrążenie tematu i za poprawkę!

888

(106 odpowiedzi, napisanych Fabryka - 8bit)

Ja też chętnie nabyłbym taki zamiennik lub też dwa.

889

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

Zanabyłem drogą kupna 130XE SECAM od Bitmana i stwierdzam, że FGTIA poprawnie generuje wszystkie sprajty i obsługuje kolizje (testowane na SysInfo2), ma 8 odcieni i zarówno tryby ANTIC-a, jak i GTIA wyświetla poprawnie.

890

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

Podłączone i sprawdzone. Monitor ma proporcje 4:3 a do tego co Panowie pisali http://www.atari.org.pl/forum/viewtopic … 38#p241338 podzielę się swoimi wrażeniami:
1. Atari 130XE PAL obraz z wyjścia VBXE (RGB) podłczone przez SCART - obraz stabilny i ostry, nic nie drży. Sygnałów composite video ani chroma/luma nie testowałem, bo nie mam kabelków.
2. Atari 130XE SECAM obraz z wyjścia monitorowego (video output) podłączony przez SCART - obraz stabilny i ostry, kolory chyba poprawne bo nieco inne niż w PAL.
Nie zaobserwowałem opóźnień.
Więc ten monitor (LG FLATRON M1917A) chyba można spokojnie polecić do VBXE.

891

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

Dzięki Panowie. Poczytałem wątki, w których pisaliście o różnych modelach. Niestety LG M1721A nie udało się namierzyć, ale zamówiłem LG FLATRON M1917A i zobaczymy jak się będzie sprawować. Obadam rzecz jak już przyjdzie i zdam relację.

892

(157 odpowiedzi, napisanych Zloty)

No bardzo ładna inwitka. Gratulacje Lisu!

893

(8 odpowiedzi, napisanych Programowanie - 8 bit)

Tak czułem niestety. Szkoda. Ale zrobię w wolnej chwili jednak test, bo kto wie - może wszyscy będziemy zaskoczeni :) Dzięki.

894

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

No i niestety kolejny monitorek (tym razem Commodore 1084, wcześniej Phillips 8833) odszedł do Krainy Wiecznych Łowów.
Używałem go głównie do działań z VBXE i pomyślałem, że może spróbuję się zaopatrzyć w jakiś monitor LCD tym razem. CRT są już leciwe i niestety będą wysiadać coraz częściej (jakkolwiek zakupię jakiś CRT na pewno, ale chciałbym mieć jakiś sprzęt co do którego nie będę musiał się obawiać że lada dzień i ten przeniesie się na łono Abrahama).
Moja idealna wizja:
1. Obsługa PAL, NTSC i SECAM.
2. Obsługa interlace zarówno standardowego (mruganie naprzemienne ramkami parzystymi), jak i Rybagsowego (ramki parzyste i nieparzyste).
3. Wejście RGB, wejście obsługujące sygnał ze standardowego gniazda monitorowego Atari.
4. Proporcje ekranu 4:3.
5. Małe opóźnienie bo miło byłoby gdyby dało się na nim grać.
Oczywiście liczę się z tym, że może ideał nie jest możliwy do spełnienia.
Czy możecie mi jakiś model polecić?

895

(75 odpowiedzi, napisanych Programowanie - 8 bit)

Wszystko to znajdziesz u Zientary w "Procedurach Wejścia/Wyjścia": http://tajemnice.atari8.info/ksiazki/index.html
Można spojrzeć do "Procedur interpretera BASIC-a" w jaki sposób realizowane jest LOCATE - wydaje mi się, że x i y należało wstawić do COLCRS i ROWCRS po czym wykonać GET (PLOT analogicznie, ale z PUT-em). Ale głowy nie dam.

896

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

Pin do ściągnięcia zasobów z internetu używa Atari :] Serio.

897

(56 odpowiedzi, napisanych Bałagan)

AS... napisał/a:

W ramach świątecznego prezentu, proponuję odbanować Bezrobottnego :)

Chciałbyś wprowadzić na forum element baśniowy?

898

(56 odpowiedzi, napisanych Bałagan)

Ale Święty Mikołaj był 2 tygodnie temu. Teraz CHOINKA :)
Zdrowych i spokojnych oraz szczęśliwego nowego!

Dziękuję, płytki dotarły całe i zdrowe.

tr1x napisał/a:

I teraz pytanie o program, który posłuży do przeprowadzenia tego eksperymentu. Wstępnie wydaje mi się, że program, którego kod wstawiłem w pierwszym wpisie w tym wątku (korzystający z joysticka i operujący na rejestrach cieniach) będzie odpowiedni. Można go zmodyfikować, aby zmieniał także (albo wyłącznie -- fotorezystor będzie umieszczony przy górnej krawędzi ekranu) kolor ramki. Joystick nie będzie tu elementem, w stosunku do którego cokolwiek mierzymy, a jedynie wyzwalaczem zmiany koloru tła (można też co sekundę zmieniać kolor tła, o czym pisałeś). Jeśli dobrze rozumiem, to ponieważ w tym programie operujemy na rejestrach cieniach, to synchronizujemy się z powrotem pionowym i dzięki temu pozbywamy się problemu związanego z niepewnością, gdzie była plamka w momencie zmiany koloru tła.

Tak jest. W tym przypadku cienie będą doskonałe.
Przykładowy program zmieniający kolor co 1s z czarnego na biały:

RTCLOK = $12
COLBAKS = $2C8

  ldx #$00
  ldy RTCLOK+2
blink:
  tya
  clc
  adc #50
  tay
sync:
  cpy RTCLOK+2
  bne sync
  stx COLBAKS
  txa
  eor #$0F
  tax
  jmp blink