Samstag, 11. April 2015

DIY Wärmebildkamera

Ich habe über meine Osterferien mein länger liegendes Projekt weiter entwickelt: eine DIY Wärmebildkamera.

Vom Auflösevermögen kann man hier meine Hand ganz gut erkennen. Die Pixeldaten werden bilinear interpoliert auf dem TFT ausgegeben.

Basis ist folgendes:
- Melexis MLX90620 16x4 IR Array
- OV7670 CMOS Kamera
- 128x160 SPI Farb TFT
- Cypress PSoC 4, Cortex-M0 Pioneer Kit

Die Kameras sind auf einem Headerboard gesteckt, welches wiederum mit dem TFT Board auf einem Arduino Header Board gesteckt sind.

Das PSoC Kit hat einen Arduino Header, so dass alles perfekt passt :-)

Zur Zeit geht entweder Wärmebild oder Kamerabild. Mein Ziel ist, dass die Bilder am Ende gemischt werden.

Trotz zahlreicher Optimierungen bestehen noch Geschwindigkeitsprobleme. Vermutlich hilft nur ein besserer Controller mit DMA Transport für die Kameradaten (Pixelsynchroner Parallelbus).

Paar weitere Bilder:


Samstag, 8. Februar 2014

KGS K7070 Reparatur

Heute geht es in der Geschichte wieder etwas zurück... Mein A7150 (ein Robotron PC, mit 8086 CPU) meldete zuletzt eine Störung in seinem Grafik Subsystem, genauer dessen Steuerung, der KGS K7070.

Laut Fehlermeldung handelt es sich um einen EPROM Prüfsummenfehler. Ich bin mit normalen Messmethoden dem Fehler bisher nicht auf die Schliche gekommen. Grund genug, etwas größere Geschütze und Zusatzaufwand aufzufahren - die Hardware ist es wert :-)

Grundproblem bei der Fehlerdiagnose alter Hardware sind die Zahlreichen Bausteine. Ohne geeignete, systhematische Vorgehensweise, ist man ziemlich aufgeschmissen. Die KGS K 7070 ist in diesem Sinne ein eigener Rechner (der A7150 ist damit ein Multi CPU System), bestehend aus einer Z80 CPU, einer SIO, CTC, RAM und EPROM. Dazu gesellen sich ein paar Register und Steuerhardware für den Local-Bus zur Grafikkarte.

In diesem Fall liegt es nahe, eine Testfirmware für die Karte zu entwickeln. Diese Firmware muss in einen EPROM und das Verhalten getestet werden. Nun gab es in den 80er Jahren noch kein JTAG, Bootloader und andere komfortable Errungenschaften der Neuzeit. Damals benutzte man sog. EPROM Emulatoren, welche mittels SRAM und zusätzlicher Schnittstellen zum Füllen, einen ROM emulierten.

Ich habe mir einen gebrauchten PEPS Emulator angeschafft und die dafür notwendige Software geschrieben.


Die Befüllung des EPROM Emulators nimmt zeitgenössisch ein 386SX40 mit MS-DOS vor. Die Programme sind ebenfalls zeitgenössisch in Turbo C++ geschrieben :-) Die Schnittstelle zum EPROM Emulator ist ein klassisches BitBang mittels Parallelport.

Ein weiteres Problem war die Einrichtung einer Entwicklungsumgebung für U880 CPUs (Z80). Unter Ubuntu gibt es zum Glück das SDCC Compiler Paket in den Repositories. Zu dem SDCC ist es noch Sinnvoll den z88dk Compiler + Assembler zu installieren (einfach: apt-get install sdcc* z88dk*). Im Netz ist es schwierig, geeignete Informationen für ein funktionierendes Setup zu finden. Mit etwas Hilfe aus dem Robotron-Dunstkreis (thx Holm!), habe ich dann einfache Assemblerprogramme zum Laufen bekommen. Von diesem Schritt zum C - Programm ist es dann nicht mehr weit.

