gbadev.org forum archive

Hi all!

For the last 4 months I have been working on an x86 emulator for NDS.
Now finally I have something to show for my efforts, so I decided to
announce this project, and release a technical demonstration.

DSx86 currently emulates 80286 processor, MCGA 320x200 screen and SoundBlaster audio.

You can find the demo at http://dsx86.patrickaalto.com/

The demo has my old DOS game LineWars II bundled with the emulator core. The emulator runs the game between 5 and 15 fps, with rare peaks up to 30 fps, depending on the amount of ships alive and visible on the screen.

I have also a blog/diary on my DSx86 web pages that gives some background about the emulator in case you are interested.

Thanks for reading!

Edit: Beta version 0.43 released! See the link in my signature.

Pate
_________________

Now working on DSx86 http://dsx86.patrickaalto.com
Get LineWarsDS from http://linewars.patrickaalto.com

Last edited by Pate on Sun Jul 01, 2012 6:30 am; edited 27 times in total

This sounds amazing, I'll try it the second I can find my DS!

[EDIT]
Very impressive!
Looks great, sounds great :D

wow, awesome, all the best of luck with this one :)
_________________
Webmaster of Nintendo DS Emulation News

http://nintendo-ds.dcemu.co.uk

When it can run Master Of Orion, then I'll just sit around all day and all night with my DS playing nothing but that game.
_________________
"We are merely sprites that dance at the beck and call of our button pressing overlord."

Very impressive. There is a DS port of DOSBox but it runs at 1 FPS with no sound on even the most simple game. Your emulator seems much faster.

Do you think you could get Alley Cat or Paratrooper working at full speed?
_________________
GTAMP.com/DS

Last edited by Sektor on Sun Nov 08, 2009 7:06 am; edited 3 times in total

Thanks for your encouragement!

Quote:

Do you think you could get Alley Cat or Paratrooper working at full speed?

That shouldn't be a problem. I plan to support all 320x200 modes, including CGA (for Elite) and EGA (for the Sierra adventure games like Leisure Suit Larry and Space Quest).

Thanks for the links to those games, btw! Giving me a link to a game download increases the chances that this specific game is the next one to be supported considerably! :-)

Quote:

When it can run Master Of Orion...

Master of Orion seems to require a 386 processor, so it won't run on my emulator, sorry. Some of the design decisions I have made in my emulator are bad for 32-bit support, and changing those would make also 16-bit support slower.

In general, if a DOS game runs on 286 processor and in 320x200 resolution it should work in my emulator in the future. The biggest worry I have is that some game uses the Parity or Auxiliary Carry flags, as I don't support those at all (and adding support would be VERY difficult without sacrificing pretty much all the current performance). There is a chance that I could code a game-specific support for those flags, but currently I just hope I won't ran into a game that uses them. :-)

My emulator is not based on DOSBox, I have only used it as a reference (which reminds me, I need to add a "credits" page on my DSx86 web site). DOSBox is very good at what it does, but is not the best option when absolute best performance is necessary.

There are still various optimization tricks I haven't used, for example if I could just get self-modifying code to work reliably I could immediately make my emulator about 10% faster, but all my attempts to use it have been failures so far.

But, I'll keep working on it and we'll see how it improves!

Thanks again!

Pate
_________________

Now working on DSx86 http://dsx86.patrickaalto.com
Get LineWarsDS from http://linewars.patrickaalto.com

Pate wrote:

Master of Orion seems to require a 386 processor, so it won't run on my emulator, sorry. Some of the design decisions I have made in my emulator are bad for 32-bit support, and changing those would make also 16-bit support slower.

Are you sure it requires a 386? Some old FAQ reports people successfully running it on a 286.
_________________
"We are merely sprites that dance at the beck and call of our button pressing overlord."

Dwedit wrote:

Are you sure it requires a 386? Some old FAQ reports people successfully running it on a 286.

Not at all, I just quickly Googled for minimum hardware requirements. If it runs on a 286, then it perhaps could be made to run in my emulator.

Pate
_________________

Now working on DSx86 http://dsx86.patrickaalto.com
Get LineWarsDS from http://linewars.patrickaalto.com

hm slightly off topic, arethere any sites that give you a list of what are 286 games?
_________________
Webmaster of Nintendo DS Emulation News

http://nintendo-ds.dcemu.co.uk

Generally, if it requires only Conventional Memory or "Expanded Memory", and doesn't obviously require protected mode (no copy of DOS4GW), it probably runs on a 286.
_________________
"We are merely sprites that dance at the beck and call of our button pressing overlord."

Use a small table for the parity (and logical flags if you want to), if you need it for 16bit values eor the 2 bytes before looking up the table.
_________________
I probably suck, my not is a programmer.

I was reading your comments about adlib emulation, very impressive how you got it to run at 32KHz.
I also tried that same OPL emulator, though I grabbed it from scummvm and was only able to get 8KHz from it if I remember correctly.

Lazy1: Thanks, I did make a lot of optimizations to the algorithm while converting it to ASM. There are still features missing (no vibrato, and I think I broke the amplitude modulation also at some point) and I haven't been working on it for a while.

LW2 uses only SoundBlaster digital audio (it uses my own 6-channel mod player version, 4 channels for music and 2 extra for sound effects), I was actually quite surprised that the highly optimized and time critical x86 ASM sample mixing loop runs emulated as well as it does in DSx86.

FluBBa: Yes, I know of the table lookup method for the parity flag, it's just that I would then have to remember the value that changed the parity flag (if I use the "lazy flags" method, which sounds the most suitable), and that would add extra code to a lot of opcodes, which will slow things down. And I hate that. :-)

Wraggster & Dwedit: Also, if the game was released before around 1992, it will probably support 286, if between 1992 and 1995 it might support, if later than 1995 then it is likely that it requires a 386 processor, though of course not necessary.

Pate
_________________

Now working on DSx86 http://dsx86.patrickaalto.com
Get LineWarsDS from http://linewars.patrickaalto.com

WOOOOOW Pate, this is looking way too good, I never thought that the DS would ever be able to handle a dos-emulator, and even less that it would have the ability to emulate a dosgame at this speed!. You have to be a skilled coder!^^ Keep up your excellente work , I am looking forward for updates!

Pate wrote:

LW2 uses only SoundBlaster digital audio (it uses my own 6-channel mod player version, 4 channels for music and 2 extra for sound effects), I was actually quite surprised that the highly optimized and time critical x86 ASM sample mixing loop runs emulated as well as it does in DSx86.

Perhaps emulating a GUS could help you move the mixing code to ARM?

Very nice :-)

kusma wrote:

Perhaps emulating a GUS could help you move the mixing code to ARM?

Yes it would, and it would be fun to emulate a GUS, as it closely resembles the NDS hardware. However, I'm not sure how worthwhile it would be, as most games that use GUS are coded when 386/486 processors started to be mainstream. It would help in LW2, certainly, but how fast LW2 runs in DSx86 is pretty much irrelevant.

BastarB & ingramb: Thanks for your kind comments! I am reasonably experienced in x86 ASM, but only a beginner with ARM ASM. This is actually my first ARM ASM project.. :-)

Pate
_________________

Now working on DSx86 http://dsx86.patrickaalto.com
Get LineWarsDS from http://linewars.patrickaalto.com

Wow Nice to see such a ambitious emulation project good luck

a dumb question but can dis emulator runs the original doom game O_o ?
_________________
Website / Blog

Let the nds be with you.

It has no chance of running Doom since Doom requires at least a 386 and it uses DOS4GW. It would also be mostly pointless since there is a port of Doom on DS.
_________________
GTAMP.com/DS

Sektor wrote:

It has no chance of running Doom since Doom requires at least a 386 and it uses DOS4GW. It would also be mostly pointless since there is a port of Doom on DS.

Yeah, and Doom requires VGA.

Great project!

Do you think it would be able to run Wasteland and the Goldbox series RPGs in the future?

Anyway, good luck!

kusma wrote:

Sektor wrote:

It has no chance of running Doom since Doom requires at least a 386 and it uses DOS4GW. It would also be mostly pointless since there is a port of Doom on DS.

Yeah, and Doom requires VGA.

MCGA practicality is the 320x200 256 color VGA mode.
_________________
"We are merely sprites that dance at the beck and call of our button pressing overlord."

Sektor wrote:

Very impressive. There is a DS port of DOSBox but it runs at 1 FPS with no sound on even the most simple game. Your emulator seems much faster.

Do you think you could get Alley Cat or Paratrooper working at full speed?

OMG I can just say THANK YOU SEKTOR! Do you know for how long I had searched for the name of that game?? For ages, so now i know it's paratrooper! YEY!!!^^

kusma wrote:

Sektor wrote:

It has no chance of running Doom since Doom requires at least a 386 and it uses DOS4GW. It would also be mostly pointless since there is a port of Doom on DS.

Yeah, and Doom requires VGA.

I could not run Doom on my 286, but I could run Wolfenstein 3d, Windows 3.0 and plenty of decent games, of which my favourites were:
- Solar Winds 1+2
- Asteroids
- Wolfenstein 3d
- Carmon Sandiego
- Turbo C++ 6.22 ;)

I love solar winds! but I haven't played it in at least 12 years.
Now I have to search out all these old classics, and one day play them anywhere on my ds :)

Wolf3d does run on a 286, it's a little slow on my 12MHz 286 box but I'm still curious how well the emulator would run it.

That's impressive, man! I gave it a run yesterday evening... well, it's really impressive to think it's a PC running in there!

I'm waiting for the release to test it with the games I coded -back in the days- in Pascal+ASM and other wonderful games I loved... ahem... will you support FAT access too?

Looking really good so far, can't wait till it can load up more games. Anyone know if windows 3.1 is small enough to work on it? :P

Thanks for all your kind comments again!

ggx2neo: Windows is most likely out of the question, I believe it needs protected mode support. In any case it would be way down on the priority list of software to support. Games that have a version ported to DS are not very high on the list either, as a direct port will always run much better than an emulated version. If they happen to run on my emulator, fine, but I won't spend time adding special support for them.

sverx: Yes, I plan to support FAT access (if I understand correctly what you mean by it). The emulator will have a DOS prompt "C:\>" where you can launch a .com or .exe file on your SD card, and give some simple commands like DIR and CD. I'm toying with the idea of actually 'booting' some real DOS version, but that might be a dumb idea. On the other hand, writing a command line parser and all the DOS commands is not very appealing either, but I'll see how it goes.

sfg: I'm not familiar with those titles, you'll just have to see when a full version is eventually released. :-)

I'm currently trying to get Norton SYSINFO running, I'd like to see it's benchmark of the CPU speed. Next is the old game Paratrooper, it is small and uses CGA graphics, which is an interesting new feature to support.

Pate
_________________

Now working on DSx86 http://dsx86.patrickaalto.com
Get LineWarsDS from http://linewars.patrickaalto.com

Well I just thought windows on the DS would be cool, but it's no big deal if it doesn't work. What I'm really looking forward to is some classic Red Baron action (my intel suggests that it works on a 286 system), I used to play that game for hours when I was a kid. :) Anyway, this is one of the most exciting homebrews I've seen in a long time. Good luck man and keep up the good work.

Pate wrote:

sverx: Yes, I plan to support FAT access (if I understand correctly what you mean by it).

Yes, I wasn't clear enough. I mean: will you support DOS interrupts for file access (21h)? Many games have their assets outside the exe file...

sverx wrote:

Yes, I wasn't clear enough. I mean: will you support DOS interrupts for file access (21h)? Many games have their assets outside the exe file...

Ah, ok. Yes, I actually already support many of the INT 21h disk access routines. For example Wing Commander 2 consists of a lot of files that it loads into memory when needed and swaps out again.

ggx2neo: Thanks, yeah I figured you wanted Windows running just for the fun factor. :-)

Pate
_________________

Now working on DSx86 http://dsx86.patrickaalto.com
Get LineWarsDS from http://linewars.patrickaalto.com

