Almost lost technologies

ここは昔の CPU を用いた工作記事を書くために用意しました。

SC/MP-III SBC 暫定版

休みのうちにというわけで、回路+基板まで今日仕上げました。とりあえず今日は回路を出しておきます。

INS8070 SBC

説明無しだと分からなそうなのが、D7 だけを 4.7k でプルアップしていることですが、これは現在の NIBL ではそのアドレスに RAM があるかどうかのテストに、読んだ値をビット反転して書いてみて、書けるかどうかで判断しているため、これだけで空きアドレスが確実に空きと判断できるという理由です。INS8073でも本当は必要な気もしますが、NS のINS8073 サンプル回路を含めてあまり対処している例は見ないな。

0x8000からの ROMTEST は飛んでから考えるパターンなんですが、とりあえず今回のメモリマップだと RAMなので変なことは起きないはずです。

 

NIBL (for SC/MP III) のメモリマップ

SC/MP-III 用の NIBL はとりあえず無理矢理 AS assembler で通るようにしたので、とりあえずバラックで組んで試験するのと並行して、まず整数 Basic で都合の良い用に手直ししようかと。
まず、メモリマップが気に入りません。当時のメモリ状況ならこれでよかったんでしょうけど、、、

NIBL のメモリマップ

SC/MP-III だと 0xff00-0xffff が 6502 なんかの ZP相当で、スクラッチとして使えるのですが、オンチップメモリは全部 NIBL が使っていて、そのすぐ下にメモリが置きたい。一方、NIBL は 0x1000 番地から 256Byte をワークに使っていて、そこにメモリがなければならない、という構成です。ベタッと RAM で埋めると 60KB という中途半端な領域が必要。
また RAM 開始番地まで 1.5KB しか空きがないので FP 処理を押し込むにはやや狭い。はみ出すと今度は上位側に ROM を持ってこないといけないんですけど、AS の都合で実メモリマップと ROM メモリマップが違っていると (そんな機能はないのでバイナリを繋げないといけなく) 処理が面倒。また、IO は好き勝手に置け、ということになっているんですけど、置いた位置までで RAM がお終いとなるので、これも上の方に持ってこないといけない。

案としては、

  1. 32KB RAM を 0x1000-0x8eff と 0xff00-0xffbf に来るようにする。FP が残り 1.5KB に入らない場合 (多分入らない)ROM 割り付けは細工する。I/O は fe00 あたりに置く。または 空き領域は RAM で埋めてしまい同様にする。ROMベースで直していると ROM の細工が入るのは悩むところ。
  2. RAM ワークを 0x8000 からに移動してしまう。これをやると自動実行 ROM 処理を潰す必要あり。
  3. RAM ワークを 0x4000 からに移動し、RAM は 0x4000-0xbeff と 0xff00-0xffbf に来るようにする。デコード回路は面倒だが、他の修正は少ない。

とりあえず、今回は (3) で、デコーダは今回は LS138 あたり一発とは行かないので GAL を焼く方向で考えています。

#なお、自動実行ROMアドレスは上の図だと 0x2000 開始になっていますが、アセンブラ見る限りは 0x8000 からです。

新旧案 (いや全部新じゃなく昔のチップなんですが) 検討中。

i8008 もまだ検討中なのですが、SPLD周りで止まっています。1.25μS cycle で動かそうとすると結構タイミングが問題で、CPLD に取り替えようと 5V 系のものを入手しているんですが、書き込み方法周りで現状中断中。

それと、なにとなく8ビット機で BASIC を走らせるのも MELPS で結構楽しかったので、今のところ速度報告がない (といっても BASIC 込みですから純粋な石の実力とは異なりますが)あたりで、SC/MP III と 2650A を試そうかととりあえず仕込んでみました。

SCN2650A/INS8070

INS8070 はネットで 2.5kByte SC/MPIII NIBL のソースを発見したので、NIBLFP相当にできるか考えてみます。ものはライセンス不明ですが、NIBL のソースを SC/MP で動かすだけなら TI も文句言ってこないでしょう。多分。

