Retro PC - 386DX/486DLC

PGA socket mod na 386 MB KMC-A419-8 ver. 1.0

      30.5.2022 Některé základní desky 386 měly na sobě připájený CPU v provedení SMD. Tato deska se zrovna vyráběla ve 2 variantách, buď s připájeným CPU nebo s PGA paticí. Já mam variantu s připájeným CPU AMD Am386DX-40 a tak mě napadlo, že bych si mohl na desku dopájet PGA patici, abych v ní mohl testovat i jiné CPU. V případě CPU AMD revize C a novější se to navíc zjednodušuje tím, že tyto CPU mají pin FLT# (54), který ho kompletně odpojí od sběrnice a není ho tak třeba vypajovat z desky. Abych mohl dle potřeby přepínat mezi onboard CPU a CPU v patici, přivedl jsem nezapojený pin FLT# na jumper, jehož druhý pin jsem zapájel do GND prokovu footprintu neosazené paměti U21. Jelikož má pin FLT# interní pull-up cca 100 kΩ na VCC (ampérmetrem jsem naměřil proud 46 µA do země) a drátový spoj je poměrně krátký, tak jsem žádný externí pull-up nepřidával. Pokud bych chtěl onboard CPU vyřadit trvale, stačila by malá kapka cínu na propojení pinů FLT# (54) a GND (55) hned vedle.

socket mod	TX486DLC-40	TX486DLC-40	TX486DLC-40	AMI BIOS setup

      Dále jsem na desce rozšířil velikost cache na 256 kB pomocí dalších čtyř 32kB DIL SRAM čipů a vyměnil jsem 8kB tag SRAM za 32kB tag SRAM. Metodou pokus-omyl jsem našel správnou kombinaci jumperů: JP5 = on, on, on; JP5 = 1-2 (původní nastavení pro 128 kB cache bylo: JP5 = on, on, off; JP6 = 2-3). UPDATE: našel jsem popis jumperů k desce KMC-40A, která vypadá velmi podobně a má i stejně rozmístěné jumpery.
      Do desky jsem zkusil osadit CPU TX486DLC-40, když už ho BIOS podporuje a otestoval propustnost paměťového subsystému pomocí DOSového programu CCT386. Jak je vidět, rychlostní skoky nastávají dle očekávání na hranici bloků 256 kB (L2) a 1 kB (L1). Zajímavé je, že 386DX dosahuje při využití cache více bodů než 486DLC s kaskádou L1 a L2 cachí (zřejmě nějaký overhead). Pro ladění nastavení L1 cache v CPU poslouží program cyrix.exe pro DOS, zde je výchozí nastavení dle BIOSu. Nastavení wait states u RAM nelze v SETUPu měnit, pouze lze ladit nastavení refreshe.
      V programu Norton SysInfo CPU Benchmark došlo oproti 386DX k nárůstu z 43,0 na 65,4 bodů (o 52%). V programu Norton Diagnostic jsem v System Board Testu zjistil, že na 486DLC neprojde CPU Arithmetic Test, netuším z jakého důvodu, ale jiným programům to zřejmě nevadí. Nakonec jsem ještě do desky nastrkal 8 MB RAM a FPU IIT 3C87-40, abych mohl spustit Quake. Na hraní to ale opravdu není, ve VGA rozlišení 320 x 200 jsem dosáhl v testu timerefresh 1,067 FPS na 386DX a 1,268 FPS na 486DLC (zrychlení o 19%). Test jsem provedl ještě jednou s lepší VGA kartou Diamond Stealth Pro S3 Vision 928 (místo low-end Relatek RTG3105), ale na výsledek to nemělo podstatný vliv: 1,295 FPS. Zde je také screenshot a report z programu SpeedSys s onboard CPU 386DX. Na TX486DLC se mi SpeedSys zaseknul při detekci CPU ("Processor: Cyrix"). Pak jsem se dozvěděl, že důvod je patrně v určitých odlišnostech specifických registrů CPU TI TX486DLC a Cyrix Cx486DLC, které SpeedSys čte přes I/O instrukce a na některých deskách/chipsetech může toto extenzivní oťukávání způsobit zátuh. Později jsem SpeedSys upravil tak, aby fungoval na 486DLC/SLC, výsledky jsou v tabulce níže.
      UPDATE1: Od Dušana jsem dostal matematický koprocesor ULSI Math*Co DX US83C87 40 MHz, s kterým se Quake výrazně zrychlil na 1,690 FPS, po přetaktování ISA na 20 MHz ještě o trochu více na 1,725 FPS. Pozor na nastavení "ISA CLK Speed" v SETUPu! Celou dobu jsem se domníval, že dělička dělí frekvenci CPU 40 MHz, ale ona dělí přímo výstup krystalového oscilátoru 80 MHz. Lze nastavit hodnoty CLK2/ 2 (40 MHz), 3 (26,7 MHz), 4 (20 MHz), 5 (16 MHz), 6 (13,3 MHz), 8 (10 MHz), 10 (8 MHz) a asynchronních 7,15 MHz. Kupodivu mi většina dosud použitých ISA karet neprotestuje, narazil jsem až u CGA/MDA repliky Graphics Gremlin, kde je strop na 10 MHz.
      UPDATE2: Podařilo se mi najít 16k x 4-bit SRAM čip QS8888-20P a tak jsem pro něj na desku dopájel DIL22 patici na pozici U21. V BIOSu v menu "Advanced Chipset Setup" je pak možné nastavit položku "Write Buffer/Back Cache" na "Back". V benchmarku SysInfo a CheckIt se aktivace Write-Back cache nijak prokazatelně neprojevila, v CCT386 byl dokonce patrný pokles bodů přenosové rychlosti u velkých bloků ze 192 na 153 bodů, ale v Doomu (doom.exe -timedemo demo1, FPS = 35*gametics/realtics) jsem zaznamenal drobné zrychlení z 9,14 FPS na 9,46 FPS (+3,5%). S VGA S3 Vision 928 jsem se pak dostal ma 11,70 FPS.
      UPDATE3: Našel jsem optimalizovanou verzi engine Doom8088 pro starší CPU 8086/286/386 a grafiky MDA/CGA/EGA/VGA včetně textového režimu. Má však řadu omezení, jako že lze hrát pouze Doom 1 epizodu 1, nejsou texturované stropy a podlahy, běží v nižším rozlišení (max. 240 x 128), zvuk jde pouze přes PC speaker (bez hudby), lze spustit jen -timedemo demo3... S VGA verzí v nejvyšší kvalitě (d386myh.exe) jsem dosáhl 20,72 FPS, u EGA verze ve vyšší kvalitě (d8088eh.exe) jsem dosáhl 26,68 FPS u barevné VGA verze (d286cga.exe) jsem dosáhl 44,78 FPS a u textmodové MDA verze (d286mda.exe) jsem dosáhl 57,01 FPS. Další trochu optimalizovanou plnohodnotnou verzí pro 386 a VGA je DJDOOM zkompilovaný v DJGPP, který je jen o trochu rychlejší než originální Doom - dosáhl jsem s ním 12,41 FPS.
      UPDATE4: Našel jsem optimalizovanou verzi engine 486Quake pro starší CPU 386/486/586 a zkusil ji otestoval na nejlepší HW konfiguraci s 16 MB RAM a ISA na 20 MHz. Timerefresh zrychlil na 1,974 FPS a timedemo z 2,5 na 2,7 FPS.
      UPDATE5: Zjistil jsem, že po určité době běhu, jak se CPU zahřeje (topí dost, ale ruka na něm v pohodě udržet jde), tak začne být nestabilní. Tato nestabilita se typicky projevuje jen v náročnějších PMode aplikacích a Windows. Např. dpmild32.exe z HX DOS Extenderu mi házel zcela nelogicky chybu "Invalid module handle 0001" a crashnul s Exception 0D. Když jsem na vršek keramického pouzdra CPU posadil masivní hliníkový pasiv, tak během pár vteřin chyba zmizela a HX DOS Extender začal normálně fungovat. Blbé je, že u těchto základních desek se nepočítalo s žádným uchycením chladiče do desky či patice a přímo na CPU nic lepit nechci.

Am386DX-40, 128kB	TX486DLC-40, 256kB	Am386DX-40, 256kB	TX486DLC-40, 256kB	NDiag TX486DLC-40

Výroba a test replik 4MB 30-pinových SIMM

      24.9.2023 Na této desce jsem narazil na takové podivné chování paměťových modulů. Mám zde osazeno celkem 8 stejných 1MB SIMMů s čipy Goldstar GM71C4400AJ70 (1M x 4, 70 ns) s paritou. MemTest 2.11 i 4.00 mi hlásil asi 300 chyb v bitu 17 v rozsahu 1,3 - 1,8 MB. Nechal jsem v desce jen 4 SIMMy a jejich prohazováním jsem se snažil lokalizovat vadný modul. Našel jsem celkem 3 podezřelé SIMMy. Ty generovaly chyby, ale jen pokud byly vloženy do patice SIMM8 (u kraje desky). Zbylé SIMMy fungovaly bez chyb i v této patici. Vhodným proházením SIMMů se mi tak podařilo docílit, aby žádné chyby v MemTestu nebyly.
      Jak jsem dále zjistil, deska nemá ráda 4 MB SIMMy, sice s nimi nabootuje, ale MemTest hází spoustu chyb u všech SIMMů, které mám a pochybuju, že by byly všechny vadné. Podobně se chovají i v další 386 MB, ale v jiné desce pro 386SX, kde stačí osadit 2 moduly, tak chyby nehází. Patrně to nějak souvisí s nastavením refreshe, ale Hidden Refresh už mám zapnutý i nejkratší dobu refreshe na 15 µs. Některé DRAM čipy vyžadují refresh period 16 ms, jiné 32 ms a 4M čipy mají typicky 2048 nebo 4096 řádků, zatím co refresh čítač v chipsetu může podporovat jen 1024 řádků. Novější 4M paměťové čipy by měly mít svůj vnitřní čítač řádků, který by měl být použit, pokud BIOS (chipset) umožňuje nastavit volbu "CAS before RAS" místo starší metody "RAS-only refresh", ale tuto volbu v SETUPu nemám.

      9.10.2024 Zapájel jsem 4 plošňáky 4MB 30-pin SIMMů navržených Alexandrem Grozou, které jsem si už dříve nechal vyrobit v JLCPCB. Osadil jsem je EDO DRAM čipy GD417404BJ-6 vypájenými z jednoho 16MB 72-pin SIMMu. PCB ver. 1.2 rev. B umožňuje pomocí pájecí propojky osadit jak FPM tak EDO DRAM. Paritní čipy 4M x 1 nemůžu nikde sehnat a tak jsem je zatím vynechal. BIOS této desky umožňuje kontrolu parity vypnout, takže to zas tak nevadí. Osadil jsem tyto 4 moduly do desky a projel MemTestem - výsledek byl OK bez jediné chyby.

osazené SIMMy	AMI BIOS setup - WB

      9.11.2025 Letos jsem na radioburze v Holicích sehnal jeden 16MB 72-pinový SIMM, který jsem využil jako donor 8 FPM DRAM čipů TMS417400DJ-60 pro osazení dalších čtyř 4MB 30-pinových SIMM modulů od Alexe (bez parity). Původní i nově osazené SIMMy jsem projel MemTestem a prošly OK, ale když jsem do desky KMC-A419-8 osadil všech 8 SIMMů, tak už byl systém nestabilní. Házel náhodné chyby v MemTestu, padal Quake a tuhly Win95. A to i když jsem zkusil vypnout obě cache a nastavil nejpomalejší časování. Asi už je to při FSB na 40 MHz pro chipset příliš velká kapacitní zátěž (tak tím to nebude, když bez problémů funguje s 8 1MB SIMMy), tak jsem se musel spokojit jen s 16 MB RAM.

      28.1.2026 Byl jsem obdarován jedním neobvyklým oboustranným 32MB 72-pinovým SIMM, který měl 8 paritních bitů místo běžnějších 4. Využil jsem ho jako donor 16 FPM DRAM čipů 4M x 4 TMS417400ADJ-60 a 8 paritních FPM DRAM čipů 4M x 1 GM71C4100CJ-60 pro osazení dalších osmi 30-pinových SIMM modulů od Alexe. S dárcem jsem se pak rozdělil a poslal mu zpět 4 zapájené 30-pinové SIMMky.

odpájené DRAM čipy	osaz. SIMMy	Norton Diagnostic Test

      8.2.2026 Zkoumal jsem trochu podrobněji jak vypadá refresh na základní desce Soyo SY-015G. Osciloskopem jsem sledoval průběhy na 2 nejvyšších adresních linkách A10, A9 na patici SIMM (se 4MB moduly). Abych eliminoval různé pseudonáhodné průběhy způsobené čtením dat, zastavil jsem CPU instrukcemi CLI a HLT. Pokud byla v SETUPu vypnutá volba "Hidden Refresh", tak byly na A10 i A9 vidět pravidelné úzké pulsy s periodou 15,6 µs. Pokud jsem zapnul "Hidden Refresh", tak byla linka A10 trvale v log. 0 a pulsy byly vidět jen na A9. DRAM by asi měla používat interní refresh čítač. Nicméně systém byl nestabilní v obou případech. Níže uvádím tabulku alespoň několika základních desek a chipsetů, kde byly 4MB SIMM testovány.

MB	chipset	CPU	funkčnost	nastavení
KMC-A419-8	ALi M1419	Am386DX-40	OK, max. 4 moduly	Hidden Refresh enabled
Soyo SY-015G	Macronix MX83C305/306	Am386DX-40	silně nestabilní	nemá vliv
Abit AB-FU3	Chips F82C351/355/356	Am386DX-33	silně nestabilní	nemá vliv
NetMate AOV476KP66E	VLSI VL82C106/320/331	i386SX-20	OK, 2 moduly
Octek Panther II 386SX	OPTi 82C206/283	i386SX-20	OK, 4 moduly	0/0 R/W wait states
Shuttle HOT-307	OPTi 82C391/392	Am386DX-33	OK, 4 moduly	Hidden Refresh enabled
PC Chips M326	SARC RC4018A4	i386DX-33@40	nestabilní
Biostar MB-1333UCG	BIOTEQ 82C3491/493	Am386DX-40	OK, 4 moduly
AcerPower V5	SiS 85C310/320/330	386/486DX	OK, 4 moduly	CAS latency +1

XTIDE BIOS na 386 MB KMC-A419-8 ver. 1.0

      27.11.2022 Jelikož tato 386 podporuje disky pouze v režimu CHS do 504 MB, rozhodl jsem se vyzkoušet OpenSource projekt XTIDE Universal BIOS, který přidává podporu služeb INT 13h s LBA a umožňuje tak používat disky o kapacitě až 128 GB. Na XTIDE jsem narazil už někdy dříve, ale mylně jsem se domníval, že je to rozšiřující BIOS jen pro určitou 8-bitovou ISA kartu pro PC-XT, které ještě nemá podporu disků v systémovém BIOSu. Avšak XTIDE lze s výhodou používat i na 286, 386, 486, které už podporu disků mají, ale obvykle kapacitně dost limitovanou. Ke vzájemné kolizi by dojít nemělo, stačí v systémovém BIOSu zakázat všechny disky a XTIDE si je inizializuje později.
      Jednou z možností, jak XTIDE do systému přidat, je použít starou síťovou kartu s paticí na BootROM, která umožňuje zavádět OS ze sítě u bezdiskových stanic. Za tímto účelem jsem vytáhl ze šuplíku 10Mb ISA síťovku D-Link DE-250CT, která podporuje 8kB EPROMky, to je tak akorát. XTIDE lze stáhnout už jako předkompilované moduly v několika variantách. Stáhl jsem si soubor ide_386.bin pro platformu 386, který se vejde do 8 kB Varianta ide_386l.bin je větší a obsahuje navíc textové interaktivní menu. Stažený image je nutné napřed zkonfigurovat pomocí utility xtidecfg.com, která také image zarovná na správnou velikost a přepočítá kontrolní součet. Ve výchozím nastavení jsem nepotřeboval nic měnit. Pak jsem image vypálil do 8kB EPROMky MBM2764 programátorem LabProg-48LV, strčil do patice na síťovce a po zapnutí PC se nic nestalo. Dovtípil jsem se, že nejprve bude třeba BootROM nějak povolit. Jelikož karta nemá žádný jumper, ale má sériovou EEPROM, bylo jasné, že se to nastavuje konfigurační utilitou. Tu jsem našel zde, po rozbalení stačí spustit soubor setup250.exe a v menu "Set Up Configuration|Remote Boot" nastavit na Enabled, vybrat volnou adresu pro mapování BootROM (vybral jsem si CC00h) a uložit. Po té už XTIDE normálně naběhnul na konci POSTu.