Will this emulator support external ram-packs like the EZ 3in1? or is that unneeded? I wish you all luck with this very promising project!^^

Pate wrote:

sfg: I'm not familiar with those titles, you'll just have to see when a full version is eventually released. :-)

For example:
http://www.mobygames.com/game/dos/wasteland/techinfo
http://www.mobygames.com/game/dos/pool-of-radiance/techinfo

As far as I can tell they should work, but of course you'll know better than me. I'm not sure if they require protected mode or not.

Oh yeah, and hopefully you'll emulate the PC Speaker too. :)

It would be pretty cool if the original Ultima series could be supported too :).
Especially Ultima VI: The False Prophet.

http://www.mobygames.com/game/dos/ultima-vi-the-false-prophet/techinfo

BastarB: No support for external RAM packs is currently planned. The standard 4MB should be enough to emulate the normal 640KB of RAM, plus around a megabyte of EMS. That should be enough for most 286 games.

sfg & phoenixclaws: Those games seem to have very modest system requirements, so it should be no problem running them.

Yes, I plan to support PC Speaker as well. :-)

Btw, I appreciate that you guys posted your first posts on this forum in this thread. Welcome to the forum! :-)

Pate
_________________

Now working on DSx86 http://dsx86.patrickaalto.com
Get LineWarsDS from http://linewars.patrickaalto.com

:P I check all of the major homebrew forums but I wasn't signed up on this one. But after seeing this homebrew I had to sign up to say nice job. If everything goes as planned and you get some pretty good compatabilty in the end, you could have the best homebrew app on the DS so far. :)

Pate wrote:

plus around a megabyte of EMS.

EMS support? Cool! :D

Just got Norton SYSINFO to run. It says the machine has a 10MHz 80286, with the CPU speed bar showing 11.6 times original PC. See the actual image on my blog (see my sig for the URL). Pretty good, I think!

Pate
_________________

Now working on DSx86 http://dsx86.patrickaalto.com
Get LineWarsDS from http://linewars.patrickaalto.com

Pate wrote:

BastarB: No support for external RAM packs is currently planned. The standard 4MB should be enough to emulate the normal 640KB of RAM, plus around a megabyte of EMS. That should be enough for most 286 games.

sfg & phoenixclaws: Those games seem to have very modest system requirements, so it should be no problem running them.

Yes, I plan to support PC Speaker as well. :-)

Btw, I appreciate that you guys posted your first posts on this forum in this thread. Welcome to the forum! :-)

Pate

Awesome. Oh yeah, and a scaler too, to fit everything on the screen if that's possible.
When this project takes off maybe you'll want to add a donation option on your site. I'd like to show my support too, not only ask for features. :)

Pate wrote:

Just got Norton SYSINFO to run. It says the machine has a 10MHz 80286, with the CPU speed bar showing 11.6 times original PC.

So it's like an 8088 running at 55,332 MHz ;) (...or a Compaq 386/33 running at 1/3... not bad at all!)

Pate wrote:

Just got Norton SYSINFO to run. It says the machine has a 10MHz 80286, with the CPU speed bar showing 11.6 times original PC. See the actual image on my blog (see my sig for the URL). Pretty good, I think!

Pate

Nice results, but I think a benchmark that's dominated by divisions is far from representative of the real capabilities of the emulator. Especially with an interpreter. The ratio of fetch/decode to execute for a divide instruction is going to be much different from most instructions.

Of course, this is only true if it really is just using divisions.

sfg: Yeah, a scaled screen option is coming. I'll think about that donation idea, haven't done anything like that before.

Exophase: The 10 MHz value is based on division instructions, but I believe the 11.6 speed index is not. I haven't checked what that is based on, but if my emulator ran at the speed of 10MHz 286, it would have gotten a speed index of only around 6.

Btw, what is interesting is that PocketDOS shows on their screenshots page a 206MHz StrongARM running Norton Sysinfo, and getting a speed index of 12.1 (with a division-based speed estimate of 33MHz). It looks to be a different version of Norton Sysinfo, but still...

http://www.pocketdos.com/screenshots_hpc.htm

The same page also show Windows 3.0 running on that thing, so I guess it would be theoretically possible to run Windows on DSx86 as well, eventually.

Oh, and those values on my blog are from No$GBA. When running on real DS Lite, it showed "Intel 80286, 11MHz" and speed index of 11.3.

Pate
_________________

Now working on DSx86 http://dsx86.patrickaalto.com
Get LineWarsDS from http://linewars.patrickaalto.com

Then yeah, I wonder what it's actually doing. I take it the file is not freely available anywhere.

It's not that surprising that your emulator would perform much better than DOSBox, but I don't think that the score you got represents the maximum your computer can do. Chances are you had cycles set to something that was artificially limiting it. You should check that, and the CPU time used while emulating that section.

I'm actually surprised No$ gets results as close as the real thing. I'm guessing what you're running is very cache friendly. I take it your interpreter is sitting in ITCM? And the working set for the benchmark probably fits in dcache easily enough.

It'd be nice to determine how many millions of instructions per second you're capable of emulating, for some "normal" sorts of instructions. Unfortunately, w/o cycle counting you can't do such a thing in the emulator and would have to rely on a benchmark to say so. Wikipedia says that a 286 at 12MHz is capable of 0.15 MIPS/MHz; personally I think this value looks too low and the real one should be closer to 0.2-0.25.

So we're looking at somewhere between 1.5 to 3 million instructions per second that your emulating is doing - or an average of about 20-40 ARM9 cycles per instruction. That's not especially unrealistic, although a little surprising still given all the fetching and decoding that goes into an x86 instruction. If your instruction stream is dominated by register and small (8bit) immediate instructions and you have a quick path for mod = 3 then I think these numbers are pretty realistic.

Well, I've done cycle counting with my emulator, the results are on my blog. The main opcode fetch loop is in ITCM, as are most of the single-byte instruction handlers and string instruction (REP) handlers.

I think your estimate of 20-40 ARM9 cycles per instruction is correct, as it takes between 11 and 30 timer ticks, including the timer start/stop overhead, to emulate an instruction. Since the timer runs at half clock speed, that corresponds to 22-60 CPU cycles (including overhead).

Anyways, I think I need to concentrate on making the emulator work with actual software next, not just optimizing the performance, although I find the latter generally much more interesting. :-)

Pate
_________________

Now working on DSx86 http://dsx86.patrickaalto.com
Get LineWarsDS from http://linewars.patrickaalto.com

Pate wrote:

Oh, and those values on my blog are from No$GBA. When running on real DS Lite, it showed "Intel 80286, 11MHz" and speed index of 11.3.Pate

So a lower speed index and an higher MHz value... fun :) [btw I've run some tests some time ago while working on libXM7/zlib integration -let's call it so- for MMLL and I noticed no$gba was performing gzip uncompression a little bit *faster* than the real hardware. I'd say the opposite but, well...]

I'll just get to the point.
Civilization

Hi Pate
Thanks for your hard work
Can you post a version of the demo that can launch Wing Commander 2 ?

PS : Do you think that Epic Pinball can work with DSx86 ?

Mavromatis wrote:

I'll just get to the point.
Civilization

Oh...wow....that would change my life forever.

This topic is starting to look like a wish list... mmm... Dune II? :D :D

gauauu wrote:

Mavromatis wrote:

I'll just get to the point.
Civilization

Oh...wow....that would change my life forever.

Why?? it's already available for the DS as Civilisation Revolution?

Pate wrote:

Well, I've done cycle counting with my emulator, the results are on my blog.

Are you sure they're up? I don't see them :(

mortys: Sorry, the WC2 version is not yet in a presentable state. I haven't checked the system requirements of Epic Pinball. I think I actually have that game, though, so I can eventually check. I have quite a few of the old Epic games, as part of the deal I had with Safari Software/Epic MegaGames with LineWars II.

Exophase: See the table below "Aug 30th, 2009 - ITCM". Unless you mean something else by cycle counting than what I thought? Each "tick" in that table is 2 CPU cycles.

All: It's fine to post wishes for games to support, I can always pick the ones that are accessible and interesting from a technical viewpoint to support first. :-)

I started working on the old Paratrooper game, as it has CGA graphics and uses PC Speaker, both of which I want to support. It contains impressively neat code, no extra baggage, every instruction has a purpose. Very nice to work with code like that.

Pate
_________________

Now working on DSx86 http://dsx86.patrickaalto.com
Get LineWarsDS from http://linewars.patrickaalto.com

I don't want to sound like a code vampire or something, but are you planning to release your OPL emulator changes?
Sorry if the request is out of line since it looks like you put a lot of work into it.

Both Wolfenstein and Doom would benefit from having such an emulator for playing their music.

Pate wrote:

Exophase: See the table below "Aug 30th, 2009 - ITCM". Unless you mean something else by cycle counting than what I thought? Each "tick" in that table is 2 CPU cycles.

Sorry, I thought it was a new post, I didn't think to look through the old ones. I wonder exactly how much overhead the timer start/stop is adding - it's probably nothing for starting it, since all of that happens before it starts running, but would have something for getting the value/stopping it. Wouldn't it be better to keep the timer always running and record the start/stop ticks and subtract the two?

One other thing.. I just want to let you know in case you aren't aware.. if you're using code that's under the GPL (in this case debug_disasm.cpp from DOSBox) then the GPL technically requires you to make your entire project GPL, not just indicate that you're using the code. This applies even if you didn't modify the file at all. So you might want to consider redoing the disassembler before someone comes demanding you release your source code.

SteveH wrote:

gauauu wrote:

Mavromatis wrote:

I'll just get to the point.
Civilization

Oh...wow....that would change my life forever.

Why?? it's already available for the DS as Civilisation Revolution?

Because I'm less interested in a newish civ game as I am in playing Civ 1 for the rest of my life.

Lazy1: My OPL emulation does not sound very good yet, but when I have improved it I might release the source. It is actually a complete rewrite, not just changes to the fmopl.c.

Exophase: Yes, keeping the timer running might be faster, but it was simpler to get consistent values by starting and stopping it.

About the debug_disasm, the code is originally by Robin Hilliard, with the following copyright:

Code:

/* COPYRIGHT: Robin Hilliard, Lough Guitane, Killarney, Co. Kerry, Ireland.
Tel: [+353] 64-54014
Internet: softloft@iruccvax.ucc.ie
Compu$erve: 100042, 1237

If you feel like registering, and possibly get notices of updates and
other items of software, then send me a post card of your home town.
*/

It is also available at http://code.google.com/p/squidutils/source/browse/trunk/Std/disasm.cpp?spec=svn2&r=2 under Apache License, which does not require distributing derivative works to include source code. I guess I need to switch to using that code instead of the DOSBox code. On the other hand, my releasing the source is not completely out of the question, but I don't want to do that yet when DSx86 is still in the early stages.

Thanks for pointing this out!

Pate
_________________

Now working on DSx86 http://dsx86.patrickaalto.com
Get LineWarsDS from http://linewars.patrickaalto.com

Just another "Oh man, I can't wait to ..." post, but playing Sherlock (no warez, those are shareware, and that's the developer's site) on the DS would be heaven. It's essentially an elimination puzzle game (think sudoku), but is hugely addictive, and I've been playing it for years now. The .doc provided with the version I have (1.5) lists the sysreqs as follows:

Quote:

REQUIREMENTS: IBM PC compatible computer with at least 512K of RAM. EGA/VGA compatible display with at least 128K or RAM.
Microsoft compatible mouse.

That said, it does run very large, at 640*350, so I have doubts as to the practicality of playing it on the DS. Still, there's plenty of other stuff worth playing that should be within realistic realms, so much appreciation for this emulator.
_________________
I've got nothing to say, but it's OK.

Sektor wrote:

It has no chance of running Doom since Doom requires at least a 386 and it uses DOS4GW. It would also be mostly pointless since there is a port of Doom on DS.

Yes, a half working one :')

And doom works just on dos 6.1 O_o and doesn't require anything extra. But I think this emulator could handle this simple 386 game simply.
_________________
Website / Blog

Let the nds be with you.

Hi,
I've seen on your blog that you speak about using a 6*8 font to show a bigger part of the screen, have you considered using subpixel font to improve this? like the 4x8 one seen on http://www.haluz.org/yesh/?

Thanks for the tip on subpixel fonts, elwing! However, looks like it is not very suitable, as I need to be able to display coloured text, and even 4x8 font would not show the whole 80 columns, so scrolling would still be needed.

Pate
_________________

Now working on DSx86 http://dsx86.patrickaalto.com
Get LineWarsDS from http://linewars.patrickaalto.com

I see you got Paratrooper running, nice work. :) What are you going to work on next?

Thanks! Currently I'm looking into supporting Master of Orion. Gotta give Dwedit something to do all day and all night. :-)

Pate
_________________

Now working on DSx86 http://dsx86.patrickaalto.com
Get LineWarsDS from http://linewars.patrickaalto.com

Hi Pate! I saw your blog, It's nice to see that you got paratrooper running^^

I also read about the issues with Master of Orion! Well, I will think about some other good games that may aid you in your development of this very promising emulator!

have a nice day, and keep up the good work^^=D

Test Drive III might be interesting, it's _playable_ on my 12MHz 286.

I guess Ultima 6 would be a good game to try next. I think it uses entirely conventional memory. It's also a very very buggy game though, but that's another story.
Or maybe lemmings?
_________________
"We are merely sprites that dance at the beck and call of our button pressing overlord."

Thanks for the ideas of new games to try!

I'm currently coding a simple DOS kernel, so that I can properly launch games from an SD card, instead of having to bundle them with the emulator core. That will then also allow me to release the first alpha version of the emulator for you all to try.

Pate
_________________

Now working on DSx86 http://dsx86.patrickaalto.com
Get LineWarsDS from http://linewars.patrickaalto.com

Pate wrote:

Anyways, I think I need to concentrate on making the emulator work with actual software next, not just optimizing the performance, although I find the latter generally much more interesting. :-)

