Ponieważ w najciekawszym dziale tego forum `Rozmowy dotyczące sprzętu` rzadko pojawiają się nowe wątki, postaram się publikować co jakiś czas ciekawe treści, aby rozruszać forum. Wszak głównie na forum powinniśmy pisać właśnie o konsolach / kardridżach w ich technicznym kontekście, zamiast przechwałek `jaka to moja kolekcja dyskietek jest wielka`. Dziś czas na opis naprawy kardridża 168-in-1.
Kardridże na układach scalonych budzą zawsze ciekawość, dla jednych - w kontekście przeróbki ich na dev-cart, dla innych (np. mnie) - z uwagi na możliwość zapoznania się z mechanizmem, w jaki działa na nich przełączanie pamięci oraz jak zostało to zrealizowane w sprzęcie (elektroników kręcą takie rzeczy!)
Ostatnio trafił w moje ręce 168-in-1, niestety niesprawny. Kardridż był w całości na układach przewlekanych (a zdarzają się konstrukcję w których pamięć CHR-RAM jest SMD)
więc wylutowałem wszystko i jako pierwszy na świecie wreszcie postanowiłem przeanalizować jego sposób działania, odtwarzając schemat.
Mamy tu PRG-ROM (8 Mbit), CHR-RAM, dwa rejestry no i archaiczny układ programowalny PAL8V16, który steruje wszystkim. Podobny układ znajdziemy też na składance Złota 5, tylko tam producent postanowił dłutem zeskrobać jego oznaczenie.
Wszystkie scalaki (oprócz PAL-a) przetestowałem - okazały się sprawne. Więc cień padł na niego. Kolejnym problemem było to, że nikt do tej pory nie wiedział, jak ten układ działa. Analizując odtworzony schemat kardridża doszedłem, które sygnały poprowadzone do PALa są jego wejściami, a które wyjściami. Mając drugi, sprawny 168-in-1, wylutowałem z niego PALa i poddałem go analizie KrzysioTesterem. Na tej podstawie odtworzyłem funkcję logiczną scalaka, którą on realizuje, tj:
* ustala mirroring,
* wyższe linie adresowe pamięci,
* blokuje zapis do CHR-RAMu w pewnych sytuacjach:
Odtworzony schemat działania układu w języku VHDL:
library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use IEEE.NUMERIC_STD.ALL;
entity pal16v8_168in1 is
port (
cpu_a1 : in std_logic;
cpu_a0 : in std_logic;
cpu_d2 : in std_logic;
cpu_d1 : in std_logic;
cpu_d0 : in std_logic;
cpu_d7 : in std_logic;
cpu_d6 : in std_logic;
cpu_a13 : in std_logic;
cpu_a14 : in std_logic;
ppu_nwe : in std_logic;
prg_a16 : out std_logic;
prg_a15 : out std_logic;
prg_a14 : out std_logic;
prg_a13 : out std_logic;
ppu_a10 : in std_logic;
ppu_a11 : in std_logic;
chr_nwe : out std_logic;
ciram_a10 : out std_logic
);
end pal16v8_168in1;
architecture Behavioral of pal16v8_168in1 is
signal mode : std_logic_vector(1 downto 0);
begin
mode <= cpu_a1 & cpu_a0;
ciram_a10 <= ppu_a10 when cpu_d6 = '0' else
ppu_a11;
chr_nwe <= ppu_nwe when mode = "01" or mode = "10" else
'1';
prg_a13 <= cpu_d7 when mode = "10" else
cpu_a13;
prg_a14 <= '1' when cpu_a14 = '1' and mode = "01" else
cpu_d0 when cpu_a14 = '1' and mode = "01" else
cpu_a14 when mode = "00" else
cpu_d0;
prg_a15 <= '1' when mode = "01" and cpu_a14 = '1' else
cpu_d1;
prg_a16 <= '1' when mode = "01" and cpu_a14 = '1' else
cpu_d2;
end;
Kolejnym problemem było, jak naprawić ten kardridż. Co prawda układ PAL16V8 znalazłem w okolicznym sklepie za jakieś grosze, ale niestety nigdzie w sieci (!!!) nie ma informacji na temat programowania tych układów ani opisu konstrukcji doń programatorów. Przemysłowe programatory PALów kosztują grube pieniądze. Istnieje też nowsza rodzina układów, zgodna z nimi - GAL16V8, a programatory do nich można prosto zbudować, jednak te układy występują głównie w obudowach PLCC, więc o prostej podmianie i wlutowaniu układu musiałem zapomnieć, a zamiast tego - wymyślić inny sposób.
Postanowiłem zamiast zepsutego układu zrobić `protezę` w postaci układu programowalnego XC9572, który by realizował identyczną funkcję. Oczywiście układ XC9572 jest w obudowie PLCC, więc konieczne było stworzenie mini-PCB pod niego. Priorytetem było, aby całość po zlutowaniu nadal mieściła się w oryginalnej obudowie kardridża. Ponieważ egzemplarz XC9572, który postanowiłem przeznaczyć był trochę uszkodzony (miał upalonych kilka wyprowadzeń podczas moich wcześniejszych eksperymentów), to musiałem poprowadzić sygnały jedynie do działających nóg.
Stosując w projekcie mikrokontroler/FPGA, staram się tak wybierać wyprowadzenia, aby maksymalnie uprościć prowadzenie ścieżek.
Jak widać kardridż bez problemu mieści się w oryginalnej obudowie, a całość zadziałała od pierwszego uruchomienia.