D-Link DE-250CT	boot s XTIDE z HDD

      XTIDE jsem vyzkoušel s několika klasickými disky a SSD s různými výsledky. Jako první jsem testoval HDD Seagate Medalist ST310232A 10 GB. Během detekce se disk 2x rychle po sobě vypne a zapne (asi cold reset disku), což se mi úplně nelíbí. Také při intenzivním zápisu v některých programech se disk začal vypínat a zapínat. V benchmarku CheckIt dosáhl přenosové rychlosti 1,57 MB/s a průměrné přístupové doby 8,3 ms. Jako další jsem vyzkoušel o něco novější Seagate Barracudu 7200.7 ST340014A 40 GB, která se při detekci ani zápisech nevypíná (jen zarachotí hlavama a jinak funguje OK.
      Pak jsem zkusil SSD Transcend TS32GPSD330 32 GB MLC s pasivní redukcí z IDE 44 pinů na IDE 40 pinů, ale XTIDE ho nedetekoval. Ani systémový BIOS ho neuměl použít s ručním nastavením na omezenu velikost 504 MB. Tento SSD mi funguje v desce Abit BX133-Raid na onboard řadiči v soutbridge intel PIIX4, ale nedetekuje se v mém retro PC s Pentiem Pro se soutbridgem intel PIIX3. Netuším proč, podle manuálu by měl SSD podporovat LBA i CHS režim a přenosové režimy PIO 0 - 4. Další SSD Samsung MZMPC032HBCD-000D1 32 GB MLC mSATA v redukci mSATA - IDE 44 pinů z AliExpressu dopadl ještě hůře - zasekl PC během POSTu tak, že se nešlo dostat ani do SETUPu. A to docela zvláštním způsobem, všimněte si vynechaných písmenek, některá zas mají porušený font. Docela by mě zajímalo, jak je možné obraz takto rozbít, když znakový generátor na grafické kartě funguje celkem autonomně (fonty jsou uloženy v EPROMce VGA BIOSu). Zkusil jsem vytáhnout síťovku s XTIDE, ale nemělo to žádný vliv. Jinak tento SSD funguje správně jak v Abit BX133-Raid, tak v Pentiu Pro. Nakonec jsem ještě vyzkoušel Compact Flash kartu Transcend 16G B Ultra 133x v mé redukci CF-IDE a ta fungovala správně. V benchmarku CheckIt dosáhla přenosové rychlosti 1,85 MB/s a průměrné přístupové doby 0,3 ms.

zásek v POSTu s SSD	IDE řadič ISA M5105

      2.12.2022 Na VOGONS fóru mě uživatel rasz_pl upozornil na to, že můj IDE řadič má bufferovanou pouze 1/2 sběrnice a že by to třeba mohlo dělat problémy. Naštěstí na desce řadiče je kromě osmice sériových 33Ω odporů i footprint na poctivý buffer (i dříve se takto šetřily náklady). Rozhodl jsem se tedy odpory vypájet a osadil tam obvod SN74LS245. Bohužel to nepřineslo žádnou změnu chování. Až když jsem vyhrabal jiný IDE řadič, tak přestal POST se SSD Samsung tuhnout, avšak stejně se oba SSD v XTIDE nedetekovaly.

vypájení odporů 33Ω	připájení SN74LS245	jiný IDE řadič ISA

      Protože mě toto podivné chování SSD vrtá hlavou, vyzkoušel jsem je v dalších 2 starých základních deskách. Ve 486 s ISA řadičem a AMI BIOSem, který už má autodetekci disku, tak se oba detekují s nesprávnou hodnotou cylindrů (15 hlav a 63 sektorů odpovídá) a malou kapacitou, ale nejde z nich bootovat. XTIDE nedetekoval SSD vůbec. V NETmate 386SX s VLSI chipsetem a integrovaným IDE řadičem se oba SSD detekují s menší kapacitou 1834 MB. SSD Transcend lze používat s omezenou kapacitou přes systémový BIOS nebo přes XTIDE s plnou kapacitou. V benchmarku CheckIt dosáhl přenosové rychlosti 693 kB/s a průměrné přístupové doby 1,6 ms. Zatím co SSD Samsung při detekci sice také vypíše kapacitu, ale v zápětí chybu "Error initializing hard disk controller 0" a XTIDE ho nedetekuje vůbec. Pro úplnost jsem ještě v desce KMC-A419-8 vyzkoušel čínskou obousměrnou redukci IDE-SATA s plotnovým SATA diskem Seagate Barracuda 7200.9 ST3160812AS 160 GB, ale chovala se stejně jako mSATA redukce, při detekci jen krátce blikla LED.

chyba detekce SSD	XTIDE netetekuje SSD

      6.12.2022 Jako další krok jsem provedl experiment s bootem DOSu z diskety, na níž jsem nahrál svou utilitu SMB, která m.j. umí na přímo komunikovat s diskem pomocí ATA příkazů. Napřed jsem poslal příkaz IDENTIFY DEVICE a SSD Transcend odpověděl, ale řada položek byla chybná (např. název a S/N disku) a neseděl kontrolní součet. Dále jsem zkusil přečíst sektor 0 (MBR) metodou CHS i LBA a oba prošly bez chyby a přečetl jsem z disku nějaká data. Problém tedy není v tom, že by SSD neuměl pracovat v CHS PIO režimu, což by podle specifikace umět měl.
      V případě SSD Samsung jsem musel postupovat tak, že jsem napřed nabootoval z diskety s odpojeným napájením SSD (datový kabel jsem nechal připojený) a až pak ho připojil. Avšak okamžitě se mi na obrazovce objevily nějaké náhodné znaky, nicméně systém reagoval dále a mohl jsem aspoň poslepu zadávat příkazy. Zajímavé je, že když jsem spustil Mikromanažera, tak ten svou modrou obrazovku se souborovými panely vykresloval bezchybně, ale když jsem se klávesovou kombinací CTRL+O přepnul na DOSovou obrazovku, tak tam byl pořád ten bordel a po přepnutí zpět do manažera jsem zas viděl čisté panely. Spustil jsem tedy SMB s výstupem přesměrovaným do souboru, ale příkaz IDENTIFY DEVICE neprošel. Zrovna jsem sehnal ještě další mSATA SSD AData ASX300S3-64GM-C 64 GB a chová se v redukci stejně jako SSD Samsung. Prostě si asi nějak tato mSATA redukce s tímto řadičem nerozumí elektricky. Vyměnil jsem tedy IDE řadič za ten druhý, s kterým to netuhlo a na něm se disk chová stejně jako SSD Transcend, čili IDENTIFY DEVICE projde, ale vrátí poškozená data, taktéž sektory čte přes CHS i LBA. Je tak logické, že když XTIDE dostane při detekci poškozenou odpověď, tak s diskem dále nepokračuje, chybu je třeba hledat někde na sběrnici. K tomu by se hodil aspoň 24-bitový logický analyzátor, ale mám pouze 8-bitový USBee AX PRO.

Transcend Identify	Transcend read LBA	Transcend read CHS	Samsung disp. trash	Samsung Identify

      8.12.2022 Až později jsem si všiml, že v přečtených raw datech ze SSD, jsou všechny MSB nulové. To mě dovedlo k tomuto vláknu, kde uživatel Jon Abbott řešil stejný problém a celý problém vysvětluje: After some basic diagnosis with a volt meter on the IDE cable and visual inspection of the SATA adapter boards today, I think I have an idea about why the MSB is missing. None of the SATA adapters control the -IOCS16 line, so they're really designed for DMA transfer only where the line is ignored. RiscPC doesn't support DMA, only PIO, so it's expecting -IOCS16 to be pulled low if 16bit data is presented on the bus.
      Proměřil jsem tedy multimetrem pin 32 na mSATA redukci a SSD Transcend, přičemž se potvrdilo, že na obou je nezapojený (dle specifikace ATA-2 ještě definovaný je, ve specifikaci ATA-3 byl zrušen). Na IDE řadiči jsem se doměřil, že tento signál IOCS16# jde přímo z konektoru disku (pin 32) na ISA sběrnici (pin D2). Teď už jen zbývá vyřešit, jak chybějící signál IOCS16# vygenerovat. Zkusil jsem narychlo přes 2 diody sloučit signály CS0# a CS1# (IOCS16# je typu otevřený kolektor s pull-upem cca 1 kΩ někde na MB), ale pak SSD vůbec nekomunikoval. Při pohledu na časovací diagram to nebude úplně triviální. Ještě se to komplikuje tím, že signál IOCS16# se nesmí generovat v režimech PIO 3, 4, DMA a navíc se má generovat jen při přístupu k datovému registru (base + 0) a nikoliv k ostatním řídicím a status registrům. To bude vyžadovat nějakou logiku s hradel z celkem 5 signálů CS1#, CS0#, DA2, DA1, DA0.

PIO timing	IDE registers

      13.12.2022 Dekodér signálu IOCS16# jsem navrhl ze 2 běžně dostupných logických obvodů 7432 (4 x 2-vstupové hradlo OR) a 7403 (4 x 2-vstupové hradlo NAND s výstupy typu otevřený kolektor). U invertoru tedy musí být pull-up odpor, zatím co výstup pracuje do pull-upu na MB. Obvod jsem narychlo poskládal na kontaktním nepájivém poli a ověřil základní funkčnost s LEDkou na výstupu. Pak jsem na zadní stranu desky IDE řadiče připájel 8 tenkých drátků s potřebnými signály včetně napájení a zapíchal je do nepájka. Zapojení jsem ještě ladil na osciloskopu, ale zobrazení není moc přehledné, neboť na signálu IOCS16# je docela čilá aktivita ze sběrnice a také na ostatních signálech se pořád něco děje i když s diskem zrovna nekomunikuju. Utilitou SMB jsem ověřil správné čtení sektoru a identifikaci, nyní už tam jsou data správně, celých 16 bitů. XTIDE BIOS pak SSD Transcend bez problémů detekoval a nabootoval z něj. V benchmarku CheckIt dosáhl přenosové rychlosti 1,85 MB/s a průměrné přístupové doby 0,1 ms. Co se týče problému s tuhnutím systému a rozbitím obrazu při připojení SSD přes mSATA v redukci na tomto IDE řadiči, tak se nic nezměnilo a se signálem IOCS16# to nijak nesouvisí. Možná nějaký problém s napěťovými úrovněmi nebo timingem. Předpokládám, že na druhém IDE řadiči pojedou mSATA SSD bez problémů. Plánuju vyrobit malý plošňáček s SMD hradly, který by se připájel zezadu IDE řadiče přímo na vyčuhující piny IDE konektoru a k tomu odněkud 1 drátkem dovedl 5V napájení. Výstup IOCS16# signálu by šel přes jumper, aby ho bylo možno v případě potřeby odpojit.

IOCS16# dekodér	IOCS16# dekodér

      Z nostalgie jsem zkusil na SSD Transcend nainstalovat Windows 95 OSR2. Instalační soubory jsem si předem nakopíroval na SSD a spustil instalátor z DOSu: setup.exe /is /ig /IW (přehled přepínačů setupu je zde). Instalace trvala asi 45 minut. Windows nastartují za 26 s (měřím do okamžiku, kdy se ukazatel myši změní z přesýpaček na šipku) a jsou docela responzivní. Když to srovnám proti mému prvnímu PC s AMD 486DX4/100 a plotnovým diskem WD 630 MB, tak to bylo docela utrpení za nekonečného hrabání disku. Při nečinnosti je vytížení CPU kolem 1% a je alokováno 9,6 MB RAM. Spuštění Internet Exploreru trvá asi 5 s a s prázdnou stránkou se spotřeba paměti zvýší na 13,7 MB.

instalátor Windows 95	instalátor Windows 95	instalátor Windows 95	běžící Windows 95

      14.2.2023 mi přišla várka plošňáků z JLCPCB a mezi nimi i malá destička dekodéru signálu IOCS16#. Osadil jsem 2 SMD šváby a pár pasiv a připájel destičku na zadní stranu IDE řadiče za vystupující kousky pinů IDE konektoru. Pak už jen zbývalo připojit napájení 5 V jedním drátkem z nejbližšího bodu na IDE řadiči. Pomocí jumperu lze výstupní signál IOCS16# z dekodéru odpojit (pro případ, že ho připojený disk generuje sám, tak aby se nepotloukly výstupy hradel). Testoval jsem opět s SSD Transcend a fungovalo to na první dobrou.

IOCS16# dek. schéma	IOCS16# dek. layout	IOCS16# dek. model	IOCS16# dek. PCB	IDE ctrl. back-side

Přehrávání MP3 na Am386DX a TX486DLC

      15.3.2025 Když jsem někdy skoro před 30 lety na svém prvním PC s AMD 486DX4/100 zkoušel poprvé přehrávat komprimované hudební soubory MP3 (128 kbps), tak to PC sotva stíhalo s vytížením CPU blízkém 100%. Používal jsem tehdá přehrávače XTC-Play 0.97c pro DOS, WinPlay3 2.3b5 pro Windows 3.11 a WinAMP pro Windows 95. Kooperativní multitasking ve Windows 3.11 byl v tomto případě výhodou proti preemptivnímu multitaskingu ve Windows 95, kde při křivém pohybu myší docházelo k výpadkům zvuku. Grabování audio CD a výroba vlastních MP3 pomocí enkodéru L3Enc pro DOS pak byla zábava na půl dne. Tehdy by mě ani nenapadlo, že by se MP3 daly přehrávat na výrazně pomalejších PC.
      Po jedné diskusi o 486 na OldComp.cz jsem zkusil trochu zapátrat, jestli náhodou někdo nenapsal nějakou optimalizovanou MP3 knihovnu pro MCUčka, která by mohla dobře běhat i na starých PC. Nejprve jsem našel knihovnu minimp3, kterou jsem zkusil zkompilovat pro DOS pomocí DJGPP. Testovací program na mém hlavním PC s Core i7-2600K dekomprimoval na RAMdisku 128kbps MP3 o délce 250 s za 0,5 s, takže teoreticky by stačil na realtime přehrávání 10MHz CPU. Avšak 386/486 mají řádově horší IPC, takže v reálu byl výsledek tragický - 16s výřez téže MP3 se na 40MHz TX486DLC na RAMdisku dekódoval 97s, což je asi 25x horší, než by zvládlo Core i7 na 40 MHz.
      Dále jsem našel projekt Nocash MP3 decoder Martina Kortha z Německa. O něm jsou i diskusní vlákna na VOGONS fóru a NesDev fóru. To už vypadalo docela nadějně, optimalizovaná knihovna kompletně přepsaná do assembleru a fixed-point integer aritmetiky - nepotřebuje tedy (dříve relativně pomalý) FPU. Jedinou vadou na kráse je, že je to Win32 aplikace (konzolová), takže vyžaduje pro běh alespoň Windows 95, které jsem už předtím nainstaloval na SSD. Potřeboval jsem akorát doinstalovat ovladače pro zvukovou kartu - sáhl jsem do krabice pro Sound Blaster AWE64. Kolega OldCompista to zkoušel s rozšířením Win32S na Windows 3.11, ale neuspěl. Autor má na webu ještě ARMovou verzi pro Game Boy Advance.
      Důležité je, že mp3play má celou řadu parametrů, které pomáhají výrazně redukovat potřebný výpočetní výkon na úkor kvality, pokud CPU nestíhá. Není tedy třeba MP3 soubor předem znovu překódovávat do nižšího bitrate a nižší vzorkovací frekvence. Tento dekodér umí některá data nesoucí informace o vyšších frekvencích vynechat už na začátku řetězce a tím výrazně šetří čas CPU. Podívejme se na tyto parametry podrobněji: /half a /quarter snižují výstupní vzorkovací frekvenci na polovinu, resp. čtvrtinu, což zrychlí dekódování asi 1,7x resp. 2,3x. Parametr /mono redukuje 2 kanály do 1, opět přináší výrazné zrychlení asi 2x. Parametry /fast (menší přesnost výpočtů) a /8bit (nižší bitové rozlišení výstupu - větší kvantizační šum) už přinesou zrychlení jen pár %, někdy dokonce způsobí i zpomalení - je třeba vyzkoušet na konkrétním CPU. Balíček také obsahuje celou řadu verzí s různými typy optimalizací (některé vhodnější pro 386, jiné pro 486), ale v praxi jsem zjistil, že rozdíl mezi nejlepší (mp3huf5.exe) a nejhorší (mp3huf2.exe) variantou je jen 7,7% (386DX), resp. 5,2% (486DLC), takže to nemá moc význam. Parametr /test slouží pro měření max. rychlosti dekódování bez zvukového výstupu a zobrazí časovou délku daného MP3 souboru a skutečný čas, který byl potřeba pro dekódování.
      Pro testování jsem použil skladbu Desmond Doom - The Dissociation Song v MP3 128 kbps, 44 kHz, joint stereo, resp. prvních 16,013 s (256000 B). Na 486DLC jsem dosáhl plynulé hratelnosti s parametrem /mono nebo /half (testovací čas dekódování: 10,011 s resp. 12,048 s, v plné kvalitě pak 19,619 s). Nebyl problém ani s přehráváním MP3 320 kbps, 44 kHz, stereo, takže bitrate zde nemá na rychlost zásadní vliv. Oproti tomu se Am386DX na stejné frekvenci ukázala výpočetně výrazně slabší, v plné kvalitě trvalo dekódování 37,512 s. S parametrem /mono jsem se dostal na 18,960 s a s /half na 22,399 s, což pořád nestačilo (ani s přidáním parametrů /fast a /8bit), takže jsem musel použít oba dohromady (tedy výstup 22 kHz mono) a pak jsem se dostal na 11,427 s, což už stačilo na přehrávání s dostatečnou rezervou. Avšak u 320kbps MP3 to přestalo stíhat s občasnými výpadky a musel jsem kvalitu snížit až na /quarter /mono.
      Zde je mé video testu na 386DX, v 2. části videa jsem přepnul zvuk z foťáku přímo na lineout zvukovky SB AWE64, který jsem vzorkoval hlavím PC na SB Audigy. Autenticky je slyšet i sekání zvuku, pokud začnu po Windows chtít něco dalšího nebo jen přepnu z fullscreenu zpět do okna. Při tom jsem našel ještě další zajímavé video nějakého Turka, který pouští upravený port mp3play ve vlastním operačním systému TRDOS 386 a zbavil se tak závislosti na Widlích. TRDOS by měl snad podporovat audio výstup na PC speaker, SB16, intel AC'97, HDA a VIA VT823x, takže námět na další testování.

      29.3.2025 Pro zajímavost jsem otestoval mp3play na dalších 486 CPU na základní desce Octek Hippo 10. Prvním překvapením bylo, že plnokrevná intel 486DX-40 s 8 kB L1 cache dosáhla znatelně horších výsledků než TX486DLC-40 s 1 kB L1 cache. Druhým, naopak velmi pozitivním překvapením byla Green 486 od UMC U5SX-40 (zde absence FPU nevadí), která naopak předvedla skvělý výkon (díky optimalizaci mikrokódu - vyššímu IPC), což s parametrem /fast umožnilo dekódovat MP3 v plné kvalitě. Mnohem výše taktovaná Am5x86 to už pak dává s prstem v nose a i DOSový přehrávač MPXPlay na ní přehrává 320kbps MP3 s vytížením CPU jen kolem 65%.
      Dále se mi podařilo mp3play rozběhnout v DOSu pod HX DOS Extenderem na SB AWE64, ale overhead emulace zvukového subsystému Win32 API byl takový, že i na Am5x86 se zvuk nepříjemně sekal a ujížděla rychlost přehrávání (nehledě na použité parametry redukce kvality), že se to nedalo poslouchat. Překvapivě na 486DLC v desce KMC-A419-8 se zvuk mp3play pod HX sekal mnohem méně, ale rychlost přehrávání s parametrem /quarter ujížděla taky. Zřejmě záleží i na chipsetu nebo byla na Hippo 10 nějaká anomálie. V režimu /test bylo dekódování pod HX o pár % rychlejší než pod Windows 95, ale při reálném přehrávání na zvukovce to nemá význam.
      Zkusil jsem též nainstalovat rozšíření Win32S 1.30c do Windows 3.11, ale nepodařilo se mi v nich mp3play spustit (ani žádnou jinou Win32 konzolovou aplikaci), takže tudy také cesta nevede. Zkoušel jsem i spustit Windows 95, které jsem nainstaloval na SSD na 386 desce KMC-A419-8, ale z nějakého neznámého důvodu běžely na desce Octek Hippo 10 velmi nestabilně, občas spadly do modré hned při startu, jindy pár vteřin po spuštění přehrávání mp3play provedl neplatnou operaci a neměl jsem zrovna chuť instalovat Widle znovu.

      7.4.2025 Vyzkoušel jsem ještě mp3play portovaný pro výše zmíněný TRDOS 386 2.0 na 486DLC v desce KMC-A419-8. Stáhl jsem nějaký bootovací image diskety a přidal do něj pomocí WinImage mp3play0.prg a testovací mp3 soubor. Image jsem nabootoval z DOSu pomocí GRUB4DOS. TRDOS umí pracovat s FS FAT12/16/32, ale neumí spouštět DOSové COM/EXE programy - používá vlastní formát *.PRG (autor pro něj přeportoval řadu DOSových programů). Následně nastal problém s Plug & Pray zvukovkou SB AWE64, jelikož se mi ji nedaří na nePNP desce zprovoznit jen s pomocí DOSových driverů. Vždy musím napřed spustit Windows 95, které provedou Plug & Play konfiguraci zvukovky a pak restartovat do DOSu, kde spustím DOSový driver nebo Unisound a pak zvukovka funguje pod DOSem normálně, i když provedu měkký reset. Ale jakmile vypnu a zapnu napájení, tak se konfigurace ztratí a DOSový driver ani Unisound zvukovku nenajde. Bohužel když spustím TRDOS po té, co před tím běžely Windows 95 (ať už z image nebo diskety), tak po stisku jakékoliv klávesy dostanu nějaký exception v kernelu a následuje restart. A když Windows 95 předtím nespustím (neproběhne Plug & Play konfigurace), tak TRDOS zvukovku nenajde. Zkusil jsem tedy ještě jinou nePNP zvukovku (PicoGUS s SB 2.0 FW). V DOSu vše fungovalo jen s nastavenou proměnnou prostředí BLASTER. TRDOS zvukovku také našel, ale žádný program nehrál, vždy se to při spuštění seklo. Takže jsem mohl vyzkoušet mp3play jen v režimu /test a běžel podobně rychle jako pod HX DOS Extenderem).