That seems very reasonable. Kudos to your discipline. I believe many people were thinking of doing an x86 emulator, and got stuck in premature optimization. ;-)

I think an obvious game to try (if it hasn't been mentioned already) is Sopwith
_________________
Warhawk DS | Manic Miner: The Lost Levels | The Detective Game

You know what else might work, is the first couple of Duke Nukem titles (shareware downloads: I and II), moreso the first, back when they were run-and-gun platformers. Sysreqs:

Quote:

Duke Nukem

There is no sound card support for this title. All sound is PC Speaker.

Duke Nukem II

The first was EGA, second was VGA. The second game also had optional SB/Pro support.

It's also worth noting that the first game's actual gameplay takes place on a 208*160 "window", well within the bounds of the DS. That cuts out the health and weapon, score, etc. but even most of that would fit on screen due to the borders around everything (see screenshot).
_________________
I've got nothing to say, but it's OK.

Hello, my question might seem a non-sense but I don't know assembly at all...
In the download page of the official website, I saw this:

Quote:

Since the actual emulator is still very limited in the opcodes, DOS calls and hardware it can support, I can not release a version that would allow you to test any DOS program on it (as with a 99.9% probability they wouldn't work).

Is there a possibility that text only based games like Infocom's A Mind Forever Voyaging or Hitchhicker's Guide To Galaxy would be part of the 0,1% games already potentially supported by Pate's emulator (or at least which wouldn't require months of work to run)?
Sorry for my english!

lincruste wrote:

Is there a possibility that text only based games like Infocom's A Mind Forever Voyaging or Hitchhicker's Guide To Galaxy would be part of the 0,1% games already potentially supported by Pate's emulator

I think most Infocom games can already be played via DSFrotz:
http://gugusse.central.free.fr/papafuji/DSFrotz.html
_________________

Quote:

Would that be the internet driver for the program?

Oo :shame:
Thanks, I'm using it now, it perfectly works... Now my DS's complete! Sorry for bothering and good day all.

headspin wrote:

I think an obvious game to try (if it hasn't been mentioned already) is Sopwith

Lazy1 ported Sopwith to DS a few years ago.

Great that paratrooper is working.
_________________
GTAMP.com/DS

It'd be cool to have keyboard profiles that map between the DS buttons and certain emulated keys. So for different games one could have different profiles in order to control them (many games should be easily controllable with 12 buttons).

Thanks for your comments again!

Ant6n: My plan has been to have configurable DS keys, and your idea of having several profiles is a good one. Thanks!

lincruste: The reason why most games will not yet work is mostly due to my "on-demand" support for opcodes. I have been adding opcodes (and their modrm bytes) only when a game encounters a previously unsupported opcode. This just so that I can see the progress, and also because when I started this project I wasn't sure if it will be doable at all, so I didn't want to spend a lot of time on something that will then have to be abandoned. So, even if a game is text only, it is no more likely to work than a graphics game. Oh, and most games should only take a few days or a week of work to support, not months. :-)

Vague Rant: Ah, Duke Nukem might be reaosnably easy to support. I don't yet have EGA support so Duke Nukem 1 would probably take more work to support than Duke Nukem 2.

headspin: Ah, Sopwith, that brings back memories! :-) Might be easy to support, but if there already is a DS version it is not very high in my priority.

Anyways, I am currently trying to get 4DOS running as a command interpreter. All sorts of problems with it yet, but getting it to work would allow me not to have to code a command shell myself.

Pate
_________________

Now working on DSx86 http://dsx86.patrickaalto.com
Get LineWarsDS from http://linewars.patrickaalto.com

Pate: First, I might be the only person here to say this, but I remember Line Wars II! I played it quite a bit on my old 486, and recall it as being a good game. I'm afraid I never registered it, though. Sorry! ;-)

Anyway, I don't have too much constructive to throw in about your project, although I am really excited about it and wish you the best of luck. Personally, aside from Wing Commander (the thought of which on my DS makes me swoon) what I'd really love to see supported are the late-80s Sierra adventure games. Space Quest 3, Quest for Glory 1 & 2, and soforth.

I also second the call to get your program to play Alley Cat. Since it's a CGA game from the 8088 era that still runs on computers today, I can't imagine it would be that difficult to implement.

Also, to whoever it was who was talking about playing Civ I on the DS: It's worth mentioning that the emulator SnemulDS can play the SNES port of Civ quite well. You might have to mess around with the layers to get the menus to display properly, but I found it perfectly playable.

Quote:

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!

Couldn't you spare a few cycles to check if its byte aligned or word aligned and use seperate code for each case. That way you wont get such a speed loss on both cases.

Normmatt wrote:

Couldn't you spare a few cycles to check if its byte aligned or word aligned and use seperate code for each case. That way you wont get such a speed loss on both cases.

Yeah, that's what I plan to do when I have the time. The problem is that there are quite a few places where stack access is used (all PUSH and POP opcodes, plus CALL, RET, IRET, etc). So that means duplicate code for quite a few places, but I'm sure the gains will be worth it, considering 99% of the time the stack will be halfword-aligned. Oh, and I could also keep the aligned code in ITCM, and the unaligned version in normal RAM (as it can/will be slower anyways).

InnocentBystander wrote:

Pate: First, I might be the only person here to say this, but I remember Line Wars II!

Thanks, it's always nice to hear from other old-timers! :-) You're not the only person on this forum to say that, but perhaps the first on this thread.

Btw, I already downloaded AlleyCat, but haven't yet tested it on DSx86. It should be easy to support (which is also partly why I haven't tried it yet, I have more challenging software to test in the queue!).

Thanks again for your comments!

Pate
_________________

Now working on DSx86 http://dsx86.patrickaalto.com
Get LineWarsDS from http://linewars.patrickaalto.com

Had a chance to try DuneII? I'd pay to play with it on my DS... :rolleyes: :)

Pate wrote:

.. The problem is that there are quite a few places where stack access is used (all PUSH and POP opcodes, plus CALL, RET, IRET, etc). So that means duplicate code for quite a few places, but I'm sure the gains will be worth it, considering 99% of the time the stack will be halfword-aligned. Oh, and I could also keep the aligned code in ITCM, and the unaligned version in normal RAM (as it can/will be slower anyways).
..

I don't know the exact structure of your emulator, but you probably decode the opcode and dispatch to the correct execution of it based on some table. Presumably the base pointer of that address might be in a register even. So you could create a second table for the case where SP is misaligned. So now you don't have to put a check every time, you just have to change the address of your table look up when the SP becomes misaligned.

sverx: No, sorry, been busy with the DOS kernel emulation.

Ant6n: Yes, I have the main opcode table in stack, so that I can access it via SP register as the base register. I can't easily switch to another table, but I can simply change the table contents for the PUSH/POP opcodes whenever the emulated stack pointer becomes aligned or unaligned. That's the way I plan to optimize the stack handling, just haven't gotten around to it yet.

Last weekend I didn't have quite as much time to work on DSx86 as I would have liked (real life intruded), but I did manage to make some small progress with the internal DOS emulation.

Pate
_________________

Now working on DSx86 http://dsx86.patrickaalto.com
Get LineWarsDS from http://linewars.patrickaalto.com

oh ok.
...of course you could also move whatever other data is on the stack to your 'mirror' location and point the SP there as well (not much more than emulated cpu state, maybe?).
Isn't it fun to think about optimizing stuff like that? :P

Man this is the most awesome thing since awesome, I can't wait. It's already going along pretty quickly and it hasn't even hit alpha stage yet.

Pate, you are officially my hero. <3

For everyone else, it seems like he updated today. :D Yaaaay.

http://dsx86.patrickaalto.com/DSblog.html

Ant6n: Yeah, optimizing is the most fun part of coding the emulator! I have tried having two stacks in the past, when I tried to improve the interrupt handling, but I couldn't get it to work reliably. Though I have to admit, I tried to change the stack inside an interrupt handler, which is most likely a bad idea in any case. But I had to try and see what happens. :-)

Anacobra: Thanks for your kind comments! Welcome to the forum! I hope DSx86 can eventually live up to your high expectations. I have to remind you, it is just my hobby project and the first ever emulator I have coded, so the first versions will certainly be very limited and buggy.

But, I hope to improve it as time passes.

Pate
_________________

Now working on DSx86 http://dsx86.patrickaalto.com
Get LineWarsDS from http://linewars.patrickaalto.com

Saw your blog post, Pate, sounds like DSx86 would make a great Christmas present if everything goes as planned.

If anyone's interested (and as long as you don't mind), I put together a quick RSS feed for Pate's DSx86 blog here.
_________________
I've got nothing to say, but it's OK.

Sure, I don't mind, thanks for publishing the RSS feed!

Pate
_________________

Now working on DSx86 http://dsx86.patrickaalto.com
Get LineWarsDS from http://linewars.patrickaalto.com

Solar Winds! I played the hell out of that, always wanted to try the second one, but for the nostalgia factor I'd rather play the first on DS. This just keeps getting better and better. Obviously there's no guarantees or anything, but it's always nice to see you specifically working on games I love. ;)
_________________
I've got nothing to say, but it's OK.

Quote:

I suppose a real PC might wrap the physical RAM address back to low memory with addresses like 0xFFFE:0xFFF0,

Umm, I think 8086 and 286 had a different behaviour in this case. Not sure, though. Does somebody know for sure?

Man, I just read your blog about all problems and stuff that has encountered during the development and how you fixed them. You are doing an excellent job Pate! Keep it up!!! And have a nice day!^^

Anyone know if Stunts!/4D Sports Racing had any -requirements- higher than what dsx86 has been mentioned to support? :)

Thanks for your comments again!

I managed to get Solar Winds logos to display, but even that required some new code, as for some peculiar reason SW moves data from main RAM to VRAM with a code like this:

Code:

push ds
mov ax,[6B99]
mov es,ax
mov ax,A000
mov ds,ax
loop:
mov al,es:[di]
mov [si],al
inc di
inc si
cmp di,4380
jne loop
pop ds

