PC98はハード上縦スクロールは出来ても横は難しい、というのをどっかで見たので一応メモ。
実物を持ってないので、動画を見た限り、ですが。

EGCを使うと、読み込んだ部分のVRAMを四プレーン一括で書き込む機能がある。
これを使うと、movswで1プレーンを扱う時間で４プレーンを書き換えられて高速。
で、当然書き込みをドット単位でシフトも可能。
これを単純に使うと、VRAMの関係上縦スクロールでの処理は割と簡単。
横スクロールの場合はVRAMがつながっていて動かした端が反対側に出てくるので、そこを処理する必要がある。
で、1dotだけのデータになる様に処理して400行分書き込んだりするのは遅くなってしまう、気がする。

動画を見た限りでは、左端に16ドット(か8ドット)を1行下に書き込んでおき、ずらすとそこが出てきて描画、となっている。
こうするとデータを処理する必要もなく描画が楽で、書き込みタイミングの時は敵出現を避けるなどの工夫をすれば速度の維持もしやすそう。

ずらす部分のライン数を指示しておけば無駄も出ないが、全ラインで行った方がキャラ書き換え判定が短い気もする。
ずらしている部分のキャラ画像がずれるので、静止状態でもキャラ書き換えは毎フレーム必須になりそう。

↑当たり判定の大雑把な情報データを用意して、それが含まれるword範囲だけを書き換えた方が効率的な感じでしょうか。
そういう情報で絞った方が地形の当たり判定も軽くなるわけですし。
連続地形は3,2,1とかのデータ構造にすれば、転送word範囲もわかるしスライドアウトしても便利かも、と思いましたがメモリを食うのが難点になりそう。

0or1なら容量は軽くなりますが、セグメントの関係でチェックと転送がやや手間になりそうな気がします。
この場合はテキストマスクした黒の部分のVRAM上やV画面外領域に展開しておくと効率的になりそうなような気もしますが、プレーン４つを駆使しないとキャラクタ合成含めたスペースが足りなさそうなのと、その辺のIO出力が必要で実際に書いてみないと分からない所ですね。

縦の分割スクロールは途中から次の行に飛ばすようにすれば(word単位で画面を区切る必要有り)同様の処理でいけそう。
縦に画面分割した横スクロール、のような場合だと端の処理がやや面倒で実用化は速度面できびしいか。

GDCのSCROLL命令で表示開始アドレスを変えれば、VRAM表示領域が変わって縦の全画面スクロール処理が簡単に作れるらしいです。
この方法を使ったことがないので詳しくないのですが、多分byte単位でのアドレス指定だろうと思うので8dot単位での横スクロールも可能じゃないかなと。(80バイトで1ラインでOK)
とするならば、8dotの高速横スクロールは(キャラ表示でアドレス変換が必要だが)背景付でも割と高速に出来るっぽいんじゃないかなと。
動画を見直してないので気のせいかもしれませんが、この項を書くもととなった同人ゲームのラストステージのタネになっている可能性もあるのかもしれません。
キャラ関係以外の再描画が画面下部だけで済む事になるので。
絵夢絶党さんによるとword指定らしいので、EGC使ってるんでしょうかねぇ。

※GDCテクニカルブックではSCROLL命令の他のコマンドで画面分割や分割スクロールも可能である、とは書いてありますが、詳しい記述がなかったりします。 絵夢絶党のHPで詳しい内容がありましたので、そちらをご覧になるといいと思います。