params / CPU:	Am386DX-40	TX486DLC-40	i486DX-40	U5SX-40	Am5x86-160	kvalita
-	37,512 s	19,619 s	28,921 s	19,602 s	7,806 s	44 kHz, 16-bit, stereo
/fast	36,178 s	20,217 s	27,663 s	13,891 s	7,471 s	44 kHz, 16-bit, stereo
/half	22,399 s	12,048 s	16,627 s	11,447 s	4,638 s	22 kHz, 16-bit, stereo
/mono	18,960 s	10,011 s	14,565 s	9,888 s	3,940 s	44 kHz, 16-bit, mono
/mono /half	11,427 s	6,211 s	8,421 s	5,815 s	2,344 s	22 kHz, 16-bit, mono
/quarter	16,224 s	8,584 s	11,517 s	7,828 s	3,342 s	11 kHz, 16-bit, stereo

rychlost dekódování MP3 128 kbps, 44 kHz, joint stereo, 16,013 s

Hackování utility SpeedSys

      13.4.2025 Trochu mě štvalo, že utilita SpeedSys neběží na mém CPU Tx486DLC a nemůžu tak přidat benchmark do tabulky a porovnat průběhy grafů propustnosti cache v režimu WT/WB. Z VOGONS fóra už vím, že problém je způsoben čtením neexistujícího specifického konfiguračního registru. Napadlo mě tedy najít odpovídající kód a zkusit ho vyřadit. To ale nebylo tak snadné, protože binárka SpeedSysu je buď šifrovaná nebo zabalená neznámým EXE packerem, takže jsem ji nemohl disassemblovat. Zkusil jsem ji rozbalit pomocí UNP, ale neúspěšně.
      Jedinou možností tedy bylo použít debugger. Už jsem docela hodně dlouho na x86 nic nedebugoval. Jelikož SpeedSys využívá PMode a nemá rád, když je CPU ve V86 mode (EMM386/QEMM386/JEMM386 a některé debuggery), rozhodl jsem se vyzkoušet Japhethův DebugXv který zvládá RM i PM. Je to celkem jednoduchý textový debugger vycházející z utility debug, která byla už součástí MS-DOSu. Jeho zajímavou funkcí je, že umí nastavit až 4 hardwarové breakpointy na adresy kódu nebo 4 I/O watchpointy. Pomocí nich lze pokrýt rozsah až 16 I/O portů. Syntaxe je poněkud obskurní, watchpoint se zadá příkazem např. bp 0:80 2, kde 80 je adresa I/O portu 80h a 2 je typ přístupu (2: 8-bitový port, 12: 16-bitový port, 32: 32-bitový port). Další háček je v tom, že aby watchpointy fungovaly, musí být nastaven bit 3 - DE (Debugging Extensions) v control registru CR4, což za vás DebugXv neudělá, ale musíte si ho nastavit sami. Jelikož s CR registry na x86 nejde pracovat přímo, je nutné provést čtení, modifikaci, zápis; např. tímto kódem: MOV EAX,CR4; OR EAX,8; MOV CR4,EAX. Další, poněkud nešikovnou vlastností (danou HW) je, že se běžící program zastaví až po vykonání IN/OUT instrukce. Bohužel jsem následně zjistil, že 486DLC nemá control registr CR4 a nelze tak I/O watchpointy požít.
      Nezbylo tedy, než program ručně odkrokovat. K tomu se hodí jiný rezidentní debugger, který lze vyvolat nějako klávesou. Zkusil jsem napřed Borlandí TD386, ale ten ani nechtěl binárku načíst. Pak jsem si vzpomněl na CandyManův Dark Debugger, který má docela hezké TUI a řadu funkcí, včetně breakpointů na I/O, ale ty též nefungovaly. Musel jsem tedy spustit SpeedSys, ve vhodný okamžik stisknout klávesu Pause/Break a pak krokovat. Když jsem došel na nějaký call (pomocí F8 - step over), po kterém následoval zátuh, poznamenal jsem si adresu a příště do něj vstoupil (pomocí F7 - trace into) a opět pokračoval k dalším callům, kde to vytuhlo. Nakonec se mi podařilo dojít až do vnitřní rutiny, která obsahovala hledané instrukce MOV AL,0FEh; OUT 22h,AL; IN AL,23h, tedy čtení konfiguračního registru FEh (port 22h je číslo registru a port 23h) je pro data. Podle datasheetu však na CPU Tx/Cx486DLC/SLC žádný takový registr není, platné jsou pouze hodnoty C0h - CFh (ty CPU dekóduje interně a negeneruje sběrnicové I/O cykly). Pokud tedy CPU zaznamená přístup k registru mimo tento rozsah, tak se vygeneruje běžný I/O cyklus na sběrnici a pokud zrovna port 22h používá i chipset, tak ho neočekávaným zápisem rozjebe. Když jsem v Dark Debuggeru tyto instrukce přeskočil, tak SpeedSys běžel dál, ale v omezeném režimu, protože nemá rád V86.
      Zbývalo tedy nějak vymyslet, jak by se dal patchnout kód SpeedSysu v paměti runtime. Mezi tím se ale na BTTR fóru ozval Robert Riebisch se skvělou zprávou, že kdysi v roce 2006 získal od autora Vladimira Afanasieva zdrojové kódy poslední verze 4.79 beta 4, které mu dovolil zveřejnit pod GPL na GitHubu. Já jsem mu zkusil teď taky napsat, ale celkem nepřekvapivě se mi mail vrátil nedoručený. Tím se situace značně zjednodušila. Jak jsem zjistil, SpeedSys je čistá práce v assembleru a celkem bez problémů se mi ho podařilo zkompilovat pomocí TASM 4.1. Autor použil oblíbený EXE packer UPX, který ale zobfuskoval přepsáním hlavičky svou utilitou speedin1.exe, kterou jsem z kompilačního procesu vynechal. Jako dirty hotfix jsem zakomentoval zmíněné I/O instrukce a nově zkompilovaná binárka je ke stažení zde. Chtěl bych to ale pořešit čistě nějakou detekcí 486DLC/SLC a podle toho kód rozvětvit, jestli se konfigurační registr bude nebo nebude číst. Na další podobnou chybu v SpeedSysu jsem narazil na mém primárním PC s Core i7-2600K, kdy zatuhne při čtení MSR. To bych také rád nějak opravil. Výsledky benchmarků jsem přidal do tabulky níže.

Dark Debugger

Oprava Paradise VGA WD90C00-JK ISA

      16.9.2022 Od Dušana jsem dostal na hraní směsici různých starých ISA/PCI karet. Mezi nimi také byla nefunkční grafická ISA karta Paradise VGA čipem WD90C00-JK a 256 kB VRAM. Když jsem ji zastrčil do slotu, tak deska vypípávala stejný chybový kód, jako kdyby v ní žádná VGA karta nebyla. Zkusil jsem napřed pomocí programátoru LabProg-48LV přečíst video BIOS ze dvou 16kB OTP EPROMek a obsah 2 programovatelných obvodů dekodérů PAL - bez problémů. Dále jsem změřil výstupy všech 4 krystalových oscilátorů a naměřil odpovídající frekvence s amplitudou cca 2,5 - 4,5 Vpp. Také jsem osciloskopem očuchal piny grafického čipu, kde jsem viděl aktivitu na adresové a datové sběrnici, ale žádnou aktivitu směrem k VRAM (MA0-8, MD0-15) a do RAMDACu (VID0-7), což indikovalo, že čip je asi mrtvý.
      Jelikož jsem měl v šuplíku vypájený grafický čip PVGA1A-JK, který by měl být velmi podobný a podle datasheetu je pinově kompatabilní (někde jsem četl, že ho Western Digital při koupi Paradise Systems patrně jen přejmenoval), tak jsem se kartě ještě rozhodl dát šanci. Naivně jsem si myslel, že jen přepájím tento PLCC100 čip a bude to fungovat, ale tak jednoduché to nebylo. Po výměně jsem stále dostával stejné pípání, jako že VGA není přítomna. Čuchal jsem znovu osciloskopem a nyní už byla vidět aktivita na sběrnici VRAM, ale do RAMDACu nešlo pořád nic, ani žádné HSYNC, VSYNC pulsy. VRAM jsem zkusil vyměnit, ale žádná změna. Pojal jsem podezření, že chyba bude asi v nějakém z hradel 74xx, dokonce i všechny odpory jsem přeměřil. Vypájel jsem pomocí vyhřívané odsávačky celkem 11 hradel 74xx a každý obvod otestoval, ale žádný vadný jsem nenašel, takže jsem je zas vrátil zpět. Kupodivu se ale chování karty změnilo - deska ani nepípla a obraz nikde, no čím dál lepší. Tak jsem zastrčil do MB i POST kartu a viděl, že se AMI BIOS pořád točí v nějaké smyčce, kde se rychle střídalo pár POST kódů. Když jsem vyjmul jeden z čipů video BIOSu, tak k zaseknutí nedocházelo. Napadlo mě tedy, že asi stávající video BIOS nebude se starším grafickým čipem kompatabilní. Podařilo se mi najít image video BIOSu pro PVGA1A-JK a tak jsem vzal 2 EPROMky Am27128A, vymazal je UV lampou, naprogramoval, strčil do karty a ejhle, ono to bootuje s obrazem :) Projel jsem testy všech video módů v Norton Diagnosticu a CheckItu a v pořádku. Kartu by šlo doosadit na 512 kB VRAM, ale UniVBE ji nepodporuje, takže vyšší rozlišení by využily jen DOSové programy přímo podporující PVGA.

po výměně WD90C00-JK	PVGA bez 74xx hradel

      27.8.2023 Dnes jsem zjistil, že mi dříve opravená Paradise VGA záhadně umřela. Ve výše zmíněné 386 desce s AMI BIOSem se POST zastaví s černou obrazovkou na kódu 2Ch, což znamená video ROM check. První, co mě napadlo, že jsem předtím nedokonale naprogramoval EPROMky a došlo k zapomenutí nějakého bitu. Avšak po přečtení v programátoru a porovnání s image jsem žádné rozdíly nenašel. Taktéž jsem zkontroloval obsah programovatelných obvodů PAL a také beze změny, tak netuším, co se posralo...

      31.8.2023 Našel jsem vyhozenou 16-bitovou ISA VGA kartu s čipem OAK OTI067 a 512 kB VRAM. Karta byla bez bracketu, ale jinak vypadala nepoškozená. Po vložení do 386 MB se tvářila, jakoby tam žádná VGA karta nebyla. Zkusil jsem tedy přečíst obsah OTP EPROM 27C256 (plastový čip bez okénka) a programátor hlásil, že nesouhlasí čtení při VCCmin a VCCmax. Když jsem si obsah prohlédl, na první pohled bylo vidět poškození mnoha Bytů (např. v textových řetězcích). Identifikoval jsem verzi video BIOSu jako 1.04 s timestampem Thu May 02 14:37:12 1991. Na tomto webu jsem našel novější verzi video BIOSu 1.06 s timestampem Mon Mar 02 14:23:12 1992, kterou jsem napálil do prázdné EPROMky, vložil do karty a karta ožila. Jak je vidět, tak některé čipy už po 30 letech začínají mít sklerózu a je tedy třeba je včas zazálohovat.

Oprava 386 základní desky Soyo SY-015G

      10.3.2023 Od Dušana jsem dále dostal na hraní 2 neznámé základní desky s onboard SMD CPU Am386DX-40 a chipsetem Macronix MX83C305FC & MX83C306FC i s origo papírovým manuálem, který jsem následně naskenoval a s BIOS dumpem poslal na Retroweb. Patrně se jedná o desku Soyo SY-015G, akorát ta moje nemá osazenou PGA patici na CPU, což by ale nebyl problém dopájet, stejně jako jsem to udělal u desky výše. Obě desky měly vyteklé NiCd baterky, které částečně poškodily měděné spoje či prokovy na PCB. Jedna deska vůbec nePOSTuje (jen kmitá oscilátor), druhá deska naběhla, ale hlásila chybu keyboard controlleru a klávesnice vůbec nedostávala napájení. Odpájel jsem tedy 5-kolíkový DIN konektor klávesnice a našel u kraje 1 sežranou napájecí cestu, která vedla přes tlumivku na napájení 5 V a propojil jsem ji drátkem. Dále jsem našel 2 vyhnilé prokovy, které nějak souvisely s funkcí KBC, neboť po jejich propojení drátkem chyba zmizela a klávesnice začla normálně fungovat. Desku jsem projel základními diagnostickými testy v Norton Diagnosticu a neobjevila se žádná chyba.
      V SETUPu mě překvapilo, že jsem tam viděl volbu "External cache: enabled", přitom na desce žádné SRAM čipy nejsou. Napřed jsem to považoval za bug, ale když jsem spustil CCT386, tak je evidentně vidět, že podle skokové změny rychlosti má někde schovaných 8 kB cache. A to zřejmě přímo v tom chipsetu, jak se o tom zmiňují na Retrowebu. Tak to jen taková zajímavost, že takové chytré chipsety existují, jen jsem o nich dosud nevěděl...

vyteklý NiCd aku	MB 386DX	oprava PCB	8 kB internal cache

      29.1.2026 Pustil jsem se do opravy druhé desky, která vůbec nePOSTovala. Opravil jsem pár sežraných cestiček v okolí baterky, kvůli čemuž jsem musel odpájet i DIN konektor klávesnice, ale beze změny. Vytáhl jsem osciloskop a očuchal signály na sběrnicích. Na pinech EPROMky s BIOSem, ISA, i CPU bylo celkem živo. Napadlo mě místo BIOSu strčit do patice testovací EPROMku s jednoduchým prográmkem, který v nekonečné smyčce posílá hodnotu 13h na I/O port 80h:

0: B0 13 MOV AL, 0x13 ; D7=1, 0 2: E6 80 OUT 0x80, AL ; D7=1, 1 4: EB FA JMPS 0 ; D7=1, 1

Avšak na POST kartě se zobrazila hodnota 93h. Takže je něco špatně s datovou linkou D7. Náhodou zrovna všechny použité x86 opkódy mají bit7 = 1, takže běh kódu nebyl narušen, ale zmrvila se jen data v přímém operandu instrukce MOV. Na osciloskopu jsem zachytil průběh na pinu D7 EPROMky, kde byla v jednom čtecím cyklu vidět log. 0 a v ostatních log. 1, takže program se z paměti čte správně, ale na ISA sběrnici jsem v zápisovém cyklu IOWR# viděl D7 na log. 1. Data se tedy můžou zmrvit někde po cestě mezi chipsetem a CPU.

EPROM D7 & OE#	ISA IORW# & OE#	CPU D7 & M/IO#	blokové schéma

      Začal sem tedy sledovat, kam vede D7 od EPROMky a došel k obousměrnému budiči sběrnice U5 - 74F245. Jeho brána B vede přímo na datové linky D7:0 ISA sběrnice (D7 je na ISA slotu na pinu A2 v pravé řadě) a brána A vede na D7:0 EPROMky, RTC, KBC a chipsetu MX83C305FC. Od něj však nevedou žádné datové linky do CPU, ty vedou pouze do druhého chipsetu MX83C306FC. Mezi sebou mají oba chipsety nějaké proprietární propojení.
      Mezitím jsem dostal balíček s dalším PC šrotem, kde se nacházela zrovna jedna vraková deska Kaimei KM-386MX s podobným chipsetem MX83C305AFC a MX83C306AFC. Zkusil jsem z ní chipset vypájet horkovzduchem a přehodit na opravovanou desku (a pro sirotčí jistotu ještě vyměnil i buffer 74F245), ale žádná změna. Musel jsem se tedy hlouběji ponořit do hledaní spojů a postupně tak vzniklo částečné blokové schéma a netlist různých komponent. K tomu jsem zpočátku hodně využíval tu druhou oholenou desku, kde se bez švábů cestičky lépe sledovaly.

      30.1.2026 Našel jsem tam i jednu odlišnost, že na KM-386MX nebyl osazený oddělovač sběrnic, ale oba chipsety sdílely stejné datové linky D7:0 připojené rovnou na ISA sloty. Tím jsem zjistil, že D7 má vést na pin 146 chipsetu MX83C306FC, ale na mojí desce byla cesta někde přerušená. Vysledoval jsem, že vede pod čipem na dolní straně pod SIMM sloty, kde zas prokovem vyleze nahoru a vede na prokov pinu A2 ISA slotu 9, jehož kraj je docela blízko baterce. Okem nebylo nic moc vidět, ale patrně u zakončení cestičky do horní plošky prokovu to bylo přežrané. Oškrábal jsem tedy nepájivou masku z kousku cestičky co nejblíže ISA slotu a připájel tam tenký drátek se zahnutým háčkem kolem pinu A2. Po zapnutí jsem konečně dostal správný kód 13h a po výměně za původní BIOS začala deska normálně startovat...
      Jenže jsem se radoval předčasně, protože pro změnu zas nefungovala klávesnice. A to docela zvláštním způsobem. U většiny desek vyblitá baterka prostě sežere cestičky CLK a DATA od DIN konektoru klávesnice ke KBC, které jsou nejvíc na ráně. Ty ale v mém případě byly v pořádku a končily v KBC na pinech 1 - TEST0 a 39 - TEST1. Navíc BIOS nepsal klasicky chybu "Keyboard error", ale poznal, jestli tam klávesnice je připojená nebo není. Asi 2 s po HW resetu na klávesnici probliknou LEDky, takže KBC provede úspěšně reset klávesnice. Zkusil jsem KBC prohodit s jiným z desky KMC-A419-8 a s ním to taky nefungovalo, zatím co KBC z této desky v druhé fungoval normálně.
      Pojal jsem podezření, jestli za to nemůže nějaká odlišnost v revizi chipsetu FC vs AFC. Napadlo mě zkusit napálit do EPROMky BIOS z jiné desky, která měla AFC verzi chipsetu. Na Retrowebu jsem našel celou řadu desek s tímto chipsetem a vyzkoušel MR BIOS pro desku Octek JAGUAR V 386, která má na fotkách uživatelů FC i AFC chipsety. Nicméně se to s MR BIOSem chovalo stejně, akorát že ten po ohlášení chyby nastavení CMOS při dalším startu už chybu nepíše a pokračuje v bootu, takže s připojeným řadičem a XTIDE jsem byl schopen nabootovat do DOSu. Do autoexec.bat jsem přidal spuštění utility na zobrazování scankódů klávesnice, ale ten po stisku klávesy nic nezobrazil.

      31.1.2026 Začal jsem tedy podrobněji zkoumat zapojení KBC (MCU 8042) a porovnal ho se zapojením na straně 111 v IBM PC AT Technical Reference manuálu a prakticky se neliší. Jelikož má KBC pouze jednosměrné porty, zatím co klávesnice používá 2 obousměrné signály CLK a DATA s otevřeným kolektorem, tak musí KBC na každý signál použít 2 porty - jeden vstupní a jeden výstupní. Navíc protože nemá výstup s otevřeným kolektorem, tak musí použít externí invertor typu 74LS05. Vydloubnul jsem KBC z patice a otestoval invertorovou logiku stimulací vstupů a měřil výstupy: v log. 1 bylo výstupní napětí cca 4,9 V a v log. 0 cca 0,35 V, což je v normě.

      1.2.2026 Zkontroloval jsem osciloskopem piny oscilátoru X1, X2, kde jsem naměřil u obou desek frekvenci 7,14 MHz. Dále jsem sledoval průběhy signálů na pinech CLK a DATA a zjistil, že po HW resetu desky tam normálně proběhne sekvence resetu klávesnice (hodiny generuje vždy klávesnice a KBC posílá data).

