Tak dneska něco málo k oživování:
předpokládám, že si každý dokáže zkontrolovat desku na zkraty napájení (žádný problém s deskou jsem nezaznamenal) ale pro každý případ bych si nastavil proudové omezení na zdroji při použití CMOS procesoru a nízkopříkonové diody na cca 40mA a s obyčejným procesorem cca 150mA. Víc by to žrát nemělo.
Samozřejmě lze hned vypálit f.hex do flashrom/eprom, nasázet všechny integráče, připojit k sériovému portu a zkusit jestli nabootuje.
Pokud ne, doporučuji vypálit program blinkp13.asm (neosazovat RAM ani UART ani budiče sběrnice ECB) a zkusit jestli se cca ve veřinových intervalech mění stav pinu 30 procesoru. U mně to byl jediný kus softwaru, který chodil a to jsem si ještě musel po velkém lámaní si hlavy, proč se neenabluje multiplexer, upravit začátek programu následovně:
BEGIN .EQU 0 (změna kvůli použití překladače TASM32, na konci se musí přidat END)
repeat
;
; light
;
ent0 clk ;tohle jsem si přidal abych viděl jestli mi reaguje aspoň na první instrukci z ROM
;anl p1,#3 ; a16data=1 a17data=0 a17code=* mux=* původní
anl p1,#0 ; a16data=1 a17data=0 a17code=0 mux=0 upravené
orl p1,#8
Jako první instrukci jsem si přidal ent0 clk, čímž se na pinu 1 objeví frekvence krystalu vydělená 3 za předpokladu, že procesor načte alespoň tu jednu první instrukci z ROM (na vývodech 2 a 3 procesoru jsem osciloskopem viděl krásnou sinusovku na frekvenci krystalu). Já jsem bohužel v první fázi uvěřil tvrzení autora, že diagnostické programy lze stejně spouštět z ROM i RAM a nic mi nechodilo. Logicky, protože autor spouštěl všechno z RAM ( v ROM měl prototypový zavaděč hex, který ale vždy správně ošetřil vynulování portu P1 po resetu a tudíž mu programy z RAM chodily i když se nezabývaly ošetřením P1). Řešením je všechny prográmky opatřit něčím takovým:
org 0
in a,p1
jb0 powerupreset ; po hw resetu jsou všechny piny high
jmp run
powerupreset
;
; a16data=0 a17data=0 a17code=0 mux=0
;
clr a
outl p1,a
run
mov a,#$80
outl p2,a
[...]
nebo prostě použít to anl p1,#0 pro vše co chci startovat jenom z ROMky.
Podle autora už by snad měl být software na webu opravený (nekontroloval jsem) ale v případě problémů víte jakým směrem pátrat.
Nyní předpokládejme, že už se podařilo rozfungovat i blink_uart.asm, který by měl blikat cca v 1 vteřinových intervalech LED diodou. Samozřejmě už s osazeným UARTem a alespoň budičem U7.
Dalším krokem může (ale nemusí) být kontrola RAMky prográmkem xram.asm. Po pár vteřinách mi vypsal lakonické OK.
Přistupme tedy k nahrání f.hex do epromky. V sw programátoru (po načtení f.hex) je dobré si zkontrolovat, jestli máme správně nastavený divider pro generování přenosové rychlosti. Pro krystal 6MHz a přenosovou rychlost (max.) 9600Bd je divider 13(0Dh), pro 11,0592MHz a 19200Bd je 12(0Ch). Leží na adrese 0025h.
0024 23 0c mov a,#12 ; baud rate divisor lsb (19200)
0026 b8 00 mov r0,#$00 ; in UART register 0
0028 90 movx @r0,a
0029 23 00 mov a,#$00 ; baud rate divisor msb (19200)
002b b8 01 mov r0,#$01 ; in UART register 1
002d 90 movx @r0,a
Po kontrole a úpravě je možno romku vypálit. Podle typu je potřeba nastavit jumpery (na mých fotkách je použita X28C256 a tomu odpovídá nastavení, pro 27C256 je nutno jumpery přehodit).
Dále bude potřeba vyrobit a zapojit kabel pro připojení k sériovému portu - schéma viz níže: (doporučuji kontrolovat propojení podle schématu až na desku na MAX232).
Příloha:
Rj45-pinout.gif.png [ 10.35 KiB | Zobrazeno 11811 krát ]
Pak už by mělo stačit nastavit v terminálovém programu 19200 nebo 9600Bd, 8N1, flow control RTS/CTS a deska by se měla ohlásit jako "SBCMCS48".
V tomto stavu čeká cca 10 vteřin na zadání povelu b (zavedení hex souboru do paměti a jeho spuštění z RAM) nebo r (zavedení obsahu ROM tedy jádra FORTHu a jeho spuštění z RAM). Po 10ti vteřinách bez stisknutí klávesy (nebo stisknutí libovolné jiné klávesy) se startuje z RAMky od adresy 0 - pokud v RAM nic není, program zabloudí. Povel je bez echa bez odezvy, takže po b nic nevidíte, počítač jen čeká na příchozí soubor. Po r by se mělo objevit:
"MCS-48
ROM Rev. 20110131"
a blikající kurzor, což je neklamnou známkou toho, že funguje FORTH.
Zde bych rád upozornil na chybu v původním softwaru f.asm (ukázka z f.list aby bylo vidět, že to tak skutečně bylo přeloženo):
0069 23 0a mov a,#10
006b 34 39 call timedgetchar
006d aa mov r2,a
006e 23 0d mov a,#13
0070 34 0a call putchar
0072 23 0a mov a,#10
0074 34 0a call putchar
0076 fa mov a,r2
0077 d3 62 xrl a,#'b' ; b (boot) loads Intel hexfile
0079 c6 84 jz goi8hexload
007b f8 mov a,r0 ;should be mov a,r2
007c d3 72 xrl a,#'r' ; r (reset) loads ROM
007e c6 86 jz romload
0080 23 06 mov a,#6 ; any other starts from RAM
0082 e4 ff jmp codesegswitch
Jak je vidět na řádku 006d, autor si schoval načtený znak z konzole do r2 a v případě testu příkazu b si ho z r2 také správně obnovil (0076). ALE u testu na příkaz r si bůhvíproč obnovil střadač z registru r0 (007b), což způsobí, že příkaz r nikdy nedetekuje, respektive by to musela být neskutečná náhoda aby zrovna "r" bylo v registru zničeném nějakou subrutinou. Chybu jsem reportoval a nepřišli jsme na to, jak se mu podařilo ten FORTH do RAM nahrát. Mě totiž nahrávání hex souborů chodí jen pro kratší kód, delší skončí zacyklením a nekonečným vypisováním 0 na konzoli (neidentifikovaný typ recordu - zavaděč zná jen typ 0 nebo 1 pro vše ostatní se zacyklí - asi správně ale mě se zacyklí i když v souboru jiný typ než 0 nebo 1 není. Takže asi nějaká ztráta znaku nebo zkomolení). Jediné vysvětlení je, že prototypový zavaděč hex souborů byl nějaký jiný, asi lepší než definitivní verze.
Pokud vše úspěšně proběhlo až sem (gratulace), dále postupujte podle instrukcí autora, tj. nahrajte si vyšší funkce FORTHu a obsluhu HW na desce (zachovejte pořadí souborů), v linuxu je to takhle:
cat f.f sbcmcs48.f y2k.f i2c.f ds1307.f lm75.f >/dev/ttyS0
v TERATERMU (používám já na Windows 10) jsem prostě použil "Send file" a postupně naposílal ty soubory. Je sranda pozorovat, jak si je to tam pomalu nasypává - domnívám se, že si je ten FORTH zrovna nějak "překládá", protože to je fakt docela pomalý proces, skoro jako kdyby to tam člověk datloval ručně. Jinak mi přijde, že všechno běhá rychle ale tenhle "hashovací" proces je srandovně pomalý.
No a pak už jen stačí otestovat napsání prvních příkazů v konzoli FORTHu
1 led!
0 led!
čímž byste měli být schopni rozsvítit a zhasnout ledku.