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.
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 10 MHz ještě o trochu
více na 1,725 FPS.
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%).
UPDATE3: 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
10 MHz. Timerefresh zrychlil na 1,974 FPS a timedemo1 z 2,5 na 2,7 FPS.
 |
 |
 |
 |
 |
Am386DX-40, 128kB |
TX486DLC-40, 256kB |
Am386DX-40, 256kB |
TX486DLC-40, 256kB |
NDiag TX486DLC-40 |
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í. Možná to nějak souvisí s nastavením refreshe,
ale Hidden Refresh už mám zapnutý i nejkratší dobu refreshe na 15 µs.
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é SIMM |
AMI BIOS setup - WB |
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. schema |
IOCS16# dek. layout |
IOCS16# dek. model |
IOCS16# dek. PCB |
IDE ctrl. back |
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 a neuspěl, já jsem to zkoušel s HX DOS
extenderem pod DOSem a mp3play 1.5 vždy crashnul (i v testovacím režimu bez zvukového výstupu). 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) už přinesou zrychlení jen pár %, /8bit někdy
dokonce způsobí zpomalení (a výstup znatelně více šumí). 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í: 13,075 s, v plné kvalitě pak 22,933 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,602 s.
S parametrem /mono jsem se dostal na 19,020 s a s /half
na 22,370 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,466 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 i slyšet 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í.
params / CPU: |
Am386DX |
TX486DLC |
kvalita |
- |
37,602 s |
22,933 s |
44 kHz, 16-bit, stereo |
/fast |
36,283 s |
19,926 s |
44 kHz, 16-bit, stereo |
/half |
22,370 s |
13,075 s |
22 kHz, 16-bit, stereo |
/mono |
19,020 s |
- |
44 kHz, 16-bit, mono |
/mono /half |
11,466 s |
- |
22 kHz, 16-bit, mono |
/quarter |
16,178 s |
9,228 s |
11 kHz, 16-bit, stereo |
rychlost dekódování MP3 128 kbps, 44 kHz, joint stereo, 16,013 s
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 noname MB 386DX s chipsetem Macronix MX83C305 & MX83C306
10.3.2023 Od Dušana jsem dále dostal na hraní
2 noname základní desky s onboard SMD CPU Am386DX-40 a chipsetem Macronix MX83C305 & MX83C306
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 |
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...
Ú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 |
Grafická karta Rendition Vérité V2200 8 MB AGP
28.5.2024 Další zajímavou kartou, kterou jsem
našel v darovaném PC šrotu ze Strahova, byla tato AGP karta Rendition Vérité V2200
s 8 MB SGRAM. Jako jedna z mála dokonce i fungovala, takže jsem ji rovnou strčil do nějaké
Super Socket 7 desky s
Tillamookem a zkusil co umí. Grafický čip pochází z konce 90. let, doby
kdy probíhal bouřlivě konkurenční vývoj 3D akcelerátorů dostupných pro běžná PC (vedle 3Dfx Voodoo
a nVidia Riva 128), kdy ještě existovala celá řada výrobců, jejichž jména už dávno odvál čas
(dnes už nám zbyla jen nVidia a AMD/ATI).
Zajímavostí je poněkud odlišná koncepce tohoto GPU. Jedná se totiž
o plně programovatelný RISC procesor, jehož mapovaná paměť se dělí na framebuffer a paměť mikrokódu,
který se nahrává ze souboru implementuje grafické funkce a API. Rendition Vérité implementuje svá
proprietární 3D API
Speedy3D pro DOS a RRedline pro Windows. Ovladače
pro Windows dále podporují i Direct 3D a OpenGL API. Tehdy vznikla celá řada her, či rozšíření
engine s přímou podporou Rendition Vérité. K dispozici je i technická specifikace čipu a programátorský manuál.
Zatím jsem vyzkoušel VQuake 1.08
pro DOS, který podporuje GPU V1000 a V2x00. Dalo mi chvíli práce najít správný soubor s
mikrokódem,
který s touto verzí VQuake funguje (ten musí mít příponu přejmenovanou na uc2
pro běh na V2x00), ale nakonec se podařilo (spd3d.uc2 z 5.11.1996 velikosti
67280 B). VQuake se vizuálně podobá GLQuake, běží v 16-bitových barvách s filtrováním textur.
Na testovacím stroji s CPU intel Pentium MMX Tillamook @300 MHz na desce Gigabyte GA-5AA 2.2
jsem dosáhl v softwarovém renderingu Quake 14,1 FPS (640 x 480) a v akcelerovaném renderingu
vQuake 32,0 FPS (640 x 480), resp. 17,0 FPS (1024 x 768). Pokud nemáte grafiku s Rendition
Vérité čipem, ale chtěli byste si vyzkoušet look některých starých her s jejich podporou, tak je
k dispozici projekt RReady - Rendition Verite wrapper
(speciální fork DOSboxu s podporou Speedy3D a RRedline API). Pod DOSem jinak karta nabízí standardní
podporu VESA VBE 2.0. Jak se ukázalo, u her a dem, které používají standardní VGA režim 320 x 200
(mode 13h) je rychlost dost bídná, což se snaží řešit renutil
přemapováním na VESA LFB mód, ale nefunguje to u VGA mode X/Y (např. v Doomu).
 |
 |
