| Home | Forums | What's new | Resources | |
| NES emulation |
| vbt - Feb 2, 2003 |
| Prev | 1 | 2 | 3 | 4 | 5 | 6 | Next |
| slinga | Nov 7, 2003 | |||
I don't follow. By 68k do you mean the saturn's sound processor (which is similiar to the genesis cpu)? And if so, do you mean to emulate all of the NES sound system on that cpu? :huh | ||||
| AntiPasta | Nov 7, 2003 | ||
| Hey, the entire Speccy has been emulated on a 68k In fact I think it's a pretty neat idea, but not that neat that it can replace one of the SH2's... that is, if you can find a useful use for dual CPUs in a emulator. | |||
| Tagrineth | Nov 7, 2003 | ||||||
Yes, I mean the Motorola 68EC000 that controls the sound chip in Saturn.
See, 68k is surprisingly powerful and NES's sound... isn't. Hell, Pagefault (of ZSNES fame) said it might be possible to run the SNES's famous SPC700 entirely on that 68k. And yes, he's done some Saturn work now. And dual CPU's are insanely useful in emulation. More spread out processing resources = very good for emulation, since you're emulating several chips at once. Context switches aren't exactly good for performance. And... I know it can't replace one of the SH-2's, BUT it's a lot easier according to pf to get "MP" running via the 68k and one SH-2 than via both SH-2's, and this could be all vbt needs to get speed up. It was just a suggestion to do first, since it's a good idea anyway, and if necessary he can still spread work onto the other SH-2... but they aren't called Twin Terrors for no reason. | |||||||
| antime | Nov 7, 2003 | ||
| Mehh, what OS are you running to suffer from context switching penalties? | |||
| Jurai | Nov 7, 2003 | ||
| does this require a comms card? | |||
| Tagrineth | Nov 7, 2003 | |||
It's a given. Nothing to do with OS, it's part of CPU architecture. I'd like to see you develop a CPU which can flush its pipeline and L1 cache, redirect pointers, and refill its pipeline in one cycle. | ||||
| slinga | Nov 7, 2003 | ||
| I'm with Antime on this one. CSPs only occur when you swap in\out processes\threads. I'd assume that VBT's code would be multithreaded (how else would you make use of the dual cpus?), but that each thread would run on its CPU. So 2 threads on 2 cpus = no switching processes. | |||
| antime | Nov 7, 2003 | |||
But why would you do any of that? (And if you really want to know, there are CPUs which do zero-cycle context switches by storing the needed data on-chip. Obviously it only works for a set number of processes.) | ||||
| Tagrineth | Nov 7, 2003 | |||
But why would you do any of that? (And if you really want to know, there are CPUs which do zero-cycle context switches by storing the needed data on-chip. Obviously it only works for a set number of processes.) [/b][/quote] Hmm, yeah, you're right, sorry... didn't research this quite enough before replying ^^; Well, does SH-2 have these traits? I doubt it does, it's probably too old. And Slinga, I think the point was that vbt is so far only using one SH-2. | ||||
| Mask of Destiny | Nov 7, 2003 | |||
Context switches are rather painful on the SH-2. The cache is way too small to handle data from multiple threads/processes, exception processing is really slow because of the pipeline (though this isn't less of an issue if you do co-operative multi-tasking, especialy if you use delayed branch instructions), refilling the registers will take a while because of contention. | ||||
| ExCyber | Nov 8, 2003 | |||
Examples? I'd like to read some white papers on how this is put together (I suppose it's on server-class processors with huge virtual address spaces and they have some vitual address bits act as a context ID...) | ||||
| antime | Nov 8, 2003 | ||
| On the contrary, most examples are specialized embedded controllers for tasks that need high throughput. Here's... one such chip which supports eight threads. | |||
| vbt | Nov 9, 2003 | ||
| I think you overestimate my programing level | |||
| AntiPasta | Nov 9, 2003 | ||
| if you need help with assembly, I'm your man (although i havent programmed much on the 68k I think I'll be able to adapt easily) | |||
| ExCyber | Nov 9, 2003 | |||
Compiler/assembler is anything that will let you produce a raw binary suited to the Saturn 68k memory map (not much to it IIRC, basically you're looking at RAM from 0x000000-0x07FFFF). To run it AFAIK you just have to upload the program to the beginning of SCSP RAM (including vector table) and use the SMPC to reset the 68K. Bart Trzynadlowski's page... has some tools and sample programs IIRC. | ||||
| slinga | Nov 14, 2003 | ||
| Out of curiousity (I'm trying to learn a little about emulation), when are you drawing to the screen? During the Vblank period? | |||
| darkdaemon | Apr 4, 2004 | ||
| Ok vbt here is a little tips & tricks for you | |||
| ExCyber | Apr 5, 2004 | ||
| I had a little trouble understanding your recommendations. The only useful recommendation I could come up with is that you're saying to use have one of the SH-2 processors emulate the PPU by using its private RAM as PPU RAM in order to save on memory bandwidth. Is that what you're saying? The rest was pretty obvious (use the sound CPU for sound, initialize your memory to a known state before using it). BTW, what games have you emulated? | |||
| darkdaemon | Apr 5, 2004 | ||
| Prev | 1 | 2 | 3 | 4 | 5 | 6 | Next |