Der Adressbus ist übrigens nur 8 Bit breit, aber es können trotzdem 65536 Adressen angesprochen werden, indem erst das High- und dann das Low-Byte übertragen wird.
Das ist mehr oder minder "normal", sprich bei vielen CPUs und erst recht µCs so, das nicht gemultiplexte vom 65xx ist eher die Ausnahme 
Aber: da gibt es dann ein Multiplex-Signal (TPx) aus der CPU raus, das regelmäßig wechseln muss, damit die CPU die ganzen 16bit auch raus bringt und ein externes Latch, das diese Daten zwischenspeichert, d.h. weitere Fehlermöglichkeiten.
Aber ich würde zuerst mal nur dieses Umschaltbit sowie die /CS resp. /CE oder /EN Leitungen von ROM, RAM(s) und eben auch den I/O-Chips, also allem, was irgendwie auch am Datenbus hängt anschauen, das muss alles regelmäßig mal angesprochen werden, d.h. low werden, wenn es wie oben gezeigt Low-Active-Signale sind. Manche bausteine haben auch mehrere dieser Anschlüsse und selbst Kombinationen mit High-Activ sind nicht ungewöhnlich, siehe auch die MOS Bausteine wie 653x oder auch die ROMs dort.
Sparte eben ein paar Gatter für die Adressraum-Selektion ein und somit Kosten und Platinenplatz.
Also erstmal an den Ziel-ICs diese Chip-Select Pins vermessen und wenn dort feste Pegel herrschen (und nicht wenigstens einer je Chip Aktivität zeigt, sollten es mehrere sein), dann den passenden Dekoder-Chip finden (sofern nicht direkt mit der CPU, sprich den Nx Ausgängen verbunden) und durchmessen, die hängen eingangsseitig dann am Adressbus (und/oder den Nx Leitungen) und eben ausgangsseitig an den Chip-Select-Leitungen, Enables oder wie auch immer das je Chip und Datenblatt benannt wurde.
/MRD wird wohl auch in I/O Cyclen bedient und ist dann quasi baugleich zu den vom 65/68xx gewohnten R/W-Signal, wobei scheinbar auf diese Weise aber ne Art direkter Pfad von externen RAM zum selektierten I/O Kanal möglich ist, ähnlich eines DMA, während /MWR nur in SpeicherSCHREIBzyklen aktiv ist.
Wenn das Alles stimmt und auch am kompletten Adressbus (z.b. aus Sicht von RAM und ROM) Betrieb herrscht, dann sollte auch die LED vom Q-Port brennen, also zum testen CPU raus und mal beide Pegel direkt an den Pin legen, vielleicht ist die ja auch defekt oder der Vorwiderstand/Leiterbahn etc.
So lange die nicht brennt scheint das Programm nicht zu laufen oder hat Fehler, aber das meldet die Kiste doch vermutlich dann durch blinken oder Fehlercode im Display, da war doch was beim ersten Patienten, oder?
Als Nächstes wären dann die Control-Bus Signale interessant, /Wait /INT und die DMA-Leitungen sollten alle inaktiv sein, sonst kann die Kiste nicht vernünftig anlaufen, bestenfalls am INT könnte etwas Bewegung sein, der Rest müsste bei dem kleinen System normalerweise inaktiv sein.
TPA und MEMRD resp. MEMWR sollten so aussehen:
Please login to see this attachment.
Möglicherweise sind die Chip select Leitungen auch durch die CPU Signale Nx abgebildet, aber natürlich kann man auch memory-mappen selbst wenn die CPU mehr Möglichkeiten hat, d.h. das hängt von der Verschaltung ab. An SC0 und SC1 sollte auch immer Bewegung sein, das sind die State-Ausgänge, mit denen die CPU kund tut, in welchem internen Cycle sie gerade ist (was den 65xx großteils leider fehlt, siehe Diskussion aktuell hier im Thread um die cmd G65SC02 basierte PC-Karte...)
Und:
Kontaktprobleme resp. umgeknickte oder "daneben" gesteckte Pins nochmals kontrollieren, das sind so die Klassiker, womit man sich selbst viel Sucharbeit spendieren kann...
Wenn das Alles nix bringt, würde ich zu einem Arbiträrgenerator, USB-IO-Block oder gleich zu nem entsprechend programmierten PIC oder Atmel greifen und den (über passend verdrahteten Adapter) im CPU-Sockel plazieren und dann mal "zu Fuß" diverse Adressen ansprechen samt aller notwendigen Control-Signale wie R/W, ALE oder wie sie bei dieser CPU eben alle heißen, letztlich ist das ja auch nix Anderes als bei anderen CPUs auch, da ja die Peripherie-Chips immer die gleichen Bedingungen brauchen, um zu funktionieren... Ein Logic-Analyzer parallel dazu (selbst billigste Ausführungen tun es da!) zum Rücklesen der gesetzten Pegel etc. ist natürlich auch hilfreich, aber ohne Stimulation allein sicher nicht sonderlich zielführend...
Wenn man auf diese Weise das RAM testen und das ROM auslesen kann, dann könnte man auch mal durchzählen am Adressbus und stoppen, sobald das Enable-Signal an den Chips der LED-Ansteuerung sich verändert, dann kennt man schon mal die Basisadresse dieser I/O-Blöcke und kann dann dort probieren, die auch extern anzusteuern.
So ein Programm, das die CPU nachempfindet, aber selbst via RS232 (also USB mit COM-Adapter) erreichbar ist, das ist nicht weiter kompliziert und schnell erstellt, vermutlich findet sich sowas auch im WWW schon halbwegs passend.
Dürfte aber leichter sein, eine bekannte und flashbare Plattform anzusteuern, als sich ein Testprogramm für die originale CPU zu schreiben. Alternativ kannst Du aber auch Deinen KIM da mal mit ins Spiel bringen und zum debuggen verwenden, z.b. über ne angeschlossene 6522 oder 6821 kann man ja die Signale der CPU auch generieren und passend einspeisen...
