multicompでは電源ONするとcamelforthが起動し、コマンドを入力することで各OS等が起動する。
どんなものがあるのか確認するためにForthのワード定義をWORDS
で見ると、FUZIX, NITROS9, FLEX, BUGGY, SDFORTH, BASIC, SDBOOT, CUBIXあたりがあるが、起動の状況が良くわからない。camelforthはreadme.09を見るとmulticomp6809-master/camelforth/chromium.scrにforthのソースがある模様。
1行64バイト固定長なので単純にエディタでは見えないため、以下のrubyスクリプトで適当に切り出してみた。
page = 1
File.open("./camelforth/chromium.scr") do |f|
catch(:exit) do
loop do
puts %Q|===page.#{page}===|
page += 1
16.times do
l = f.read(64)
throw :exit if l == nil
puts l
end
end
end
puts
end
結果
: MMUMAP \ enable MMU with 1-1 mapping 29aug15nac
10 0 DO I DUP 8 LSHIFT OR FFDE ! LOOP 20 FFDE C! ;
: EFTOCD ( --) \ map top 8K to C000-DFFF so it can be loaded
2607 FFDE ! ;
: CDTOCD ( --) \ restore 1-1 map
2606 FFDE ! ;
\ Multicomp extras: start CUBIX/BASIC/BUGGY/FORTH 29aug15nac
: CUBIX \ 4KB from SD at 0x2.0000
MMUMAP EFTOCD
2 SDLBA2 0 D800 4 SDRDn 0 SDLBA2 \ load bootloader to F800
CDTOCD PIVOTRST ; \ restore map, go thru RST
: SDBOOT ( n - ) \ 8KB from SD at 0x2.nnnn and jmp thru RST
MMUMAP EFTOCD 2 SDLBA2
( n ) C000 10 SDRDn 0 SDLBA2 \ load 8Kb from n to E000
CDTOCD 2787 FFDE ! PIVOTRST ; \ restore map, protect, jmp
: BASIC 1000 SDBOOT ; \ on SD at 0x2.1000
: SDFORTH 0FF0 SDBOOT ; \ on SD at 0x2.0FF0 - blk file with src
: BUGGY \ 7KB from SD at 0x2.1E00
MMUMAP EFTOCD
2 SDLBA2 1E00 C400 E SDRDn 0 SDLBA2 \ load to E400
CDTOCD PIVOTRST ; \ restore map, go thru RST vector
\ Multicomp extras: start FLEX/NITROS9/FUZIX 10may16nac
: FLEX \ 512 bytes (256 used) from SD at 0x2.2000
MMUMAP
2 SDLBA2 2000 C100 SDRD 0 SDLBA2
C100 PIVOT ; ( entry point of loader)
: NITROS9 \ load track34 and start it
\ disk is on SD at 0x2.8000 so track34 is at 0x2.84C8
MMUMAP EFTOCD
2 SDLBA2 84C8 2600 \ load from 0x2.84C8 to 2600
12 SDRD256n 0 SDLBA2 \ 18 (hex 12) 256-byte sectors
\ vectors to RAM expected by krn
0100 DFF2 ! 0103 DFF4 ! 010F DFF6 ! \ SWI3 SWI2 FIRQ
010C DFF8 ! 0106 DFFA ! 0109 DFFC ! \ IRQ SWI NMI
CDTOCD 2602 PIVOT ; \ restore map, start at 2602
: FUZIX MMUMAP 3 SDLBA2 0 D000 SDRD D000 PIVOT ;
⇒MMUの仕様がわからないとさっぱり解読出来ない。
そこでmulticomp6809-master/multicomp/Components/MMAPPPER2/mem_mapper2.vhdを読む(vhdlは良くわからないけどコメントで説明がある)。
6809は8ビットCPUでアドレス空間は64KB。そこでMMUで8KB毎にマッピングを行っている。論理的な8KBx8ブロックを物理的な8KBx128ブロックに対応させるため、$FFDE, $FFDFに書き込みによりコントロールを行う。
リセット直後はMMUは無効なので、MMUMAPで以下のようにマップの初期設定を行っている。
「10 0 DO I DUP 8 LSHIFT OR FFDE ! LOOP 20 FFDE C!
」
$FFDE(下4bitは論理アドレスブロック)と$FFDF(下7ビットは物理アドレスブロック)に同じもの(0〜$f)を書き込み、1-1マッピングと呼ばれる状態とした上で、MMUイネーブル。
EFTOCDは、「2607 FFDE !
」により、論理アドレスブロックに6、対応する物理アドレスブロックに7を設定。
これによりCPUがブロック6の$CDxxをアクセスすると、ブロック7の$EFxx領域がアクセスされることになる。
CDTOCDは、「2606 FFDE !
」により、論理アドレスブロックに6、対応する物理アドレスブロックは6と戻す。
要するに、$EFxxの8KBはROM領域なので書けない。そこで$EFxxのRAMを$CDxxにマップさせて書き込みを行い、元に戻す。最終的にROMを無効化すれば良いという考え。
ROMの無効化は以下のようになる。6809CPU自身が$A0をFFDEに書き込みROMの無効化($FFDE bit7=1)を行っている。
: piv ( --) \ helper for PIVOT, PIVOTRST
4F 1000 C! ( CLRA)
1F8B 1001 ! ( TFR A,DP)
86A0 1003 ! ( LDA #A0)
B7 1005 C! FFDE 1006 ! ( STA FFDE ; page ROM out)
1000 EXECUTE
;
: PIVOT ( addr --) \ copy to RAM, init DP, disable ROM, jump
7E 1008 C! 1009 ! ( JMP addr ; go there)
piv ;
これを見ながら最初のCUBIXからFUZIXまでのブート定義を見ると理解出来た。
※コメント投稿者のブログIDはブログ作成者のみに通知されます