776

(279 odpowiedzi, napisanych Fabryka - 8bit)

Deklarowałem, że jeśli nikt inny się nie podejmie, ja napiszę ten firmware. Tyle że mam już pod opieką parę rzeczy, i branie na siebie kolejnej nie wróży dobrze dotrzymywaniu jakichkolwiek terminów :)

777

(46 odpowiedzi, napisanych Fabryka - 8bit)

toriman1 napisał/a:

Przy zastosowaniu mikroprocesora jest to możliwe - jednakże mikroprocesor musiałby wykonywać ciągły polling rejestrów SID aby nie zostać zaskoczonym przez "niespodziwany odczyt" hehe).

A nie można wykorzystać patentu z YM/AY, że mamy specjalny rejestr, do którego program zapisuje nr rejestru I/O, który chce odczytać, a drugim rozkazem odczytuje z niego daną? To eliminuje problem "ciągłego pollingu", ale czy to przydatne, musiałby się np. mono wypowiedzieć.

778

(1,653 odpowiedzi, napisanych Bałagan)

Przykład, poniekąd na czasie: http://drac030.krap.pl/wapniak-2012.flac

Tylko że z głośników monitora brzmi to inaczej, by nie rzec, że lepiej. I nie wiem, czy to mój pecet źle nagrywa, czy monitor "ulepsza" to, co idzie na głośniki...

779

(49 odpowiedzi, napisanych Zloty)

Ode mnie 30 PLN.

780

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

Nie, kwestia inicjowania POKEY-a przez procedurę RESET. 400/800 inicjują zegar, oidp, na 64 kHz, a XL OS na 1,77 MHz, i stąd cały ambaras.

781

(126 odpowiedzi, napisanych Zloty)

@Sikor: czy mógłbyś umieścić na stronie adres party place w jakimś widocznym miejscu? "Mapka" jest jakaś mało czytelna. Dzięki!

782

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

Adam Klobukowski napisał/a:

Z mojego punktu widzenia, tryb chunky to tryb z indeksowaniem koloru.

Uhm. A dlaczego akurat indeksowanie koloru jest kluczowe?

783

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

Adam Klobukowski napisał/a:

Jeśli chodzi Ci o tryb Truecolor, to nie jest to to samo co chunky.

Hmm. Mógłbyś rozwinąć? O ile jeszcze w ogóle cokolwiek pamiętam, True Color Falcona to chyba dość dobry przykład na tryb chunky: 1 piksel opisany jest przez jedno, 16-bitowe słowo w pamięci obrazu. A taka organizacja obrazu stanowi przykład trybu chunky na en.wiki:

http://en.wikipedia.org/wiki/Packed_pixel napisał/a:

In packed pixel or chunky framebuffer organization, the bits defining each pixel are grouped together. For example, if there are 16 bits per pixel, each pixel is represented in two consecutive (contiguous) 8-bit bytes in the framebuffer (a.k.a. screen buffer).

784

(8 odpowiedzi, napisanych Programowanie - 8 bit)

Gdyby komuś chciało się z tym powalczyć: można łatwo zakwestionować listingi na podstawie tego, że nie pochodzą ze źródeł, lecz jest to twórczość własna któregoś z redagujących hasło. Zasada WP:NOR http://en.wikipedia.org/wiki/Wikipedia: ... l_research

785

(8 odpowiedzi, napisanych Programowanie - 8 bit)

Hehe, no tak.

Tak a propos, widzę, że to już zniknęło, ale pl.wiki w artykule o 6502 był kiedyś przykładowy listing demonstrujący dzielenie na 6502: konkretnie była to procedura dzieląca zawartość akumulatora przez 2 przy użyciu wielokrotnego odejmowania. Do znalezienia w historii (rok 2010).

786

(279 odpowiedzi, napisanych Fabryka - 8bit)

Proszsz http://atariki.krap.pl/index.php/Evie

787

(41 odpowiedzi, napisanych Bałagan)

A tu filmik nagrany 2 lata temu w Cisnej. Ogólnie nagrane telefonem i z doskoku, więc sorry za marną jakość. Może jeszcze kiedyś będzie szansa złapać tę kolejkę lepiej.

PS. Odpowiedź na pytanie, które pada w tle, brzmi: 40 koni :D

788

(279 odpowiedzi, napisanych Fabryka - 8bit)

pasiu napisał/a:

Chcąc mieć jednak więcej to wchodzimy już w temat implementacji 816 w fpga

Pytanie, czy odtworzenie 65C816 w FPGA nie grozi aby nalotem prawników nasłanych przez producenta oryginału... Tzn. samo odtworzenie zapewne nie grozi (chociaż pewien tego nie jestem), ale już wypuszczenie karty z takim rdzeniem jakby pewnie mogłoby.

789

(279 odpowiedzi, napisanych Fabryka - 8bit)

No nie, coś mi się potentego... jeszcze raz: 5th_demo.z80 to jest plik na ZX Spectrum 128. Format wersja 2, hardware type 3, czyli wg opisu "Spectrum 128". Zresztą zawiera bloki pamięci nieistniejące w 48k. Sry.

