8086 vs. Z80 vs. 6809 vs. 6502　その16

8086 vs. Z80 vs. 6809 vs. 6502　その16 (918ﾚｽ)
上下前次 1-新

1(2): [aga] 2022/05/15(日)04:33 AAS
AA省

838: 09/13(土)04:26 AAS
MSの6502BASICって、どのアセンブラでアセンブルする想定なんだろ？
一部のニーモニックが独自だったり、やたら^Oとかいうなじみの無い8進数を多用したり…
ちょっとナナメ読みしようと思ったけど、読みづらくて仕方ない

839: 09/13(土)06:38 AAS
アセンブラも自前なんじゃね

840: 09/13(土)22:08 AAS
開発パッケージCC65内のアセンブラでいけるのでは？

841(1): 09/13(土)22:58 AAS
そんな当時ないツール持ち出されても

842: 09/14(日)02:10 AAS
素直に他のアセンブラへのトランスレータ作るなりしろw

843: 09/14(日)04:45 AAS
8KB Basicなんだからハンドアセンブルでもできそうな
ファミコンディスクシステムエミュに移植してフリーエリア24KB環境を作るとかネタになるのでは

844: 09/14(日)14:38 AAS
なんか、ちょっと想像できてきた。
ソースの冒頭でどの機種用にアセンブルするか設定しているんだけど、APPLE向けやCOMMODORE向けなんかと並んでPDP-10上のシミュレータ向けっていう設定もあるんだよね。
デカコンですかw そんなもん使えるんなら、アセンブラだってそこで動かした方が速いし効率もいいんじゃね？と妄想。
もしかしたらリスティングファイルの方が見やすいか？とも思い、cc65内のアセンブラca65に食わせてみるも撃沈。マクロや条件アセンブルの書式が違っているっぽいのと、独自ニーモニックでもERROR連発している。
それで独自ニーモニックや8進数の書き換えプログラムを昨日から書いているワケなんだけど、それによると6955行中762行が書き換え対象になった。
数値演算パッケージ内あたりに8進数の定数がまだゴロゴロしているんだけど、やっとナナメ読みできるくらいにはなった…と思う。

845: 09/14(日)18:44 AAS
>>841
MSのページの方でいける様に書いてあったのだが駄目なのか…

He has ported the code to assemblers like cc65, making it possible to build and run on modern systems.

<Chrome約文>
彼はコードをcc65などのアセンブラに移植し、最新のシステムでビルドして実行できるようにしました。

846(2): 09/14(日)20:23 AAS
俺が学生のときPC88版のイースやソーサリアン等の
解析＆改造に使った逆アセンブラも順アセンブラも
N88 BASICで自作した懐かしい思い出ｗ

847: 09/14(日)23:42 AAS
今アセンブルしたいだけならLLMでできそうだけどね
当時は8080同様PDP-10にシミュレータと開発ツール書いて移植した模様

848(1): 09/14(日)23:43 AAS
>>846
オレの消防時代もまさにそれだった

849: 09/15(月)20:30 AAS
>>846
BASICでアセンブラを自作したと言うなら凄いな
8ビット機ではBASICを触っていたけど扱い難かった

>>848
消防時代とは更に凄いな

850(1): 09/15(月)20:46 AAS
BASICでアセンブラ作るってのは
月間マイコン等の記事であった希ガス！

851(1): 09/15(月)22:23 AAS
厨房のとき街の家電屋さんにパソコンで自由に遊べるコーナーがあって、PASOPIAとPC6001mk2とPC8001が置いてあった
土日に通って来る奴らは消防から厨房まで殆どが機械語モニタで直接16進コードを打ち込む変態ハンドアセンブル奴ばかりで震えたわｗ

852: 09/15(月)23:36 AAS
学生時代linuxでZ80の逆アセンブラなら書いたけどな

853: 09/16(火)00:06 AAS
>>851
16進で直接コードを打ち込む奴はほぼZ80組だった

854: 09/16(火)00:10 AAS
>>850
アセンブラはニモニックを手書きしてそれをハンドアセンブルして作る方が建設的
で出来上がったアセンブラに上のニモニックを食わせるとサイズが数分の1のコードが出来上がる

