assembly RE: "Why Do You Need DOSBox?"

[kalipar]

if my CPU is x86-64, can I (assuming I have the product's complied code, not the source code, and have adequate knowledge) 

1. go from 16bit assembly -> 16bit assembly with ONLY the mov opperation(opcode) [the may be very inefficient, but is turing complete]-> treat it like 'native' x86-64, since each mov just needs to be replace with a movt (16bit mov) 
2. perhaps, decompile the game (automated reverse engineering) to C code, on a 32bit CPU-> recomplie the game to native x86-32 -> run it on a x86-64 with windows 10 (which afaik cant do 16bit)

are they any other fun and interesting ways to run code old 16bit code? 

[Master Disaster]

5 minutes ago, kalipar said:

if my CPU is x86-64, can I (assuming I have the product's complied code, not the source code, and have adequate knowledge) 

1. go from 16bit assembly -> 16bit assembly with ONLY the mov opperation(opcode) [the may be very inefficient, but is turing complete]-> treat it like 'native' x86-64, since each mov just needs to be replace with a movt (16bit mov) 
2. perhaps, decompile the game (automated reverse engineering) to C code, on a 32bit CPU-> recomplie the game to native x86-32 -> run it on a x86-64 with windows 10 (which afaik cant do 16bit)

are they any other fun and interesting ways to run code old 16bit code? 

So fun fact, even the most modern Intel CPU you can buy today (I'm not sure about AMD CPUs) retains 100% backwards compatibility with all 8086 instructions. The problem lies in software, the Windows kernel dropped support for 16 bit apps.

 

I'm no programmer and I know next to nothing about ASM so I can't help you but I do think its interesting that technically you could run MSDOS V1 on a Core I9 assuming you can get past the hardware restrictions.

[Unimportant]

On 12/25/2019 at 7:15 PM, kalipar said:

if my CPU is x86-64, can I (assuming I have the product's complied code, not the source code, and have adequate knowledge) 

1. go from 16bit assembly -> 16bit assembly with ONLY the mov opperation(opcode) [the may be very inefficient, but is turing complete]-> treat it like 'native' x86-64, since each mov just needs to be replace with a movt (16bit mov) 
2. perhaps, decompile the game (automated reverse engineering) to C code, on a 32bit CPU-> recomplie the game to native x86-32 -> run it on a x86-64 with windows 10 (which afaik cant do 16bit)

are they any other fun and interesting ways to run code old 16bit code? 

It's not so much about the CPU executing the instructions, a modern x86-64 CPU is perfectly capable of executing 16-bit code, but more about the entire execution environment. A computer is much more then simply which instructions a CPU understands.

 

Any x86 CPU still boots in real mode, which is a 16-bit environment capable of accessing 1MB RAM using a 16-bit segment:16-bit offset memory model. Install freeDOS and you can run all the 16-bit DOS programs you want. However, much of these old programs are hard coded to access certain peripheral hardware directly. Many of these peripherals have been removed or modernized trough time, resulting in missing or malfunctioning functionality or even flat out crashing when the software tries to access these non-existing/modified peripherals. And, as said in the video, many things will run way too fast, which can also cause technical issues as lots of old software has hard coded timing routines for talking to hardware, etc. 

[Mira Yurizaki]

One of the issues with say trying to convert 16-bit x86 to x86-64 is it breaks any sort of "hack" programmers back then were doing. Heck, this surfaced as soon as x86 was 32-bit capable with the infamous Line A20 issue.

 

There's also the issue that a lot of apps at the time heavily depended on how fast the machine was.

 

EDIT: Had a brain fart, the Line A20 was an address mode issue, the processor was still 16-bit. But still, similar things could happen.