Mein Testprogramm besteht aus folgenden Dateien:
  • crt0.s (Bootscript in Z80 Assembler für Sprung auf _main aus dem folgenden C Code)
  • initi_ctc_sio.s (Init Script für CTC+SIO von Holm Tiffe, gehört mit in die crt0.s nach init)
  • main.c (das eigentliche Testprogramm)
  • ioport.s + ioport.h (Assembler Zugriffsroutinen auf I/O Ports vom C Programm aus)
Folgendes Makefile dient dem Built des Programmes:


all: release.bin release.hex release.dasm

Release: release.bin release.hex release.dasm

#Binary and HEX Output:
release.bin: release.hex release.ihx
srec_cat release.hex -intel -o release.bin -binary

release.hex: release.ihx
packihx < release.ihx > release.hex

#Compile Files:
main.o: main.c
sdcc -I ./ -mz80 -c main.c

mycrt.o: crt0.s
as-z80 -lo mycrt.o crt0.s

ioport.o: ioport.s
as-z80 -lo ioport.o ioport.s

#Links
release.ihx: main.o mycrt.o ioport.o
sdcc -I ./ -mz80 mycrt.o ioport.o main.o --no-std-crt0 --code-loc 0x0200 --data-loc 0x8000
mv mycrt.ihx release.ihx

#Disassembler:
release.dasm: release.bin
z80dasm -t -g 0x0 -l release.bin -o release.dasm

#Clean:
clean:
rm -f *\.o *\.ihx *\.sym *\.lst *\.map *\.noi *\.bin *\.dasm *\.lnk *\.rel *\.def *\.hex


Das ganze Schlamassel bindet man am Besten in eine IDE ein. Ich mag Code::Blocks sehr.

Das Programmgrundgerüst mit Ausgabe auf der seriellen Schnittstelle ist einfach gestrickt:
#include <stdio.h>
#include "ioport.h"

#define ctc    0x00     //RW
#define sioad  0x08     //RW
#define sioac  0x09     //RW
#define siobd  0x0a     //RW
#define siobc  0x0b     //RW
#define ereg   0x010    //R
#define areg   0x011    //W
#define sreg   0x012    //R
#define intrf  0x013    //RW
#define errf   0x014    //RW
#define memsel 0x015    //W
#define dsel0  0x016    //R
#define dsel1  0x017    //R

void out_string(char *str)
{
    unsigned char status;

    while (*str != 0)
    {
        do
        {
            status = in(sioac);
        }
        while( (status & 0x04) == 0x00 );

        out(sioad, *str++);
    }
}

void main()
{
    
    while(1)
    {

    }
}

Ein Speichertest lässt sich wie folgt implementieren, dazu muss "free" als erste ungenutzte Variable im DATA Speicherbereich deklariert sein. Von da an wird alles, inkl. dem Stack, überschrieben.
    addr = &free;

    while(addr < (unsigned char *)0xFFFF)
    {
        *(addr) = 0x55;
        *(addr) = 0xAA;

        if(*(addr) != 0xAA)
        {
            sprintf(buffer, "Error at 0x%X \n\r", addr);
            out_string(buffer);
            n_ok++;
        }
        else
        {
            ok++;
        }
        addr++;
    }

    sprintf(buffer, "ready size: 0x%X, def: 0x%X \n\r", ok, n_ok);
    out_string(buffer);

Über eine serielle Console lassen sich die Ausgaben auswerten. Die Speichergröße ist nicht wie erwartet 0x7FFF, da "free" nach notwendigen Zählvariablen und dem Ausgabebuffer definiert ist. Man sieht also, dass auch der RAM funktioniert.

Ein Registertest z.B. so:
    while(1)
    {
        out(areg, k);
        k++;
    }

Für den Registertest hilft ein billiger Logic Analyzer ungemein. Von 8 möglichen Datenleitungen hängen D0...D6 an den Eingängen 0...7 des DS8282 Registers. D7 nutze ich als Trigger am Strobe Eingang. Die hübschen IC Klammern habe ich beim Umzug der Firma aus dem Müll gefischt :-)

