<p>the function that sneakily changes DS also changes SI.</p><p>fun.</p><p>this is definitely hand written assembly because compilers make more sense than this</p>

<p>after it makes that array of 256 0xFFFFs, it makes another array that&#39;s the values 0-255. </p><p>suspicious. definitely doing some kind of huffmanning or LZ*</p>

<p>I can&#39;t find the exact details but that&#39;s definitely what&#39;s happening</p>

<p>okay it&#39;s doing some weird effective-address calculating that means there&#39;s an implicit SS: prefix on that address.</p><p>Ghidra is not showing this to me, which is very very confusing</p>

<p><span class="h-card" translate="no"><a href="https://social.nancengka.com/users/gombang" class="u-url mention">@<span>gombang</span></a></span> yes, Filipinos love basketball. But it&#39;s no longer as popular as before. Probably because people watch less tv now.</p>

<p>I&#39;m now reading the DOSBox source code to try and figure this out because I have a normal life</p>

<p>wikipedia has a great article documenting the ModR/M format used in x86 encoding, including a very handy table explaining how it works (in 16bit mode, too!), but it never mentions segment selectors once.</p><p><a href="https://en.wikipedia.org/wiki/ModR/M" target="_blank" rel="nofollow noopener noreferrer" translate="no"><span class="invisible">https://</span><span class="">en.wikipedia.org/wiki/ModR/M</span><span class="invisible"></span></a></p>

<p>it IS pulling from the SS register, but I do not know why</p>

<p>SS:BP+06 is in linear addresses, 27748h</p><p>but DS:BP+04 is 37758h</p><p>those are different places. this shouldn&#39;t work, unless I&#39;m missing something very badly</p>