855: 09/16(火)00:21 AAS
8086でハンドアセンブルは無理だと思ってBASICでアセンブラを作った。

856(2): 09/16(火)00:58 AAS
BASICでHEXコードの書込とラベルのアドレス計算をするプログラムなら作ったな
ハンドアセンブルはいいけどアドレスの手計算は面倒臭いのでこうしてた
しかしZ80やMC6809はローカル変数をどう処理してたんだろう？スタックフレーム？

857: 09/16(火)09:27 AAS
>>856
スタックは使いにくいので自己書き換えが多かった
キャッシュや先読みが無いからやってた事だな

858(1): 09/16(火)09:40 AAS
>>856
前提が不明瞭だ、BASICでアセンブラ作ると言う流れだけど
8ビット機のBASICではローカル変数が使えないのに何故ローカル変数が出てくる？

8ビット機のアセンブラをマクロ的に使うと言うことか？

859: 09/16(火)10:07 AAS
BASICで作ったアセンブラでアセンブルする対象の
ゲームプログラム等で使うローカル変数の話では？

860(1): 09/16(火)10:13 AAS
自己書き換えが1番楽だし便利よね
相対ジャンプのオペランドすら書き換えてた

8ビットCPUに思い入れのある人が未だに多いのは
こういう小技を考えるのが楽しかったからだと思うｗ

861: 09/16(火)12:14 AAS
>>858
C言語の話かもしれん

別のスレで取り扱ってる話題なんだけどさ

たしか、LSI-C80ではローカル変数はスタックに取ってたような

ただし、先に取れる限りのレジスタ変数を確保して、レジスタが足りない分だけスタック

スタックフレームを扱う用の命令がないから、たぶん苦心しながらアクセスしてそう
SPをインデックスレジスタにでもコピーするのかなあ?

862(1): 09/16(火)12:19 AAS
>>860
いつの頃からか、命令とデータをメモリ空間ごと分けてるCPUが増えて、自己書き換えできなくなってきたのが残念だな
組み込みCPU専用のアーキテクチャのヤツってたいてい、キャッシュを積んでるわけでもないのに禁止なんだよな
中には命令が10bitとか12bitとか、データとbit幅が違うヤツすらある

863: 09/16(火)12:37 AAS
Hitech-CなんかだとSPに加えてフレームポインタとしてIXを使ってそこにローカル変数を確保してる。

6809は元々がローカル変数の確保と使用が簡単にできるようになっててそれに則るだけで容易にポディションインディペンデントになるようになってるし、それでも効率はそんなに低下しないし、スマートでデバッグもしやすい。

まあ、当時、そこら辺が十分活用されていたのかどうかはアヤしいけどねw

864(2): 09/16(火)13:34 AAS
>>862
ROM化できないだろ

865: 09/16(火)19:39 AAS
>>864
卒業＆就職してゲームプログラムが仕事になって、
ROMカセットを差し替えるタイプの家庭用ゲーム機の開発を始めた時、最初のうちはウッカリ自己書き換えコードを書いてよく怒られてた
開発環境のICEだとワーニングが出るだけで一応動いちゃうんだよなぁｗ