I really don't see what's the advantage of that instead of using source and destination indices like they are supposed to be used, and why not do it in the standard way:

Code:

mov ax,[6B99]
mov ds,ax
mov ax,A000
mov es,ax
mov cx,something
rep movsb

which does pretty much the same thing, but much more efficiently!

The original code runs quite slowly in DSx86 compared to the string instruction code. Hopefully the actual game code uses string instructions, I haven't yet gotten that far so I don't know yet.

Pate
_________________

Now working on DSx86 http://dsx86.patrickaalto.com
Get LineWarsDS from http://linewars.patrickaalto.com

Pate wrote:

... for some peculiar reason SW moves data from main RAM to VRAM with a code like this:

Code:

push ds
mov ax,[6B99]
mov es,ax
mov ax,A000
mov ds,ax
loop:
mov al,es:[di]
mov [si],al
inc di
inc si
cmp di,4380
jne loop
pop ds

Quite fun. Seems backwards :)
Dyslexia on the part of the programmer? :P

Suddenly I'm reminded of the compiler optimization thread... maybe some undereducated developer thought they were being particularly clever and efficient. :)

Hello, I like what I am seeing so far!

Just wondering, you've included Linewars II in the NDS file itself as a technical demonstration, in future releases how will you make DOS games accessible?

Also, a few suggestions:

Jill of the Jungle
Bio Menace
Monster Bash

I think all of these have minimum requirements of a 286 computer...so I hope you can get them to work! :) (System requirements for Bio Menace and Monster Bash can be seen here .

EDIT: Also wondering about the second series of games of Commander Keen. (The first series, Invasion of the Vorticons, is already emulated by CommanDS Keen, coded by Alekmaul)
The system requirements for Commander Keen 4 (Secret of the Oracle which is the first part of the Goodbye Galaxy series) were:

SYSTEM REQUIREMENTS

* XT Computer (286 or higher recommended)
* 565k of conventional memory
* 1 meg of Hard Drive Space (for shareware)
* 3 meg of Hard Drive Space (for registered)

OPTIONALLY SUPPORTED

* Sound Blaster or 100% compatible
* Adlib
* Joystick
* Gravis Gamepad
* Disney Sound Source

Hope this can be emulated. *fingers crossed*

Fancypants wrote:

Hello, I like what I am seeing so far!

Just wondering, you've included Linewars II in the NDS file itself as a technical demonstration, in future releases how will you make DOS games accessible?

Thanks!

DSx86 uses libFAT to access the SD card, like it was a C:\ disk drive. I have a DSTT card so that I don't need to do any patching or things like that to make it work on my DS Lite hardware, and to be honest I don't even know the details regarding this patching thingy, so I just hope you can make it work in your environment like you do with other nds files that need file access.

I also have a bundled version, which currently has 4DOS and a couple of small games (currently PTROOPER, ALLEYCAT and ELITE) inside the nds file, so that I can run it in No$GBA without any trickery to test it easily. I won't release this version, though.

By the way, the released version won't work at all without 4DOS.COM on your SD card. I'll provide you with the necessary info and download locations for that as well when I release the emulator. Sorry for this extra bother, but I think the advantages of a real command shell are well worth the extra hassle. You can even use 4DOS to build a game menu within DSx86, using it's advanced batch file and screen writing features!

I'm thinking of requiring the 4DOS.COM to be either on the root of your SD card, in the \4DOS\ directory, or anywhere on the card if you have a CONFIG.SYS in the root directory with a "SHELL=path\4DOS.COM" line in it. Does anyone have any objections to this? The last option will also enable other command shells in the future.

Quote:

Also, a few suggestions:

All of those seem to be suitable for DSx86, so there is a good chance they will eventually work.

Pate
_________________

Now working on DSx86 http://dsx86.patrickaalto.com
Get LineWarsDS from http://linewars.patrickaalto.com

Consider adopting the \DATA\ folder convention used by some homebrew programs, which helps declutter the root of the card. I'm not sure if this means that the file location would be at \DATA\4DOS\4DOS.COM or \DATA\DSX86\4DOS.COM or \DATA\DSX86\4DOS\4DOS.COM (etc) but in all cases, the root is decluttered since (hopefully) multiple applications all use the DATA folder.

The config file is also a decent idea, and is used by SNEmulDS for path configuration.

I'm glad to hear about all of that!

So just wondering, how will you use the native controls of the DS?

The D-Pad will most likely be the arrow keys correct? :p

A, B, X and Y could be Alt, Ctrl, Shift and Enter/Space? What do you have planned for this?

An interesting idea I had...if in the config file or some other file you could designate the controls depending on what game has been booted, because different games use a variety of different keys, (and I don't want to be playing with the touch-screen all the time) is this possible do you think? I suppose you would need a large collaborative effort to get a lot of games though I guess...

dantheman: Ok, I believe \DATA\DSx86\ would work fine as the location for the required files of DSx86.

Fancypants: Your idea is pretty much spot on what I have planned. :-) By default D-Pad will be the arrow keys, and A will be Enter. Other default keys I haven't decided yet, but I plan to have an optional section per game in the configuration file (probably using INI-file syntax) where you can override the keys per game. You can also override the default screen handling method (blit/direct write, scaled/scrolled) and other things that might need per-game configuration. I'll provide a default configuration, but I expect the user to then modify this file to suit their needs and add their own game sections there.

For example, I can't play WC2 using the default up/down arrows (as the ship moves to the wrong direction). The configuration file will allow swapping of the Y-axis for this game to suit my preferred up/down steering style, even when the game itself does not have this configuration.

I would like to have a GUI for updating this configuration info, but I'm pretty sure that won't be in the first released version yet.

Pate
_________________

Now working on DSx86 http://dsx86.patrickaalto.com
Get LineWarsDS from http://linewars.patrickaalto.com

Is there any hope to see Windows 3.0 or 3.1 run on this one day ?

There is slight hope that Windows 3.0 might run (in real mode) some day. I personally don't see much use for that, so supporting it is not high on my priority list.

Pate
_________________

Now working on DSx86 http://dsx86.patrickaalto.com
Get LineWarsDS from http://linewars.patrickaalto.com

Pate -

The idea of having to have a config.sys in the root of my DS card makes me giggle. However, my suggestion - and this is just my personal taste - is to confine things to subdirectories. I find that the root of my DS card is absolutely *filled* with incomprehensible crap due to all the various homebrews and things that require files in the root, yet I can't delete stuff because I don't know what files are used by what. I much prefer it when programs can keep things contained in subdirectories, just for the sake of tidiness.

If anyone formats their card as FAT16, you MUST keep stuff out of the root directory. That filesystem limits the size of the root directory, unlike FAT32.
_________________
"We are merely sprites that dance at the beck and call of our button pressing overlord."

Ok, sounds like a directory like \data\DSx86\ will be the best location for the required files. I'll use that as the default, but allow the files to be put on root as well.

Btw, I'm using a separate SD card for DSx86 development, mainly so that I don't destroy my other DS homebrew stuff if there is a serious bug in DSx86 FAT handling (or in a DOS program I'm running on it). You might want to consider this as well, just to keep your other important data safe. I'm a bit worried as DSx86 gives such full access to your whole SD card, so that giving for example a "del *.*" command will really delete everything in that directory. I don't think I'll support commands like "format c:", though, as that would not result in anything useful. :-)

Pate
_________________

Now working on DSx86 http://dsx86.patrickaalto.com
Get LineWarsDS from http://linewars.patrickaalto.com

Regarding your latest blog post and the inability to test with no$gba, have you considered trying the "FCSR" DLDI file? It's a method with which you create a virtual FAT12 filesystem with all the files you need, tack it onto the end of the .nds file, and load the entire thing with no$gba.

You can either follow the instructions at http://dev-scene.com/NDS/FCSR_Tutorial or simply install "DLDIrc" which includes two-click FCSR image creation as a feature. In either case, if you choose to try it, I would highly suggest using Dwedit's "add_to_disk_image.exe" program rather than the included "BFI.exe" program, as it's more stable in creating the FAT12 image. Simply put it in the same folder, open up build.bat in Notepad, and replace the "bfi.exe -q -c0 -f=%1 %2" line with "add_to_disk_image.exe %1 %2" to make it work.

There's also the EFS filesystem for the DS, which I believe offers a similar feature, but I have not looked into this at all so I don't know anything else about it.

If I remember correctly libfilesystem works under no$gba.

Lazy1 wrote:

If I remember correctly libfilesystem works under no$gba.

Yup libfilesystem works under no$gba fine, and IIRC is a hell of a lot more stable than EFS is.

dantheman wrote:

Regarding your latest blog post and the inability to test with no$gba, have you considered trying the "FCSR" DLDI file? It's a method with which you create a virtual FAT12 filesystem with all the files you need, tack it onto the end of the .nds file, and load the entire thing with no$gba.

Ah, thanks for the info and links! I was aware there was a method like this, but I hadn't found good instructions on how to use it. This method allows the nds file to grow over 4 megabytes, correct?

It's not a huge deal having to use real hardware for much of the testing, but I'm afraid the SD card contacts (or more likely the slots) might stop working eventually when I keep inserting and ejecting the card dozens of times a day.

Pate
_________________

Now working on DSx86 http://dsx86.patrickaalto.com
Get LineWarsDS from http://linewars.patrickaalto.com

Pate wrote:

I'm afraid the SD card contacts (or more likely the slots) might stop working eventually when I keep inserting and ejecting the card dozens of times a day.

This is part of the reason why one of the first things I wrote for the DS was something that'd let me send stuff to my SD card over Wifi.
_________________
It's not an illusion, it just looks like one.

Pate wrote:

This method allows the nds file to grow over 4 megabytes, correct?

My guess is that if there is a limit, it would be 32 MB. There probably isn't, but I don't have any evidence either way. It's over 4 MB though, I can tell you that.

Wifi transfer is also another good option, assuming you only need to transfer a small number of files each time. As another option to Pete's program, I used httpexec for a while myself, which worked well until it stopped working on my card for some reason (which I never bothered figuring out).

No clue what libfilesystem is, but it may be less tricky to setup than FCSR image creation, in which case it would be worth looking into.

EDIT: There are also a few options for transferring wirelessly via FTP: DSFTP, Lilou Combox, and DSLinux. DSLinux can also interface with standard Windows network drives with SAMBA if configured properly.

dantheman wrote:

Pate wrote:

This method allows the nds file to grow over 4 megabytes, correct?

My guess is that if there is a limit, it would be 32 MB. There probably isn't, but I don't have any evidence either way. It's over 4 MB though, I can tell you that.

Wifi transfer is also another good option, assuming you only need to transfer a small number of files each time. As another option to Pete's program, I used httpexec for a while myself, which worked well until it stopped working on my card for some reason (which I never bothered figuring out).

No clue what libfilesystem is, but it may be less tricky to setup than FCSR image creation, in which case it would be worth looking into.

EDIT: There are also a few options for transferring wirelessly via FTP: DSFTP, Lilou Combox, and DSLinux. DSLinux can also interface with standard Windows network drives with SAMBA if configured properly.

AFAIK libfilesystem is VERY simular to the nitroFS that the official carts use, just to run libfilesystem apps on a real DS you need to run it via the homebrew menu launcher application that is in the devkitPro's SVN. To use libfilesystem you just need to set up a directory in your project, add a couple of defines in the makefile (look at the libfilesystem example in your examples folder that comes with devkitPro) and compile it.

The max size of an nds file with libfilesystem is approx 32MB (IIRC), also note that if you use the homebrew menu to run your apps it sets up a couple of things that are very handy for applications that use files on the SD card, like the current directory is set to the one your NDS file is in - which means that your data folder does not need to be in the root, it can be in the same folder as your nds file.

I'm using the homebrew launcher instead of the supplied launcher on my EzFlash Vi, and appart from a couple of games that expect the data folder to be in the root folder everything is in it's own sub folder - no need for the /DATA/DSx86 folder, you can just use DOS/command.com to access command.com in the dos sub folder of your SD card (making the current folder the root of your virtual C: drive)

SteveH wrote:

Yup libfilesystem works under no$gba fine, and IIRC is a hell of a lot more stable than EFS is.

I was updating my old project to build againt the latest devkitARM r27 and I played around with these two just recently and found out some things:

1) looking at the code, I prefer libfilesystem.. written "more correctly" IMO

