8255A vraag ivm het programmable deel

Veel 18F/24F/32F pic's hebben een 'PMP' mode (parallel master port), dan is interfacen van een 8 bits peripheral helemaal simpel...

Nogmaals: het probleem KAN ook prima elders op de bus zitten.
Zoals reeds eerder genoemd: ALS er ergens anders een rotte address decoder zit dan zou het kunnen dat er soms een bus conflict is - waardoor het lijkt dat de ellende in de 8255 of achterliggende logica zit. Nogmaals, het is een suggestie niet gestoeld op enige waarneming tot op heden (maar wel op enige ervaring in ontwikkeling met 'bus').

Wat me in het geheel niet aan staat, is dat de boel gelijk van de leg is als je er een probe op prikt. 'Ohms' zal die probe geen drol voorstellen (immers, in die tijd was 4k7 als pull-up heel normaal; ik mag hopen dat die probe Ohms gezien daar erg ruim boven zit). Blijft capacitatief (of inductief) over, waarbij mijn inschatting is dat capacitatief veruit dominant is tov. inductief. Echter, bij een fatsoenlijke probe zit dat in de pF range. Dat red je ook met een board waar de betreffende trace aan de andere kant een ground plane heeft. En daar hoort het ook niet van van de leg te raken (tenzij het HEEL kritisch is qua timing en men dus heeft geknoeid). Kortom: dat is ook een red flag.

Als ik die processor toch weer een beetje met een 8051 en 8088 mag vergelijken (daar heb ik wel mee gespeeld, met een 80188 niet), dan kan die bus best wat hebben voordat er dingen omvallen.

Het zomaar wisselen van ICs... Tsja... soms moet je het pragmatisch zien. Als je maar terug kunt. Het is fijn om te weten wat de ellende veroorzaakt heeft, maar als je met wat wisselen de boel werkend hebt en dit speelt geen rol bij de nauwkeurigheid...

