|
Post by jlf65 on Feb 25, 2007 16:22:10 GMT -5
Not only possible, but an interesting idea. ;D
An FPGA would work... you could use a smaller FPGA with separate CPUs, or use a larger FPGA and put the CPUs in it as well. Depends on how much work you wanted to do.
If you aren't too good with FPGA's, another solution (the one I would do myself if I were doing this), would be to use a ColdFire processor to simulate both the CPUs and the hardware. FreeScale makes ColdFire MCUs that have all kinds of interfaces that would be handy.
|
|
|
Post by jlf65 on Mar 6, 2007 2:31:38 GMT -5
I'm guessing that you can't use half multipliers. 7.83 MHz x 3.5 = 27.40 Mhz which is closest to 28.7 MHz without going over. Well, they do half multipliers NOW, but certainly not back in the mid-90's. ;D
|
|
|
Post by jlf65 on Mar 5, 2007 15:10:35 GMT -5
I also don't get why sega retarded the clock speed to 23.5 MHz when the SH2 was designed to run at 28.7 MHz, I'm assuming that they didn't want the 32x to run into the Saturn market. The SH2s use a PLL to generate a 3X Genesis clock. Four times would be >30MHz, which was too fast for them. Using a clock synchronized to the main Genesis clock made the logic easier than using an asynchronous clock (28MHz).
|
|
|
Post by jlf65 on Mar 2, 2007 22:04:45 GMT -5
It really wouldn't be feasible to have a 128M ROM unless you un-gimped the SH2's to their stock speed of 28.7 MHz and created a very good software renderer so that 3D mode doesn't look like garbage. Unreal's software mode was and still is probably the best out there, because you don't get de-forming polygons and warping textures when you rotate your view which was very common on the 32x, Saturn and PS1. it would be nice if someone could impliment it on the 32x, assuming the correctly clocked SH2's could handle it. I'm assuming they could if you made both SH2's do the rendering and sent the game data off to the 68000 in the main genesis or SCD. All those consoles did affine texture mapping. Perspective correct mapping requires a division for every single pixel plotted, so on older systems, they would calculate the correct value at the start and end of a pixel span, then interpolate linearly between those points. If the two points are closer together, the linear region closely matches the non-linear curve generated by dividing at each point along the curve. If the points are farther apart, you get the classic fish-eye effect. So it's a trade-off: move the endpoints farther apart and you go faster (fewer divides), but you get fish-eye; closer together prevents fish-eye, but slows rendering due to an increase in divides. So you can render on the 32X such that textures aren't warped (or not enough to really tell), but it will slow down the rendering.
|
|
|
Post by jlf65 on Feb 23, 2007 19:51:23 GMT -5
If memory serves me weel, the SH2 has a 25 bit address bus : 32MB. Moreover, there are 4 chip select : CS0 to CS3, so 128MB. The 32X memory mapping does state it. But the ROM cartridge only goes from 0200 0000h to 0240 0000h, even if the CS1 would allow a cartridge from 0200 0000h to 0400 0000h. I've never tried to go beyond 0240 0000h. Yes, i do think that's right. That's where I remember the 32M from. The ROM has one select line dedicated to it and can be a max of 32M, but I don't know what the largest anyone has actually tried is.
|
|
|
Post by jlf65 on Feb 22, 2007 20:52:11 GMT -5
It can. They're talking about the Genesis side mapping for the 68K/Z80. If I remember correctly, the 32X can access up to 32MB directly on carts. I'd have to check my notes again to be certain on the exact size, but it's far larger than the Genesis side.
|
|
|
Post by jlf65 on Feb 7, 2007 22:38:30 GMT -5
Using the FIFOs for inter-CPU communications is an interesting idea. For most things, the COMM registers are sufficient for communications, and what SEGA meant for you to use. The FIFO is meant for being a DMA target/source for copying data between the two sides independent of the CPU communications.
|
|
|
Post by jlf65 on Feb 22, 2007 20:55:43 GMT -5
It depends on the device - they make USB carts for the Atari and C64 that work great with things like mice and keyboards and joysticks. It would be trying to do USB2 to a drive that would be a wee-bit pokey. ;D
|
|
|
Post by jlf65 on Feb 17, 2007 22:00:52 GMT -5
Since you put a socket in for the 68000, you might be able to make a carrier board to allow extra mem and other stuff, like an ATA port. I know the old Amigas had various things like that which plugged into the 68000 socket. I haven't looked, so I don't know if there's enough space around the 68000 in the Genesis for that.
Two plug-into-the-68k-socket devices that were most common: an ATA port, and a 68020 card. The 68020 used a clock-doubler on the 68000 clock line to run at 14MHz instead of 7. The ATA was cool as it took BARELY any more room than just the 68000 (they fit the PAL chip underneath the 68000 to save space.
In fact, I seem to remember there being plans for a 68020 that plugs into the 68000 socket on AmiNet.
|
|
|
Post by jlf65 on Feb 7, 2007 22:23:58 GMT -5
You're lucky the Genesis runs in supervisor mode all the time. The move sr,dn/move dn,sr instructions were made privileged in the 68010 and newer. That was a pain on the Atari ST/TT and Amiga series computers that ran user code (and some system code) in user mode. There were patches on both computer lines that were run by the privileged instruction exception that modified the instruction to the 68010+ instruction, move ccr,dn/move dn,ccr.
The main difference from the 68000 (besides the one above) was that the 68010 added a prefetch before certain instructions. The main one that made a noticeable difference in speed had to do with the dbcc instruction. Otherwise, the chips were virtually identical in performance.
|
|
|
Post by jlf65 on Feb 7, 2007 22:14:51 GMT -5
Some things remain strange to me : who write "MARS" at A130EC, who starts first (68k, SH2), who does what and when (SH2 BIOS/cartridge), did Sega already plan the re-mapping of the 68k memory map, or is this memory mapping one of all that are planned ... ? The 32X is disabled by default. The 68K runs initially. The register that says "MARS" is hardcoded and the ONLY register from the 32X that responds to the 68K while the 32X is disabled. It is how the 68K program code in the cart determines if a 32X is present or not. If it finds that value at that location, the 68K program now knows that the 32X is present, and if it wants to use it, it enables the 32X. Once enabled, the 68K waits for the SH2s to initialize and start handshaking. SEGA has always been sticking Genesis extensions into the hardware area. The SEGA CD works in a very similar manner. So does the modem cart they made. Each one decodes to a slice of that 0xAnnnnnnn area in the Genesis, presenting some register that the 68K can mess with.
|
|
|
Post by jlf65 on Feb 10, 2008 14:26:03 GMT -5
Even if you were looking up larger chunks of data, if you don't have the VRAM to hold that data, it isn't going to work. You can only store so much color and sprite information as the VRAM can hold. Which is why you use two VDPs - each one controls their own 64K of VRAM. One VDP would have half the data in its VRAM, and the other would have the other half in its VRAM. Remember, the 68000 doesn't access the VRAM directly, it goes through the VDP registers. You'd simply have a second VDP mapped in to a new memory location so you can access its memory the same way you do the normal VDP.
|
|
|
Post by jlf65 on Feb 9, 2008 20:49:11 GMT -5
Actually, the VDP has extra pins because they're used on the arcade boards to hook to an external RAMDAC. SEGA would use a couple VDPs in pairs to gain more colors on arcade machines that way. Adding more VDP's isn't going to give you more colors. If you want a higher color resolution, you have to add more VRAM. I don't think that the genesis has external CRAM or VRAM on the board, otherwise you could theoretically add more RAM and have more available colors if the VDP supported it (which it should). I've only been loosely following the thread on the arcade boards over at SpritesMind.net, but IIRC, adding another VDP allowed them to fetch the other "half" of the pixel data so that instead of internally looking up four bits in one of four internal palettes, you're now looking up eight bits in an external RAMDAC. Something like that. The point is, the "extra" line are a digital output that bypasses the internal palette lookup, or something along those lines. They aren't used on the Genesis, but are on arcade boards made around the same time.
|
|
|
Post by jlf65 on Feb 9, 2008 16:33:27 GMT -5
Most support chips that sega used were in-house fabs and customized for their needs, so they could turn out quite different than a stock unmodified chip. Take a look at the genesis VDP, it eventually had the Z80, PSG and itself all in one chip. I suspect the reason it had more pins is either some of them aren't used and are there to keep reverse-engineering hard. Or that there is actually some other chip integrated into it. Actually, the VDP has extra pins because they're used on the arcade boards to hook to an external RAMDAC. SEGA would use a couple VDPs in pairs to gain more colors on arcade machines that way.
|
|
|
Post by jlf65 on Mar 29, 2007 0:34:57 GMT -5
I was thinking about PWM DMA from the Genesis side... while it doesn't look like you can do it directly, it actually is fairly simple to do. First make double buffers in the SDRAM, and have the PWM DMA come from those buffers. Then fill the buffers from the Genesis side. You could use the FIFO to SDRAM DMA for that. The two sets of DMA would be completely independent of each other, one filling the buffers, the other emptying them.
It's a little more overhead then directly PWM DMAing from the Genesis side, but wouldn't tie up the Genesis side as much (FIFO to SDRAM DMA's being very fast, while PWM DMA only occurs at a word/longword every 1/22050th of a sec). As you can see, DMA channel 1 for one of the SH2's would be tied up completely by PWM DMA, so best not to tie up anything else that completely.
|
|