2) EFS 2.0 is faster as it uses read/lseek, and open()'ing files is much quicker (the internal finding of the files is faster)

3) libfilesystem can be sped up by changing the code to use file desc instead of the stream... basically change fread, fseek to read/lseek in nitroSubRead()... also the open()'ing files in your project that contains lots of files sitting in a single dir will give you a speed hit (from my testing on hw.. YMMV)

4) however, it's probably not worth doing #3 in most projects and the improvement might seem negligable to some. Plus, libfilesystem is maintained and a part of the toolchain and also see #1

5) The only unstable part of EFS 2.0 (that I have come across) is the dirnext() stack problem which is used in the SearchDirectory() call. This can be fixed completely with this code:

Code:

// search in directory for the NDS file
bool SearchDirectory() {
DIR *pdir;
struct dirent *pent;
struct stat statbuf;
bool found = false;
char path[EFS_MAXPATHLEN];

pdir = opendir("."); if (pdir) {
while(((pent = readdir(pdir)) != NULL) && (!found)) {
stat(pent->d_name, &statbuf);
if(S_ISDIR(statbuf.st_mode)) {
if(strcmp(".", pent->d_name) != 0 && strcmp("..", pent->d_name) != 0) {
chdir(pent->d_name);
found = SearchDirectory();
chdir("..");
}
} else {
getcwd(path, EFS_MAXPATHLEN-1);
strcat(path, pent->d_name);

if(CheckFile(path, true)) {
found = true;
break;
}
}
} }
closedir(pdir);

return found;
}

This function only gets called once to write out the NDS path first time you ever run your program (or rename/move it afterwards). Funny thing tho, I changed to diropen/dirnext/etc while using libfilesystem and still got corruption... it's as if the problem is in libfat or something.

6) libfat 1.0.4 (built using r27, don't use pre-built) is a lot faster than the latest 1.0.6 (and 1.0.5). I believe that new caching stuff that was put in it really killed it for my particular set up.

I decided to stick with EFS 2.0 (with code changes as listed in #5) and linked against an r27 build of libfat 1.0.4 ... this setup gave me almost 3x faster in loading/reading files off the SD card (im my particular project, YMMV) when compared to the stock libfilesystem and libfat that's in r27.

For the best of both worlds, I check for argv[0] and, if found, use that in efs_path. If that fails, only then do I let the SearchDirectory() call go do its thing.

wintermute may chime in on this, but these are just my own little experiments :)

Last edited by ritz on Tue Dec 22, 2009 7:35 pm; edited 1 time in total

ritz wrote:

5) The only unstable part of EFS 2.0 (that I have come across) is the dirnext() stack problem which is used in the SearchDirectory() call. This can be fixed completely with this code:

Code:

// search in directory for the NDS file
bool SearchDirectory() {
DIR *pdir;
struct dirent *pent;
struct stat statbuf;
bool found = false;
char path[EFS_MAXPATHLEN];

pdir = opendir("."); if (pdir) {
while(((pent = readdir(pdir)) != NULL) && (!found)) {
stat(pent->d_name, &statbuf);
if(S_ISDIR(statbuf.st_mode)) {
if(strcmp(".", pent->d_name) != 0 && strcmp("..", pent->d_name) != 0) {
chdir(pent->d_name);
found = SearchDirectory();
chdir("..");
}
} else {
getcwd(path, EFS_MAXPATHLEN-1);
strcat(path, pent->d_name);

if(CheckFile(path, true)) {
found = true;
break;
}
}
} }
closedir(pdir);

return found;
}

This function only gets called once to write out the NDS path first time you ever run your program (or rename/move it afterwards). Funny thing tho, I changed to diropen/dirnext/etc while using libfilesystem and still got corruption... it's as if the problem is in libfat or something.

ritz, what do you mean by this? Are you calling that function when your using libfilesystem? If you are I take it its because of the issues with the current card launchers not providing the arguments to the nds files correctly, and if that's the case you should use the homebrew launcher as that's the only thing that you can really use to launch your nds files correctly at any point.

No, that code is to replace the same named function in the EFS 2.0 code. It fixes a stack problem related to this.

EDIT: Just clarifying...

ritz wrote:

Funny thing tho, I changed to diropen/dirnext/etc while using libfilesystem and still got corruption... it's as if the problem is in libfat or something.

What I meant here was that I simply tried using the dirnext() calls in my own program (which was linked to the stock libfilesystem) just to check if the bug still existed using libfilesystem.

libfilesystem is not very similar to the nitro filesystem used on official carts, it's a library which currently provides an interface to the nitro filesystem as used on official carts. In the future there will be another couple of interfaces.

The 32meg limit is only when running the nds file from GBA cart or via no$gba & emulators which run the NDS from GBA cart space. On slot 1 cards the limit is raised to the max file size accessible via FAT.

Ritz, if you feel like doing a patch for libfilesystem to use lseek,read,open it would be much appreciated.

There may still be a few tweaks we can do to the cache stuff on DS that may help - on wii/gamecube that code made libfat 10x faster. There's also a small possibility that the speed hit may be related to the DLDI - devkitARM r27 has been patched for unbuffered IO.

I'm really not keen on the search for nds file approach - there are some quite bad failure cases with this and obviously the ideal situation is for all card menus to support argv.
_________________
devkitPro - professional toolchains at amateur prices
devkitPro IRC support
Personal Blog

wintermute wrote:

Ritz, if you feel like doing a patch for libfilesystem to use lseek,read,open it would be much appreciated.

well, here's my first n00by attempt at submitting a patch. No, I don't have a sourceforge account yet :P

Wow, looks like there are a lot of options besides the SD card swapping method! I think I'll look into that WiFi method first, I have a WLAN router but I haven't taken it in use yet (been using only wired network at home). That looks like the least amount of learning new stuff. I'd rather work on getting the first alpha version of DSx86 released than learning new methods of debugging it. :-)

Pate
_________________

Now working on DSx86 http://dsx86.patrickaalto.com
Get LineWarsDS from http://linewars.patrickaalto.com

FYI, the first alpha version 0.01 has now been released!

Pate
_________________

Now working on DSx86 http://dsx86.patrickaalto.com
Get LineWarsDS from http://linewars.patrickaalto.com

Awesome, it works fine on my DS-X. I tested Paratrooper and Alleycat and they ran just as fast or faster than they used to on my XT and the sound is just as good/bad. Great job!

I tried Digger and Pizza Worm but of course unsupported op code and there are DS ports anyway.
_________________
GTAMP.com/DS

Hi there again, just ran the file on my DS and already found something a bit strange...unless something happened that's wrong...

Well as I ran the file the default command prompt starts in "C:/"

This makes it hard to navigate to my programs as they are hidden away in subdirectories to avoid clutter, and I cannot see in the DSx86.ini file anywhere about designating the default folder, or mounting a folder as the C:/ drive.

Can this be changed?

Thanks in advance.

Quote:

Can this be changed?

4DOS uses a startup file called 4start.btm (or 4start.bat). Create such a file into the 4dos directory, and put

cd \data\dsx86\whatever

into it, so you go to the correct directory when you start.

You can put whatever other initialization commands as well to that batch file (or create a menu of your favorite games or whatever).

Sorry I forgot to mention that on my web pages, but I'll compile a FAQ page based on questions I get here. :-)

Pate
_________________

Now working on DSx86 http://dsx86.patrickaalto.com
Get LineWarsDS from http://linewars.patrickaalto.com

It stops reading files in the directory after 14 files! I'll go look into whether the disk image is corrupt or not..
Edit, never mind, the directory was indeed corrupted. I fail at making disk images..

Edit again:
I just tested Ultima 6, and got these unhandled instructions:

02B5:0016 D326AC1E shl word [1EAC],cl
13FF:0008 8C04 mov [si],es
3C2B:001C 8AE0 mov ah,al
023D:1581 0A4EFC or cl,[bp-04]
_________________
"We are merely sprites that dance at the beck and call of our button pressing overlord."

I can also confirm Paratrooper and Alleycat work fine.
I really hope there will be support for Apogee classics in the future, like Commander Keen, Duke Nukem, Crystal Caves, Secret Agent ...
I've tested some games with following errors :

If you are looking for people to test new releases you can count me in :)

Duke Nukem 1
Unsupported INT call!
AX=000D BX=86C0 CX=0704 DX=0201 SP=0FC8 BP=0FC8 SI=100C DI=0041
DS=19EE ES=0000 SS=2769 CS=020B NV UP EI PL ZR ?? ?? NC
020B:0276 5D pop bp

Commander Keen 2
Unsupported INT call!
AX=0002 BX=0001 CX=0000 DX=0001 SP=FFFE BP=091E SI=060E DI=04E3
DS=01FB ES=01FB SS=01FB CS=01FB NV UP EI NG NZ ?? ?? CY
01FB:0398 B409 mov ah,09

Leisure Suit Larry 1
Unsupported opcode!
AX=0720 BX=00C8 CX=0004 DX=0B84 SP=02BF BP=091E SI=00E4 DI=FFFE
DS=01FB ES=01FB SS=01FB CS=01FB NV UP EI PL NZ ?? ?? NC
01FB:0A42 D226CC09 shl byte [09CC],cl

Arctic Adventure
Unsupported INT call!
AX=1C00 BX=003E CX=FFFF DX=D7B2 SP=3E70 BP=3E74 SI=0207 DI=FE6A
DS=1E50 ES=1E50 SS=2E4C CS=150F NV UP EI NG NZ ?? ?? CY
150F:04A2 3C1C cmp al,1C

Digger:
Unsupported opcode

AX=0000 BX=0000 CX=0000 DX=0000
SP=FFB4 BP=FFD6 SI=0000 DI=4C6E
DS=25A6 ES=0040 SS=25A6 CS=020B
NV UP EI NG NZ ?? ?? CY
020B:9A89 F7A00000 mul word [bx+si+0000]

Does anyone know if the The Incredible Machine is supported? I tried running it and get:

Unsupported opcode!
AX=0 BX=01f8 CX=01F8 DX=3f48
SP=FF96 BP=ff9a SI=0 DI=0
DS=2F47 ES=3F48 SS=2F47 CS=1E30
NV UP EI PL ZR ?? ?? NC
1e30:60f2 7a02 jpe 60f6 ($+2)

Is there anyway to reset the emulator when it gets into this state apart from turning the DS off and on again?

Thanks for your bug reports!

When you get an "Unsupported INT call" I need more info from the logs, as the address the debugger points to is the NEXT command after the actual INT call (that's because you can actually continue after such a problem by using the 'G' and 'v' symbols on the bottom row). The messages with yellow text are not fatal errors, though they will probably make the game not run properly.

Quote:

Unsupported opcode!
1e30:60f2 7a02 jpe 60f6 ($+2)

Ah, that's nasty, it checks the parity flag, which I don't support (as ARM does not have that flag). If you can provide me with the whole disassembly part of the log, I might be able to code a workaround for this specific game.

Oh, and there is currently no better way to continue but to reboot the console. I could perhaps add a soft reboot (relaunch the shell) later.

Thanks again guys for taking the time to test it, I know it is probably frustrating for you to test new games when they never work! It is for me, at least. :-)

Pate
_________________

Now working on DSx86 http://dsx86.patrickaalto.com
Get LineWarsDS from http://linewars.patrickaalto.com

Pate wrote:

Quote:

Unsupported opcode!
1e30:60f2 7a02 jpe 60f6 ($+2)