Dan nog een andere: kijk eens of je kunt zien of de clocksnelheid van het geheel nog correct is. Ik weet niet wat dat genereert en of je daar een scope in kunt prikken zonder dat het gelijk aan de rel gaat. Als om de een of andere reden de boel 'te snel' geworden is, dan zou dat ook een hoop verklaren. Het is een slag in de lucht uiteraard. Maar de controle is snel.
Lomp: halveer de clock en kijk of het is opgelost (als in: als het alleen maar de besturing van een decade bank is, dan zal 'timing' denk ik niks doen met 'nauwkeurigheid' of 'werking'. Wel met wat er allemaal op de bus gebeurt...

[offtopic]Ooit eens aan een alarmpaneel gewerkt. Dat ding bewaakte wat inputs en had bit-banged serieel uit. De ontvangende kant verslikte zich soms in de output: het miste een interrupt en dus een character (DOS based, 8250 UART). Dat paneel was ontwikkeld door een afdeling die niet meer bestond. En ja, er was nog wel wat documentatie, maar niemand wist waar. Er zaten er wel een 10k van in het veld en 'de nieuwe software' - uiteraard ingekocht en dus niet simpel aan te passen - werkte er onbetrouwbaar mee.
Lang verhaal kort: door de clock van de CPU van dat ding te halveren, werd ook de bitrate gehalveerd. De ontvangende kant was instelbaar en had nu 2x zo lang om de boel te processen. En het mooie: er liep een eigen oscillator waar een deler achter zat. Kwestie van op het board een draadbrug verleggen.
Netjes? Mwah. Effectief: ja hoor. Het heeft nog zeker 15 jaar gedraaid.

Zeker als er iets qua timing op het randje zit kan het helpen er een nieuw IC in te stoppen: Met een beetje geluk is die in een recenter proces gebakken dat qua maximum snelheid een stuk hoger ligt. (Ook als dat niet in de datasheet vermeld staat)

Dat zou hier concreet betekenen dat de nieuwe 8255 soepelere setup- en holdtijden heeft dan in de datasheet zijn, en dus wellicht net wel werkt. Moet je wel een echt nieuwe nemen (Farnell heeft hem!), geen andere tweedehands.

Maar ik begrijp dat testen of het probleem optreed een langdurig proces is, dus ik snap dat je niet graag gaat gokken

Toch zijn we op het "gokken" punt aangekomen: "random chips vervangen".

Offtopic: Voordat ik Elektro ging studeren werd mij gevraagd of ik "deze" WYSE50 terminal kon repareren. Random chips verwisselen tussen een werkende en niet werkende -> het moest chipje X zijn. Dus: Nieuwe besteld er in gesoldeerd en... niets! Geen success! :-(

Het was een 93C46 chipje (of iets wat er op lijkt). Een eeprom. Kennelijk kon de firmware een "verse" niet correct initializeren.

Dat is precies het "programmeerbaar" waar Fred in dit topic naar vroeg!

ISA bus, en wat er op lijkt, moet NIET van de leg raken van een probe. Daar ben ik het mee eens. Ik heb 2x een ISA insteekkaart gemaakt op basis van wirewrap technologie. Gewoon zelf met wat decoder chipjes de adresdecodering doen en op een flank van het gedecodeerde adres-signaal een schuifregister laten schuiven.

Als het kritisch is, dan is er "iets" raars aan de hand. ook waren frequenties niet zo extreem als nu. Het max van de parallelle ISA bus lag ergens rond 1Mb/sec. Echt super-traag. Het datasheet van de toshiba variant... ik zie timing specs van 650ns, dus harder dan 1MHz cycletijd zal je wel niet moeten willen.

[Bericht gewijzigd door rew op (12%)]

Op vrijdag 9 januari 2026 12:20:51 schreef rew:
[...]
De 80188 is de opvolger van de 8088 / 8086. Die bood nauwelijks voordelen over de 8088/8086, dat haast niemand hem in een PC-achtige heeft gemonteerd. Hij is wel veel in "embedded" toepassingen terecht gekomen. Ik heb nog harddisks waar hij als "controller" in zit. .

In mijn eerste PC, een Philips Yes:, zat een 80188. Die Yes: is overigens compleet geflopt in de markt omdat Philips lak had aan 'compatibiliteit'. Op zich was het een leuk ding dat met de PS/2 van IBM moest concurreren..... Geen ventilator, compact mainboard (80188 heeft peripherals aan boord), goed ogende kast met ruimte eronder waar je het keyboard in kon verstoppen en toen al 3,5" floppies.
Je hebt gelijk, ik heb ook wat meetapparaten met een 80188, maar in PC's vond je hem weinig.

De 80c188 zat vaak in "high speed" modems, (jaren 90).Heb er nog een paar ergens liggen te leggen :)

Als het board zonder al de optische aansluitingen wil werken, en ik er achter kom hoe dat koppelboard vast zit, dan kan ik hem misschien buiten de kast laten draaien want dan zijn de bandkabels waarschijnlijk net lang genoeg. Dan kan ik op de bus meten of daar rare artefacten rond zweven. Als ik het goed heb heeft mijn scope ook een runt-trigger mogelijkheid.

Er zit niet zoveel op het board, ik kan de bus IC's in voetjes zetten en dan verschillende IC's proberen. Ik heb behoorlijk wat NOS 74 logica liggen. Dan kan ik steeds 1 IC uitwisselen en weer terug zetten als het niet helpt (en de boel anders steeds even helpen door op de bus te proben)

Ik bedenk me nu, het heeft zo'n 3 weken iedere dag een paar keer aan uitzetten gekost voor hij de fout inging (met de kast dicht) maar nu ik hem open heb liggen dacht ik geluk te hebben omdat hij nu veel vaker de fout in gaat, maar als ik jullie reacties lees op het proben dan zou dat best wel eens geen toeval kunnen zijn. (de 10x probe is een goede 200MHz probe op een 300MHz R&S scope dus de belasting is laag) Dan zou het best, zoals Eric noemt, een "ontwerp probleem" kunnen zijn.

De processor heeft een 14,7xx MHz Xtal (zit soldeer over de xx)

Het PCB

De CP82C55A van Harris is een 8MHz versie volgens de datasheet, dus dat klopt.
De N80C188XL12 CPU lijkt me een 12MHz exemplaar?

Maar er zit een 14,7MHz Xtal in. Is dat niet te snel voor die processor (en de rest)? Ik heb een berg 12MHz Xtals liggen, ik zou dat kunnen proberen. Als het een tim8ing probleem is zou dat het kunnen oplossen? Het is zo geprobeerd.

[Bericht gewijzigd door fred101 op (46%)]

Op vrijdag 9 januari 2026 20:26:19 schreef fred101:
Maar er zit een 14,7MHz Xtal in. Is dat niet te snel voor die processor (en de rest)? Ik heb een berg 12MHz Xtals liggen, ik zou dat kunnen proberen. Als het een tim8ing probleem is zou dat het kunnen oplossen? Het is zo geprobeerd.

Zit het kristal rechtstreeks aan de processor of word het nog ergens gedeeld ?
//Edit, denk dat hier het antwoord is :

7. nogiets MHz is volgens mij een ideale UART frequentie

Het Xtal zit direct aan de processor.

Die 16552 zal wel iets van een UART zijn (een 16550 is dat, in tegenstelling tot een 8250 met wat 'hardware' buffering; die 552 zal dan wel een dual versie ofzo zijn). Je zou verwachten dat die een eigen piepsteen heeft. Immers, de CPU dropt een character het output register en dat ding gaat dat zelfstandig naar buiten staan shiften en geeft de CPU een interrupt (als dat enabled is) als-ie klaar is. Of in dit geval: ruimte in de buffer.
Zou men hebben bezuinigd en UART en CPU op dezelfde piepsteen laten lopen?
ALS dat zo is: Die UART zit er niet voor niks. Als je kunt controleren of de bitrate klopt (hang er iets 'terminal' aan en kijk of de output leesbaar is ofzo), dan weet je ook dat de clock klopt.

Die RN100 en RN101, strak tegen de CPU voet aan, lijken de eerder door mij genoemde pull-up weerstanden te zijn. Zit dat allemaal vast? Ik kan me er wel wat bij voorstellen als dat ergens niet lekker zit dat en scope probe genoeg is om de boel van de leg te krijgen.
[edit]Nu met een stukje schema erbij... Die netwerkjes lijken vooral gebruikt te worden om de interrupts op gedefinieerde niveau's te krijgen. Als dat mis gaat, dan zou je andere ellende verwachten. Dus in deze context lijken ze minder relevant te zijn[/edit]

Rew heeft het over een ISA kaart... Nou ik dat lees... Ik heb ook ooit nog eens zoiets gemaakt. Ik had wat I/O nodig. Dus wat latches en een eigen kaartje maken - je kon in die tijd gaatjes print met een edge connector kopen. Ik geloof nooit dat draadjes-over-print-naar-address-decoder een lagere capaciteit heeft dan een scope probe.

Overigens zie ik heel weinig wat voor address decoding bruikbaar kan zijn. Het zou natuurlijk kunnen dan men heel lomp een paar 'hoge' address lijnen als deel van nCS gebruikt heeft. Immers... dat board heeft nauwelijks I/O. Dus het is dan ook niet erg als je bijvoorbeeld 512 adressen gebruikt wat ook met 4 had gekund - scheelt decoderen.
[edit]Met die stukjes schema erbij... Met heeft een I/O pin van de controller gebruikt voor nCS. Vergeet het hele verhaal over address decoderen. In deze opzet niet van toepassing.[/edit]

Op vrijdag 9 januari 2026 20:52:22 schreef fred101:
Het Xtal zit direct aan de processor.

Processor heeft intern een 2-deler

Op vrijdag 9 januari 2026 20:26:19 schreef fred101:
Maar er zit een 14,7MHz Xtal in. Is dat niet te snel voor die processor (en de rest)? Ik heb een berg 12MHz Xtals liggen, ik zou dat kunnen proberen. Als het een tim8ing probleem is zou dat het kunnen oplossen? Het is zo geprobeerd.

De kans dat de seriele stuff blijft werken is natuurlijk klein. Of weet je waar de twee seriele poorten voor gebruikt worden? Edit: Oh, Dat zei EricP ook al. Maar ik heb ter verificatie het datasheet er bijgepakt en we hadden alletwee goed gegokt.

Dat kristal zou dan 14745600Hz moeten zijn, dat is 9600 * 16 * 96.

Je stelt stopt dan (dacht ik) 95 in het divisor register, en je seriele poort draait exact 9600 baud. Ik verwacht echt niet dat in zo'n systeem uit 1994 een tweede kristal zit. Die chip draait gewoon op de "clock out" van de CPU.

@ericP, ik verwacht dat het programmeerbare chipje wat met adres decodering doet.
P.S. Ik zie 2* 64K PROM, 2*32k RAM (denk ik... 2 verschillende chips, 1 in een voetje! dus achteraf uitgebreid.)

[Bericht gewijzigd door rew op (26%)]

Hier de rest van de schemas van dit board. De processor kaart heeft een optisch interface, een GPIB/ IEEE interface, RS232 interface, praat met keyboard en display, en heeft 2 bananen voor een kaart recorder en twee voor een sync uitgang.

Eric, ik zal naar die weerstanden kijken, desnoods desoldeer ik ze even om te meten. Ik heb alle solderingen op het board gechecked maar er kan er misschien een open zijn ofzo. (denk het niet maar je weet nooit)
De LA van mijn scoop kan UART decoderen maar ik ga er van uit dat dat werkt want het apparaat werkt meestal gewoon en de fout is een soort fantoombitje/byte die ervoor zorgt dat er een menu wordt "aangeklikt"

Op vrijdag 9 januari 2026 21:03:42 schreef EricP:
Die 16552 zal wel iets van een UART zijn (een 16550 is dat, in tegenstelling tot een 8250 met wat 'hardware' buffering; die 552 zal dan wel een dual versie ofzo zijn). Je zou verwachten dat die een eigen piepsteen heeft.

Heeft hij niet, clock komt via CLKOUT van de processor , pen 66
//Edit. Rew was me voor

Met de schema's erbij wordt het inderdaad makkelijker :)
Maar goed...
Als die UART dus op de juiste snelheid loopt, dan is dat ook gelijk getackled. Dus address decoding is uitgesloten, als de clock speed ook klopt dan is timing in dat opzicht ook uitgesloten.
Dan kom je toch terug op het oorspronkelijke verhaal van Fred: die 8255 en z'n omliggende logica.

Blijft dat ik het raar vind dat de boel zo van de leg raakt van een scope probe.

Alvast bedankt voor alle moeite. Wordt gewaardeerd.
Ik zal morgen kijken of ik dat board buiten de kast kan opstarten en dan de klok en clock-out pin 66 (?) meten.
Daarnaast die weerstanden testen. Dan zet ik de 82C55 in een voet en de HC245 en HC32 ook zodat ik kan kijken of de boel dan nog steeds zo heftig reageert met andere IC's. Lost dat het op dan kunnen de voetjes er weer uit. Dan kan ik ook de hele keyboard matrix proben.

Als ik het goed begrijp: De schakelaar signalen gaan naar de 8255. De 8052 stuurt die naar de processor. De processor neemt actie en stuurt een data update, via een HC245 naar de display waarbij hij een stukje menu text inverteert ten teken dat de knop is ingedrukt. De HC43 verzorgt wat controle lijnen van de display.
Het vreemde is dus dat alleen de data horende bij knop 2 spontaan gegenereerd wordt. De processor denkt dus dat knop 2 wordt ingedrukt terwijl dat niet gebeurd. Op die lijnen aan de input kant van de 8255 gebeurd niets. De uitgangkant is hypergevoelig voor proben.
Begrijp ik de werking zo correct?

[Bericht gewijzigd door fred101 op (46%)]

Gezien het schema, zijn die weerstandjes al wat minder waarschijnlijk geworden... Voor de CPU speed: het moet 'ongeveer' kloppen - de orde grootte zeg maar. Niet een factor 5 hoger :) Voor de UART moet het (redelijk) exact kloppen. Maar zeg 10% te hoog zou die 8255 geen pijn mogen doen.