V2200 AGP-top |
V2200 AGP-bottom |
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ů může VLB verze obsluhovat pouze 2 MB místo 4 MB videopaměti, což je pro
3D akceleraci málo.
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 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 platné
jen pro 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 platné pro 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. 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.
Oprava 486 MB 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, resp. chipset
nepodporuje L1 write-back cache a odpovídající piny CPU, které byly definované až později na 486DX4, zde
nejsou nikam zapojené.
V lepším případě by snad CPU mohl fungovat v režimu write-through (s o něco nižším výkonem).
 |
 |
 |
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 |
Speedsys CPU/MemBW |
VESATEST |
Doom* |
Quake 320/640** |
KMC-A419-8 |
AMD Am386DX-40 |
40 MHz |
40 MHz |
CPU: 7,26 / 48,20 MB/s |
5 MB/s |
7,53 FPS |
2,0 / - FPS |
KMC-A419-8 |
TI TX486DLC-40 |
40 MHz |
40 MHz |
zásek při detekci CPU |
5 MB/s |
11,44 FPS |
2,5 / - FPS |
Leopard 486SLC2 |
IBM 486SLC2 |
50 MHz |
25 MHz |
CPU: 13,78 / 22,82 MB/s |
- MB/s |
11,80 FPS |
1,4 / - FPS |
AB-AH4 |
intel 486DX-33 |
33 MHz |
33 MHz |
- / - |
10 MB/s |
14,24 FPS |
- / - FPS |
SY-025D2 |
intel 486DX-33 |
33 MHz |
33 MHz |
CPU: 12,44 / 35,24 MB/s |
11 MB/s |
14,90 FPS |
4,1 / 1,7 FPS |
Hippo 10 (WT) |
intel 486DX-33 |
33 MHz |
33 MHz |
CPU: 12,43 / 82,39 MB/s |
14 MB/s |
15,26 FPS |
4,1 / 1,6 FPS |
Hippo 10 (WT) |
ST 486DX4V100 |
100 MHz |
33 MHz |
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 |
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 |
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 |
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 |
CPU: 49,74 / 89,51 MB/s |
14 MB/s |
45,82 FPS |
13,3 / 5,6 FPS |
EXP4044 |
AMD Am5x86-P75 |
133 MHz |
33 MHz |
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 |
CPU: 57,64 / 46,24 MB/s |
13 MB/s |
46,25 FPS |
14,4 / 6,2 FPS |
EXP4044*** |
AMD Am5x86-P75 |
160 MHz |
40 MHz |
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 |
CPU: 51,58 / 107,80 MB/s |
15 MB/s |
47,16 FPS |
14,8 / 6,1 FPS |
Hippo 10 (WB, L2-) |
AMD Am5x86-P75 |
160 MHz |
40 MHz |
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 |
CPU: 59,71 / 107,80 MB/s |
15 MB/s |
53,82 FPS |
15,8 / 6,7 FPS |
NexGen NxVL |
Nx586-P90 |
84 MHz |
42 MHz |
CPU: 66,51 / 223,96 MB/s |
12 MB/s |
38,46 FPS |
0,9 / - FPS# |
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: S3 Vision 928 (ISA @10MHz, 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
* Doom v DOSu, 320x200, "-timedemo demo1"
** Quake v DOSu, 320x200 / 640x480, "timedemo demo1.dem"
*** DataExpert EXP4044 a VGA S3 765VL s 0 WS ROM
# Quake běžel na NxVL 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.
Oprava 486 MB 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.
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,
přidal do tabulky výše. Též přidávám report
z programu CACHECHK V5.
Zkusil jsem FSB i na 50 MHz, ale to ani nePOSTne.
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ý.