Ah, that's nasty, it checks the parity flag, which I don't support (as ARM does not have that flag). If you can provide me with the whole disassembly part of the log, I might be able to code a workaround for this specific game.

I've zipped up the log and you can download it from:

http://magnetic-inc.myzen.co.uk/dsx86-tim.zip

The .exe was packed with LZEXE put after unpacking it I still get the above error.

Quote:

Oh, and there is currently no better way to continue but to reboot the console. I could perhaps add a soft reboot (relaunch the shell) later.

Yeah, something like what the PC reset button does would be great.

Did a little quick smoketesting on my R4.

Seems to be a bit of weirdness when I do a DIR (but that may be my 4DOS version, as I used the same 7.55 I use on DOSEMU), Unsupported INT call, right after it says Volume in drive C is unlabeled. A "G" gets back where I was.

GWBASIC (3.23) fails with "Unsupported opcode":

Code:

04FD:FC83 20267D07 and [077D],ah

(I can use GWBASIC for a lot of quick smoketesting, when it works)

And apparently Commander Keen 4 (an 8086 app) is failing on a "LEA BX,[DI]". I have both the CGA and EGA versions of it.[/code]

lerock wrote:

Commander Keen 2
Unsupported INT call!
AX=0002 BX=0001 CX=0000 DX=0001 SP=FFFE BP=091E SI=060E DI=04E3
DS=01FB ES=01FB SS=01FB CS=01FB NV UP EI NG NZ ?? ?? CY
01FB:0398 B409 mov ah,09

Hey, by Commander Keen 2 do you mean "Commander Keen in Invasion of the Vorticons: The Earth Explodes", or do you mean the second series of Commander Keen, which is "Commander Keen in Goodbye Galaxy: The Secret of the Oracle"?

Because if you were trying to play "The Earth Explodes" this is "CommanDS Keen" which was a port of "Commander Keen in Invasion of the Vorticons" to the DS. CommanDS Keen plays the first 3 episodes of Commander Keen quite exceptionally except for a bit of lag and buggy graphics occasionally, but otherwise very, very well.

Also, when I ran certain DOS games, they indeed did crash and replied with an error, but according to the DSx86.ini it should've created a log file.

I don't have a log file anywhere on my SD card, is there DSx86 has to do other than crash to need to create a log?

EDIT: Nevermind...stupid me...I though the log would be in the DSx86 folder...not the root...nevermind...*facepalms*

EDIT2: Okay here is my log file. :)

The LOADFIX command from IBM DOS 5 seems to work, if it is necessary to stuff the bottom 64K.

Its COMMAND.COM, though, seems to do things dsx86 doesn't like (specifically int21/ax=6300). I tried that for kicks. :P (There is, for all intents and purposes, no difference in the functionality of PC DOS 5.0 and MS-DOS 5.0. I like IBM DOS, so that's what I tested with.)

Hey guys,

I have read this topic and I have downloaded DSx86...but I don't understand almost everything! So, I have some questions:
- How do you put the .ini file on the SD? I have tried many times but it still doesn't read the .ini.
- How do you put 4DOS on your DS? I have put this on my DS, but I don't think I have done this good.
- How do you get a DOS game working on your DS?

Can someone answer these questions?

Thanks a lot in advance!!
(I'm sorry for my english, it's not my usual language)

BIG THANKS FOR THIS UPDATE PATE.=D=D
I have tried it a little, so far I have not managed to find a game that runs with the exception of the supported games in your game-list.
Should I post every log rapport from every game i try or is it currently unnessesary since this is a so early release?

Keep up the nice work^^ And good luck^^

Nanimes wrote:

Hey guys,

I have read this topic and I have downloaded DSx86...but I don't understand almost everything! So, I have some questions:
- How do you put the .ini file on the SD? I have tried many times but it still doesn't read the .ini.
- How do you put 4DOS on your DS? I have put this on my DS, but I don't think I have done this good.
- How do you get a DOS game working on your DS?

Can someone answer these questions?

Thanks a lot in advance!!
(I'm sorry for my english, it's not my usual language)

Hi Nanimes and warmly welcome to this forum!=)

Check Pates blog at http://dsx86.patrickaalto.com for information regarding the installation of files.

I can shortly say that the .ini file should go to /data/dsx86/ and the 4DOS.COM file should go into a folder named 4dos located here: /data/dsx86/4dos/

To run a program in DOS, you have to mount the correct folder of the game.
For example, if I'm going to play paratrooper, I have to get into the folder of it first. The name of this game-folder is "ptrooper" on my card. And I put it in \data\dsx86\ptrooper (But you can put it on any other location on your cart i think)

To locate that location in dxs86, you have to type the "cd" command just before you type the path you would like to mount. So you have to type it like this:

cd c:\data\dsx86\ptrooper

and then push enter

When you have done this, the commandpromt will look like this:

c:\data\dsx86\ptrooper>

Now this have become the current mounted directory. now you just have to type the name of the game file that is located inside this ptrooper folder. on my card the name is: ptrooper.com

So for me I'm just going to type "ptrooper.com" after the > sign. It will look like this:

c:\data\dsx86\ptrooper>ptrooper.com

Then press enter, and voila, you are inside the game.

Here's another unsupported opcode .log for Sopwith, Populous, Prince Of Persia and Sim City.

http://magnetic-inc.myzen.co.uk/dsx86-2.zip

With 4DOS it is possible to change directories by typing FOLDER\ (trailing backslash). Also, it has tab completion, which is in and of itself one of the main reasons I use it.

Hi Pate,

thanks for the wonderful work so far. Is it possible to run DSx86 in an emulator and if so, how? I would like to shoot some screenshots for my blog.
_________________
My blog:
HomebrewWelt

To BastarB: Thanks for your answers!!! It makes many things clear to me.

EDIT: I'm sorry, but I still can't get the .ini file working. I thought it worked, but a few hours later I turned on the ds again and saw that it still doesn't read the ini file. I have put 'dsx86.ini' in folder data>dsx86 on my SD.
What do I wrong?

Last edited by Nanimes on Wed Dec 30, 2009 6:29 pm; edited 1 time in total

Thanks for all your encouragement and debug logs!

It seems like DSx86 really does not currently run any other games than those I have tried myself, sorry about that. Coding this emulator is quite a big project, almost like eating an elephant, so I have to do it one "spoonful" at a time. :-)

If you feel like testing further games and sending me the logs, that is appreciated, but I already have quite a list of new opcodes and various INT calls I need to add before releasing the next version. I have also found some more bugs in my core emulator, so I'll be busy for the next couple of weeks just with those!

Echtzeit: Sorry, I don't know of an easy way to run DSx86 with a DOS game in an emulator. :-(

usotsuki: Interesting info about 4DOS tricks, LOADFIX and COMMAND.COM. I plan to add support for other command shells, but I think 4DOS is simply the best. :-)

Commander Keen 4 uses "lea bx,[di]"?? Funny... I didn't add that opcode as I didn't think anyone (or anything) would use that!

Again, thanks for your logs!

Pate
_________________

Now working on DSx86 http://dsx86.patrickaalto.com
Get LineWarsDS from http://linewars.patrickaalto.com

It is indeed...4DOS FTW :P

I have tested some games (.ini still doesn't work), and these are the games that not work:

warcraft1 (not in log file)
warcraft2 (not in log file)
bat 'n ball
Stellar Conquest III
mario
Scorched Earth
elder scrolls: arena (not in log file)
elder scrolls: daggerfall

Here's my log file

http://showothers.webs.com/

The .ini file does not work cause when you save it you name it dsx86.ini then save it as all files. oh and can you add .bat support plz that may help with the elder scrolls arena.
_________________
i'm in the corner of your eye were you never want to look http://www.mediafire.com/?noymnnmtwmm

4DOS supports .bat files already, not?

LOL!,not?
_________________
i'm in the corner of your eye were you never want to look http://www.mediafire.com/?noymnnmtwmm

Got a curious message while I was trying to run a DOS game I wrote back in 1997 (it's here, screenshots here):

Unsupported port I/O!

I guess it happens when my soundblaster library is probing I/O ports searching for the soundblaster DSP address... but I believe that on a real PC when a program writes to a port where there's nothing it just does nothing, and when it reads from a port where's nothing it just gets a zero (... or a 0xFF maybe?)

Well, is it possible to change soundblaster I/O settings in DSx86 so that I can try to match the 1st port probed?

Thanks! And congratulation: it's 0.01 but it's already a wonderful work! :D

Heh, yeah, those Unsupported Port I/O messages are there just so that I see if a game does something with a port I don't yet support. I meant to make it not stop for ports that are "well known", like the other possible SB ports besides the one mentioned in the BLASTER environment string, but forgot to do that in the rush to get 0.01 released. :-)

You can hit B to skip those messages and continue with the game. There is a slight problem that hitting B does not swap the bottom screen back to displaying the keyboard, so you might need to click on the upper right X on the keyboard (which at this point is not visible!) to cause a user-breakpoint, and then click on the bottom row 'G' and 'v' to continue with the keyboard visible.

I have spent the last couple of days working on my opcode tester program (as Leisure Suit Larry 3 kept crashing on me and I couldn't find the reason), and now Ihave found about half a dozen bugs in my opcode handlers and now finally LSL3 runs fine. Also, now with the tester program working fine I dare add more opcodes, as I can immediately test that I didn't break anything when adding them.

Thanks again, and Happy New Year everyone!

Pate
_________________

Now working on DSx86 http://dsx86.patrickaalto.com
Get LineWarsDS from http://linewars.patrickaalto.com

Nanimes wrote:

To BastarB: Thanks for your answers!!! It makes many things clear to me.

EDIT: I'm sorry, but I still can't get the .ini file working. I thought it worked, but a few hours later I turned on the ds again and saw that it still doesn't read the ini file. I have put 'dsx86.ini' in folder data>dsx86 on my SD.
What do I wrong?

Your english is almost perfect, for someone who doesn't use it as a first language. What is your primary/first language?

Well first let me just say nice job on the emulator so far, once you start adding more oppcodes and features this thing is just gonna keep getting better :P I do have a question though, when you type dir and it shows all the files, is there any way to scroll up to see more?

You could use "dir/p" ?

Yep, that works nicely. Thanks.

No prob, just some tips from someone who's been there (I *still use* DOS - PC DOS 7, actually - through dosemu, and have used DOS since 1992 on long-antiquated beasts).

do you have to wright a different op code for each game or can one run a few games so in other words is the op code for the processor or game soz bit of noob at programming only known i have for about 3 years
_________________
i'm in the corner of your eye were you never want to look http://www.mediafire.com/?noymnnmtwmm

It's for the hardware but since there are many not supported, it's highly unlikely any non tested games will work at the moment.
_________________
GTAMP.com/DS

To El_Posible: my first language is Dutch. I'm from the Netherlands.

"There's only two things I hate in this world. People who are intolerant of other people's cultures..."

Also in alpha v0.02 can you add the option to use expandable ram also does the elder scrolls arena need a 386 processor or 286 because both the elder scrolls arena and the elder scrolls dagger fall are free from Bethesda soft works website and to play them on d.s would be a dream come true

Edit:I just found out it's 386
_________________
i'm in the corner of your eye were you never want to look http://www.mediafire.com/?noymnnmtwmm

As for Commander Keen 4 that I mentioned, it is an EGA game, but a rare CGA version exists, if that would make testing easier I have it...

when you click on the line wars 2 link it doesn't spell the URL correct as it doesn't put a . in front of the com
_________________
i'm in the corner of your eye were you never want to look http://www.mediafire.com/?noymnnmtwmm

Pate wrote:

Heh, yeah, those Unsupported Port I/O messages are there just so that I see if a game does something with a port I don't yet support. I meant to make it not stop for ports that are "well known", like the other possible SB ports besides the one mentioned in the BLASTER environment string, but forgot to do that in the rush to get 0.01 released. :-)

Oh, thanks :) Can I also ask you to implement ini parameters to configure the soundblaster base port / IRQ / DMA mapping? It could be useful and not too hard to add :)

How exactly do the overflow and halfcarry flags work on the X86, and how similar are the X86 flags to the Z80 flags? SMSAdvance exploits the fact that they work almost the same way as they do on the ARM for certain instructions, and reads the ARM CPSR flags directly, then calculates the halfcarry flag in 3 instructions.
It also uses pre-shifted numbers, so the processor overflow flag and carry flag work directly as expected.

For instance, this is how SMSAdvance executes the Z80 Add instruction:

Code:

MACRO
opADD $x,$y
mov r1,z80a,lsl#4 ;Prepare for check of half carry
adds z80a,z80a,$x,lsl#$y
mrs z80f,cpsr ;S,Z,V&C
mov z80f,z80f,lsr#28
cmn r1,$x,lsl#$y+4
orrcs z80f,z80f,#PSR_H
MEND

But the subtract instruction works slightly differently, since the ARM carry flag has a meaning opposite to the Z80 when subtracting, it inverts the carry flag.
_________________
"We are merely sprites that dance at the beck and call of our button pressing overlord."

Dwedit: My understanding is that the ARM flags (that exist) work just like x86 flags, except for the SUB and CMP instructions that use inverted carry flag. My x86 ADD and SUB instructions look like this:

Code:

.macro add_reg16_reg16 rl rr
adds \rl, \rr
b    loop
.endm
.macro sub_reg16_reg16 rl rr
subs \rl, \rr
b    complement_carry
.endm

op_f5:                      @ Opcode F5 = CMC (Complement Carry)
.global complement_carry
complement_carry:
mrs    r0,cpsr
eor    r0, r0, #0x20000000
.global restore_flags_from_r0
restore_flags_from_r0:          @ Many functions jump here to restore flags and continue loop
msr    cpsr_f,r0
@------ Start the opcode decoder loop
.global loop
loop:

I also use the register values pre-shifted to the upper halfword, and use the ARM flags as-is for the x86 flags.

I try to push back supporting the aux-carry flag "for real" for as long as I can, hopefully I can do that by coding game-specific handlers for those few games that need it.

sverx: Why should the SB port/irq be configurable? I emulate a PC hardware that has SB at port 220 and irq 7, all games should be able to work with those settings. If they don't, it's the game that is buggy! :-)