SCN2650A の方は jim11662418 さんのところに Microworld BASIC のバイナリが落ちています。これこそライセンス不明。問い合わせ先は分からなくもないんですけど、聞かれたらだめと答えざるを得ない、という可能性もあり、ちょっとなんとも言えないな。
専用モニタの PIPBUG はソースが公開されているのでモニタの方はあまり問題にならない。

何れも AS Assembler でなんとかなるので、改造自体はなんとかなるかも。
回路的にはどっちも簡単です。どちらも BASIC の前提はソフトシリアルなので、INS8070 の方は同じ NS の NS16450 あたりで、Signetics の方は同じ Philips の 2661B で何とかしようかと。なお、2650A は 1975-6 あたりで発表されており、この年の 3 月に Signetics は Philips に買収されているので、ほとんど 1st source だと思います。

MELPS740 OSI Basic patch

一応パッチは載せておきます。

--- OSI_BASIC_GSEELES.orig/osi_bas.s	2023-05-28 22:37:22.403333500 +0900
+++ OSI_BASIC_GSEELES.740/osi_bas.s	2023-05-28 22:58:27.884511500 +0900
@@ -5768,19 +5768,31 @@
 
 ; STARTUP AND SERIAL I/O ROUTINES ===========================================================
 ; BY G. SEARLE 2013 =========================================================================
-ACIA := $A000
-ACIAControl := ACIA+0
-ACIAStatus := ACIA+0
-ACIAData := ACIA+1
+ACIA := $F4
+ACIAControl := $F4
+ACIAStatus := $F5
+ACIARData := $F7
+ACIATData := $F6
 
 .segment "IOHANDLER"
 .org $FF00
 Reset:
+	.byte	$12	; CLT
+	CLD
+	LDA	#$32	; Stack Page1, Timer stop, MP mode
+	STA	$FF
 	LDX     #STACK_TOP
 	TXS
-
-	LDA 	#$95		; Set ACIA baud rate, word size and Rx interrupt (to control RTS)
+	LDA	#$FF		; port4 all output
+	STA	$0EB
+	LDA	#$FE		; bit 0 LED on
+	STA	$0EA
+;
+	LDA	#$08		; 8-bit UART, Ext CLK
 	STA	ACIAControl
+	NOP
+	LDA	#$5		; RSV/TRN Enabled
+	STA	ACIAStatus
 
 ; Display startup message
 	LDY #0
@@ -5816,15 +5828,16 @@
 	CMP	#2
 	BNE	SerialOutWait
 	PLA
-	STA	ACIAData
+	STA	ACIATData
 	RTS
 
 MONRDKEY:
 	LDA	ACIAStatus
-	AND	#1
-	CMP	#1
+	AND	#8
+	CMP	#8
 	BNE	NoDataIn
-	LDA	ACIAData
+	LDA	ACIARData
+	STA	ACIARData
 	SEC		; Carry set if key available
 	RTS
 NoDataIn:

 

MELPS740 ASCII-ART完走

とりあえず Grant さんの OSI 6502 Basic 3.2 を焼いたところ、あっさり動いてしまいました。
ほうめい版の WD65C02 より遅い理由は追求していませんが、実力でしょう。CPUクロックは2MHz、シリアルは内蔵のもの、速度は 19200bps です。

さて、とりあえずこれは完成扱いにするかなぁ。UNIMON が動かない理由は追っかけていないんですけど。

MELPS740 SBC チェック(9)

うーん、Unimon のポートは1文字も出ないでハングアップします。様子から見ると多分どっかで I/O ポートの設定を踏み潰して死んでいる感じです。進行状況を LED に出すようにフックしているんですけど、それすら出ない (というかポートディレクションレジスタが書き換わっている……)。

#追っかけているんですが、慣れないアーキテクチャの人の書いたアセンブラソースを辿ってメモリ破壊箇所を探るのはもう泣きたい気分。

もうこれは放り出して、ZP 利用状況がある程度見当がついている OSI Basic の方をやろうかと思います。