KBC oscillator X1, X2	KBD reset @SY-015G	KBD reset @KMC-A419-8

      Patrný rozdíl je viditelný při vyslání scankódu z klávesnice do KBC, který klávesnice pošle pouze při prvním stisku a pak už nic. Zatím co na zdravé desce se signál CLK vrátí po chvilce zpět do log. 1, tak zde zůstane CLK viset trvale v log. 0. A to z vůle KBC, který drží výstup P26 na log. 1, takže invertor jen dělá svou práci. Když jsem tedy vyčerpal všechny možnosti na straně KBC směrem ke klávesnici, napadlo mě, že problém musí být na druhé straně od KBC směrem k chipsetu. KBC by totiž měl generovat signál přerušení IRQ1 na portu P24 (pin 35) pro chipset a ten by měl vyčtením scankódu přerušení potvrdit. Avšak pokud nikdo z KBC scankódy neodebírá, tak ten na to reaguje právě tímto způsobem, čímž záměrně brání klávesnici posílat další data, která se mezitím hromadí v jejím interním bufferu. Takže viník byl jasný a nedalo už moc práce dohledat další užranou cestičku k pinu pin 123 chipsetu MX83C306FC poblíž baterky, která na to úplně nevypadala. Po překlemování drátkem klávesnice ožila a deska začla konečně normálně fungovat...