In der Software des Logic Analyzers sieht man schön, wie der Registerwert hochgezählt wird:

Weitere Tests werden folgen. Ich wünsche einen schönen Samstag Nachmittag :-)



Mittwoch, 15. Januar 2014

Reparaturbericht UM8810-PAIO

Ich habe heute mal wieder meinen Teil gegen die Wegwerfgesellschaft beigetragen.

Es geht um folgendes Board. Auf dem Bild ist der Dallas schon von mir "modernisiert" und ein anderer BIOS Chip installiert. Verkauft wurde das Board als defekt. Ich habs quasi als die "Katze im Sack" bei Ebay für nen kleinen Preis mitgenommen. Wenns denn klappt, dachte ich mir, ist dieses Board das schönere UM8810. Immerhin braucht es kein VRM Modul wie die späteren Revisions.

Als das Board heute eintraf, musste ich feststellen, dass es wohl mal aus den üblichen Schrott Auktionen stammte. Es kann auch sein, dass es auch einfach nur "hart" gelagert wurde. Auf der Unterseite waren augenscheinlich 3 Leiterbahnen defekt, welche ich schnell repariert habe. Hier und da noch mit dem Glasfaserpinsel Bröckel-Lötstopplack entfernt, um zu sehen, dass die restlichen Leiterbahnen in Ordnung sind.

Als nächstes die CPU gejumpert. Für erste Tests nehme ich immer einen Intel DX2-66 mit 5.0V. Die CPU geht in jedem Board und ich bin nicht auf einen funktionierenden Vcore Regler angewiesen.

Das UM8810 hat in fast allen Revisions im Gegensatz zum Rest der damaligen Welt ein Phoenix BIOS. Für mich ein Glücksfall, da es mich direkt auf die Problemlösung durch seine POST-Codes führte.

Der Speaker trötet mit jedem Rest "1-2-2-3" nach Phoenix - Notation. Laut Tabelle ein BIOS CRC Fehler. Also BIOS neu flashen.... aber gleicher Fehler hmmmpf. Ich habe dann erstmal den Line Transceiver vom BIOS ausgelötet und auf Funktion getestet. Ebenso das Keyboard BIOS getauscht und schlussendlich den Dallas gemodded. Das Board wollte immer noch nicht booten.

Das nächste Geschütz wurde aufgefahren: ich habe mit dem Oszilloskop alle Adress- und Datenleitungen am BIOS abgelauscht, um festzustellen, dass da auf D0...D7 und A0...A15 ordentlich Betrieb ist. A16 dagegen floatete fröhlich vor sich hin. Das war mir so verdächtig, da das BIOS definitv Inhalt in seinem oberen Speicherbereich hat, dass ich der Sache auf den Grund bin. Ich habe dann die A16 Leitung durchgeklingelt, jedoch kein Ziel am UMC Chipsatz gefunden. Zwischen A16 am BIOS und den unteren 2 ISA Slots war jedoch Verbindung (das BIOS hängt am ISA Bus). Ich habe dann also zwischen den ISA Slots die A16 Leitung untersucht und festgestellt, dass zwischen den beiden oberen Slots was Faul war...

Und mein Tagesziel war erfüllt  :keen: Man sieht, wie schön die A16 Leitung eingekerbt und unterbrochen ist (da wo "RP4" steht):

Keine Ahnung, wie man das schafft... aber man hat es offensichtlich geschafft. Der schnellste Fix war einfach eine Brücke auf der Rückseite:

Und Tada, das Board bootet und scheint auf den ersten Test funktional. Zum Glück habe ich jetzt 2 Wochen Urlaubt  :-)

Danke fürs Lesen!

VG
Franz

486er PCI Mainboard Vergleich

Ich habe jetzt meine kleine Sammlung an Spät-486er Boards mal evaluiert. Dafür habe ich folgende Auswahl getroffen, dass von jedem verfügbarem Chipsatz eins dabei ist:

  • VIA Pluto (VIP-IO2)
  • SiS 496/497 (4SAW2)
  • UMC U8881F/8886AF (UM8810P-AIO)
  • UMC U8881F/8886F (HOT-433)

