wraggster
November 24th, 2009, 11:07
Pate has posted more news of his Dos Emulator for the DS:
Last saturday I started working on the internal BIOS and DOS emulation, which until now had mostly been just a collection of quick hacks to get certain programs running. I decided to rewrite much of it, reorganize the source files to logical collections, etc. A lot of maintenance work, in other words.
I also downloaded source codes for FreeDOS, to learn how a real DOS version handles stuff like memory allocation and task launching. Much of saturday was spent just looking at the code and figuring out the best ways to do something similar in DSx86. Saturday evening I managed to get a proper memory allocation scheme working in DSx86.
Sunday morning I then rewrote the task launching code, which now should resemble the way real DOS works. It is still missing some features, but I managed to launch both COM and EXE files (still bundled with the core) using the new code, so in principle it seems to be working.
Perhaps the biggest reason why I wanted to make the internals work like in a proper DOS is that I *really* don't want to write a command interpreter (or shell) for DSx86. I've written about a dozen language parsers in the past, and writing yet another couldn't be less interesting. So, I try to make my DOS kernel look-a-like be able to run an existing DOS shell, like 4DOS (which is what I used instead of COMMAND.COM back in the early 90's when coding the original LineWars games).
I just got 4DOS.COM to run up to presenting the prompt inside DSx86, so I think I will by default support 4DOS as a command interpreter for DSx86. It is very feature-rich compared to the standard DOS shell, it is faster, takes less conventional memory, and best of all, it is nowadays freeware! So I think it will be a good way for me to avoid writing yet another parser.
However, 4DOS has one very annoying feature: It uses an unaligned stack pointer! It does this only in a very small snippet of it's code, but that was enough to crash DSx86 (where I had assumed that no coder in their right mind would use byte-aligned stack pointer, and thus used ldrh/strh opcodes for all stack emulation). Now I had to fall back to separate ldrb/strb opcodes, only because of a few lines of code in 4DOS.COM! Very annoying!
Well, I just hope I can figure out some new tricks to speed up the stack handling back to the previous level in the future.
http://dsx86.patrickaalto.com/
Last saturday I started working on the internal BIOS and DOS emulation, which until now had mostly been just a collection of quick hacks to get certain programs running. I decided to rewrite much of it, reorganize the source files to logical collections, etc. A lot of maintenance work, in other words.
I also downloaded source codes for FreeDOS, to learn how a real DOS version handles stuff like memory allocation and task launching. Much of saturday was spent just looking at the code and figuring out the best ways to do something similar in DSx86. Saturday evening I managed to get a proper memory allocation scheme working in DSx86.
Sunday morning I then rewrote the task launching code, which now should resemble the way real DOS works. It is still missing some features, but I managed to launch both COM and EXE files (still bundled with the core) using the new code, so in principle it seems to be working.
Perhaps the biggest reason why I wanted to make the internals work like in a proper DOS is that I *really* don't want to write a command interpreter (or shell) for DSx86. I've written about a dozen language parsers in the past, and writing yet another couldn't be less interesting. So, I try to make my DOS kernel look-a-like be able to run an existing DOS shell, like 4DOS (which is what I used instead of COMMAND.COM back in the early 90's when coding the original LineWars games).
I just got 4DOS.COM to run up to presenting the prompt inside DSx86, so I think I will by default support 4DOS as a command interpreter for DSx86. It is very feature-rich compared to the standard DOS shell, it is faster, takes less conventional memory, and best of all, it is nowadays freeware! So I think it will be a good way for me to avoid writing yet another parser.
However, 4DOS has one very annoying feature: It uses an unaligned stack pointer! It does this only in a very small snippet of it's code, but that was enough to crash DSx86 (where I had assumed that no coder in their right mind would use byte-aligned stack pointer, and thus used ldrh/strh opcodes for all stack emulation). Now I had to fall back to separate ldrb/strb opcodes, only because of a few lines of code in 4DOS.COM! Very annoying!
Well, I just hope I can figure out some new tricks to speed up the stack handling back to the previous level in the future.
http://dsx86.patrickaalto.com/