KBD scancode @SY-015G	KBD scanc. @KMC-A419-8	KBD scancode-decoded

      Nakonec jsem ještě na desce udělal PGA socket mod jako na desce zmíněné výše. Na spodní straně po onboard CPU se nachází pájecí propojka od pinu 54 (FLT#), kterou lze jednoduše propojit se zemí. Já jsem tam připájel malý SMD přepínač, abych mohl CPU měnit dle potřeby. Provedl jsem pár testů s onboard CPU Am386DX-40 a PGA CPU TX486DLC-40. Jak jsem záhy zjistil, deska nezvládá rychleji taktovanou ISA sběrnici na 20 MHz - okamžitě se začnou objevovat na obrazovce náhodné znaky v textovém módu, takže jsem musel o krok níže na 13 MHz. Dále deska nezvládá stabilně běžet se 4 x 4MB SIMM moduly, přestože manuál tvrdí, že zvládne osadit až 32 MB RAM. Zkoušel jsem několik různých modulů i ty nově vyrobené a nebyl jsem schopen dokončit ani timedemo v Quake, Win95 spadly hned po startu a i SpeedSys a Norton Diagnostic hlásily chybu paměti. A to i s nejpomalejším časováním RAM a ISA frekvenci na default. Některým chipsetům prostě tyhle 4MB RAMky nešmakujou. Takže jsem testoval s 8 x 1MB SIMM moduly. Také jsem zjistil, že s originálním AMI BIOSem systém běží o něco rychleji než s MR BIOSem z Octek JAGUARu V (např. v Doomu byl rozdíl 7,21 vs 7,06 FPS a v Quake 1,9 vs 1,8 FPS).

Jak se mnou vyjebal vypínač na redukci od ATX zdroje

      23.9.2023 Pro testování starého PC šrotu používám micro ATX zdroj Fortron FSP200-50SNV (asi třetinové velikosti proti běžnému ATX zdroji). Abych nemusel mít po ruce ještě starý velký AT zdroj, vyrobil jsem si kabelovou redukci z ATX konektoru na AT. Na pin PS_ON# (14) jsem si přidělal malý vypínač pro případ, že bych redukci použil s jiným ATX zdrojem, který nemá vlastní vypínač, ale tento Fortron vypínač má, takže používám spíše ten. V poslední době se mi stávalo, že testované AT desky, které jsem tímto zdrojem napájel, tak se po nějaké době náhodně restartovaly. Někdy krátce po bootu, jindy třeba za půl hodiny. Pojal jsem podezření, že ve zdroji asi vyschly elyty a nějaká proudová špička pak shodí napětí příliš dolů. Kouknul jsem na výstupy zdroje osciloskopem, ale nic podezřelého jsem tam neviděl, jen klasické zvlnění-jehly. I tak jsem zdroj rozebral a proměřil pár elytů, ale ty výstupní byly celkem OK. Pouze 2 mrňavé elyty, které se nacházely v blízkosti evidentně hodně topících odporů 22 kΩ (byl pod nima zhnědlý plošňák), byly vysušené, ale na funkci neměly moc vliv. Vypečené odpory jsem vyměnil za větší. Nicméně i tak problém přetrvával. Pak mě teprv napadlo sáhnout na ten malý vypínač a už při letmém dotyku došlo k restartu. Špatný kontakt způsobil tak krátké přerušení na signálu PS_ON#, že se zdroj viditelně nestihl vypnout (větráček pořád běžel), ale zřejmě stihl shodit signál PWR_OK, což vyvolalo restart. Párkrát jsem vypínač procvakal a umoudřil se. No, takové pinožení a taková kravina...

Jak se mnou vyjebala klávesnice

      5.11.2025 Před více než 17 lety jsem si koupil multimediální PS/2 klávesnici KME KM-3801 a byl jsem s ní spokojený, až do teď. Z ničeho nic mi začly problikávat všechny 3 stavové LEDky a postupně přestala reagovat. Po odpojení a připojení k PC na chvilku fungovala a pak se zas rozblikala. Vypadalo to jako mžiková ztráta napájení. Zkusil jsem zakvedlat PS/2 konektorem, ale nic. Když jsem připojil jinou klávesnici, tak fungovala normálně. Napadlo mě, že se možná přežvýkla žíla v kabelu v místě, kde vychází z těla klávesnice (něco podobného se mi už stalo u vrtačky). Klávesnici jsem tedy rozebral, uštípnul asi 15 cm kablíku a připájel znovu k destičce elektroniky. Složil jsem ji, připojil k PC, fungovala asi minutu a zase se rozblikala. Znovu jsem ji rozebral a zkusil připájet 2 drátky pro napájení přímo k destičce elektroniky a pustil tam 5 V z lab. zdroje. Po chvilce zas začala blikat, takže přívodní kabel za to opravdu nemohl. Na destičce je akorát nějaký čip v podobě "plivance", 3 LED, odpůrek a 10µF elyt. I ten jsem pro sichr vypájel, změřil a vyměnil (byl ještě celkem OK), ale nepomohlo to. Když jsem destičku zkoušel všelijak prohýbat, tak na to nijak nereagovala. Nebylo už dál co opravovat, tak jsem se s ní rozloučil a odnesl jí do šrotu...

Úprava Sound Blaster AWE32 CT3900

      2.11.2022 V jednom vláknu věnovaném bugům zvukových karet Sound Blaster na VOGONS fóru jsem se dočetl, že návrháři z Creative dělali i takové prasárny, jako že nechávali plovoucí vstupy nevyužitých operačních zesilovačů. To znamená, že takový OZ pracuje bez zpětné vazby s obrovským zesílením a je tak náchylný k zesilování šumů naindukovaných do vstupů. I když je výstup nezapojený, tak to cvičí s proudovým odběrem a rušení se po napájení přenáší i na sousední OZ zpracovávající signál.
      Vzpomněl jsem si, že v jednom starém PC mám Sound Blaster AWE32 CT3900 a tak jsem si ho podrobně prohlédnul. Na PCB jsem našel tři 4-násobné OZ: 2 bipolární MC3403 - U26 a U27, které byly plně využité 1 JFETový TL074C - U31, z nějž byly využité jen OZ 1 a 4, zatím co 2 a 3 byly ponechány úplně nezapojené. Zapojil jsem tedy nevyužité OZ jako sledovače (invertující vstup spojen s výstupem) s uzemněným vstupem (napájení je symetrické ±5 V). Zem jsem našel na sousedních použitých OZ na invertujících vstupech, takže to stačilo propojit drátkem ob jeden pin. Na novějších PCI Sound Blasterech se už vyskytovaly jen dvojité OZ, které byly plně využité, na AWE64 jsem také žádné plovoucí nenašel.

Upgrade wavetable ROM na zvukové kartě ESS AudioDrive ES1869F

      13.2.2024 Na VOGONS fóru jsem našel zajímavé vlákno uživatele Paar z Čech, pojednávající o výměně originální 1MB wavetable ROMky ES981P za 2MB FlashROM s kvalitnější bankou samplů na zvukových kartách ESS. Naprostá většina karet je osazená 1MB verzí nebo úplně bez ROMky, ale podařilo se mu získat originální 2MB ROM ES982A (vyskytuje se např. v některých noteboocích Compaq) a dumpnul její obsah pomocí programátoru TL866. Obsah dumpu pak lze nahrát do vhodné pinově kompatabilní 2MB FlashROM s 16-bitovou datovou sběrnicí na 5 V, např. MX29F1610.
      Jelikož jsem zrovna při oživování svého projektu LPC2ISA jednu takovou starou zvukovku vyhrabal, rozhodl jsem se mod také vyzkoušet. Objednal jsem 2 FlashROM čipy z AliExpressu za 75 Kč a k tomu přihodil redukci se ZIF paticí SOP44 na DIP44 za 105 Kč. Image jsem do pamětí nahrál programátorem LabProg-48LV. Při tom jsem zjistil, že jeden čip je mrtvý, nepřečetl ani flash ID, data četl samé wordy FF00h a nešel vymazat. Tak jsem ho u Číňana reklamoval a dostal full refund, za který jsem objednal další 2 čipy. Ty pro změnu přišly nesmazané, ještě s původním obsahem nějakého neznámého FW, ale aspoň fungovaly, budou se ještě hodit. Mám někde zabordelenou další zvukovku ESS AudioDrive ES1868 s 1MB ROM a line-out výstupem, tak jí pak taky někdy modnu. Při výměně ROMky za flashku je třeba mít na paměti, že původní ROM má nezapojené piny 1 a 44, které mají u flashky význam WE# a WP#. Tyto vstupy by se neměly nechávat plovoucí, takže jsem je připojil drátkem na nejbližší 5V napájení (na fotce ještě není). Otestoval jsem to pak v Doomu, hraje to pěkně...

ESS AudioDrive ISA	Flash MX29F1610 a redukce	programování FlashROM

ROM ES981P	odpájení ROM	připájení FlashROM

Rozšíření paměti RAM na zvukové kartě Sound Blaster AWE64 Value

      22.12.2025 Když jsem naposled v JLCPCB objednával velkou várku plošňáků i pro další členy OldComp.cz fóra, vzal jsem si pro sebe i jednu destičku modulu SIMMConn2, kterou navrhl uživatel Blaster. Ta je vylepšením původní verze SIMMConn (alternativa k originálnímu drahému modulu od Creative) od Xu Wanga a umožňuje na zvukovou kartu osadit 72-pinový SIMM o kapacitě 4 - 32 MB 60ns EDO/FPM RAM. Na verzi SB AWE64 Value je v základu jen 0,5 MB RAM, která se při použití rozšiřujícího modulu deaktivuje. Z větší paměti pak benefituje E-MU8000 DSP Advanced Wave Effect Synthesizer pro kvalitnější zvuk i 3D efekty a DirectSound akceleraci. Do RAM je možné nahrávat hotové či vlastní vytvořené soundfonty.
      Na modulu není mnoho součástek, ale je zde použita programovatelná logika typu PAL/GAL16V8, kterou je třeba naprogramovat odpovídajícím JEDEC souborem dle verze zvukovky (Value/Gold). Já jsem použil šuplíkový obvod GAL16V8D5LJ od Lattice, který jsem naprogramoval programátorem LabProg-48LV s vlastnoručně vyrobenou PLCC-DIL redukcí. Jelikož mám pouze SB AWE64 Value verzi, nedával jsem ani GALa do patice a rovnou ho připájel na desku. Jinak mi v šuplíkových zásobách chyběl pouze buffer SN74LVC1G126DBVR, na který jsem musel počkat z Mousera. Pro SIMMy se 2 paměťovými čipy by asi nebyl problém buffer nahradit drátkem. Patici pro 72-pin SIMM jsem použil ležatou, vypájenou z nějakého starého notebooku, která však neumožňuje osazení oboustranného SIMMu (čipy na dolní straně by kolidovaly s GALem). To mi nijak nevadí, počítal jsem s osazením jednostranného 16MB SIMMu s 8 EDO RAM čipy Siemens HYB5117405BJ-60, které jsou na seznamu ověřených čipů (větší kapacity mám stejně nacpané v různých motherboardech). Pro konkrétní SIMM je třeba nastavit konfiguraci jumperů JP1 a JP2, v mém případě jsem nastavil 1-2, 2-3 (2k refresh).

SIMMConn2 adapter-top	SIMMConn2 on SB AWE64

      12.1.2026 Osazený modul jsem nasunul na pin headery SB AWE64 a nejprve v DOSu otestoval paměť pomocí Creative Diagnostic Utility 4.05 (diagnose.exe). Asi po půl minutě skončil test úspěšně, viz níže. Pak jsem zkusil do RAM uploadnout nějaký soundfont a otestovat zvuk. Bohužel jak jsem zjistil, tak SB AWE64 nepodporuje standardní HW MIDI (MPU-401) wavetable syntézu na portu 330h (jako třeba zvukové karty ESS186x) a nemá ani header na WaveBlaster, ale používá k tomu softwarový emulátor (TSR) AWEUTIL 1.36, který můžeme za běhu loadnout příkazem aweutil.com /EM:GM (emulace dle standardu General MIDI) a unloadnout příkazem aweutil.com /U. Pozor, nekombinovat v autoexec.bat na jednom řádku s parametrem /S, který tam automaticky přidá instalátor SB ovladačů, ale v případě potřeby zapsat na 2 samostatné řádky: aweutil.com /S a aweutil.com /EM:GM. Při tom se načte automaticky do RAM soubor SFBANK\synthgm.sbk (cestu nelze specifikovat ručně), což je soundfont formátu v1.
      DOSový AWEUTIL bohužel neumí načítat novější a běžnější soundfonty ve formátu v2 (*.sf2). Dodávaný soubor synthgm.sbk spolu s ovladači má jen 35 kB, protože mapuje General MIDI nástroje na samply v onboard 1MB wavetable ROM. Hledal jsem nějaký lepší soundfont v1, ale našel pouze neoficiální 2MB verzi finegm.sbk (je třeba ho přejmenovat na synthgm.sbk, originální soubor si předem zazálohujte). UPDATE: našel jsem velkou sbírku soundfontů, kde jsou i některé ve formátu v1, např. 8MB fantagm2.sbk. Načítání větších sounfontů chvíli trvá (8MB se načte za cca 20 s). Soundfonty formátu v2 lze do v1 konvertovat pomocí komerčního programu Awave Studio (ke stažení je i 30-denní trial verze), avšak je třeba mít na paměti, že formát v1 nepodporuje tolik fíčur jako v2 a zkonvertovaný soundfont bude patrně znít jinak.
      Dále jsem zjistil, že emulace pomocí AWEUTIL TSR funguje pouze v realmode DOSových programech. AWEUTIL aktivuje na SB AWE32/64 hardwarově asistované přesměrování I/O portů, kdy při přístupu na MIDI port 330h karta generuje NMI (pokud je nasazený jumper MFBEN), které AWEUTIL v realmode zachytává a patrně po nějaké transformaci předává na porty nativní wavetable syntézy. Nevyužívá tedy možnosti zachytávání I/O portů v režimu V86. Problém je, že většina DOSových extenderů zachytí NMI v PMode a nepředá ho do realmode tak jako ostatní přerušení. Navíc na některých novějších základních deskách nemusí NMI fungovat správně. Když jsem zkusil pustit např. PMode Doom, tak zatuhnul při přehrání první noty. Vyzkoušel jsem tak alespoň realmode DOSový přehrávač DOSMid 0.9.8. Rozdíl s 2MB soundfontem nebyl moc znát, ale s 8MB už ano. Naštěstí řada PMode DOSových her podporuje nativní SB AWE32/64 wavetable syntézu na portu 620h, jenže ta zas používá fixně onboard 1MB wavetable ROM a nikoliv nahraný soundfont v RAM. Ještě zbývá možnost připojit externí MIDI syntezátor přes MPU-401 UART gameportu...
      Nakonec problém PMode her pomohl vyřešit upravený extender DOS32AWE 1.9 (původně DOS/32A 9.1.2) od uživatele georgel z VOGONS fóra, který přesměrovává NMI z PMode do realmode. Stačí spustit hru příkazem dos32awe hra.exe. Z nějakého důvodu georgel vložil do kódu umělé omezení zabraňující spuštění DOS32AWE ve V86 módu (od verze 1.3, ale ty starší zmizely) a nezveřejnil své upravené zdrojáky. Ty dal na GitHub až jiný uživatel na základě reverse engineeringu jeho binárky a původních zdrojáků DOS/32A. Já jsem jen upravil jeden podmíněný skok, abych vypnul kontrolu V86 módu. Moje upravená verze je zde. Má zkušenost je taková, že při použití JEMM386 se mi jednou stalo, že v Doomu II krátce po startu při prvním výstřelu se najednou hra a zvuk začal silně sekat a při opětovném spuštění to celé vytuhlo. Při dalším spuštění zas běžel Doom několik minut bez problémů. V případě použití standardního himem.sys a UMBPCI mi zatím k žádnému zatuhnutí nedošlo. Také jsem zjistil, že podobný efekt jako DOS32AWE má spuštění CWSDPMI serveru v rezidentním režimu (s parametrem -r, ale to dávalo dost nestabilní výsledky. Někdy Doom zatuhnul hned při startu, jindy cca do 10s po zahájení hry. Totéž jsem vyzkoušel i s HDPMI32, ale s ním mi Doom vytuhnul vždy při startu ("HU_Init: Setting up heads up display"). Takže doporučuji používat HIMEM a DOS32AWE.
      Pod Windows je situace lepší. Pomocí AWE Control Panel utility (awecp32.exe) je možné do RAM nahrávat i soundfonty v2. Použil jsem 8mbgmsfx.sf2 z CD ovladačů k SB Live! Tam byl rozdíl při přehrávání MIDI souborů znatelný. Windowsí ovladače též podporují emulaci General MIDI s využitím soundfontu v RAM v režimu V86, takže DOSové hry, které se s Windows snesou, je možné si vychutnat s lepším zvukem. Já jsem na testovacím retro PC zatím ještě nenainstaloval Windows 98, takže jsem testoval jen pod Windows NT 4.0 a ty se s DOSovýma PMode hrama moc nekamarádí.

DRAM test-start	DRAM test-progress	DRAM test-done

Výroba repliky CGA/MDA Graphics Gremlin pro 8b sběrnici ISA

      18.5.2021 Objevil tuto malou zajímavou OpenHW/SW grafickou kartičku Graphics Gremlin od TubeTime do 8-bitového ISA slotu, která emuluje CGA a MDA s výstupem na běžný VGA monitor (vedle klasického MDA TTL D-SUB 9 a analogového CINCHe), neb staré MDA a CGA CRT monitory se už blbě shání. Karta je založená na FPGA Lattice ICE40HX4K-TQ144 a lze do něj potenciálně nahrát i emulace jiných grafických karet. Ty stávající FPGA designy jsou napsané ve Verilogu a bohužel se zdá, že autor projekt opustil a nic nového už nevzniklo...
      30.11.2021 Když jsem objednával várku plošňáků v JLCPCB, tak jsem si k tomu přihodil i tuhle destičku. Bohužel je zrovna čipová krize a FPGA není zrovna k mání, ale Martin 8-bity už jednu osadil a rozchodil, tak si můžete počíst u něj. UPDATE: Yeo Kheng Meng vylepšil zapojení Graphics Gremlina o převodník TFP410 na HDMI výstup.
      6.7.2024 Tak už jsem posháněl potřebné součástky z Mouseru a kartu osadil. Už zbývá jen nalejt bitstream pro FPGA do SPI FlashROM...
      24.1.2026 Konečně jsem se dokopal k naprogramování bitstreamu do 1MB SPI FlashROM SST26VF080A. Jak jsem zjistil, tak můj program SPIPGM tuto paměť ještě neznal, takže jsem nejprve přidal podporu do nové verze 2.36. Následně jsem zjistil, že komunikace s pamětí na kartě přes LPT port je nějaká nespolehlivá, i když mám FPGA držené jumperem v resetu, takže by do toho nemělo kecat. Jelikož nemám zmíněný adaptér s FT2232H, nezbylo mi než paměť odpájet a naprogramovat samostatně, pak už nebyl problém. Image soubor isavideo.binm ve skutečnosti obsahuje 3 různé bitstreamy (emulace MDA s výstupem na MDA, emulace MDA s výstupem na VGA a emulace CGA s výstupem VGA a CGA CINCH), které se vybírají pomocí DIP switche 3 a 4.
      Karta generuje videosignál hned po zapnutí napájení i bez připojení na ISA sběrnici (zobrazí náhodná data z VRAM). Bohužel při prvním zapnutí v desce KMC-A419-8 jsem dostal nějaký rozbitý obraz, kde 2/4 resp. 4/8 obrazovky zobrazovaly náhodná neinicializovaná data. Zkoušel jsem to i v jiném MB a žádná změna. Vypadá to na nějaký problém kolem adresy A10. Koukal jsem na to napřed pod lupou, ale nic podezřelého nenašel. V práci jsem na to koukal pod zvětšovákem jak husa do lahve a pořád nic moc evidentního, sem tam nějaká smítka a jakási asi cínová šupinka pod nohama FPGA v dolní řadě pinů směrem k ISA slotu. Radši jsem celé FPGA znovu nafluxoval a pečlivě přepájel...

Graphics Gremlin	CGA POST screen	CGA mode 4	MDA text mode

      26.1.2026 Na druhý pokus už karta POSTovala OK, ale při bootu zas začla zobrazovat náhodné znaky různě po celé ploše obrazovky. Jak jsem zjistil, tak moc nezvládá přetaktovanou ISA sběrnici (což jsem ani netušil) a bezchybně mi fungovala max. na 10 MHz. Tam mi test VRAM v Norton Diagnostics prošel bez problému. Dále jsem vyzkoušel např. CGA verzi Doom8088, který se dal hrát krásně plynule nebo dualhead setup s Borland TurboDebuggerem, kde při spuštění s parametrem -do lze ovládat debugger na sekundárním MDA displeji a laděný program běží na primárním VGA displeji (karty používají jiné adresy VRAM a I/O portů, takže nekolidují). Kdysi jsem o téhle zajímavé možnosti četl, ale až teď jsem si to mohl reálně vyzkoušet.

NDiags VRAM test OK	CGA Doom8088

Výroba repliky grafické karty S3 765VL pro sběrnici VLB

      25.4.2024 Jelikož mám i pár historických MB se sběrnicí VLB (VESA Local Bus), ale VLBových grafických karet jen po málu (a dnes už se blbě shání), zaujaly mě na VOGONS fóru projekty replik VLB grafik od uživatele Madao - 968VL a 765VL. Jedná se více méně o reverse engineering zapojení grafických karet SPEA Mercury P64V s čipem S3 Vision 968 (86C968) a STB PowerGraph 64V VL s čipem S3 Trio64V+ (86C765). Na kartu 765VL by měl jít teoreticky bez dalších úprav osadit i S3 ViRGE (86C325), který jako poslední z S3 čipů ještě podporuje duálně sběrnice VLB a PCI, avšak bohužel kvůli sdílené funkci některých pinů (RAS1# je dostupný jen na PCI) může VLB verze obsluhovat pouze 2 MB místo 4 MB videopaměti, což je pro 3D akceleraci málo a navíc by se musely upravit i ovladače, které fungují jen na PCI verzi.

      27.5.2024 Madao publikoval na GitHubu výrobní podklady (GERBERy a BOM) pro kartu 765VL. Až se mi sejdou další PCB designy k výrobě, pošlu to hromadně do JLCPCB.

      27.6.2024 Dnes mi dorazila várka plošňáků z JLCPCB a mezi nimi je též 5 desek na repliku grafické karty S3 765VL ve zlacené povrchové úpravě (ENIG). O všechny 4 zbylé desky se přihlásili další zájemci, kterým je teď budu rozesílat (už jsou pryč).

plošňáky z JLCPCB	765VL PCB-top	765VL PCB-bottom

      1.7.2024 Vyhrabal jsem ze zásob jednu noname S3 Trio64V+ PCI kartu se 2 MB RAM a opatrně sfouknul horkovzduchem paměti a S3 GPU. Pro 765VL jsou použitelné jen 2 DRAM čipy 256 k x 16 ve velkém SOJ40 pouzdru. Přístupová doba by měla být 50 ns nebo kratší. Další dvě 35ns paměti jsem našel vypájené v zásobách. Občas se dají najít třeba ve starých CD/DVD mechanikách, kde slouží jako data buffer. Následně jsem se pustil do osazování. Při pájení pamětí v SOJ pouzdru je poněkud nepříjemné, že footprint má dost krátké pady, které z pod pouzdra moc nevyčuhují ven. Dále jsem v BOMu narazil na oříšek v podobě hradel 74F260 (dost obskurní dvojité 5-vstupové NOR hradlo) a 74AHC1G32 (mrňavé 2-vstupové hradlo v SC70-5), které nemám zrovna v šuplíku a nejsou ani na TME. Budu muset počkat na nějakou objednávku u Mousera.

dárcovská PCI karta	vypájené DRAM a GPU

      20.8.2024 Sehnal jsem zbylé součástky a doosadil desku. Pak už zbývalo jen napálit video BIOS do EPROM a otestovat. Vypálil jsem si oba dostupné image s 0 a 1 VLB wait state. Ten s 0 WS by měl být o něco rychlejší, ale má nějaké mouchy a nechodí na všech chipsetech, ten s 1 WS je o něco pomalejší a kompatabilnější. Karta naběhla na první zapnutí a testoval jsem ji zatím v základní desce Abit AB-AH4 s chipsetem SIS 85C471 a CPU intel 486DX-33. Mezi chováním 0 WS 1 WS ROMek jsem našel řadu rozdílů. 0 WS ROM je skutečně o něco rychlejší (7 MB/s banked mode, 11 MB/s LFB mode), VESA módy (testoval jsem svou utilitou VESATEST) běží s refresh rate 60 Hz, ve VESA mode listu jsou nesprávně reportované i videomódy, které jsou dostupné jen s 4 MB VRAM (pokud se takový mód nastaví, tak zčerná obrazovka) a při návratu z VESA módu do textového módu jsem dostal taky černou obrazovku nebo hlášení monitoru, že je mimo synchronizaci. 1 WS ROM je o něco pomalejší (5 MB/s banked mode, 10 MB/s LFB mode), VESA módy běží s refresh rate 75 Hz, ve VESA mode listu jsou správně reportované jen videomódy, které jsou dostupné s 2 MB VRAM a přepnutí z VESA módu zpět do textového módu proběhne korektně.
      Oba video BIOSy podporují pouze VBE 1.2. Pro rozšíření na VBE 2.0 (LFB režimy) je třeba použít patchnutou utilitu S3VBE20 3.18, která se nesnaží přeprogramovat bázovou adresu LFB. Jak jsem také zjistil, na mém LCD monitoru NEC 2190UXp nelze použít rozlišení 1600 x 1200, protože Trio64V+ ho zvládá jen v prokládaném (interlaced) režimu, což většině LCD nechutí. Na monitoru bliklo na zlomek vteřiny varování "out of sync" s nějakou nesmyslně vysokou frekvencí a obrazovka hned zčernala. Takže nejvyšší použitelné rozlišení je v mém případě 1280 x 1024 / 8bpp. V rychlosti jsem ještě otestoval výkon v Doomu (doom.exe -timedemo demo1) a proti ISA VGA OAK OTI067 jsem zaznamenal zrychlení z 9,31 na 14,24 FPS (o 53%). Předpokládám, že s rychlejším CPU bude rozdíl markantnější. A skutečně, při testu na ST 486DX4V100 jsem dostal 15,25 FPS s ISA VGA a 29,79 FPS s VLB VGA (rozdíl o 95%).

osazená 765VL-top	osazená 765VL-bottom

      15.10.2024 Vyzkoušel jsem tuto VGA v další VLB desce Alaris Leopard 486SLC2 rev. C, která je specifická tím, že používá CPU IBM 486SLC2 (50G7261) s 16-bitovou externí sběrnicí jako 386SX. VLBus byla primárně navržená jako 32-bitová a grafický čip S3 Trio64V+ 16-bitové přenosy nepodporuje, takže jsem dostal na POST obrazovce jen rozsypaný čaj. Jiná VLB VGA s čipem Cirrus Logic CL-GD5429-86QC tam fungovala správně, ale její benefit proti obyčejné ISA VGA díky úzké sběrnici nebyl v Doomu příliš patrný: 11,80 FPS vs 9,38 FPS. S FPU intel 387SX-25 dala v Quake pouze 1,4 FPS. Zde je screenshot a report z programu SpeedSys.

      1.4.2025 Zkusil jsem nainstalovat ovladače STB PowerGraph 64V+ pro Windows 3.11, ale když jsem spustil jeho setup.exe, dostal jsem chybovou hlášku "STB Vision Installation Utility: The current installation cannot be completed due to an unrecoverable error" a nazdar. Zkusil jsem i překopírovat instalační soubory na disketu a spustit z ní, ale nepomohlo to. Takže jsem nainstaloval jen holé ovladače z DOSu spuštěním programu setup.exe z adresáře Windows a zadáním cesty k souboru oemsetup.inf v adresáři s ovladačem na disku. Ten se nainstaloval bez problémů a Windows se spustily ve vybraném rozlišení.

Oprava 486 základní desky DataExpert EXP4044 s VLBusem

      24.8.2024 Jeden známý mi na radioburzu v Holicích donesl 2 vraky základních desek 386SX a 486, které měl připravené na součástky. Pro mě byla zajímavější 486 deska DataExpert EXP4044 ver 1.0 a chipsetem OPTi 82C895 a 82C602 se sběrnicí VLB / ISA, tak jsem se ji pokusil oživit. Deska byla nejen klasicky poleptaná od louhu z vyteklého NiCd akumulátoru, ale ještě jí někdo utrhl horní část ZIF patice na CPU. Po propípání spojů jsem zjistil, že byl přerušen akorát 1 prokov na cestě od konektoru klávesnice, tedy nic fatálního.
      S paticí na CPU to bylo poněkud horší, musel jsem ji opatrně vypájet horkovzduchem a pak odsát cín z jednotlivých prokovů. Naštěstí jsem měl v zásobě náhradní patici vypájenou z nějaké jiné desky, kterou jsem tam připájel, osadil CPU a mohl to zapnout. Deska však vůbec nePOSTovala. Zkontroloval jsem napětí a hodiny CPU, který mírně hřál. Dále jsem zkontroloval obsah EPROMky s BIOSem, ten se zdál být v pořádku. Ještě jsem tam zkusil zasunout testovací EPROMku s jednoduchým programem, který v nekonečné smyčce posílá kód na port 80h, ale taky nic.
      Očuchal jsem adresové, datové a řídicí piny EPROMky. Zjistil jsem, že adresy a data se mění, ale CS# a OE# jsou trvale neaktivní (log. 1). Dopípal jsem se, že signál CS# vede na pin 49 - ROMCS#/KBDCS# velkého čipu OPTi 82C895 a OE# na pin 68 - MEMR# malého čipu OPTi 82C602. Předpokládám, že chipset tyto signály generuje na základě signálů W/R#, M/IO# D/C# procesoru, tak jsem je také propípal i s dalšími piny okolo. Poblíž jsem pak našel odpojený adresní pin A3, který vedl na přerušený prokov pod paticí. Nevím, jestli už byl vadný před tím nebo jsem ho poškodil teplem při odpájení patice.
      Po jeho opravě kouskem tenkého drátku začala deska POSTovat, ale jen krátce. během vteřiny jsem zahlédl kódy: C1h, BEh, C6h. Dle seznamu POST kódů k Award BIOSu 4.50G má kód C6h význam "cache presence test" a měl by asi následovat kód 08h - test a inicializace dolních 64 kB paměti. Jeden známý mi doporučil použít alternativní MR BIOS pro stejný chipset, který by měl mít detailnější POST a beep kódy. Od něj jsem dostal POST kódy: 02h, 03h, 09h, 0Ah, kde poslední znamená "base 64K pattern test failure", takže nějaká chyba paměti. Zkoušel jsem 8MB SIMM modul vyjmout a dostal stejnou sekvenci kódů. Když jsem ho chtěl zasunout do druhé SIMM patice, všiml jsem si, že má 2 ohnutá pérka, která se dotýkala sousedních! Až příliš jsem se soustředil na poleptané cestičky PCB, že jsem si poškozené SIMM patice nevšimnul. Pérka jsem opatrně narovnal pinzetou a voalá, deska naběhla. Zasunul jsem do ní VGA S3 765VL, VLB IDE řadič, připojil HDD a prošel nastavení SETUPu (RAM a cache jsem nastavil na 0 WS). BIOS nemá problém ani s 20GB LBA diskem (Abit AB-AH4 zvládá jen 8 GB, více pak přes XTIDE). Nabotooval jsem do DOSu a spustil pár testů a her. VESATEST reportoval stejnou propustnost RAM - VGA jako s Abitkou, i výsledky v Doomu byly prakticky stejné.
      Dále mě napadlo, že když je na desce přichystaný footprint na CPU v pouzdru QFP208 (onboard CPU lze deaktivovat jumpery JP11, JP12, JP25), mohl bych tam zkusit připájet top speed procák AMD Am486DX5-133V16BHC alias Am5x86-P75, který se dá na AliExpressu koupit výrazně levněji než tytéž keramické PGA CPU. Snad mi nepřijde nějaký fake. Také pak musím pořešit VRM, protože na mé desce není osazený a z fotek se mi nikde nepodařilo identifikovat použité LDO či tranzistory Q1, Q1A, Q1B, ale to se dá pořešit nějakým jiným LDO z šuplíku. Horší může být to, že deska nepodporuje L1 Write-Back cache a odpovídající piny CPU, které byly definované až později na 486DX4, zde nejsou nikam zapojené. Tak snad CPU poběží aspoň v režimu Write-Through (s o něco nižším výkonem). Více info zde.

EXP4044 ver 1.0	poškozený a náhradní socket	po výměně socketu

      26.9.2024 Až teď jsem si všiml, já kokot starý, že ten footprint na desce není SQFP208, ale pouze PQFP196 pro 486SX. Pinouty jsou totálně odlišné, takže tam objednaný CPU nepůjde připájet :( To mě kapánek nasralo, ale pokusil jsem se tu negativní energii přetavit do vytvoření interposeru, který by umožnil tento SMD CPU strčit do PGA patice. Částečně jsem na to zrecykloval už dříve vytvořený interposer pro Pentium MMX Tillamook. Díky tomu, že 486 má výrazně méně nožiček jak Pentium a jsou v hrubším rastru, tak to šlo naroutovat výrazně rychleji a vystačil jsem se standardními prokovy 0,3/0,6 mm. Deska je 4-vrstvá, kde vnitřní vrstvy tvoří souvislé VCC a GND planes. Od doby, co JLCPCB nabízí výrobu 2 i 4-vrstvých destiček za 2$, tak stejně nemá cenu vrstvama šetřit a souvislá nízkoimpedanční zem je vhodná pro stabilitu, s VCC plane navíc tvoří vestavěný kondenzátor. Díky tomu, že piny 486 jsou v regulérní mřížce 100 mil, tak jako PGA nožičky půjde použít běžná pinová lišta. Akorát vnitřní řadu budu muset ucvakat a připájet jako SMD.

PCB layout	3D model

      30.9.2024 Dnes jsem PCB layout dotáhnul do konce a poslal ho do výroby k JLCPCB. Měl jsem na výrobu pouze tento jeden PCB design, tak jsem byl zvědav, kam se dostanu s cenou poštovného a skutečně je to o dost levnější než u více desek. Vybral jsem dodací službu "Global Standard Direct Line" a zaplatil: 2$ za výrobu PCB, 1,55$ za dopravu a 0,75$ za poplatky a cla, celkem tedy 4,30$.
      Dále jsem se pídil po použitém typu neosazeného LDO pro CPU VRM. Propípal jsem zapojení všech 3 footprintů:
Q1: 1 - ADJ, 2 - Vin, 3 - Vout; k tomu jsem nenašel žádný odpovídající LDO, všechny 3-pinové mají pin 2 jako výstup a pin 3 jako vstup.
Q1B: 1 - Vin, 2 - Vout, 3 - GND, 4 - ADJ; podle tipu od Tomáše by to mohl být Sharp PQ30RV2 a šel by též použít KA278R33, který má na pinu 4 místo feedbacku ovládání ON/OFF#.
Q1A: 1, 2 - Vin, 3 - GND, 4 - Vout, 5 - ADJ; šel by použít SPX29302. Zpětnovazební odpory děliče jsem naměřil 274 Ω mezi Vout a ADJ, 430 Ω mezi ADJ a GND. Později jsem našel zapojení VRM na jednom ruském fóru, kde někdo úspěšně použil LDO LM1084-ADJ na pozici Q1A.

      2.10.2024 Z šuplíku jsem vyhrabal výše zmíněný LDO KA278R33 a připájel ho na desku na pozici Q1B. Pin 4 (ON/OFF#) jsem ohnul a připájel ho k pinu 1 (Vin). Přenastavil jsem jumpery pro 3,3V CPU (BTW na PQFP196 footprint jde stále 5 V napájení) a vyzkoušel desku s CPU ST 486DX4V100. BIOS ho detekoval jako Cx486DX-S na 66 MHz, ale běžel správně na 100 MHz. S VGA S3 765VL jsem otestoval rychlost v Doomu, která se proti intel 486DX-33 zvýšila více než dvojnásobně na 29,79 FPS a v Quake jsem dostal 8,0 FPS v 320 x 200, resp. 3,5 FPS ve VESA 2.0 LFB módu 640 x 480. Zde je screenshot a report z programu SpeedSys.
      Také mi dnes z AliExpressu dorazil CPU. I přes to, že byl dobře zabalený v plastovém rámu, tak měl na jedné straně všechny piny ohnuté do boku. Následně jsem na Číňanovi uhádal slevu 49 Kč a piny srovnal pinzetou. Pro kontrolu, jestli čip není úplně dummy/fake, jsem propípal VCC a GND piny podle datasheetu a překvapilo mě, že 4 z 8 rohových GND pinů, se tváří jako nezapojené a taktéž jsem našel 1 či 2 VCC piny u kraje, které byly v luftu. Jinak další piny tak nějak odpovídají datasheetu. Tak jsem zvědav, jestli bude CPU funkční a co je vlastně uvnitř za křemík...

Am5x86-P75 CPU	Am5x86-P75 CPU

      21.10.2024 V pátek mi přišly plošňáky na interposer z JLCPCB. Koukám, že jsem zapomněl zamaskovat prokovy, ale to nevadí. Dnes jsem koupil v GME oboustranné pinové lišty na PGA nožičky a večer se pustil do osazování. Jelikož by vnitřní řada pinů kolidovala s pady SMD pouzdra CPU nahoře, musel jsem vnitřní řadu pinů udělat jako SMD na spodní straně. SMD piny jsem jednoduše vyrobil uštípáním kratších a tlustších kolíků pinové lišty. Konce jsem pocínoval a po pečlivém zarovnání na plošňák je připájel tenčím hrotem mikropájky z boku. Střední a vnější řadu pinů jsem zapájel klasicky jako THD. Aby piny seděly v rastru, zastrčil jsem je před zapájením do precizní patice PGA168. Nakonec jsem na horní stranu destičky připájel SMD CPU a 10 blokovacích kondíků 100 nF, 10 µF a 22 µF o celkové kapacitě cca 70 µF.

PCB top, bottom	PCB top	PCB bottom	PCB pins-side

      Po vložení mého výtvoru do patice na MB a zapnutí jsem napjatě sledoval displej POST karty, ale nic se neobjevilo. Začal jsem měřit piny a zjistil, že některé visí v luftě, což bylo způsobeno špatně připájenýma nožičkama TQFP pouzdra CPU. Po důkladném propájení a kontrole pod zvětšovákem už deska naběhla a BIOS CPU detekoval jako "80486DX/2" na 100 MHz (při nastaveném násobiči 3x). Po přejumperování násobiče na 2x CPU naběhl na 133 MHz. Samotný CPU ani moc nehřeje, zato LDO se při zátěži rozpálí tak, že na něm neudržím prst, což mi patrně způsobuje nestabilitu, že se občas systém náhodně restartoval či zatuhnul. Také budu muset vymyslet nějakou alternativní sponu na uchycení chladiče k ouškám ZIF patice, protože CPU s interposerem je vyšší než běžný PGA CPU.
      Tento CPU už podporuje instrukci CPUID, takže ho detekuje i můj program CPUID. S VGA S3 765VL jsem otestoval rychlost v Doomu, která se proti intel 486DX-33 zvýšila zhruba 3x na 40,91 FPS a v Quake jsem dostal 12,0 FPS v 320 x 200, resp. 5,3 FPS ve VESA 2.0 LFB módu 640 x 480. Zde je screenshot a report z programu SpeedSys.

Am5x86 CPU v MB	Am5x86 CPU s chladičem	Award BIOS SETUP

      22.10.2024 Chladič na LDO jsem vyměnil za vyšší, že už se na něm dá udržet ruka a pomohlo to stabilitě na 133 MHz. Dále jsem zkusil jít výše na 160 MHz (40 MHz FSB), ale systém byl nestabilní a tuhnul při spouštění programů v DOSu. Zatím co na 133 MHz mi fungovalo všechno na nejrychlejší časování s 0 wait states pro RAM (3-2-2-2) i L2 cache (2-1-1-1), tak na 166 MHz jsem musel prodloužit časování RAM na 1WS (3-2-2-2) a L2 cache na 1WS (2-2-2-2), abych byl schopen dokončit benchmark v Quake. To však výrazně degraduje propustnost paměti a tak efekt zrychlení při přetaktování nebyl příliš výrazný. Podezírám LDO s fixním napěťovým výstupem, že má kvůli vnitřní zpětné vazbě horší dynamickou odezvu, než by měla nastavitelná verze s feedback pinem, který patrně snímá napětí blíže CPU. Zde jsou shrnuty benchmarky výše zmíněných 386 a 486 systémů:

MB	CPU	fCPU	fFSB	L1	L2	Speedsys CPU/MemBW	VESATEST	Doom1	Quake 320/6402
Panther II 386SX	intel Am386SX-20	20 MHz	20 MHz	0 kB	0 kB	CPU: 3,77 / 30,82 MB/s	2 MB/s	1,84 FPS	0,5 / - FPS
TI JCI-S1S H	AMD Am386SX-25	25 MHz	25 MHz	0 kB	0 kB	CPU: 4,13 / 32,53 MB/s	2 MB/s	2,31 FPS	- / - FPS
AB-FU3	AMD Am386DX-33	33 MHz	33 MHz	0 kB	64 kB	CPU: 5,80 / 71,28 MB/s	3 MB/s	6,08 FPS	1,6 / - FPS
AB-FU3	AMD Am386DX-33	33 MHz	33 MHz	0 kB	128 kB	CPU: 5,80 / 71,28 MB/s	3 MB/s	6,11 FPS	1,6 / - FPS
SY-015G	AMD Am386DX-40	40 MHz	40 MHz	0 kB	8 kB	CPU: 7,03 / 85,45 MB/s	4 MB/s	7,21 FPS	1,9 / - FPS
KMC-A419-8	AMD Am386DX-40	40 MHz	40 MHz	0 kB	256 kB	CPU: 7,26 / 48,20 MB/s	5 MB/s	7,53 FPS	2,0 / - FPS
SY-015G	TI TX486DLC-40	40 MHz	40 MHz	1 kB	8 kB	CPU: 10,40 / 115,45 MB/s	4 MB/s	10,68 FPS	2,4 / - FPS
KMC-A419-8 (WT)	TI TX486DLC-40	40 MHz	40 MHz	1 kB	256 kB	CPU: 10,85 / 51,75 MB/s	5 MB/s	-	- / - FPS
KMC-A419-8 (WB)	TI TX486DLC-40	40 MHz	40 MHz	1 kB	256 kB	CPU: 10,85 / 51,75 MB/s	5 MB/s	11,70 FPS	2,5 / - FPS
Leopard 486SLC2	IBM 486SLC2	50 MHz	25 MHz	16 kB	128 kB	CPU: 13,78 / 22,82 MB/s	-	11,80 FPS	1,4 / - FPS
AB-AH4	intel 486DX-33	33 MHz	33 MHz	8 kB	256 kB	- / -	10 MB/s	14,24 FPS	- / - FPS
SY-025D2	intel 486DX-33	33 MHz	33 MHz	8 kB	256 kB	CPU: 12,44 / 35,24 MB/s	11 MB/s	14,90 FPS	4,1 / 1,7 FPS
EXP4044	intel 486DX-33	33 MHz	33 MHz	8 kB	256 kB	CPU: 12,38 / 36,90 MB/s	12 MB/s	14,77 FPS	4,0 / 1,6 FPS
Hippo 10 (WT)	intel 486DX-33	33 MHz	33 MHz	8 kB	256 kB	CPU: 12,43 / 82,39 MB/s	14 MB/s	15,26 FPS	4,1 / 1,6 FPS
Hippo 10 (WT)	intel 486DX-40	40 MHz	40 MHz	8 kB	512 kB	CPU: 14,92 / 99,10 MB/s	15 MB/s	18,39 FPS	5,0 / 2,0 FPS
Hippo 10 (WT)	UMC U5SX-40	40 MHz	40 MHz	8 kB	512 kB	CPU: 21,75 / 103,45 MB/s	15 MB/s	21,80 FPS	0,6 / - FPS4
Hippo 10 (WT)	ST 486DX4V100	100 MHz	33 MHz	8 kB	256 kB	CPU: 39,69 / 89,62 MB/s	14 MB/s	31,95 FPS	8,8 / 3,7 FPS
Hippo 10 (WB)	ST 486DX4V100	100 MHz	33 MHz	8 kB	256 kB	CPU: 40,11 / 89,61 MB/s	14 MB/s	32,33 FPS	8,8 / 3,7 FPS
EXP4044	ST 486DX4V100	100 MHz	33 MHz	8 kB	256 kB	CPU: 39,95 / 38,39 MB/s	12 MB/s	29,79 FPS	8,0 / 3,5 FPS
Hippo 10 (WT)	AMD Am5x86-P75	133 MHz	33 MHz	16 kB	256 kB	CPU: 48,01 / 89,52 MB/s	14 MB/s	42,30 FPS	13,0 / 5,3 FPS
Hippo 10 (WB)	AMD Am5x86-P75	133 MHz	33 MHz	16 kB	256 kB	CPU: 49,74 / 89,51 MB/s	14 MB/s	45,82 FPS	13,3 / 5,6 FPS
Hippo 10 (WB)	AMD Am5x86-P75	133 MHz	33 MHz	16 kB	512 kB	CPU: 49,74 / 89,51 MB/s	14 MB/s	47,65 FPS	13,8 / 5,7 FPS
EXP4044	AMD Am5x86-P75	133 MHz	33 MHz	16 kB	256 kB	CPU: 47,80 / 38,35 MB/s	12 MB/s	40,91 FPS	12,0 / 5,3 FPS
EXP4044	AMD Am5x86-P75	160 MHz	40 MHz	16 kB	256 kB	CPU: 57,64 / 46,24 MB/s	13 MB/s	46,25 FPS	14,4 / 6,2 FPS
EXP40443	AMD Am5x86-P75	160 MHz	40 MHz	16 kB	256 kB	CPU: 57,52 / 46,24 MB/s	15 MB/s	48,30 FPS	14,4 / 6,4 FPS
Hippo 10 (WT)	AMD Am5x86-P75	160 MHz	40 MHz	16 kB	256 kB	CPU: 51,58 / 107,80 MB/s	15 MB/s	47,16 FPS	14,8 / 6,1 FPS
Hippo 10 (WB)	AMD Am5x86-P75	160 MHz	40 MHz	16 kB	0 kB	CPU: 59,72 / 118,16 MB/s	16 MB/s	50,38 FPS	15,4 / 6,6 FPS
Hippo 10 (WB)	AMD Am5x86-P75	160 MHz	40 MHz	16 kB	256 kB	CPU: 59,71 / 107,80 MB/s	15 MB/s	53,82 FPS	15,8 / 6,7 FPS
Hippo 10 (WB)	AMD Am5x86-P75	160 MHz	40 MHz	16 kB	512 kB	CPU: 59,71 / 107,80 MB/s	15 MB/s	52,96 FPS	16,3 / 6,8 FPS
NexGen NxVL	Nx586-P90	84 MHz	42 MHz	32 kB	256 kB	CPU: 66,51 / 223,96 MB/s	12 MB/s	38,46 FPS	0,9 / - FPS4

RAM: 4 x 4 MB 60 ns 30-pin FPM SIMM / 1 x 16 MB 60 ns 72-pin FPM SIMM
VGA na KMC-A419-8, JCI-S1S H a Panther II: S3 Vision 928 (ISA @20MHz, VBE 1.2 bank-switched)
VGA na Alaris Leopard 486SLC2: Cirrus Logic CL-GD5429-86QC (VLB, VBE 1.2 bank-switched)
VGA na Abit AB-AH4, Soyo SY-025D2, DataExpert EXP4044, Hippo 10, NxVL: S3 765VL 1 WS ROM (VLB, VBE 2.0 LFB)
Na Octek Hippo 10 testováno s L1 cache Write-Through / Write-Back a L2 cache Write-Back a bez L2 cache
1 - Doom v DOSu, 320x200, "-timedemo demo1"
2 - Quake v DOSu, 320x200 / 640x480, "timedemo demo1.dem"
3 - DataExpert EXP4044 a VGA S3 765VL s 0 WS ROM
4 - Quake běžel na Nx586 a U5SX s emulátorem FPU Q87X 4.13

      17.11.2024 Vytáhnul jsem osciloskop, abych se podíval na zvlnění napájecího napětí procesoru Vcore a vyřešil problém s nestabilitou. Frekvenci FSB jsem nastavil zpět na 33 MHz. S fixním LDO KA278R33 jsem naměřil zvlnění při zátěži ve Quake 530 mVpp a poklesy někam ke 3,0 V (měřil jsem přímo na horní straně PCB interposeru mezi Vcore pinem a GND přilehlého jumperu JP38). Napřed jsem zkusil vyměnit 1 tantal 10 µF se změřeným ESR 0,4 Ω za low-ESR elyt 100 µF se změřeným ESR 0,1 Ω, ale nemělo to prakticky žádný vliv. Napadlo mě, že regulátor s fixním napětím, který si bere zpětnou vazbu přímo uvnitř obvodu, se asi bude chovat dynamicky hůře, než LDO s ADJ vstupem, který je krmený z děliče blíže CPU a může tak reflektovat poklesy napětí na vedení.
      Našel jsem v šuplíku LDO LT1587, který je pinové kompatabilní s LM1084-ADJ a připájel ho na pozici Q1A. S výchozími hodnotami odporů děliče jsem naměřil na prázdno napětí 3,28 V. Při zátěži však byl výsledek měření překvapivě horší. Zvlnění se zvětšilo na 640 mVpp a poklesy k 2,86 V. Zkusil jsem tedy další LDO LX8383A-00, s nímž byl výsledek o něco lepší: zvlnění 488 Vpp a pokles k 2,92 V.
      Je evidentní, že pro úspěšné přetaktování bude třeba napětí zvýšit úpravou děliče. To jsem provedl změnou horního odporu R63 z 270 Ω na 240 Ω, abych získal 3,5 V. Stabilita se zvýšila tak, že se mi na 160 MHz (40 MHz FSB) s nejrychlejším časováním RAM a L2 cache podařilo dokončit timedemo benchmark ve Quake, ale při druhém kole už crashnul a ve VESATESTu jsem dostával jen černou obrazovku. Přistoupil jsem k dalšímu zvýšení napětí na 3,7 V změnou R63 na 220 Ω. Přímo na blokovacím kondu na interposeru s CPU jsem naměřil reálně 3,45 V, což ukazuje na nezanedbatelný úbytek napětí na vedení od LDO. S tímto Vcore už zdá se běží vše stabilně tak jak má. Ještě jsem vyzkoušel otestovat Doom a Quake s použitím 0 WS ROMky ve VGA S3 765VL a u Doomu dostal asi o 2 FPS více, u Quake se to moc neprojevilo (tam nestíhá CPU).

KA278R33 3,3V DC	KA278R33 3,3V AC	LT1587 3,3V DC	LX8383A-00 3,3V DC	LX8383A-00 3,5V DC

      Chladiči na LDO jsem musel dole částečně odfrézovat žebra, protože při otočené montáži pouzdra LDO na pozici Q1A kolidoval s jumpery JP45 a JP46. Na CPU jsem přidělal menší černý chladič z nějakého starého síťového switche a připevnil ho sponou vyrobenou z ocelového drátku, která je zaháknutá za ouška Socketu 3. Chladič se ani moc nehřeje, při testování jsem na něj jen foukal větráčkem z PC zdroje ležícího vedle.

      5.6.2025 Pohledem do datasheetu chipsetu OPTi 82C895 jsem zjistil, že podporuje až 512 kB direct mapped L2 cache. I když se manuál k desce o této možnosti nezmiňuje, tak na pozicích U1 - U4 jsou osazeny dlouhé patice DIL32, které fyzicky umožňují zastrčit 128kB cache SRAM čipy. Dále je v datasheetu zmíněno, že jsou podporovány 2 banky cache s prokládáním nebo 1 banka bez prokládání (až 4 x 128 kB). Zkusil jsem tedy osadit 4 nové 128kB čipy + 32 kB tag a otestoval všechny možné kombinace jumperů JP13, JP27, JP28, JP29, ale nepodařilo se mi rozchodit 512 kB. Systém buď vytuhnul po testu RAM nebo nedetekoval žádnou L2 cache. Je divné, že nefungovala ani 1-banková kombinace 128 kB. Nakonec jsem multimetrem zjistil, že v DIL32 paticích nejsou zapojené piny A16 (2. pin v levé řadě, A15 a VCC zapojené jsou).
      Na velikosti L2 cache také záleží, jakou velikost RAM je možné cachovat (64 kB cache + 8 kB tag - 16 MB RAM, 128 kB cache + 8 kB tag - 32 MB RAM, 256 kB cache + 32 kB tag - 64 MB RAM, 512 kB cache + 32 kB tag - 128 MB RAM). Doporučené přístupové doby cache SRAM čipů pro 33 MHz FSB a časování 2-1-1-1 burst čtení, 0 WS zápis jsou 15 ns pro tag a 20 ns pro ostatní čipy. Pro 40 a 50 MHz FSB a stejné čipy je nutno prodloužit časování na 3-2-2-2 burst čtení, 1 WS zápis. Časování pro rychlejší čipy datasheet neuvádí.
      Chipset dokonce podporuje L1 cache v režimu Write-Back, ale návrháři desky se na to vykašlali a nepropojili na CPU socket některé důležité signály, jako např. CACHE#, INV a HITM# (Hit Modified Line), takže CPU nemůže správně provést Write-Back cyklus (došlo by porušení koherence cache). Proto ani SETUP nenabízí tuto volbu pro L1 cache. Je tedy zřejmé, že tato deska nevyužívá naplno potenciál použitého chipsetu.

Oprava 486 základní desky Octek Hippo 10 s VLBusem

      2.3.2025 Posledním bonbónkem ze strahovské nadílky byla základní deska Octek Hippo 10 s chipsetem UMC UM8498F. Na svou dobu vypadá docela moderně vybavená, neboť už má na sobě integrovaný 2-kanálový IDE řadič disků a disketovky, 2 x COM, 1 x LPT a 1 x game port. Deska má 2 VLB a 4 ISA sloty, 4 72-pinové SIMM patice, podporuje FSB do 50 MHz, CPU s duálním napájením a umožňuje osadit až 512 kB L2 Write-Back cache.
      Deska napřed vůbec nePOSTovala, až jsem pohledem zjistil, že si z ní nějaký bastlíř vypájel 14,318MHz krystal. Po jeho navrácení začla nabíhat, ale nefungovala klávesnice, protože louh vyteklý z akumulátoru sežral všechny cestičky na PCB pod ním a u DIN konektoru. A to velmi důkladně, že jsem měl dost problémy zjistit, co kam vedlo. Nakonec se mi to podařilo nějak nadrátovat a klávesnice se rozběhla, ale nejsem si 100% jistý, že jsem vše propojil správně. Deska se totiž chová divně po zapnutí: pokud byla dlouho bez proudu, tak někdy nechce POSTnout, ale když šťouchnu do HW resetu, tak spolehlivě naskočí. Když ji vypnu jen na pár minut a znovu zapnu, tak naběhne normálně. Za běhu se přitom chová zdá se stabilně. UPDATE: toto podivné chování po pár dnech samo odeznělo a deska teď nabíhá normálně.

Octek Hippo 10	oprava PCB	Award BIOS setup

      Na desce byl v EPROMce starý Award BIOS z 10.11.1994 a tak jsem tam hned napálil poslední verzi BIOSu z 9.1.1996. Desku jsem nejprve testoval s CPU intel 486DX-33. Když jsem tam chtěl strčit něco rychlejšího a začal zkoumat, jak se nastavuje napětí CPU, tak jsem zjistil, že moje revize 1.01 vůbec nemá v manuálu zmiňovaný blok jumperů JP53-56. Jsou zde pouze relevantní jumpery JP46 a JP48. Na desce je lineární regulátor napětí realizovaný obvodem TL431 a MOSFETem SMP50N06-25 podobného zapojení jako toto. Dalším zkoumáním jsem zjistil, že jumper JP46 je zapojený na referenci a GND a JP48 na referenci a Vout. Připojením externího odporu na JP46 by se mělo Vout zvýšit a odporem na JP48 naopak snížit. Když jsem JP48 zkratoval propojkou, kleslo výstupní napětí na hodnotu reference, tj. 2,5 V. Co mě však zmátlo, že deska implementuje nějakou autodetekci CPU s duálním napájením a pokud v patici není žádný CPU, tak tam posílá natvrdo 5 V (na gate MOSFETu je pak +12 V). Když jsem do patice zastrčil CPU ST 486DX4V100, tak se automaticky napětí změnilo na 3,5 V a nenašel jsem jinou možnost jak ho jumpery změnit.
      Při pohledu na prázdné patice cache nastalo zklamání, jelikož jak jsem zjistil, pro dosažení 512 kB je třeba osadit 4 delší 128kB čipy, které bohužel nemám (resp. mám pouze v SMD provedení). Cache je totiž rozdělená do 2 banků, kde bank 0 má delší patice DIL32, které pojmou 32 / 64 / 128kB čipy a bank 1 má kratší patice DIL28, které pojmou pouze 32kB čipy. Osadil jsem tedy 9 32kB čipů W24257AK-15 (celkem 256 kB) a zkusil objednat z Alíku nějaké recykláty W241024AK-15 za 95 Kč. Při testech nastalo druhé zklamání, když jsem zjistil, že volba režimu cache Write-Through/Back jaksi nic nedělá a výsledky jsou prakticky stejné. Nicméně i tak deska podala o trochu lepší výkon jak DataExpert EXP4044, výsledky testů jsem přidal do tabulky výše.
      Nakonec jsem do desky strčil svůj nejrychlejší CPU AMD Am5x86-P75. Při nastavení jumperů dle AMD 486DX4 dával ve SpeedSysu nějaké podivně retardované výsledky. Manuál se samozřejmě o jeho existenci vůbec nezmiňuje, nicméně BIOS obsahuje string "Am5x86-P75", takže se s ním počítá. Zkusil jsem ho tedy najumperovat podle nějakého dodatku jako pro Cyrix 5x86 (JP32: 1-2, JP33: 1-2,3-4, JP34: 1-2,3-4, JP35: 1-2, JP36: 3-4,5-6, JP37: 1-2,4-5) a BIOS ho pak skutečně detekoval jako "Am5x86-P75-S" a výkon ve SpeedSysu se spravil. Avšak volba cache WB/WT v SETUPu opět neměla žádný efekt. Když jsem FSB posunul na 40 MHz, tak to vždy zatuhlo na začátku bootu DOSu z HDD (i když jsem všechna nastavení související s ISA a HDD přepl na nejpomalejší), budu muset napřed trochu zvednout napětí CPU na 3,7 V jako na desce EXP4044. Pak jsem i změřil, jak vypadá Vcore na osciloskopu při zátěži v Doomu a zvlnění je menší než na VRM desky EXP4044.

VRM 3,7V DC, Doom load	VRM 3,7V AC, Quake load

      5.3.2025 Napadlo mě zkusit propípat, kam vede pin WB/WT# (B13) z patice CPU a zjistil jsem, že je na 4. pinu jumperu JP37. Sousední 5. pin JP37 je na +5 V, takže propojením pinů 4 a 5 se aktivuje režim L1 cache Write-Back. A to natvrdo, takže volba v SETUPU na to nemá vliv. Pokud se 4. pin JP37 nechá nezapojený, je přes pull-down 10 kΩ připojený na GND a L1 cache je v režimu Write-Through (volba v BIOSu je zmražená na Write-Through). Aktuální režim cache lze ověřit např. DOSovou utilitou CHKCPU. V Norton SysInfo s WB brutálně nerealisticky poskočilo skóre ze 198 na 288 bodů. Ve SpeedSysu je rozdíl CPU mnohem méně výrazný, jen 49,74 vs 48,01 bodů. Výrazný skok je vidět v rychlosti přesunu dat (move) L1. V Doomu přidalo WB 3,5 FPS (8,25%) a v Quake jen 0,3 FPS (2,3%).

      6.3.2025 Samozřejmě jsem zkusil CPU také přetaktovat na 160 MHz (FSB na 40 MHz). Napřed jsem ale potřeboval zvednout Vcore, což se dalo snadno provést připojením odporu na piny jumperu JP46 (s hodnotou 220 kΩ jsem dostal 3,66V). Dále se ukázalo nutné zvýšit u L2 cache počet wait states z 0 na 1, jinak se bootování zaseklo vždy na úvodní hlášce "Starting MS-DOS..." To mě kapánek překvapilo, když na desce EXP4044 L2 cache zvládá 0 WS. Schválně jsem zkusil i prohodit cache SRAM čipy mezi deskami, ale nepomohlo to. Takže se musím holt spokojit s 1 WS, ale i tak se mi podařilo dosáhnout nového rekordu v Doomu a Quake, viz tabulka výše. Též přidávám report z programu CACHECHK V5. Zkusil jsem FSB i na 50 MHz, ale to ani nePOSTne (ani bez VLB VGA). Na desce použitý PLL obvod MX8315PC bohužel neumí generovat žádnou další frekvenci mezi 40 a 50 MHz. Teoreticky by se dal výstup CK (pin 8) přepojit na nějaký externí krystalový oscilátor (mám v zásobě frekvence 41,539; 42,192; 44; 45,158 a 48 MHz).
      Na další problém s časováním jsem narazil, když jsem zkusil do desky strčit dva 8-čipové (16MB) nebo jeden 16-čipový (32MB) paměťový modul, tak se to seklo při bootu. Musel jsem přepnout "DRAM Page Mode" z "Fast" na "Normal" nebo zvýšit počet DRAM wait states z 0 na 1, což zas ubralo trochu výkonu (rychlost čtení z RAM klesla z 40,2 MB/s na 33,3 MB/s; rychlost zápisu zůstala stejná). Domnívám se, že je to zvýšenou kapacitní zátěží paměťové sběrnice, neboť v případě 8-čipového modulu je každý bit zatěžován pouze 1 log. vstupem paměti, zatím co u 16-čipového modulu jsou na 1 bitu 2 log. vstupy paralelně. Větší kapacita vstupů pak více deformuje elektrické signály a našponované časování se rozpadne. To záleží na schopnostech chipsetu i PCB layoutu.
      Jelikož tato deska už podporuje úsporné režimy přes APM, vyzkoušel jsem, jestli se na CPU aktivuje SMM. Pro tento účel jsem dal na interposer LEDku na signál SMIACT# (pin C12). A skutečně při sepnutí suspend tlačítka na pinech JP43 se LEDka krátce blikne, na POST kartě se objeví kód D3h a CPU se asi 10x zpomalí. Při stisku nějaké klávesy opět velmi krátce blikne LEDka, na POST kartě se objeví kód FFh a CPU se zrychlí na původní úroveň.

      8.3.2025 Na VOGONS fóru padl nápad, že by se na této desce dal vyzkoušet jiný BIOS (Phoenix) pro desku ECS UM4981 AIO se stejným hlavním chipsetem UM8498F, který má v SETUPu volby režimu Write-Through/Back pro obě L1 a L2 cache. BIOS image jsem pokusně napálil do FlashROM AM29F010 a zasunul do desky. BIOS naběhl, ale záhy jsem narazil na řadu problémů, např. zatuhne při autodetekci HDD (musel jsem ručně nastavit user režim 47), vypisuje nějaké chyby neplatných I/O adres u portů a FDC, SpeedSys zatuhne na začátku ve fázi "Determining system contents... Memory type" a hlavně celý systém běží asi 10x pomaleji. Zkusil jsem aspoň benchmark v Doomu a dostal bídných 3,81 FPS a to nezávisle na zvoleném režimu L1 a L2 cache. Podobně mizerný výsledek 5,16 FPS dostanu s originálním Award BIOSem pokud vypnu L1 i L2 cache. Tento BIOS tedy cache vůbec neinicializuje a je tedy nepoužitelný.

      24.3.2025 Dnes mi dorazily 128kB cache SRAM čipy W241024AK-15 z AliExpressu. Vypadaly nepoužité, ale značení bylo neoriginální, pálené LASERem. Napřed jsem je otestoval v programátoru LabProg-48LV a zjistil, že 1 z 5 čipů selhal už při Device insertion testu a následné měření multimetrem potvrdilo, že spousta pinů nebyla vůbec připojená na křemík. Že by ty čipy přepouzdřovali do nových futrálů a přitom se jim pokazilo bondování vývodů? Jaké jsou skutečné dynamické parametry je ve hvězdách. Na Alíku jsem tedy nahlásil stížnost a požádal o částečný refund, který byl do druhého dne promptně vyřízen. Naštěstí mi stačí 4 funkční čipy, protože tag SRAM je zde jen 32kB.
      Vyměnil jsem tedy cache čipy na desce a přenastavil jumpery JP21: on, JP22: on, JP23: 1-2,3-4,5-6, JP24: 1-3. Po zapnutí BIOS správně detekoval velikost 512 kB L2 cache. Při testech na 33 MHz FSB fungovalo vše stabilně na nejrychlejší časování s 0 WS. V Doomu jsem si polepšil o 1,83 FPS (4%) a v Quake o 0,5 FPS (3,7%), v 640 x 480 už byl rozdíl jen nepatrný (0,1 FPS).
      Avšak při přetaktování FSB na 40 MHz jsem narazil na problémy se stabilitou, která se překvapivě projevila nikoliv v Quake (kde stačilo zvednout časování L2 cache na 1 WS jako dříve), ale v Doomu, který zatuhnul okamžitě při startu, resp. už při startu extenderu DOS/4GW, jenž nestihl ani nic vypsat. Pro úspěšné dokončení testu v Doomu jsem musel zvednout časování L2 cache na 1 WS 3-2-2-2, což se projevilo poklesem o 0,86 FPS proti 256 kB L2 cache s rychlejším časováním 1 WS 2-1-1-1. Výsledky jsem přidal do tabulky výše.

      9.5.2025 O kvalitě a dynamických parametrech čínských SRAM čipů jsem měl určité pochybnosti. Podařilo se mi sehnat čtyři 128kB SRAM čipy IDT (nyní Renesas) 71024S12TYG8 s přístupovou dobou 12ns ze spolehlivého zdroje. Akorát že jsou v SMD pouzdrech SOJ32 / 300 mil. Navrhnul jsem si tedy jednoduchou redukci na DIL32. Jelikož už JLCPCB nedělá u malých PCB cenový rozdíl mezi 2 a 4-vrstvou deskou, vložil jsem do vnitřních vrstev rozlitou měď GND a VCC a přidal malý blokovací SMD kondenzátor na spodní stranu pod SOJ32 pouzdro. Nicméně PCB lze vyrobit i jako 2-vrstvý, jen by se musely vývody kondenzátoru připojit k VCC a GND ručně drátkama. Vytvořil jsem si vlastní panelizaci po 4 kusech, abych se vešel do rozměru 5 x 5 cm a nechal tak vyrobit celkem 20 ks (rozřezal jsem je pak ručně pásovou pilou). Kdyby měl někdo zájem, mohu se podělit o přebytky.

      3.6.2025 Ve čtvrtek mi dorazily plošňáky z JLCPCB. Musel jsem ale ještě dokoupit 2-řadé pinové lišty na nožičky, takže jsem se k testování dostal až dnes. To bohužel přineslo velké zklamání, protože se ukázalo, že s těmito 12ns cache je MB při rychlejším časování úplně stejně nestabilní jako s těmi čínskými 15ns z Alíku, takže Číňan čipy asi označil pravdivě. Jako 32kB tag SRAM čip jsem v obou případech použil originál 12ns Winbond. Systém je stabilní až s pomalejším časováním 1WS 3-2-2-2, kdy je výkon mírně degradován pod úroveň 256 kB cache s rychlejším časováním. Zkusil jsem ještě zvýšit Vcore CPU na 4,0 V a povyměňoval pár elytů okolo (nebyly ani moc vyschlé), avšak nemělo to žádný vliv.

redukce SOJ32-DIL32 layout	PCB model	osazené PCB

      K chipsetu UMC UM8498F není dostupný žádný datasheet, ale je dost pravděpodobné, že řadič cache je konstruovaný stejně jako u chipsetu OPTi 82C895 na desce EXP4044. Čili, že dosahuje vyšší rychlosti s pomalejšími čipy pomocí dual bank interleavingu a při osazení jen 1 banky, kdy nemůže využít prokládání, tak už neumí rychlejší čipy využít. Na VOGONS fóru jsme došli ke stejnému závěru, ale zjistil jsem, že by bylo teoreticky možné rozšířit banku 1 na DIL32 patice (a dodrátovat příslušné signály), aby pobrala 128kB SRAM čipy a tím získat rychlejší 1 MB L2 cache s interleavingem. Uživatel pshipkov už takto jednu desku upravil.
      Dále jsem se dozvěděl, že pečlivým vybíráním SRAM čipů z větší skupiny (řádově 100 kusů) lze dosáhnout lepšího timingu na vyšších frekvencích FSB, přičemž nezáleží moc na tom, jestli je čip 12ns nebo 15ns, ale asi na tom, jak se shodují reálné dynamické parametry. To je ale časově dost náročná sranda kvůli pár FPS navíc. Prozatím jsem se vrátil k dual bank 256 kB L2 cache. Vyzkoušel jsem 15ns čipy různých výrobců a našel jsem určité rozdíly ve stabilitě. Např. s čipy Alliance AS7C3256-15PC mi při časování 1 WS 2-1-1-1 opakovaně crashoval Quake v timedemu, tak s čipy UMC UM61256FK-15 opakovaně procházel OK, i MemTest několik hodin OK, avšak při 0 WS to zatuhlo hned při bootu Starting MS-DOS...

      4.7.2025 Napadlo mě vylepšit stávající PCB design SQFP208 - PGA168 interposeru pro Am5x86 o spínaný DC-DC měnič s obvodem RT5789 s rychlou odezvou, který jsem umístil na spodní stranu destičky pod CPU. Předpokládám, že bych tak mohl snížit zvlnění Vcore při zátěži oproti lineárnímu VRM na desce a tím zlepšit stabilitu, případně i snížit potřebné Vcore. To by mohlo pomoci zejména u žravějších CPU jako je Cyrix 5x86. Také se tím vyřeší problém se základními deskami, které VRM nemají osazený nebo ho nemají vůbec. Výstupní napětí je nastavitelné odporovým děličem od 0,6 V a výstupní proud teoreticky až 6 A, záleží hlavně na kvalitě cívky. Gerber data jsem poslal do výroby k JLCPCB. Další CPU Am5x86 jsem si objednal opět na Alíku, ale původní prodejce ho už neměl skladem a našel jsem jen dražší za 285 Kč.

PCB layout v2	3D model v2

      21.7.2025 V pátek mi přišly plošňáky na interposer v2 z JLCPCB a dnes druhý CPU Am5x86 z Alíku. Přestože byl dobře zabalený v plastovém rámu, měl viditelně ohnuté 3 nožičky. A to jednu tak, že naopak dole nebyla zahnutá do roviny plošňáku, ale rovně trčela pod jeho úroveň, což se rozhodně nemohlo stát při balení, ale už při výrobě/recyklaci, kde se asi čipy znovu pouzdří. Pinzetou jsem nožičku opatrně dole ohnul a ostatní narovnal. Tento kus má na kovovém IHS docela pěkně vyvedený černý popisek.
      4 oboustranné pinové lišty z GME jsem měl už koupené v zásobě a tak jsem se večer pustil do osazování. Nejprve jsem na spodní stranu osadil spínaný DC-DC měnič a otestoval ho, že dává požadované napětí 3,6 V. Pak jsem připájel CPU, keramické kondíky a nakonec pinové lišty. Při 1. zapnutí jsem nedostal vůbec žádný POST kód. Musel jsem tedy proměřit všechny piny a zjistil, že byla nepřipájená nožička A10 na SQFP pouzdru (po šťouchnutí pinzetou se hýbala, ale nebylo to zrovna moc vidět). Po propájení nožičky už deska s CPU nastartovala. Zkusil jsem i přepnout FSB na 50 MHz, ale opět žádný POST kód, to bych musel jít s Vcore výše...

PCB top, bottom	Am5x86-P75 CPU	PCB top	PCB bottom

USB řadič s CH375 pro 8-bit ISA

      21.10.2025 Pro přenos dat je dnes přece jen pohodlnější používat větší, rychlejší a spolehlivější USB flashdisky než diskety. Avšak první nativní USB řadiče se začaly na základních deskách objevovat až na konci éry Pentií (Socket 7) a běžně se dají sehnat jen karty pro sběrnice PCI a PCI-E. Před časem jsem však objevil USB řadič pro 8-bit ISA od firmy Lo-tech založený na čínském čipu CH375. Jedná se o jednoduchý USB-host řadič s 8-bitovým paralelním rozhraním, který podporuje USB 2.0 low-speed (1,5 Mb/s) a full-speed (12 Mb/s) zařízení třídy mass-storage (nelze ho tedy použít pro myši, klávesnice, atd.). Pro připojení k ISA sběrnici stačí přidat dekodér I/O adres a pár dalších drobností. Karta řadiče je též vybavená paticí na EPROMkou, do které je možné vložit BIOS umožňující bootování z USB flashdisku. Lze ho koupit na AliExpressu za 409 Kč. Na podrobnou videorecenzi se můžete podívat zde.
      Bastlíř František Štefanec vytvořil vlastní PCB design v KiCADu vycházející z referenčního designu od výrobce čipu, který má na webu ke stažení. Já jsem jeho PCB design mírně upravil, aby bylo možné osadit i 64kB EPROM (27C512) a nahrát do ní ROMOS s mass-storage DOSovým ovladačem. K tomu jsem potřeboval na desku vměstnat pár další jumperů, což se nakonec povedlo. Také jsem mírně upravil rozměry desky na 100 x 50 mm, aby bylo možné nechat v JLCPCB provést sražení hran ISA konektoru (s deskama menšíma jak 50 mm v jednom směru mají problém z upnutím do frézky), kde jsem si nechal vyrobit 5 kousků. 5 čipů CH375 jsem objednal na AliExpressu za 58 Kč.

ISA-USB schéma	ISA-USB PCB layout	ISA-USB PCB model

      11.11.2025 Dnes mi přišla velká várka plošňáků z JLCPCB. Jeden jsem téměř kompletně osadil, akorát jsem neměl v zásobě USB ESD ochranu USBLC6-2SC6, kterou jsem provizorně přemostil 2 odpory 22 Ω. UPDATE: USB ESD čip dorazil z Mouseru, tak už je na svém místě. Jen upozorňuju na výběr USB-A konektoru, že existují 2 varianty s kontakty nahoře a dole (zrcadlově prohozené pořadí pinů) - zde je třeba osadit tu s kontakty dole. Při osazení špatné varianty dojde k přepólování a pravděpodobně zničení USB flashdisku! USB řadič jsem zasunul do jedné desky s CPU 386SX-20, kterou jsem zrovna testoval, a fungoval na první zapnutí.

plošňáky z JLC	osazený USB-ISA řadič

      29.11.2025 Jak už bylo patrné z recenzí jiných uživatelů, nelze od tohoto USB řadiče čekat žádnou raketovou rychlost, spíše o něco rychlejší disketu. Našel jsem a otestoval 2 verze DOSového ovladače ch375dos.sys. Ten lze zavést buď klasicky v config.sys nebo až po bootu pomocí utility devload.com a akceptuje 3 parametry, viz příklad: DEVICE=C:\ch375dos.sys @260 #0 %3. 1. parametr je bázová I/O adresa, která se musí shodovat s nastavením jumperu J2 na řadiči (možné hexa hodnoty: 230, 240, 250, 260). 2. parametr je IRQ, opět musí odpovídat nastavení jumperu J3 (možné hodnoty: 0-nepoužívat přerušení, 3, 4, 5, 6, 7). 3. parametr je IOspeed - jakási čekací prodleva pro I/O komunikaci s kartou (čím nižší hodnota, tím vyšší rychlost). Výchozí hodnota je 3 a při nižších hodnotách se mohou na některých systémech objevit nějaké problémy.
      Verze 2.0A se ukázala o něco pomalejší a patrně vůbec nepoužívá při přenosu IRQ, neboť se naměřené rychlosti v obou případech prakticky nelišily. Verze 1.9 mi nefungovala bez zapnutého IRQ jumperem (při detekci flashdisku jsem dostal chybu "error boot sector") a se zapnutým IRQ byl přenos rychlejší, nejvyšší rychlosti čtení 50,5 kB/s jsem dosáhl s parametrem IOspeed=0. Po zavedení ovladače se přiřadí USB flashdisku nové písmenko jednotky navazující na existující diskové oddíly (bez disku se přiřadí písmenko C:). Ovladač neřeší souborový systém, to přenechává na DOSu, takže se správnou verzí lze používat i FAT32.

IOspeed	ver. 2.0A, no IRQ	ver. 2.0A, IRQ 7	ver. 1.9, no IRQ	ver. 1.9, IRQ 7
3	28,63 kB/s	28,63 kB/s	-	32,99 kB/s
2	32,49 kB/s	32,49 kB/s	-	38,20 kB/s
1	37,01 kB/s	36,90 kB/s	-	44,77 kB/s
0	40,44 kB/s	40,33 kB/s	-	50,49 kB/s

ch375dos.sys USB read speed (715kB file), 386SX-20, 2 MB RAM, MS-DOS 7.10

      Dále jsem upravil 64kB disk image svého ROMOSu, do nějž jsem zahrnul ovladač verze 2.0A, MikroManažer, utilitu DynaLoad a config.sys, který ovladač natahuje. FreeDOS kernel je původní verze pro CPU 386 a vyšší. Tato verze ROMOSu je nakonfigurovaná pro emulaci diskové jednotky A: (disketovou jednotku jsem neměl připojenou), binárka je ke stažení zde. Napálil jsem ji do EPROMky 27C512 a nastavil potřebné jumpery. V této konfiguraci je jediná možná volba paměťové adresy na segmentu D000h. Po spuštění ROMOSu se ovladač natáhnul dle očekávání. S pomocí takto vybavené karty můžu USB ovladač přenést na disk libovolného retro PC, případně i naformátovat disk a nainstalovat OS.

Oprava základní desky Octek Panther II 386SX

      30.11.2025 Už od loňské radioburzy v Holicích mi doma ležela druhá deska od známého Octek Panther II 386SX rev. 1.01 s připájeným CPU intel 386SX-20, s chipsetem OPTi 82C283 a F82C206, se sběrnicí ISA. Bohužel byla docela brutálně poleptaná od louhu z vyteklého NiCd akumulátoru. Po zapnutí poslala pár POST kódů a skončila s chybou detekce paměti (kód 10h). Což se dalo čekat, protože louh natekl i pod DIL patice pamětí a možná trochu i pod patice SIMM.
      Původně jsem spíš uvažoval rozebrat desku na součástky, ale zkusil jsem tomu dát ještě šanci. Postupně jsem začal opravovat viditelně poškozené cestičky a prokovy. Někde bylo sežráno i několik cm spojů, takže jsem je musel nahradit izolovanými drátky. Také jsem musel odpájet DIN konektor klávesnice, který měl vevnitř sežraná pérka a spoje pod ním byly také sežrané. Také 2 krajní DIL patice pro RAMky měly sežrané některá pérka a musel jsem je vyměnit. Diod-testem jsem zkontroloval všechny piny krajních DIL patic, jestli někam vedou a našel několik přerušených spojů. Ty se mi podařilo postupně všechny vysledovat kam vedou a opravit je. Při výměně DIL patic se mi také pár spojů přerušilo v místě mezi padem a cestičkou (pouhým okem to ani nebylo vidět), tak jsem to musel též prodrátovat.
      Následně jsem zkusil do 2 krajních banků 0 a 1 osadil DILkové RAMky 44256 a 41256 a viola, rozběhl se boot, 1MB RAM OK. Vlezl jsem do SETUPu (zde použitý Mr. BIOS 1.0F vypadá docela zajímavě a atypicky), ale po cca 10s mi zmizel obraz a na POST kartě jsem si všiml, ze se trvale rozsvítil RESET. Na RESET vstup to nereagovalo a po vypnutí a zapnutí se to opakovalo. Když už jsem s tím strávil několik hodin práce, rozhodl jsem se to dotáhnout do konce. K tomu jsem musel detailně prozkoumat funkci resetovacího obvodu, jehož schéma jsem částečně překreslil, viz níže. Jak jsem zjistil, resetovací CMOS vstup chipsetu měl uhnilý prokov a jen si tak plaval ve vzduchu, takže po chvíli sám překlopil. Po opravě prokovu pro změnu deska nestartovala vůbec a visela v resetu. Bylo tedy třeba prozkoumat, jaké všechny podmínky se vyhodnocují, aby se RESET odbrzdil.
      Resetovací obvod je postavený na 4-násobném komparátoru LM339 z nějž jsou využity 3 se společnou referencí (na invertujících vstupech). Jeden komparátor (piny 9, 7, 14) snímá stav signálu Power Good z napájecího konektoru zdroje, ten byl překlopený správně. Další komparátor (piny 5, 4, 2) snímající stav RESET vstupu P1 (od tlačítka) byl blokovaný dalším komparátorem (piny 7, 6, 1), který snímá napájecí +5V větev přes dělič R49 a R50. Zde bylo na uzlu děliče cca 2,8 V. Problém byl v tom, že reference měla napětí 4,8 V, takže tento komparátor byl překlopený špatně. Jak jsem vysledoval, vstup reference měl vést na katodu klasického obvodu TL431C, jenže spoj uhnil a tak se na vstup reference odněkud dostávalo vyšší napětí přes R54. Po opravě spojů reference jsem naměřil předpokládané napětí 2,52 V, takže se komparátor snímající +5V větev překlopil správně a neblokoval druhý komparátor hlídají RESET a chipset se tak mohl rozběhnout.
      Nakonec jsem ještě diod-testem zkontroloval zapojení patic 30-pinových SIMMů a zjistil, že pin 4 (A0) je v luftu. Jelikož cestička k němu vede pod paticema, tak se mi ji nedařilo celou vysledovat, ale bylo jasné, že vede na signál A0 DIL patic. Tak jsem tam natáhl drátek a deska se rozběhla se 16 MB RAM ve čtyřech SIMMech. Ty mohou být bezparitní (BIOS si asi přítomnost paritního bitu sám detekuje), ale překvapivě musí být po čtyřech, i když má 386SX 16-bitovou sběrnici a obvykle takové desky fungují se 2 SIMMy jako 286-tky. Na této desce to ale se 2 SIMMy prostě nejelo v jakékoliv pozici. Po otestování jsem opravené spoje na horní i dolní straně přestříknul transparentním matným syntetickým lakem. Do desky jsem pak ještě loupnul matematický koprocesor 387SX a zbenchmarkoval obvyklým způsobem. V Quake jsem dostal "úžasných" 0,5 FPS a v Doomu stejně nepoužitelných 1,84 FPS. Jak je vidět, oproti 386DX je 16-bitová sběrnice prostě výrazný bottleneck...

Octek Panther II	detail	schéma resetu	po opravě-top	bottom

Oprava 386 základní desky Abit AB-FU3

      13.2.2026 Pustil jsem se do operace dalšího pacienta - základní desky Abit AB-FU3, kterou jsem loni dostal o Pepíka z bastlírny. Je osazena chipsetem od Chips & Technologies F82C351, F82C355 a F82C356, má PGA patice na CPU (s AMD Am386DX-33) a FPU (387DX / WTL3167), 32 - 256 kB Write-Through cache (s 64 kB) a až 32 MB RAM v osmi 30-pinových SIMMech. Chipset je dle značení určen max. pro 33 MHz FSB a krystalový oscilátor 66 MHz je na desce natvrdo připájený. Na první pohled byla deska taková odrbaná se zohýbanými piny, ulámanými zámky SIMM patic a už bez baterky, která nestihla napáchat větší škody.
      Po zapnutí deska vyhazovala ochranu zdroje, jelikož byl na -12V větvi proražený tantal, který ale nevystřelil. Tak jsem ho odpájel a deska poslala pár POST kódů a skončila na 13h - chyba detekce paměti. Snažil jsem se ručně přidržet SIMM moduly v paticíh, ale dál jsem se nedostal. Desku jsem pořádně prohlédnul, na rovnal různé ohnuté piny a propájel pár podezřele škrábnutých cest. Posunul jsem se na kód 33h a 3 pípnutí - taktéž chyba paměti. Vypájel jsem tedy rozlámané SIMM patice vyhřívanou odsávačkou a osadil náhradní vypájené z jiné desky. Jak jsem dále zjistil, deska vyžaduje pro úspěšný start paměťové moduly s paritou (i když se dá pak v SETUPu vypnout) a musí být jako první osazena banka 0. Navíc chipset nemá rád moje nové 4MB moduly (ani ty s paritou). Ani s nejpomalejším časováním a různýma volbama refreshe. Dochází přitom ke generování NMI a MemTest se okamžitě restartuje. Když jsem je vyměnil za 8 x 1MB SIMMy, tak problémy s pamětí zmizely.

Abit AB-FU3	AB-FU3 bez KBC	Chipset SETUP

      Další problém byl, že deska odmítala startovat s běžnou VGA kartou (zastavila se na kódu 2Ch), ale s 8-bitovým Graphics Gremlinem (CGA/MDA) normálně naběhla. Všiml jsem si zoxidovaných pinů na KBC a jeho patici. Ta měla pérka už v horším stavu a tak jsem se ji rozhodl vypájet a vyměnit za jinou precizní. Piny KBC jsem očistil tvrdou gumou a pomohlo to, už jsem nabootoval i s VGA kartou. Už to vypadalo, že je vše opraveno, ale záhy se objevila záhadná chyba po vložení FPU do patice. Jakmile jsem pustil nějaký program, který se jen pokusil FPU detekovat (třeba DOS Navigator, ten normálně běží i bez něj), tak zatuhnul. Vyzkoušel jsem několik různých FPU a CPU, ale změna nastala až při výměně CPU za TX486DLC. Systém byl sice podivně nestabilní, ale většina programů, které předtím tuhly se spustila. Jenže FPU špatně počítal. To bylo vidět třeba na VESATESTu, který místo soustředných kružnic vykreslil jeden jakýsi kosočtverec s oblýma rohama.
      Pojal jsem tedy podezření na chybu v komunikaci CPU a FPU. Propípal jsem všechny piny v patici FPU 378DX a zjistil, že pin L3 - výstup READYO# nikam nevede. Později se však ukázalo, že některé desky tento signál nepotřebují a generujou CPU READY# jiným způsobem (chipset 82C35x žádný takový dedikovaný vstup nemá). Napadlo mě trochu vyzpovídat AI od Googlu, aby mi vysvětlila, jak vlastně komunikace mezi CPU a FPU funguje a jaké signály se k tomu používají. Díky tomu mě správně navedla na signál BUSY#, byť uváděla nesprávná čísla pinů. Popsala mi přesně i stavy, ke kterým dojde, pokud signál BUSY# na straně CPU zůstane viset trvale v log. 1 nebo 0. CPU se prostě nedozví, že instrukce FPU skončila a zůstane čekat. 486DLC se zachová jinak díky interní L1 cache a na dokončení instrukce nečeká.
      Následně jsem se dopípal, že signál BUSY# od FPU i CPU končí v obvodu U6 s kryptickým značením A458-00-1BS 9134, avšak pod paticí bylo viděl v potisku "16L8", což odkazuje na programovatelnou logiku PAL16L8. Jak jsem se dále dopípal, tento obvod snímá a generuje i další řídicí signály, viz tabulka níže. S překvapením jsem zjistil, že celá výstupní strana PALu (piny 12 - 19) je odPÁLená, resp. piny visí v luftu bez jakéhokoliv náznaků PN přechodu mezi GND či VCC. Napadlo mě, že uvnitř čipu mohly zoxidovat nebo se utrhnout bondovací drátky. Blbé je, že takto z něho už nemůžu vyčíst původní konfigurační matici. AI mi navrhla, abych zkusil jednoduše propojit odpovídající signály BUSY#, ERROR# a PEREQ a dokonce mi vygenerovala i zdroják v jazyku ABEL, který jsem následně zkompiloval do JEDEC souboru a napálil programátorem LabProg-48LV do náhradního obvodu GAL 16V8D-25QP s Flash pamětí. Po té programy na FPU začly fungovat správně, ale chtělo by to doplnit i generování dalších signálů. Patrně se používá nativní signalizace chyb pomocí ERROR# a nikoliv přes IRQ 13. Ideální by bylo od někoho získat dump původního PALu (nebo zapůčit k dumpnutí). Jinak se zdá, že už deska funguje správně a výsledky testů jsem přidal do tabulky...

pin	signál	pin	signál
1	FPU K1 - PEREQ	20	VCC
2	FPU K2 - BUSY#	19	CPU C8 - PEREQ
3	FPU L2 - ERROR#	18	F82C356 138 - IRQ 13
4	CPU E14 - ADS#	17	NC?
5	F82C356 77 - NMI	16	CPU A8 - ERROR#
6	FPU L10 - RESETIN	15	NC?
7	CPU C9 - RESET	14	NC?
8	F82C351 149 - REFRESH#	13	NC?
9	WTL3167 M12 - INTR	12	CPU - BUSY#
10	GND	11	WTL3167 M2 - PRES#

PAL16L8 pin mapping