Nog ff een andere over die gevoeligheid... Je schreef ooit ergens dat je je werktafel ofzo naar de nul van de 230V voeding had hangen. Je creëert met de 'massa clip' van je probe toch geen groundloop ofzo he? (ik weet het... je zult er wel over nagedacht hebben, maar ik trap de open deur toch maar even in).

Ik heb ooit het ongenoegen gehad om een fout op moeten te lossen in een nieuwe batch van een van onze oudere (6800-based) systemen: met de nieuw ingekochte RAM werkte het op zijn best slecht, en vaak helemaal niet.
Zelfde fabrikant, zelfde type, zelfde behuizing, alleen 35ns sneller.
Wegens tijdgebrek werd besloten dit niet tot op de bodem uit te zoeken, maar om via een broker de tragere variant in te kopen en het gewraakte model end-of-life te verklaren...

Een ander systeem(pje) weigerde soms om op te starten, en viel soms spontaan uit. Dat heb ik toen tot op de bodem uitgezocht: het bleken twee ontwerpfouten te zijn, een in hardware (timing) en een in software (incorrecte initialisatie van een RF-chip)...
In de hardware was er een vertraging van 80ns nodig van de chip-enable van een van de periferie chips, vier achter elkaar geschakelde CMOS inverters waren voldoende om het probleem op te lossen.

