#134472 - khan - Fri Jul 13, 2007 9:58 am
I was wondering if we will ever see NeoGeo MvP/CD on DS? *Just a question*
Thanks
#134500 - jester - Fri Jul 13, 2007 1:25 pm
whats its full specs again?
_________________
If anyone needs a dragonball online email me @ aaronthejester@hotmail.com
#134505 - khan - Fri Jul 13, 2007 2:12 pm
Processor
Main Processor: Motorola 68000 running at 12 MHz
Although the 68000 CPU was designed by Motorola, there were many other clones of this CPU found in the Neo Geo hardware. The most common CPU is the TMP68HC000 manufactured by Toshiba. This is essentially a Motorola 68000 clone.
Co-Processor: Zilog Z80 running at 4 MHz. This is used as an audio controller.
Sound chip: Yamaha YM2610 15 Sound Channels. 7 Digital, 4 FM synthesis, 3 PSG, and 1 Noise Channel.
Memory
Main Memory (used directly by 68K): 64 KiB
Main Video Memory: 64 KiB
Palette Memory : 8 KiB
Fast Video RAM : 2 KiB
Sound Memory (used directly by Z80): 2 KiB
Display
Display resolution: 304x224 (320x240 with 8px borders on each side)
Color Palette: 32,768
Maximum Colors On-Screen: 256
Maximum Sprites On-Screen: 384
Minimum Sprite Size: 1x2
Maximum Sprite Size: 16x512
Maximum Sprites per scanline: 96
Background Layers: 0
Aspect ratio: 4:3
A/V output:RF, composite video, RGB (with separate 21 pin cable FCG-9).
Power
Source: separate DC 5 V(older systems) and DC 9 V adapter (newer systems).
Consumption: 8 W older Systems, 5 W newer Systems
Dimensions
Console: 325mm (width) x 237mm (depth) x 60 mm (height).
Controller: 280mm (width) x 190mm (depth) x 95 mm (height).
Storage
Removable Memory Card: 8 KiB or 68-pin JEIDA ver.3 spec memory
Any 68-pin memory that fits the JEIDA ver.3 spec will work
#134508 - jester - Fri Jul 13, 2007 2:34 pm
possible perhaps.
_________________
If anyone needs a dragonball online email me @ aaronthejester@hotmail.com
#134517 - OOPMan - Fri Jul 13, 2007 3:20 pm
I dunno, I doubt it myself. NeoGeo games could slow-down even on P200-type machines. I suspect the kind of complex emulation necessary would not be so easy on the DS.
The NeoGeo Pocket has been emulated, though...
_________________
"My boot, your face..." - Attributed to OOPMan, Emperor of Eroticon VI
You can find my NDS homebrew projects here...
#134600 - M3d10n - Sat Jul 14, 2007 3:57 pm
Someone needs to emulate the Genesis first. The biggest question is if the DS can emulate the M68000 at full speed.
If the CPU can be emulated, the graphics could be done using HLE mapping to the DS's own 2D system. The main problem would be memory.
Most NeoGeo cartridge roms would not fit on the DS main RAM. Games would need to be streamed from FAT, and it's uncertain if that's viable or not.
Neo Geo CD games would be impossible without RAM expansions, since it had 7MBytes of RAM.
#134601 - LiraNuna - Sat Jul 14, 2007 5:10 pm
| Quote: |
Display
Display resolution: 304x224 (320x240 with 8px borders on each side)
Color Palette: 32,768
Maximum Colors On-Screen: 256
Maximum Sprites On-Screen: 384
Minimum Sprite Size: 1x2
Maximum Sprite Size: 16x512
Maximum Sprites per scanline: 96
|
You're kidding, right? even if you get the CPU core to be fast enough, you are FORCED to use FB rendering for this small baby.
Emulation is possible, but not in speed of more then ~12FPS.
_________________
Private property.
Violators will be shot, survivors will be shot again.
#134602 - kusma - Sat Jul 14, 2007 5:13 pm
| LiraNuna wrote: |
| You're kidding, right? even if you get the CPU core to be fast enough, you are FORCED to use FB rendering for this small baby. |
Why is that?
#134605 - LiraNuna - Sat Jul 14, 2007 5:30 pm
I have highlighted why in the above quote.
Maximum Sprites On-Screen: 384
Even if you do use HBlank tricks to increase the sprite count (which may be unfeasible for x3 the count of the DS sprite count), maximum number of sprites per scan line is 96, which is x3 as the DS's limit.
Not only that,
Maximum Sprite Size: 16x512
Do I need to say more? either you use more sprites to achieve a semi meta-tiling effect, you will need 16 16x32 sprites to achieve that - or Hblank sprite move.
I don't think you'll want to handle ANY of that without framebuffer, unless you're really mad.
_________________
Private property.
Violators will be shot, survivors will be shot again.
#134606 - kusma - Sat Jul 14, 2007 5:41 pm
| LiraNuna wrote: |
I have highlighted why in the above quote.
Maximum Sprites On-Screen: 384
Even if you do use HBlank tricks to increase the sprite count (which may be unfeasible for x3 the count of the DS sprite count), maximum number of sprites per scan line is 96, which is x3 as the DS's limit.
Not only that,
Maximum Sprite Size: 16x512
Do I need to say more? either you use more sprites to achieve a semi meta-tiling effect, you will need 16 16x32 sprites to achieve that - or Hblank sprite move.
I don't think you'll want to handle ANY of that without framebuffer, unless you're really mad. |
Won't textured quads do the trick?
#134607 - Lazy1 - Sat Jul 14, 2007 5:47 pm
M68k Emulation:
The CPU core in Mini vMac DS is fairly fast for something that is not optimized for embedded platforms. It runs roughly 40FPS at idle and 30FPS under load, which isn't bad and keep in mind that Cyclone68000 would be even better.
Framebuffer rendering would kill it though as was already mentioned, but then again some people are willing to use slow emulators.
All you need is to find a developer who has enough interest.
#134608 - khan - Sat Jul 14, 2007 5:48 pm
Do you guys think the likes of CPS1/2 might be possible on DS as most of the games I think are less than 10MB, may be around 6MB each?
CPS1 specs:
Main CPU: Motorola 68000 at 10 MHz
Sound CPU: ZiLOG Z80 at 4 MHz
Sound chip(s): Yamaha YM2151 at 3.57958 MHz + OKI MSM6295 at 7.576 kHz or QSound at 4 MHz
Maximum number of colors: 4096 (12 bit RGB)
Colors per tile: 16 (4 bits per pixel)
Maximum number of objects: ?
Scroll faces: 3
Scroll features: Horizontal & vertical scrolling, linescroll
Resolution, pixels: 384?224
CPS2 specs:
Main CPU: Motorola 68000 at 16 MHz
Sound CPU: ZiLOG Z80 at 8 MHz
Sound chip: QSound at 4 MHz
Maximum number of colors: 4096 (12 bit RGB)
Colors per tile: 16 (4 bits per pixel)
Maximum number of objects: 900 (16?16 pixels)
Scroll faces: 3
Scroll features: Horizontal & vertical scrolling, linescroll
Resolution, pixels: 384?224
#134609 - LiraNuna - Sat Jul 14, 2007 5:58 pm
| kusma wrote: |
| LiraNuna wrote: | I have highlighted why in the above quote.
Maximum Sprites On-Screen: 384
Even if you do use HBlank tricks to increase the sprite count (which may be unfeasible for x3 the count of the DS sprite count), maximum number of sprites per scan line is 96, which is x3 as the DS's limit.
Not only that,
Maximum Sprite Size: 16x512
Do I need to say more? either you use more sprites to achieve a semi meta-tiling effect, you will need 16 16x32 sprites to achieve that - or Hblank sprite move.
I don't think you'll want to handle ANY of that without framebuffer, unless you're really mad. |
Won't textured quads do the trick? |
That would be even slower, since that's not how emulation works.
Emulation runs by scanlines, and you won't be able to real-time update information that fast.
if you chose to fake it and update data (convert from tiles to NDS texture format which is FB) per frame for 384 16x512 quads, you'll waste more speed then framebuffer emulation...
_________________
Private property.
Violators will be shot, survivors will be shot again.
#134611 - Sausage Boy - Sat Jul 14, 2007 6:41 pm
| Quote: |
| maximum number of sprites per scan line is 96, which is x3 as the DS's limit. |
Whoa. I quote GBATEK:
| Quote: |
| ...and under best circumstances up to 128 OBJs (of small 8x8 dots size) can be displayed per horizontal display line. |
Since the maximum width of the NeoGeo sprites is 16px, I assume you can cram in something like 64 per scanline, and that's assuming they're all 16px wide. Perhaps the NeoGeo has some other limit about that? And it's not like more than 64 sprites per scanline are likely to be used often. Also, stacking sprites vertically to achieve the larger sizes isn't really a huge problem, but all this would take a very tricky sprite manager.
The main issue, as I see it, is memory. From what I've gathered at Wikipedia, games can be around 330MBits, or even larger, and that's memory mapped ROM. The NeoGeo CD would work, but it has a lot more RAM:
| Quote: |
The CD system's 58Mbits / 7Mbytes of ram was split accordingly:
* 68000 Program Memory: 2Mbytes
* Fix Layer Memory: 128Kbyte
* Graphics Memory: 4Mbytes
* Sound Sample Memory: 1Mbytes
* Z80 Program Memory: 64Kbytes
* VRAM: 512Kb (For graphics attributes)
* SRAM: 2KB (For high scores / general save data)
|
Once you start poking with memory extensions and stuff, I seriously doubt you'd get any good performance.
_________________
"no offense, but this is the gayest game ever"
#134622 - kusma - Sat Jul 14, 2007 10:37 pm
| LiraNuna wrote: |
That would be even slower, since that's not how emulation works.
Emulation runs by scanlines, and you won't be able to real-time update information that fast.
|
Wouldn't it be possible to track all sprite-changes for a full hardware-frame, and _then_ construct the quads from that?
| Quote: |
if you chose to fake it and update data (convert from tiles to NDS texture format which is FB) per frame for 384 16x512 quads, you'll waste more speed then framebuffer emulation...
|
By "FB", do you mean linear addressing? (not all frame buffers are linear)
If so: Not really. You can do lazy updates and dirty-flagging of memory-regions and so on to get this rather effective. I suspect that most games don't change that much all the time.
#134623 - jester - Sat Jul 14, 2007 10:45 pm
so to normal folk the answer is YES but a slow fps rate
_________________
If anyone needs a dragonball online email me @ aaronthejester@hotmail.com
#134628 - Ant6n - Sat Jul 14, 2007 11:09 pm
would it not be possible to emulate gfx chip in arm7, and cpu in arm9. there'd be no sound, but big whoop.
#134636 - Sausage Boy - Sun Jul 15, 2007 2:01 am
The memory problem remains, though. And if extra memory in the GBA slot is used, something will have to handle 8bit writes. I sense pain. :D
_________________
"no offense, but this is the gayest game ever"
#134642 - Ant6n - Sun Jul 15, 2007 5:10 am
other question:
if somenody did an implementation of an m68 core, what things could be possibly emulated with that.
What other processors would be useful to emulate, and what devices would that lead to?
#134661 - kusma - Sun Jul 15, 2007 12:45 pm
AMIIIIGAH!
#135079 - Ant6n - Fri Jul 20, 2007 2:17 am
So one could write a 68000 cpu core running at 8MHz (~1 MIPS) in arm9, and leave enough 'hooks' so that the system could be emulated in arm7 (for the most part). Sounds like a lot of work, but it could be a very interesting project, with lotsa possibilities.
I've never owned an amiga, but it seems the amiga500, running at 7.16MHz, is the one everybody usually refers to, no?
#135139 - jester - Fri Jul 20, 2007 10:53 am
Perhaps memory management tricks could help it to emulate at a faster fps rate.
_________________
If anyone needs a dragonball online email me @ aaronthejester@hotmail.com
#135169 - ethoscapade - Fri Jul 20, 2007 4:02 pm
it's been said before, but the 68k/z80 combo is so popular among hardware from the early 90s that we might as well focus on getting a lower-spec (genesis/CPS1) one up and running first.
#135225 - quadomatic - Sat Jul 21, 2007 12:28 am
I think I've already asked this before...anyways, I don't think it can be done. I hear PSP has problems with this as it is.
I don't think there is enough memory on the DS for this.
#135234 - Ant6n - Sat Jul 21, 2007 3:29 am
in my book 4mb is enough to emulate 2mb. 68K at 8 MHz is doable in asm with lots of dirty tricks imho, so its a lot of work, but quite possible. (maybe ill attempt it, next year...)
#135247 - jester - Sat Jul 21, 2007 12:11 pm
But to get it going at a good framerate is another dea on its own.
_________________
If anyone needs a dragonball online email me @ aaronthejester@hotmail.com
#135248 - Metaluna - Sat Jul 21, 2007 12:23 pm
| M3d10n wrote: |
| Someone needs to emulate the Genesis first. The biggest question is if the DS can emulate the M68000 at full speed. |
I think you should check this out : http://forum.gbadev.org/viewtopic.php?t=13632
#135306 - M3d10n - Sun Jul 22, 2007 3:03 am
| Metaluna wrote: |
| M3d10n wrote: | | Someone needs to emulate the Genesis first. The biggest question is if the DS can emulate the M68000 at full speed. |
I think you should check this out : http://forum.gbadev.org/viewtopic.php?t=13632 |
Wh... what?? Tears are flowing down on my face. First because it seems to be full speed, second because I have no means to run it with my GBA Flashcart which became useless since the dawn of DLDI.
/cries
#135310 - dantheman - Sun Jul 22, 2007 3:26 am
M3d10n, have you considered using FCSR? While it is read-only (so you could use save files from your computer but not save your progress in-game), it will let you run DLDI-enabled applications on a NOR-based cart.
The easiest method of using the FCSR method is probably to use DLDIrc. Download and install it first. Then put jEnesisDS.nds somewhere and create a folder there called "jEnesisDS" (must be named the same as the .nds file minus the extension). Right-click the *.nds file and select the FCSR patch option. It should create a file for you to flash to your cart. Note that if you see an error in the command shell that appears at any point, like "InjectFile 'sonic.bin' failed" then something went wrong. Try renaming the .nds and the folder or game files, or move them up higher in your directory tree (put them in C:\ for instance). If that fails, you'll probably have to try the FCSR method manually, doing each step yourself.
To do it manually, you'll need some knowledge of the command line. Get the tools from http://gpf.dcemu.co.uk first, from the sidebar. Prepend the "ndsmall.bin" loader (don't know the source) to the front of the file using the "copy /b" command. Use padbin (from the GBFS distribution) to padbin it to 512 bytes. Use the build.bat batch file to create a FAT12 image out of the directory you specify. Use the "copy /b" command to add the FAT12 image onto the padbinned jEnesisDS.nds file, then patch with the fcsr.dldi file. Flash to your cart and try it out.
#135328 - khan - Sun Jul 22, 2007 11:17 am
I personally would welcome any arcade EMUs on DS. Even CPS1/2 would be awesome on DS.
#135329 - clems45 - Sun Jul 22, 2007 12:03 pm
hi everybody, I'm not a programmer, I know a bit of C, but the only thing that I can say is that jenesis 0.4 is very very fast in HW mode, the sound is only missing.
#135337 - Wonder Boy - Sun Jul 22, 2007 2:28 pm
Yeah, Amiga 500 my more lovely computer with the Spectrum... :-)
jEnesisDS Mega Drive emulator is fantastically fast due to it's 68000 arm asm core, but not due to forget that the Amiga besides to use the 68000 processor, uses three coprocessors more, and that already is too much load of work for the DS Hardware... :-(
I suppose that through partial emulation, something could be obtainedon Amiga 500 emulation... or perhaps something more than only something... :-)
Last edited by Wonder Boy on Sun Jul 22, 2007 9:10 pm; edited 1 time in total
#135364 - khan - Sun Jul 22, 2007 7:56 pm
As sombody suggested in SnemulDS forum, do you think, it is possible to reduce slowdowns if we are to use a temporary file which could be used to decompress the one ROM that you're playing or for other things?
#135373 - Metaluna - Sun Jul 22, 2007 10:02 pm
All of this reminds me there is another 68000 processor emulator on the DS : STYX DS, an amazing Atari ST emulator.
#135381 - kusma - Mon Jul 23, 2007 12:20 am
| Wonder Boy wrote: |
| I suppose that through partial emulation, something could be obtainedon Amiga 500 emulation... or perhaps something more than only something... :-) |
I suspect that it will be tricky to correctly and efficiently emulate the blitter and the copper...
#135465 - ethoscapade - Mon Jul 23, 2007 6:42 pm
| khan wrote: |
| As sombody suggested in SnemulDS forum, do you think, it is possible to reduce slowdowns if we are to use a temporary file which could be used to decompress the one ROM that you're playing or for other things? |
the roms would almost definitely have to be stored decompressed as-is; the limitation would be with the enormous amounts of ram the neo had when compared with the DS.
there was an xbox emulator that was able to finagle metal slug 3 (a ninety-some megabyte game when decompressed) with the xbox's 64 megs of ram, but..
that's 64 megs of ram we're talking about. not four. much as was true of the dreamcast and psp (initially), neocd is a much wiser goal, except in that case, the memory is absolutely not there.
the compromises necessary to do this would (i'd think) push it well outside the realm of being worth anybody's time and effort.
#135599 - M3d10n - Tue Jul 24, 2007 10:33 pm
| dantheman wrote: |
M3d10n, have you considered using FCSR? While it is read-only (so you could use save files from your computer but not save your progress in-game), it will let you run DLDI-enabled applications on a NOR-based cart.
The easiest method of using the FCSR method is probably to use DLDIrc. Download and install it first. Then put jEnesisDS.nds somewhere and create a folder there called "jEnesisDS" (must be named the same as the .nds file minus the extension). Right-click the *.nds file and select the FCSR patch option. It should create a file for you to flash to your cart. Note that if you see an error in the command shell that appears at any point, like "InjectFile 'sonic.bin' failed" then something went wrong. Try renaming the .nds and the folder or game files, or move them up higher in your directory tree (put them in C:\ for instance). If that fails, you'll probably have to try the FCSR method manually, doing each step yourself.
To do it manually, you'll need some knowledge of the command line. Get the tools from http://gpf.dcemu.co.uk first, from the sidebar. Prepend the "ndsmall.bin" loader (don't know the source) to the front of the file using the "copy /b" command. Use padbin (from the GBFS distribution) to padbin it to 512 bytes. Use the build.bat batch file to create a FAT12 image out of the directory you specify. Use the "copy /b" command to add the FAT12 image onto the padbinned jEnesisDS.nds file, then patch with the fcsr.dldi file. Flash to your cart and try it out. |
Whoa! I didn't know that. I'm at work and cannot test with the Flashcart, but I installed it and it worked perfectly with No$GBA.
You're my savior. I had actually given up on using that cart for DS stuff because everyone was moving to FAT devices and was using GBA apps exclusively. Time to test those DS ebook readers!