jam_888: Thanks for pointing out the typo in the download link! I don't think there is need for expandable RAM, I believe 1MB conventional RAM plus 1 MB EMS is enough for all games that should reasonably run on DSx86.

usotsuki: Thanks, but I have quite a few games already to test, and my plan is now to improve the opcode support a lot before the next release, so many games should have a chance to run in 0.02 version.

Pate
_________________

Now working on DSx86 http://dsx86.patrickaalto.com
Get LineWarsDS from http://linewars.patrickaalto.com

Pate wrote:

sverx: Why should the SB port/irq be configurable? I emulate a PC hardware that has SB at port 220 and irq 7, all games should be able to work with those settings. If they don't, it's the game that is buggy! :-)

mmm... well, I admit you're right, don't know what I was really thinking about when I posted that :| I guess I'm lacking of sleep these days...

btw I'm really waiting the next release, hopefully it'll ignore the reads/writes to unknown/unused ports :)

Can you please if it's not to much update your blog more often as i and others probably enjoy reading your progress.
_________________
i'm in the corner of your eye were you never want to look http://www.mediafire.com/?noymnnmtwmm

jam_888: It's nice to hear you like reading my blog posts! I try to write a new post every Sunday or thereabouts, depending on whether there has been progress. I doubt I'll increase the frequency, as writing the blog posts takes time away from actually coding DSx86, and during weekdays I don't have much time to do either anyways.

sverx: I just rewrote much of the port handling. The new code makes it easier to ignore certain port ranges, so that should be in the next version. I don't want to ignore all unknown port addresses, as I need to know for what ports I still need to add support.

Pate
_________________

Now working on DSx86 http://dsx86.patrickaalto.com
Get LineWarsDS from http://linewars.patrickaalto.com

thanks for the reply
_________________
i'm in the corner of your eye were you never want to look http://www.mediafire.com/?noymnnmtwmm

Pate wrote:

I just rewrote much of the port handling. The new code makes it easier to ignore certain port ranges, so that should be in the next version.

Wonderful :) According to some very old specs I have, a soundblaster base port address can be one of the following: 210h, 220h, 230h, 240h, 250h, 260h and 280h (including soundblaster 1.0 and 1.5 base ports...)
Hope it helps :)

I just released version 0.02. It has somewhat improved opcode support, though still far from complete. It also ignores the alternate SB ports, and fixes the problems with Leisure Suit Larry 3 and the SB effects in Solar Winds.

Nothing major has changed, but a lot of minor improvements, in other words. I decided to release it now before I start working on the bigger issues (during which time the code might be broken for longer periods of time).

Thanks for your interest in DSx86, and feel free to send me debug logs again!

Pate
_________________

Now working on DSx86 http://dsx86.patrickaalto.com
Get LineWarsDS from http://linewars.patrickaalto.com

nice job releasing the second alpha but do you remember when you used Norton utilities 5.0 and it said you had a 10 MHz processor well i was wondering if you improved CPU emulation since then and if so can you test it again and show the picture cause i want to know how fast it is now
_________________
i'm in the corner of your eye were you never want to look http://www.mediafire.com/?noymnnmtwmm

New debug log for you.

http://magnetic-inc.myzen.co.uk/dsx86dbg-002.zip

Tested again with the following games

Scorched Earth 1.50
Prince Of Persia
Armour Alley 1.1
Sim City
Sopwith
The Incredible Machine
Populous

Armour Alley gets a lot further now - past the config and bailing out when trying to request EGA graphics. Prince Of Persia, Sim City, Scorched Earth and Populous have unsupported opcodes at different points now, so I guess that's progress too. :)

Thank you so much for all your effort. The day this emulator plays my favourite games, my life will be complete!

Tested games with 0.02 and default config:

Battlechess
Battletech: Crescent Hawks Inception
Castle Wolfenstein
Risk (1989 Virgin Interactive Version)
Microsoft Word 5.5 ( DL from Microsoft )

http://www.mediafire.com/file/etfwnwobmmy/DSx86DBG.zip

Also: As wikipadia says

Quote:

Anecdotal evidence from the period suggests that Microsoft Flight Simulator 1.0 was used as a benchmark
program. It was said that if one's computer could run MSFS 1.0 and Lotus 1-2-3, it was 100% IBM PC-compatible, and if it couldn't, it
wasn't

MS FS 1.0 or 2.0 could be interesting games to test.

Last edited by drdim on Sun Jan 10, 2010 6:48 pm; edited 1 time in total

In Dangerous Dave, the game stucks right after the first level has been loaded.
Here is the log file: http://www.mediafire.com/?zzzzxm2nudg

Very nice job by the way!
Keep going!

Getting "packed file is corrupt" on a few things, chkdsk said my card is fine but I'll reformat later to be sure.

Avoid the noid:
http://pastebin.ca/1745865

After a bit of prodding (and an error about graphics mode) it actually starts playing music.
Pressing the arrow keys causes a "Unsupported string op seg/dir!" though.

Thanks for your encouragement and your log files!

drdim: Yeah, MS Flight Simulator might be interesting to test. Though, I know DSx86 is still very far from 100% IBM PC compatible, so it might not be all that useful to test it yet. But perhaps eventually..

jam_888: I've been concentrating on the coverage of my CPU emulation, not the speed of it, so if anything the current CPU emulation core is somewhat slower than before. My plan is to first add pretty much all the opcodes, and only after that try to optimize it further. First correctness, only then speed. :-)

Lazy1: That "packed file corrupt" is a problem with the original EXE packer code that many of the old games used, there's nothing wrong with your SD card. It is caused by the games loading below the first 64KB of RAM, which corrupts the segment address they use. DOS 5.0 and above had a LOADFIX program to help with this, I plan to include something similar but haven't yet had the time. You can try launching a secondary command shell but telling it not to swap by "\data\dsx86\4dos\4dos //swapping=none" (or whereever you installed 4DOS. Notice the double slashes.

Oh, and welcome to the forum drdim, crypter and all you other users who joined this forum to comment on DSx86. Much appreciated!

Pate
_________________

Now working on DSx86 http://dsx86.patrickaalto.com
Get LineWarsDS from http://linewars.patrickaalto.com

GW-BASIC 3.23:

Code:

04FE:BBF1 FF51FE call near word [bx+di-02]

Commander Keen 4 CGA:

Code:

1484:025B 20E3 and bl,ah

Pate wrote:

[...] It also ignores the alternate SB ports [...]

so my tests could go further :) In fact now it gives unsupported port I/O on a next spot, when accessing ports 0x00A0 and 0x00A1, 'secondary PIC' ports (here a nice document on ports that you might find interesting)

After that it stops then when hitting the Unsupported opcode

Code:

mov es:[di-00A2],bl

which I believe it's been generated by the compiler, not by me :D

Thanks for your efforts! Keep up the good work! :)

edit: Oops, I forgot to mention I also tried DuneII: the main exe requires to run the setup, then you run the setup and nothing happens :| I don't have any other details...

About SQ4 that thinks you've got a monochrome display, maybe you can check this, hope it helps :)

Thanks for the link to the I/O port document, sverx! I hadn't seen that document, it looks to be more complete than the documents I've been using, so it is very useful!

I believe I have done those methods that EGA/VGA detection in your other link uses, so it must be something else. I don't support EGA/VGA ports properly yet, so I suspect those are the culprit.

I plan to add practically all the missing opcodes before releasing the next version, so there should not be any opcode errors (unless the game uses something very special) after that. I also try to code some sort of simple EGA emulation, but the problem is that even the simple EGA modes are really complex (read: slow to code and to emulate), compared to CGA and MCGA modes!

Pate
_________________

Now working on DSx86 http://dsx86.patrickaalto.com
Get LineWarsDS from http://linewars.patrickaalto.com

Yeah, ugh, I wished I knew how to do 640x200 EGA mode because it would have hamstrung me less when writing Dapple. :/

Hi Pate! Big thanks for your alpha update! You are doing a great job!^^

I also wonder if there is anyone who knows which "Achtung, die Kurve" (Also called Zatacka) system requirements is? Is it possible to run that game in DSX86 in the future maybe??!

Have a nice day everyone!??

BastarB wrote:

Hi Pate! Big thanks for your alpha update! You are doing a great job!^^

I also wonder if there is anyone who knows which "Achtung, die Kurve" (Also called Zatacka) system requirements is? Is it possible to run that game in DSX86 in the future maybe??!

Have a nice day everyone!??

It's from 1995 so I doubt it'll work.

But there are multiple open source & multiplatform remakes, so it should be easy to make a DS port.
It would be THE perfect single-handheld multiplayer game (with one player taking the dpad and the other one XYBA).
We had daily 6-player "Kurve" tournaments back in high school. Good times...

Very cool.

drdim wrote:

BastarB wrote:

Hi Pate! Big thanks for your alpha update! You are doing a great job!^^

I also wonder if there is anyone who knows which "Achtung, die Kurve" (Also called Zatacka) system requirements is? Is it possible to run that game in DSX86 in the future maybe??!

Have a nice day everyone!??

It's from 1995 so I doubt it'll work.

But there are multiple open source & multiplatform remakes, so it should be easy to make a DS port.
It would be THE perfect single-handheld multiplayer game (with one player taking the dpad and the other one XYBA).
We had daily 6-player "Kurve" tournaments back in high school. Good times...

Why would a game from 1995 not work? Too advanced at this stage, or could ever be run?

if it uses a 386 processor then it will not work unless pate programs it and even if he did games from 1995 probably use more ram then the ds has but then again what do i know about the project i have only been programming for like 2 years and only just learnt c++ like a month ago
_________________
i'm in the corner of your eye were you never want to look http://www.mediafire.com/?noymnnmtwmm