De moraal van dit verhaal: ALTIJD de timing checken van alle gebruikte chips, in het worst case scenario.

Een ander spookverhaal was de (vaak) falende SPI communicatie tussen twee Microchip MCUs. Buslengte nog geen 3cm, geen andere participanten; firmware voor beide processors gemaakt door dezelfde persoon.
En het gekke: als ik een scoop (of LA) aansloot werkte het perfect...
Nooit gevonden waar het nou precies aan lag, maar met drie 10p condensatortjes op de bus was het probleem over.

Nog wat verder mijmerend: die PPI heeft geen interrupt, dus daar kan het probleem niet vandaan komen.
Een -voor mij althans- grote verdachte is de IEEE interface, als die om de een of andere reden de CPU wijsmaakt dat het menu remote wordt geactiveerd is het volkomen logisch dat het keyboard niet meer reageert...

[edit]
Wat ik ook nergens kan vinden in de schema's is een weerstandsnetwerk wat de databus op een gedefinieerd nivo houdt (meestal 0xFF) voor het geval dat er een timingprobleempje is...

(opa vertelt) :P
In mijn tijd was het gebruikelijk om een set pullups te hebben van 10k tot 47k die de datalijnen 'hoog' brachten.

[Bericht gewijzigd door fatbeard op (35%)]

