Jump to content

TheChuckster

Members+
  • Posts

    41
  • Joined

  • Last visited

Everything posted by TheChuckster

  1. The new version supports DLDI. Just patch it and you're good to go.
  2. Hmm. I will look into that. Perhaps I've compiled in an older version of the library...
  3. Not yet. Well, someday I would like to learn ARM assembly and rewrite the CPU core so that I get a speed increase.
  4. I finally got around to adding GBAMP support to StellaDS. It should also work with your M3s and Supercards as long as chism's FAT library supports them. Download the new release at my site, along with some free legal ROMs.
  5. Another idea. Does this update the whole screen or just the changed regions? The server could save you some bandwidth if it only does the latter.
  6. Would JPEGs really be the solution for compressing screen captures? How would GIF or PNG fare as far as compression ratio goes?
  7. I don't have a magnifier. If only this program had the functionality to zoom in built in.
  8. What port does the server use? Is it possible to have the DS connect to a remote IP?
  9. Any progress on the actually library itself since the 2nd of this month?
  10. Try getting a San Disk thumb drive. Mine hasn't failed me since.
  11. taratata, the alternative would be to use one of the many canned premade CPU core emulators found on the internet. Just search. Z80 has a ton of them. Mame is a gold mine for CPU emulators.
  12. I am in the same trap as you. I have only 256 MB of RAM, but it's RDRAM so I can't upgrade it. In case you didn't know, 256 MB more of RDRAM is about the same cost as 1 GB of DDR now because nobody uses it anymore. Dell screwed me over. I soon realized I could have built a much better PC myself for the same price I paid for my Dell. I can agree that the case inards are a pain to work with. I recently opened my clam shell style case to upgrade. Figuring out how to open it was tough enough. Then as I opened it with what seemed to be an overly excessive amount of force for opening a PC case, it felt like the plastic was about to collapse and shatter. Piece of junk... who makes plastic cases?! Cut to slipping in my new wifi card into one of their PCI slots. They had some weird clamping mechanism to hold all of the PCI cards in place instead of screws like the rest of the world. I undid the clamp and stuck the card in but then I couldn't get the clamp shut again. The latch on it wouldn't click back into place no matter what. Now if you press on the PCI cards on the back of the case like if you're trying to plug in a VGA cable or something, they will come out of their slots. Then there's the forced bloat of bundled software. I know I'll never use my free AOL icon or that DELL branded photo editor/media player shareware app that came with my computer. As soon as I got my computer, I did a clean install. Not to mention the Utility partition which I wiped out since I dual boot Linux and Windows. Dell is fine for casual newbies that want to check their email once a week, but anything more and it's better to just build your own, which I will do as soon as this machine becomes too obsolete.
  13. I just hope malware doesn't become a problem with this online demo server.
  14. Get psyched for online multiplayer Atari games on your DS!
  15. I thought Gameboy had a Z80. I learned a lot porting Stella to the DS. Emulation is a black art. There aren't any books or tutorials on it. What you need to know is how a computer WORKS. You need to know Assembly and what the various components like the CPU, RAM, and various I/O devices do and how they interact. You also need to know how to perform arithmetic on hex and binary numbers. The best way is to learn Assembly. It doesn't get much lower level than that. You don't have to code your emulator in Assembly, but it is a very good teaching tool for the above prerequisite knowledge. Really what you want to do is parse the ROM and load ("copy") it into an array representing the machine's memory. To emulate the CPU, begin by declaring registers, setting the Instruction Pointer, and fetching and "emulating" each opcode. Let's say you encounter C3 at the IP location. On the Z80, that is the opcode for jp. Easy enough. Fetch the next 2 bytes and change the IP to the address stored in them. Eventually you're going to want to count cycles so that you have consistent timing going. You're probably going to want to expand on the CPU to do something more than just jump. You'll need interrupts emulated as well. Games use interrupts such as the VBlank and Timer interrupts to do event-based routines. The RAM might be more complicated as well. Reads and writes will need to consider mirrored memory, read-only memory, hardware mapped memory (I'll get to that in a second), and bankswitching/paging. As far as video goes, lets say we have a framebuffer (easiest example) that contains bits representing a 256x128 monochrome display at say memory address 300000. What you need your emulator to do is to check the contents of that every frame and update the onscreen display using routines for what ever graphics library you're using (SDL? libnds?). Data can be anything. It's all about how we (the user and the programmer) interpret it. To the computer it could be code or a piece of stored information such as a document or sprite (to stick with the game theme). Knowing that "philosophy" is key to knowing the computer at its lowest level. That's programming an emulator in a nut shell. Providing you're not hand-coding every opcode or squashing that minor glitch bug that you just cannot seem to figure out the cause to, emulator programming can be quite a fun and worthwhile pursuit. I hope somebody finds what I have written useful to them. It should give you a good start.
  16. I've always speculated that perhaps the best usage for the Revolution controller will be for aiming in FPS games...
  17. Wendys makes better hamburgers. Ever hear of the chicken head story?
  18. To compile ROMs you need Devkit Pro installed. Used the Windows update utility at devkitpro.org to install it. Move the source code into the C:\devkitpro\ directory. Drop all of the ROM.bin files into the atarids\arm9\data directory. Open up a command prompt and change to the atarids directory. Type make. The resulting NDS and DS.GBA files should work. I will add scrolling to the ROM menu and possibly GBA Movie Player support in a later release. I have no plans of purchasing a GBA MP as of now. Until then you can play as many ROMs as fit on your screen. A bug in GBFS is preventing the name of the first ROM from showing up, but instead the first ROM will say (null) in the menu. In that case, you can still play it by hitting the A button just like for any other ROM.
  19. Don't press B. I'm using it as a sound test in the newer versions and the floating point loop in the Stella sound routine makes it slow to a crawl. If you happen to by accident, wait a few minutes. Should've posted that.
  20. There is clear documentation on the web site about the controls, and don't forget R and L control the switches. Paddle emulation doesn't work yet, but I'm going to see about interfacing real Atari paddles to the GBA port (I use WMB). Try recompiling with other ROMs. Since I abide by the forum rules, I cannot give out links or any more information.
  21. TheChuckster: New web site! http://thechuckster.homelinux.com/stellads/ I am working on a port of the Atari 2600 emulator Stella. So far almost the entire code base has been ported. Download a ROM and put it in the data directory. Name it "pacman.bin" and recompile. The emulator will load, MD5 sum, and execute it. What's left? I am having problems with the frame buffer so no visuals. It's a problem with the ported emulator code, not the DS framebuffer because I can write to the DS framebuffer fine. The source code is in the zip; perhaps, you could take a look. Namely, the TIA.cpp file is what handles the Atari's framebuffer. I honestly don't know what's the matter, but then again, this is my first real DS project. Also, sound and controls need to be implemented. Shouldn't be too hard -- at least the controls. I am not going to start on these features until I get framebuffer working though. Download the source code and binaries at: http://thechuckster.homelinux.com/atarids.zip Consider this the alpha version. EDIT: Update with added debug info -- registers and instructions just to prove that the dang thing works! GPFerror: replace your updateframebuffer() function with the below code works on hardware. just needs to be seriously optimized Code: void updateframebuffer() { int i = 0; int j = 0; uInt8* buffer=theConsole->myMediaSource->currentFrameBuffer(); uInt16* buffer2=VRAM_A; int x=0,y=0; int x2=0,y2=0; int h=210; int w=160; uInt8* line; uInt16* l2; buffer += y * w + x; buffer2 += y2 * 256 + x2; for(i = 0; i < h; ++i) { line = buffer + (w * i); l2 = buffer2 + (256 * i); for(j = 0; j < w; ++j) { uInt8 v = *line++; *l2++=RGB15(myPaletteR[v],myPaletteG[v],myPaletteB[v]); } } } TheChuckster: You're getting visuals from the emulated game? iDeaS just displays all black. Thank you for the function. EDIT: Got somebody to test it on their hardware. It works! I wish I could do more but it won't work in emulators and Neo Flash won't replace my defective Slim Loader which is a shame because I'll never get to enjoy my work. Guess the community will just have to wait for sound, scaling, optimizations, controls. Even with it as an extended rotation background instead of a framebuffer it's still not showing up in iDeaS. Dualis crashes and DSEmu won't display anything at all. http://thechuckster.homelinux.com/atarids.jpg Wraggster: Awesome stuff, i mirrored your release and posted news here --> http://nintendo-ds.dcemu.co.uk/ TheChuckster: You can actually play ET now! http://thechuckster.homelinux.com/chuck.jpg So as you can see, I got controls working but the framebuffer still needs optimized. I will work on that now. Hopefully, the framebuffer is what's slowing things down. My plan is to only draw the updated portions each frame and to use an extended rotation background on Mode 5 instead of the FB0. If the emulated processor or the C++ emulator core code are the bottlenecks and the code needs a drastic rewrite, this project will surely grind to a halt. I have no experience whatsoever with optimizing for embedded systems or even with ARM assembly for that matter. By the way, the latest ROM can be found at http://thechuckster.homelinux.com/atarids.nds Forget the old source code zip. I will update it once my framebuffer optimizations are in place. UPDATE: The emulator has been quite optimized and plays at a smooth playable speed now thanks to a faster framebuffer drawing routine. I will continue to work on it though and add sound. I need to order a Wifi card to do more complete experimentation because there's pretty much no hope at all of getting a replacement Neo Flash. As promised, I have released the source code: http://thechuckster.homelinux.com/atarids.zip Feel free to try some optimization of your own! GPFerror: cool, glad it helped. Yeah I wasn't able to get it to work in the emulators either, so I had someone on irc test it on hardware before I posted my code I run into the same problem with my neo pocket emulator, but it now works in dsemu. One thing to try is to make the emulated frame buffer, have a width of 256 and apply the color directly as its being created. then you can just use a dmacopy or a swifastcopy to copy it to vram, which might speed it up some. Troy Wraggster: awesome work, ive once again mirrored the release and screens here --> http://nintendo-ds.dcemu.co.uk/stellads.shtml I also submitted this news to Joystiq.com and they posted it, so your famous i do have one request could you number your releases or date them as for all emu sites its easier to see whats new etc mrnull: I don't see any binaries, just source! I recently moved and don't have access to my ol' computer. Please help! TheChuckster: Try the new web site for binaries. http://thechuckster.homelinux.com/stellads/ I managed to get it to work in Dualis by removing -mthumb from the Makefile. Problem is it's still running slower than the actual games -- at least in the emulator. Can anyone else that has the hardware confirm if it's running quite a bit slower in the emulator than the hardware or if it's running just as slowly on both? Looks like even more optimization work is necessary. Also, a Mode 5 hardware scale factor of 3 << 7 seems to make it smaller even though it SHOULD make it 1.5x larger. Is this true only to Dualis or does it malfunction on the hardware as well? Perhaps I'm using the wrong scale factor. Is 3 << 7 correct for a factor 1.5? gladius: The scale factors are actually the amount the DS adds after each pixel to the x and y co-ordinates. To get a scale factor of 1.5, you actually want to add ~0.66667 each pixel. Or converting to fixed point (1/1.5 * 256) you want 171. Tepples: And you might want to change the horizontal constant offset each frame by a fraction of a pixel so that the player doesn't see an obvious pattern of 2, 1, 2, 1, 2, 1 repeated pixels in the A2600's two bitmapped objects. This technique, used (albeit in the other direction) by PocketNES, may look flickery on emulators, but it'll look OK on a real DS.
  22. Hello, fellow retro gamers: The StellaDS web site is located at http://thechuckster.homelinux.com/stellads/ There you can download the emulator and its source code or receive updates. I will also post them in this forum. Thanks for your interest.
×
×
  • Create New...