Die Boards habe ich wenn Möglich auf Award BIOS geflashed. Beim HOT-433 machte dies keinen Unterscheid in der Performance.

Das Setup ist für alle Konfigurationen gleich (FPM und S3 Trio für den kleinsten gemeinsamen Nenner):

  • CPU: AMD 5x86-P75 @133MHz (4x33MHz)
  • GPU: S3 Trio 64
  • RAM: 32MB FPM 
  • HDD: 8GB CF
  • LAN: NE2000
  • SOUND: Miro PCM10
  • OS: MS-DOS 6.22

Durchgeführt habe ich die beiden Standard Benchmarks PCPlayer und Speedsys. Zuvor habe ich versucht, die BIOS Einstellungen auf die schnellstmöglichen, stabilen zu bringen. Wenn dies nicht nötig war (z.B. bietet das Soyo 4saw2 fast keine Optionen im Originalbios!), habe ich TweakBIOS zu Rate gezogen. Für den VIA Pluto im FIC war auch dies nicht möglich, da musste ich mich mit den wenigen verügbaren Einstellungen zufrieden geben.

FIC VIP-IO2


PCPlayer Benchmark: 6.9fps

ECS UM8810P-AIO


PCPlayer Benchmark: 8.8fps

Shuttle HOT-433


PCPlayer Benchmark: 8.8fps

Soyo 4SAW2


PCPlayer Benchmark: 8.8fps

Fazit

Für mich war interessant, dass wenn man den UMC 881x und den SiS496/497 entsprechend tweaked, es quasi keinen Geschwindigkeitsunterschied gibt. Auch zwischen den UMC Revisions gibt es keine Unterschiede. Letztere 3 Mainboards sind faktisch gleich schnell.

Wenn jemand noch Optimierungstipps hat, dann freue ich mich sehr.

VG
Franz

AT Mainboards mit ausgelaufenem NiCd Akku restaurieren

Viele alte AT Mainboards verwenden für den Erhalt des CMOS Setups einen NiCd Akku, welcher nach 10...15 Jahren seine Dichtigkeit verliert. Die Folge ist, dass Lauge aus dem Akku ausläuft, den Lötstopplack und schlussendlich die Leiterbahnen, Durchkontaktierungen und IC Beinchen angreift.