Op vrijdag 9 januari 2026 22:59:03 schreef fatbeard:
Nog wat verder mijmerend: die PPI heeft geen interrupt, dus daar kan het probleem niet vandaan komen.

Wel een soort van, zie pag 6.

8255A.PDF

Op vrijdag 9 januari 2026 22:59:03 schreef fatbeard:
Nog wat verder mijmerend: die PPI heeft geen interrupt, dus daar kan het probleem niet vandaan komen.
Een -voor mij althans- grote verdachte is de IEEE interface, als die om de een of andere reden de CPU wijsmaakt dat het menu remote wordt geactiveerd is het volkomen logisch dat het keyboard niet meer reageert...

Ik denk niet dat dat IEEE interface wordt gebruikt want als je op het schema kijkt moet het adres met een rij schakelaartjes worden gezet naar gnd. Maar ipv iets als dipschakelaars zit daar een leeg IC voetje. Dus al die schakelaars staan als het ware open. Zou dat een probleem kunnen zijn (er horen dipswitches in dat voetje die ze er ooit vergeten zijn in/terug te zetten?)

In mijn tijd was het gebruikelijk om een set pullups te hebben van 10k tot 47k die de datalijnen 'hoog'

Zou ik als test pull up weerstanden aan de bus kunnen hangen?

Eric: de gnd van dat board hangt nergens aan de kast. Ook de gnd van de andere pcb's hangt niet aan het chassis. De kalibrator wordt gevoed door een AC labvoeding. De nul zit aan PE , de werkbank is van hout. De antistatische mat hangt via 1M aan de PE (en dus nul) Maar ik kan die nul/PE koppeling zo weghalen als test.

Op vrijdag 9 januari 2026 23:15:49 schreef bprosman:
[...]
Wel een soort van, zie pag 6.
[bijlage]

OK, maar die wordt hier niet gebruikt: de drie signalen van port C die niet naar het keyboard gaan gaan naar het display als blanking en de fibre-optic interface als enable signalen...

@fred: een 47k netwerkje op de databus naar Vcc als test kan weinig kwaad, als het makkelijker is kun je ook naar GND gaan.
Het ontbrekende DIPswitchje betekent alleen dat het IEEE interface permanent is ingesteld op adres 255 (of nul, als de firmware het inverteert). Er zitten pull-ups aan die DIPswitch (volgens schema).
De vraag of het er ooit ingezeten heeft en nu nog op een werkbank van jouw klant ligt kan alleen die klant beantwoorden...

Op vrijdag 9 januari 2026 20:26:19 schreef fred101:
Maar er zit een 14,7MHz Xtal in. Is dat niet te snel voor die processor (en de rest)? Ik heb een berg 12MHz Xtals liggen, ik zou dat kunnen proberen. Als het een tim8ing probleem is zou dat het kunnen oplossen? Het is zo geprobeerd.

Ik denk dan: "If it worked why change it¨? Het kristal zal niet de oorzaak zijn van de storing.