790

(279 odpowiedzi, napisanych Fabryka - 8bit)

Pin napisał/a:

Draco - jeden z takich plików:
pin.atari.pl/zx_spec/5TH_DEMO.Z80

Faktycznie, to jest "48k + MGT ROM". Jeśli ten "MGT ROM" (cokolwiek to jest) nie jest jakoś absolutnie wymagany do działania programu, poprawię loader tak, żeby to akceptował bez jęczenia.

791

(279 odpowiedzi, napisanych Fabryka - 8bit)

Pin napisał/a:

Mam za to cały katalog demek oldschool w którym to większość przy uruchomieniu wypluwa komunikat, że nie jest to plik pod ZX 48k.

Może tak być, jeśli program jest pod 48k, ale został uruchomiony w trybie 128k i tak zrzucono snapszot, plik wtedy zawiera dodatkowe banki pamięci i tym podobne. Dla pewności możesz mi z jeden taki podesłać (najlepiej po jednym SNA i Z80, które tak mówią).

792

(279 odpowiedzi, napisanych Fabryka - 8bit)

Po demkach to się za wiele nie spodziewaj ;) Emulec nie trzyma żadnych timingów (po prostu robi ile może w czasie rzeczywistym), więc muzyczki, o ile nie są na VBL-u, Ci się raczej rozjadą; atrybuty ładuje raz na ramkę, więc żadne tam zmiany kolorów w środku linii atrybutów; aha, i 14 MHz to za mało, żeby wszystko zmieściło się w ramce :)

793

(279 odpowiedzi, napisanych Fabryka - 8bit)

Pin napisał/a:

opcja Save sna, też by się przydała

Masz "Save memory", która zapisuje plik .Z80. Ale to dopiero wczoraj zakodowane, więc mocno alpha, używać ostrożnie ;) Widzę, że są z nią kłopoty, jeśli się ma włączoną/załadowaną 80-kolumnową konsolę (CON.SYS). Na razie lepiej jest przejść w tryb 40-kol. i to Resetem, bo CON 40 nie pomaga. Właśnie próbuję zbadać, o co w tym idzie.

794

(279 odpowiedzi, napisanych Fabryka - 8bit)

Pin napisał/a:

$FF0081=$20

A jesteś w stanie wstawić tam $00 przez POKE?

Ten parametr /M to miał powodować, że emulator ma omijać pierwszy bank fast ramu.

Wręcz przeciwnie, wręcz przeciwnie: miał wymuszać ładowanie do pierwszego banku fast RAM-u niezależnie od tego, jakie ewentualnie bzdury zwraca funkcja alokacji pamięci.

@mono: słuszna uwaga.

795

(279 odpowiedzi, napisanych Fabryka - 8bit)

zx /? ;)

796

(279 odpowiedzi, napisanych Fabryka - 8bit)

Ja mam tak:

Z80,CAR:X.COM,F:>ścieżka>ZX.EXE -A -V 1 %

W Twoim rdzeniu ten "tryb kompatybilny" jest na stałe, czy da się wyłączyć? Konkretnie, po załadowaniu "pacza", co masz w $FF0081?

Dorzucę automatyczne wyłączanie, w razie czego (i włączanie z powrotem przy wyjściu, ma się rozumieć).

797

(279 odpowiedzi, napisanych Fabryka - 8bit)

Hmm. A pamiętny "tryb kompatybilności" http://www.atari.org.pl/forum/viewtopic ... 02#p180102 masz włączony czy wyłączony? Jeśli jest włączony, to wyłącz, bo to bruździ w fast RAM-ie.

798

(279 odpowiedzi, napisanych Fabryka - 8bit)

To przednio :) Taka uwaga: o ile dobrze rozumiem, staticu masz 512k, z tego 448k powyżej $00FFFF. Wynika z tego, że "ogon" programu zalega w SD-RAM-ie. Jeśli ta pamięć nie trzyma danych, to raczej nie licz na poprawne działanie Sinclair BASIC-a. Reszta powinna mniej lub bardziej chodzić.

799

(279 odpowiedzi, napisanych Fabryka - 8bit)

Sprawdź PM.

Na joystick chwilowo nic nie poradzę, zepsuł mi się.

800

(279 odpowiedzi, napisanych Fabryka - 8bit)

OK, chyba rozumiem problem, ale nie wiem, czy jest na niego dobre lekarstwo:

"SD-RAM nie działa za dobrze", ale pewnie się daje wykrywać, skutkiem czego tablica alokacji pamięci jest właśnie w SD-RAM-ie. Jeśli ten RAM nie działa dobrze, to pewnie jest w niej sieczka, a zatem funkcje alokacji pamięci zwracają mniej lub bardziej bezsensowne wyniki. Jeśli dobrze popadnie, emulator załaduje się do static RAM-u i będzie działał. Jeśli źle popadnie, pójdzie w jakieś buraki.

Mogę dodać przełącznik wymuszający ładowanie pod $010000, może pomoże.