Yes, like jam_888 said, if a game requires a 386 processor, it won't run in DSx86.

It would be technically possible to add support for 386 processor, but that would mean a major rewrite of the whole CPU emulation. Also, the resulting emulator would still run at the speed of a 12MHz 286, so it still would not run those games properly. This is why I have no plans to add support for 386 processor in DSx86.

Pate
_________________

Now working on DSx86 http://dsx86.patrickaalto.com
Get LineWarsDS from http://linewars.patrickaalto.com

Even that you can get the speed of a 12 MHz 286 out of it is an emulation speed factor of almost 1:5, which isn't bad.

This considering all the naysayers didn't think anyone would be able to get past 1 MHz (1:66)... after all, DOSBOX isn't the most optimized PC emu out there!

hay does a 386 processor use the same opcodes as a 286 just wondering since ones 16 bit and ones 32 bit (Big Jump) surprised there isn't a 24 bit again no one has to answer just curious :)
_________________
i'm in the corner of your eye were you never want to look http://www.mediafire.com/?noymnnmtwmm

Kind of. The 386 is in 16 bit mode when it boots up. If it's switched to 32-bit mode, then some of the instructions change meaning. It's not pretty.

Thanks Kusma i always just thought 386 was 32 bit mode but thanks again for clearing that up
_________________
i'm in the corner of your eye were you never want to look http://www.mediafire.com/?noymnnmtwmm

jam_888 wrote:

Thanks Kusma i always just thought 386 was 32 bit mode but thanks again for clearing that up

Well, it is. It just isn't when it boots up. For DOS, the applications themselves needs to enter 32-bit mode (usually though a DOS-extender like DOS4GW or PMODE/W).

thanks again
_________________
i'm in the corner of your eye were you never want to look http://www.mediafire.com/?noymnnmtwmm

no ones talked for a while on this forum so i thought why not my opinion which has something to do with turkeys dynamite Pokemon and Listerine but i can't quite remember what it was???? yeh can someone please tell me what i was thinking of plz :)
_________________
i'm in the corner of your eye were you never want to look http://www.mediafire.com/?noymnnmtwmm

Would it be possible for this to run Lemmings 2?

Isn't Lemmings 2 protected mode?

Just play a console version instead.
_________________
"We are merely sprites that dance at the beck and call of our button pressing overlord."

The code mentions EMS memory which suggests to me it's at least not 386-specific.

Whoohoo! Can't wait for a version with loadfix and new opcodes.

All the oldschool simulations (e.g. mechwarrior, gunship, falcon) got the packed file error in 0.02. I'm so eager to test them. Maybe they even start with the added opcodes!

i wonder when the next version will be out probably when schools back on WHAAAHHHHH :( i may only be still in school but that doesn't mean i don't have feelings which i don't know what that has to do with anything but i like food there i said it are you happy nah kids I'll shut up now
_________________
i'm in the corner of your eye were you never want to look http://www.mediafire.com/?noymnnmtwmm

Version 0.03 released!

This version brings preliminary support for EGA 320x200 16-color mode, and it has the Packed File Corrupt fix. It also has much improved opcode support, there are only a few 8086 opcodes still unsupported. The graphics modes (especially EGA) use different versions of some of the opcodes, though, so those might still give "Unsupported opcode" errors.

I have been testing the EGA support using Duke Nukem 2 (the shareware version), which is still somewhat glitchy but quite playable. It takes a really long time to load (I always think it has hung), but if you wait for a long time it will start. :-)

Please let me know of any problems you encounter, I'll again try to fix many of those for the next version!

Thanks for your interest in DSx86!

Pate
_________________

Now working on DSx86 http://dsx86.patrickaalto.com
Get LineWarsDS from http://linewars.patrickaalto.com

thanks for update
_________________
i'm in the corner of your eye were you never want to look http://www.mediafire.com/?noymnnmtwmm

Screenshot of ultima 6 crashing:
http://www.dwedit.org/dwedit_board/attachment.php?item=285

Debug log:
http://www.dwedit.org/dwedit_board/attachment.php?item=284

Program names for the debug log:
CAT = alley cat
GAME = Ultima 6
U = Ultima 6
ULTIMA6 = Ultima 6 (this is an infinite loop)
INSTALL = Ultima 6
MARIO = Mario Bros VGA
ROGUE = Rogue
QB = QuickBasic 4.5
MM = Megaman 3
ZANY = Zany Golf
TURBOSCI = Quarky & Quaysoo's Turbo Science
INSTALL = installer for turbo science
PT-HINT = hint program for Pharaoh's Tomb
4DOS = trying to hit ctrl+C and getting an error
PTOMB1 = Pharaoh's Tomb
INVADERS = freeware space invaders game (infinite loop)
MM = Mega Man
DIAMOND = freeware Diamond game
CITY = Freeware City Runner game

Other games are still giving Packed File Errors, such as Warajevo Manic Miner.
_________________
"We are merely sprites that dance at the beck and call of our button pressing overlord."

your main page for dsx86 says MCGA graphics adapter (a stripped-down VGA with a maximum resolution of 320x200) but it supports other graphics as well now so you should probabley update that
_________________
i'm in the corner of your eye were you never want to look http://www.mediafire.com/?noymnnmtwmm

Thanks Dwedit for taking the time to test that many games! Much appreciated!

I took a quick look at the log file, most of the opcode errors are from the few still unsupported opcodes, so these are fixed in the next version. The last two, DIAMOND and CITY, use 386 opcodes, so those won't be supported. Ultima 6 INSTALL port I/O problem is due to the limited EGA support, and the ZANY "pop ss" is just something I seem to have forgotten to add, will be supported in the next version. Turbo Science INSTALL port I/O problem looks like a Gravis Ultrasound detection problem. The INT problems look reasonably easy to handle in the next version as well.

The infinite loops are trickier, I'll see what I can do about those... I'll try to improve the Packed File Corrupt detection as well.

jam_888: Yeah, I guess I need to update my main page, thanks!

Pate
_________________

Now working on DSx86 http://dsx86.patrickaalto.com
Get LineWarsDS from http://linewars.patrickaalto.com

gbadev.org forum archive

DS homebrew announcements > DSx86 (PC emulator) (v0.43 beta)

#171221 - Pate - Sat Nov 07, 2009 4:27 pm

#171223 - Lazy1 - Sat Nov 07, 2009 6:03 pm

#171225 - Wraggster - Sat Nov 07, 2009 10:22 pm

#171226 - Dwedit - Sat Nov 07, 2009 10:53 pm

#171228 - Sektor - Sun Nov 08, 2009 4:54 am

#171229 - Pate - Sun Nov 08, 2009 6:31 am

#171230 - Dwedit - Sun Nov 08, 2009 7:23 am

#171231 - Pate - Sun Nov 08, 2009 8:33 am

#171232 - Wraggster - Sun Nov 08, 2009 10:43 am

#171233 - Dwedit - Sun Nov 08, 2009 12:55 pm

#171234 - FluBBa - Sun Nov 08, 2009 3:38 pm

#171236 - Lazy1 - Sun Nov 08, 2009 5:12 pm

#171237 - Pate - Sun Nov 08, 2009 8:29 pm

#171238 - BastarB - Sun Nov 08, 2009 9:56 pm

#171239 - kusma - Sun Nov 08, 2009 10:10 pm

#171241 - ingramb - Mon Nov 09, 2009 3:46 am

#171244 - Pate - Mon Nov 09, 2009 5:59 am

#171245 - wolfmanz51 - Mon Nov 09, 2009 6:15 am

#171248 - hacker013 - Mon Nov 09, 2009 11:31 am

#171251 - Sektor - Mon Nov 09, 2009 3:45 pm

#171252 - kusma - Mon Nov 09, 2009 4:01 pm

#171253 - sfg - Mon Nov 09, 2009 4:31 pm

#171255 - Dwedit - Mon Nov 09, 2009 4:58 pm

#171256 - BastarB - Mon Nov 09, 2009 9:54 pm

#171257 - keldon - Mon Nov 09, 2009 10:36 pm

#171258 - Lazy1 - Mon Nov 09, 2009 10:44 pm

#171262 - sverx - Tue Nov 10, 2009 9:43 am

#171269 - ggx2neo - Wed Nov 11, 2009 12:00 am

#171274 - Pate - Wed Nov 11, 2009 6:02 am

#171275 - ggx2neo - Wed Nov 11, 2009 6:39 am

#171277 - sverx - Wed Nov 11, 2009 10:21 am

#171278 - Pate - Wed Nov 11, 2009 12:08 pm

#171279 - BastarB - Wed Nov 11, 2009 1:39 pm

#171280 - sfg - Wed Nov 11, 2009 3:24 pm

#171282 - phoenixclaws - Wed Nov 11, 2009 4:50 pm

#171288 - Pate - Thu Nov 12, 2009 5:48 am

#171289 - ggx2neo - Thu Nov 12, 2009 6:38 am

#171291 - sverx - Thu Nov 12, 2009 10:40 am

#171295 - Pate - Thu Nov 12, 2009 4:16 pm

#171296 - sfg - Thu Nov 12, 2009 4:23 pm

#171299 - sverx - Thu Nov 12, 2009 4:56 pm

#171302 - Exophase - Thu Nov 12, 2009 6:01 pm

#171304 - Pate - Thu Nov 12, 2009 8:05 pm

#171305 - Exophase - Thu Nov 12, 2009 8:45 pm

#171310 - Pate - Fri Nov 13, 2009 5:59 am

#171313 - sverx - Fri Nov 13, 2009 10:10 am

#171315 - Mavromatis - Fri Nov 13, 2009 10:37 am

#171316 - mortys - Fri Nov 13, 2009 11:50 am

#171318 - gauauu - Fri Nov 13, 2009 4:17 pm

#171319 - sverx - Fri Nov 13, 2009 4:43 pm

#171320 - SteveH - Fri Nov 13, 2009 5:10 pm

#171323 - Exophase - Fri Nov 13, 2009 6:17 pm

#171327 - Pate - Fri Nov 13, 2009 8:28 pm

#171329 - Lazy1 - Fri Nov 13, 2009 8:32 pm

#171331 - Exophase - Fri Nov 13, 2009 9:06 pm

#171334 - gauauu - Fri Nov 13, 2009 9:40 pm

#171339 - Pate - Sat Nov 14, 2009 6:32 am

#171350 - Vague Rant - Sun Nov 15, 2009 4:43 pm

#171352 - hacker013 - Sun Nov 15, 2009 5:42 pm

#171362 - elwing - Mon Nov 16, 2009 7:23 am

#171367 - Pate - Mon Nov 16, 2009 11:05 am

#171392 - ggx2neo - Wed Nov 18, 2009 6:06 am

#171396 - Pate - Wed Nov 18, 2009 10:24 am

#171467 - BastarB - Sat Nov 21, 2009 5:49 pm

#171471 - Lazy1 - Sun Nov 22, 2009 12:31 am

#171476 - Dwedit - Sun Nov 22, 2009 3:11 am

#171477 - Pate - Sun Nov 22, 2009 7:09 am

#171478 - Ant6n - Sun Nov 22, 2009 11:05 am

#171479 - headspin - Sun Nov 22, 2009 5:28 pm

#171482 - Vague Rant - Sun Nov 22, 2009 10:34 pm

#171483 - lincruste - Mon Nov 23, 2009 12:13 am

#171487 - sonny_jim - Mon Nov 23, 2009 1:57 am

#171491 - lincruste - Mon Nov 23, 2009 12:55 pm

#171492 - Sektor - Mon Nov 23, 2009 1:06 pm

#171509 - Ant6n - Tue Nov 24, 2009 12:36 am

#171511 - Pate - Tue Nov 24, 2009 9:07 am

#171512 - InnocentBystander - Tue Nov 24, 2009 11:14 am

#171541 - Normmatt - Wed Nov 25, 2009 9:16 am