Ich nehm das mal zum Anlass, eine kleine Fotostrecke reinzustellen, wie man solche Mainboards restauriert. (Betrifft auch aktuelle Diskussion hier: http://www.dosforum.de/viewtopic.php?f=16&t=7871)

Objekt ist ein ExpertBoard mit leichtem Akkuschaden. Hatte ich schonmal notdürftig sauber gemacht. Heute für die Fotostrecke dann nochmal mit Säuberung unter dem KB Controller Sockel.

Wie man sieht, ist die übliche Region um den Akku zerfressen. Es sind zum Glück bis auf die Keyboard Leitungen keine wichtigen Signale vorhanden, so dass die Reparatur sich auf das kosmetische beschränkt.
Methode:

  • Glasfaserpinsel: grobflächig die Leiterbahnen "polieren" und Dreck entfernen
  • offenes Kupfer neu verzinnen
  • ggf. defekte Leiterbahnen neu ziehen. Dazu eignen sich einzelne Drähtchen aus Kupferlitze

Auf dem ersten Bild ist der Sockel vom Keyboard Controller bereits entfernt. Die Lötaugen sind ebenfalls frei poliert, so dass kein grüner Siff mehr sichtbar ist:

Jetzt gehts ans Wiedereinlöten des Sockels. Hinten im Bild sind die neu verzinnten Bahnen der Unterseite zu sehen:

Und nochmal. Nach dem Verzinnen geh ich nochmal mit dem Glasfaserpinsel über die Bahnen, um sie anzurauhen.

Wie man sieht, sieht das alles schei**e aus. Die Optik des Boards leidet unter der Behandlung sehr. Wenn auch die Funktion im jetzigen Zustand wieder 100%ig ist.

Ich wasche die Platine als nächstes mit Isopropanol ab. Zum Entfernen von Flussmittelresten muss das Iso etwas einweichen. Aber wichtig: Zahnbürste nicht vergessen  :keen:

Nochmal von oben:

Das Board ist nun sauber, sieht aber immer noch schei**e aus:

...ich behelfe mir mit Plastikspray - quasi das Haarspray für Männer:  :keen:

Ein feiner Sprühneben auf dem Board sorgt für eine klasse matte Optik. Wenn man Glanz will, dann einfach direkt sprühen:

Und das schönste ist: Frauchen toleriert mein Treibern in der Küche kommentarlos.

Hier noch ein Beispiel, wo die Lauge unter die SIMM Sockel und Schaltkreise gelaufen ist. Dazu wurde alles in der Umgebung entfernt und die Leiterbahnen poliert.


Robotron EC1834 - PCs aus dem Ostblock

Die Vorstellung eines IBM PC XT im www.dosforum.de hat mich motiviert, einen Ausblick in eine (den meisten unbekannte) existente DOS Ecke zu machen.

Ich besitze eine größere Sammlung an Computern, welche in der DDR hergestellt wurden. Daruntern waren auch IBM PC Kompatible Rechner, welche nahezu vollständig mit "Ostblock"-Halbleitern hergestellt wurden (DDR; Sowjetunion, Polen, CSSR, ...)

Meinen mit viel Aufwand instandgesetzten Liebling, einen EC1834, möchte ich euch hier vorstellen. Gebaut wurde er in meiner Uni-Stadt Chemnitz, damals Karl-Marx-Stadt.

Kurz die Daten (http://de.wikipedia.org/wiki/EC_1834):

  • IBM PC XT Kompatibel
  • Sowjetischer 8086 (kein 8088 !)
  • Intel 8087
  • 640 kB DRAM
  • MFM Controller mit 20MB Robotron Festplatte aus dem thüringischen Zella Mehlis
  • 2x 5.25" Floppy
  • CGA Kompatible Grafik
  • RS232, Centronics usw.
  • 1x ISA Slot, die übrigen Slots mit Stifleisten Steckverbinder, elektrisch 16bit ISA


Bild vom Rechner. Der EC1834 ist der obenstehende. Unten drunter steht ein Robotron A7150 (ebenfalls 8086 Technik). Standard ist ein grüner Monochrommonitor.

Auf dem Rechner läuft zur Zeit MS-DOS 6.2. Um die DOS-Fähigkeit zu demonstrieren, starten wir Commander Keen:


Der EC1834 funktioniert auch am TFT Monitor, wenn man erwas Adapter bastelt. Die Grafik ist wie gesagt CGA kompatibel.


Blick auf das offene Gehäuse. Den Deckel klappt man zur Seite weg.

Blick auf den voll ausgebauten Rechner:


Das Herz des Systems. Ein sowjetischer 8086. Westliche Schaltkreise wurden im kalten Krieg aufwendig analysiert (Maskenschliff, Mikroskopie, ...), reverse-engineered und dann in eigenen Fabs gefertigt. Meine gesammelten KR1810WM86 stammen u.a. aus Kiev. Weiter hinten sitzt ein 8087 von Intel, den ich dazu gesteckt habe. Sowjetische Pendants habe ich noch nicht gesehen.

Für den Systemcheck und einen Benchmark verwende ich gern CheckIt. Ein PC-XT wird durch den 8086 (statt 8088) deutlich geschalgen:


Ein NEC V30 fühlt sich im DDR Rechner ebenfalls pudelwohl:..


...und gewinnt gegen den 8086 im Benchmark:

Wenn ich Zugriff habe, dann organisier ich mir schon jetzt alle Ersatzschaltkreise, um den Rechner möglichst lange in Betrieb zu halten :-)