866(1): 09/16(火)21:12 AAS
>>864
RAMに転送すれば良いじゃん(ニッコリ

867: 09/16(火)21:27 AAS
>>866
たいていの組み込み機器はROMの容量がRAMの数十倍ぐらい大きいからなあ

CPUの種類によってはプログラムはROMにしか置けないものすらある
RAMが8ビット幅なのに命令が12ビット長とかのサイズ違いだったり、色々

PIC12とかのチップで自己書き換えは無理やろうなあ……

868: 09/17(水)12:20 AAS
無理なやつは、しなくてもいいような機能が追加されてるのでは

869: 09/17(水)12:58 AAS
ハーバードアーキテクチャではプログラムとデータのバスが分離しているのでRAM上でプログラムは実行できない
PIC12とかの場合コードのビット幅とデータのビット幅が異なっているのでそのままの形で転送する事すらできない

自己書き換えは速度が遅くアセンブラで書く必要があった時代の徒花
そういった小手先の技が得意といった当時のゲームプログラマの人でWindows時代でも生き残った人は少ないと思う

870(1): 09/17(水)15:16 AAS
Macで680*0が使われていたころ、Inside Macintoshに
自己書き換えはするな
キャッシュの容量や方式が変わったらそれまで動いていたプログラムが
動かなくなるかもしれないから
と書かれていたが、やっていたソフトはいくつもあったようで
68040Macの登場で問題が起こった

871: 09/17(水)15:26 AAS
小手先のテクニックにすぎないのはそうだが、
テトリス的な詰めて行く快感が有るから動作しないようになってないとやる
メインメモリのコード領域はリードオンリーにOSでプロテクトかけてるようなハードにしとかないと

872(1): 09/17(水)19:52 AAS
>>870
68020や68030でもキャッシュメモリ積んでたから自己書き換えで誤作動を起こしそうな気がするんだが、起こしてなかったの?

873: 09/17(水)21:32 AAS
自己書き換えプログラムでやってる事って
自己書き換えはしないって前提でコードを書くようにしていればそれでも大抵実現できるよね

自己書き換えって速度や容量面で有利な部分もあったろうけど
それよりもプログラマーの自己満足による部分の方が大きかったんじゃないかな

市販ソフトならリバースエンジニアリング対策かね

874: 09/18(木)08:14 AAS
当時はRAM容量が少なすぎて、空いたところに別のコードぶっこまざるを得なかったのもあるよね。

875: 09/18(木)11:09 AAS
>>872
68040が使われたことで表面化したという雑誌記事だったから
68030のときは誤動作しなかったんだろうな
68040は68030よりキャッシュ容量がずっと大きくなったそうだし
方式もライトスルーからライトバックに変わったんじゃなかったかな
自己書き換えをしても、その部分が実行される前にデータキャッシュの内容が
メインメモリに書き出され、プログラムキャッシュに読み込まれていれば誤動作しないわけで

876(2): 09/18(木)20:18 AAS
自己書き換えってことは、アセンブリ言語で書いた比較的小さなライブラリとか、インラインアセンブラで書いた小さなブロックなんだろうね。
68040になっても、MacOSってスーパーバイザモードオンリーだったんだっけ？それならば、自己書き換えの後でキャッシュをフラッシュすればまだそのままイケるねw
マルチスレッドなんてもんが導入されたら、キャッシュもクソもなく動かなくなるけど。
って、MC68040ユーザーズマニュアルを引っ張り出して眺めていたらとんでもないBUGというかミスを見つけた。最後の方のページに「MC68030ユーザーズマニュアル(和文) 2,575円」ってシールが貼られてるw
これ本当はいくらだったんだ？w

877: 09/18(木)20:47 AAS
>>876
MacOSでメモリ保護を使いだしたのはMacOSXからでMacOS9まではアプリもスーパーバイザモードで動かしてたはず
68040でもだ

878: 09/18(木)20:52 AAS
9とXは別物だし

879: 09/19(金)00:42 AAS
MMUでのきちんとした制御までしなくてもバンク切り替え的にRAMをリードオンリーなROM化する制御でも付けてれば保護機能で安定性高まったろうけどな
それ以前にまずスーパーバイザーモードで動かすなよって話だが

880(1): 09/19(金)01:25 AAS
もともとMacOSは（MacOSと呼ばれるようになる前から）常時スーパーバイザモードで動いていた。
RAMが少なかったからで（初代MacintoshはROM64KB, RAM128KB）、切り詰める必要があった。

881(1): 09/19(金)02:17 AAS
>>876
>自己書き換えの後でキャッシュをフラッシュ

するようにしたからもう大丈夫と、不具合が起きたソフトを売ってた会社の人が言ってた
やるなと書かれていたことをやったことについての反省の言葉はなかった

882(1): 09/19(金)07:43 AAS
>>881
嘘でしょw ホントにやる奴なんていないよねw
にしても、68000時代に「このアドレステーブル、最上位の1バイト無駄じゃない？そうだ、そこをアトリビュートに流用しよう！」とやった連中が68020到来で無事ひどいことになったり、
その手のやんちゃが好き過ぎるよねw

883: 09/19(金)09:27 AAS
>>882
それとはすこし違う利用法だけどX68000でシステムコールや浮動小数点数演算用のライブラリコールにラインF割り込みを使ってたせいで68030採用の時にトラブルを起こしてたよな

884(1): 09/19(金)19:46 AAS
>>880
ユーザーモードとスーパーバイザモード切り分けないからって、メモリ使用量そんなに変わる？せいぜいそれぞれのスタック領域をある程度ずつ確保しなきゃならない程度の問題な気が。
が、よくも128KBでウィンドウシステム構築したよね。この128KBにはビデオメモリが確か20KBくらい含まれるわけで、フリーエリアはさらに小さいという。

885: 09/19(金)20:43 AAS
>>884
言っても最小限の機能しかなかったし
白黒だったしね
むしろそんなのでも素晴らしいと思わせるデザインセンスが凄まじい

886: 09/20(土)00:09 AAS
ToolBoxを書いたヤツがスゴかったらしいね。

カリカリチューニングして64KBだっけ？

887(1): 09/20(土)02:12 AAS
wozならやりそう。ウォズニャックはLisaやMacに関わってないんかな

888(1): 09/20(土)04:25 AAS
Macintoshは元々、6809を使ったCUIのコンピュータになるはずだったけど
ジョブズが開発プロジェクトを乗っ取り、自分の好みに合わせて変えていった結果
ああなったのだという

889: 09/20(土)05:00 AAS
8080マシン語モニタならなんとか作れた。Peek,Pokeと16進変換だけで済むから。
皆凄いな

890: 09/20(土)05:24 AAS
ビル・アトキンソン(William Dana Atkinson)がQuickDrawの最初のバージョンをほぼ1人で書いた

891: 09/20(土)12:33 AAS
>>888
5インチモニターな持ち歩けて何処でも使えるポータブルパソコンは乗っ取るとか以前な方向性が別の物では
ポータブル機は実現したApple2cの方がまだマシになったろうし、互換性無い6809機として作るのは中途半端すぎた

892: 09/20(土)18:19 AAS
>>887
ウォズは直接は関わってはないらしいけど、ウォズに憧れて集まった技術者がたくさんいてそいつらをジョブズが強奪して、これまた強奪したプロジェクトのMacの開発につぎ込んだらしい。

ウォズはジョブスの無理難題でおかしくなる技術者の精神的な支えだったみたい。

アンディ・ハーツフェルド著『レボリューション・イン・ザ・バレー開発者が語るMacintosh誕生の舞台裏』

とかその元になった

外部ﾘﾝｸ[html]:www.folklore.org
省1

893(2): 09/22(月)20:53 AAS
初代Macはソフトウェア的には見るところが多いんだろうけど、ハードウェアはコストダウンなのか何なのか、最初から諦めモードの雰囲気で冴えない感じ。
64kx1の汎用DRAMを16個並べたものしかRAMが無いから、MPUのRAMアクセスタイミングはVIDEO読み出しの合間にコソっと挟みこまれる形。
ちょこっとタイミングチャート引いたことあるけど、最悪7ウェイト入るでしょ？ロングワードアクセスすれば下位ワードアクセスに必ず4ウェイト入るし。
そんな体たらくだからRAMよりROMアクセスの方が高速。アプリケーションはどう高速化しようともウェイト食らいまくりじゃヤル気も萎えるよね。
折角夢の68000だってのに、何か悲しかった記憶。

894: 09/23(火)08:08 AAS
当時とはいえ2500ドルくらいだし妥当なスペックかと
日本円だと今とは比にならない円安でバカ高だったけど

895: 09/23(火)09:56 AAS
1984年の為替レートは$1=237.5円程度

896(1): 09/23(火)10:26 AAS
1980年代前半の為替レートは$1=235円程度。
1980年代後半になると$1=145円程度に円が急騰する（といっても現在の為替レートとほぼ同じ）。
円高によりバブル期には全米の土地が買えるなどと言ってうかれていた。
1991年にバブル崩壊するが円のレートは上がり続け、1995年には$1=94円と100円を割る事態に。
超円高によりかつての輸入品=高級品という概念は完全に崩れ、激安製品が大量に流入してきて、一見バブル崩壊後の不景気な暮らしを支えるのに役立ったが、円が高くなり過ぎて日本で作ったものは海外で売れなくなり、日本の工場の中国などへの移転が進み、国内が空洞化してデフレ経済から抜け出せなくなった。
失われた30年の始まりである。

897: 09/23(火)10:30 AAS
後年1000ドルMacとか出したんだから本国でも安いとは思われてなかったんだろな

しらんけど

898(1): 09/23(火)13:08 AAS
>>893
ジョブスは「このハードウェアはこれで全て完結している完全体！他に拡張はいらない！」ってマシンが好きだから
「macの拡張はこれでできる」と言っておもむろにフロッピーを挿して見せる

899(1): 09/23(火)15:15 AAS
>>896
バブル崩壊より前に瞬間的とはいえ1ドル=88円台まで円高が進んだこともあっただろ

900(1): 09/23(火)21:50 AAS
>>899
いつ頃？
バブル崩壊を1991年とする

901(1): 09/23(火)22:09 AAS
>>900
88年か89年あたりだったか、円高の瞬間的ピークで88円台をだしてたはず

902(1): 09/23(火)22:32 AAS
>>898
これで完結！？冗談でしょ…最悪7ウェイトも入るし、命令フェッチみたいな連続アクセスも4ウェイトなのに？
そりゃ、dot CLKを4分周もして、5MHzでしか動いていないLISAよりはもしかしたら速いかもしれないけど、それで満足しちゃったんですか？
見たらSIMMを使えるようにした世代のMacになってもなお、独立したVRAMって設けなかったみたいだし、そんなんで本当によかったんですかね？
64KbitのSRAMでも4個突っ込んでVRAMで御座いってやれば、それだけでもっともっと速くなったのに…

903: 09/23(火)23:14 AAS
>>901
外部ﾘﾝｸ:www.smd-am.co.jp
🤔

904: 09/24(水)01:21 AAS
>>902
そんな設計だったから68030とか68040の世代になっても、思ったほど早くなかったんだな

905: 09/24(水)01:24 AAS
PowerMacの初期モデルで通常版機種はキャッシュメモリ非搭載にした蛮行も、前からの前歴の延長だったんだな、おそろしい

906(1): 09/26(金)03:45 AAS
>>893
VRAMとメインメモリが兼用てこと？

907: 09/26(金)15:37 AAS
MacIIくらいからはVRAMというか vide card がNuBusに刺さる形式になってる
一体型のやつは最後までメインメモリと兼用だった気がする

908: 09/27(土)14:25 AAS
68040世代になると流石にメインメモリと共有では無かった。
メインとは別のDRAMをビデオ用として基板に貼り付けたりとか。当然、増設不可。

909: 09/27(土)18:47 AAS
>>906
供用だったね。今で言うユニファイドメモリアーキテクチャ。ただ、使うメモリは汎用の64Kbitや256kbitDRAM、サイクルタイムの大きさがシャレになっていない。
LISAから始まった設計だけど、LISAも一体型Macも16dotCLKがタイミングの基本単位。その半分の8dotCLKをVideo読み出しに、残り8dotCLKをMPUに割り当てている。
16bitメモリだから一回のVideo読み出しで16dot分読めるのでそうなっている。
が、8bit時代の68系みたいな同期BUSじゃないから、VideoとMPUアクセスのサイクルスチールなんて事は無理なので、MPUアクセスは割り当てられたアクセスタイミングまでひたすら待ちになる。
これでVRAM部分だけ別のメモリチップになっているのなら、VRAMアクセス最大xxウェイトとなるんだけど、メインメモリの一部がVRAM領域なのでアプリケーションソフトは最悪7ウェイト(一体型Macの場合)を常時食らう。
LISAはMPU CLKがdotCLKの1/4なので、実はちょっとしたサイクルスチール状態になる。同期が取れていない状態からは最悪3ウェイト食らうのだけれど、最初のワードアクセスが同期したら連続するワードアクセスはノーウェイトになる。
省2

910(2): 09/27(土)20:11 AAS
普通の64Kbit汎用DRAMでもビデオ表示は連続アドレスなのでページモードアクセスすれば速かったのにイギリス製8bitパソコンしか使わずに広がらなかったんだよな
IBM PC一色に塗り固められてビデオチップがMC6845って古いのに遡ってロストテクノロジー化してしまう
1980年代初頭に70年代よりも技術が落ちて行くと言う

911: 09/27(土)20:30 AAS
CPUからのアクセスが同じページとは限らないし、ロジックが面倒くさくなる割に効果は微妙なところでしょ。
ページモードで効果的なのは少ないメモリチップの数で高解像度が実現できるとかそういう感じだと思う。
日本のPCは値段が高いこともあって大量にDRAM積んで24bitバスで高解像度を実現してたから、わざわざページモードを使う必要がなかったのでは。

912(1): 09/27(土)20:36 AAS
Amigaのユーザー改造でページモード使って2倍アクセスが流行ったりしたぞ
Amigaは6800バスのように68000も裏表交互なアクセスさせてるが、ビデオの方を2回アクセスに増やす改造ができた
メーカーではできないロストテクノロジーだったが

913: 09/27(土)21:19 AAS
>>910
なるほど、ページモードアクセス＋バッファリングなら少しタイミングに余裕を作れるね。
日本の8bitパソコン、特に普及機を目論んだ機種はVRAMアドレスの下位側をRowアドレスに、上位側をColumnアドレスにしてMUXすることで、CRTC読み出しをDRAMのリフレッシュと兼用させてた。
そしてDRAMコントロール回路はなるべくシンプルな構成に、FM-8/7なんかは特にそんな感じ。
だからページモードを使えない。VRAMアドレスの最下位bitだけColumn側にMUXすればイケるけど、あまり手の込んだことをできるコントロール回路じゃなかった。
ある程度のロジックを集積できて、30MHzとかそのあたりで動かせるゲートアレイが使えるようになったら各社とも各種やってきたみたいだけど。

914: 09/28(日)00:09 AAS
>>912
それはBitBltみたいな機能があるから2倍にすると効果があるってだけだろ。
ビデオ表示を2倍速でアクセスしても解像度を2倍にしたいとかでもない限り何の意味もないわ。

915: 09/28(日)00:10 AAS
あと、もっと言うと、日本のパソコンはページモードを使ってないなんてのがそもそもデマで
MSX2は使っている。

916: 09/28(日)00:51 AAS
80年代初頭にMSX2が使えてた人も居たのか

917(1): 09/30(火)01:44 AAS
>>910
あれ、これはもしかしてと思ってFM-11の回路図見てみたんだが、FM-11のサブシステムは恐らくこの制御パターンだね。
メモリがニブルモード対応なので、Videoデータの読み出しはそれを使っているっぽい。
640x200ドットモードの場合、68B09のEクロックのL/HでVideo/MPU切り替えをすれば普通にサイクルスチール出来るんだけど、640x400ドットモードだとドットクロックが高速になって68B09の最高周波数をあからさまに越える(640x200ドット時も0.8%程オーバークロックしてるけど)
FM-11活用研究を見てみると、サブ側のタイミングジェネレーターは4bitカウンタの出力からグラフィックVRAM周りのタイミングを作成しているので、最長16dotCLK周期で動いていると考えられる。
ということで640x400モード時のタイミングを推測すると、最初の8CLKでニブルモードも使って16dot分のデータを取得、後続の8CLKでMPUによるVRAMアクセスとすると一応破綻無く動作すると思える。
確認のためDRAMアドレスをMUXしている部分を見てみると、ニブルモードでカウントUPされる2bitがしっかりColumn側の下位bitに配置されているし、Videoデータ用シフトレジスタの前段に8bitのD-F/Fが入れられていて8dot分のバッファになっている。
省3

918: 09/30(火)02:50 AAS
>>917
ニブルモードによるメモリ高速アクセスと言うとZ800CPUが対応してたのが有名だったが
ビデオに使ってた例もあったんだな
ニブルモードとかバーストモードとか呼ばれて結構な高速化だったのに採用例が少ない

上下前次 1-新書関写板覧索設栞歴

ｽﾚ情報赤ﾚｽ抽出画像ﾚｽ抽出歴の未読ｽﾚ AAｻﾑﾈｲﾙ

ぬこの手ぬこTOP 0.041s