|
GG2MD
Jul 4, 2007 21:30:15 GMT -5
Post by jlf65 on Jul 4, 2007 21:30:15 GMT -5
That's what the above does. It writes out a proper SMD header and then the data in the right order for SMD format.
|
|
|
GG2MD
Jul 3, 2007 15:22:53 GMT -5
Post by jlf65 on Jul 3, 2007 15:22:53 GMT -5
|
|
|
Post by jlf65 on Jun 30, 2007 13:50:05 GMT -5
Seems like a nice idea (and it's in Spanish too). It's too expensive to build a custom ASIC, instead of burning a FPGA? Notice the odd chinese name in the "subprocessor": it's the custom ASIC, although it sounds more like a "stock" part from a Chinese builder than a DIY-part. (and everybody knows from where the Radica is/was). If you look in Google for the TV16B, you will get your usual part-miner pages, but NO datasheets. The guy mentioned that he had to deal directly with that chinese IC manufacturer to get the datasheet. UPDATE: Hey, here is a (hi-rez) pic of the TV16B! It's a pirate clone of our beloved Genesis VDP/IO/whateverelse chipset! So this project is quite real, but using pirate parts I see - he's using that pirate part rather than the SEGA ASICs. Yeah, it'd be better if he just used an FPGA, but that would require more work on his part. With an FPGA, if he ran into compatibility issues, he could correct them in the FPGA. With the ASIC, he's stuck with whatever it can handle.
|
|
|
Post by jlf65 on Jun 27, 2007 1:06:10 GMT -5
The joypad muxer doesn't matter. You can use the "old" muxer with 6 button just fine. The 6-button communicates via bits that were previously undefined as you toggle the joypad successively. Here's a brief hand-waving idea of how SEGA did controllers:
3-button: wait for VBLANK read reg toggle read reg toggle
6-button: wait for VBLANK read reg toggle read reg toggle read reg toggle read reg toggle
6-button controller notice the extra toggle/reads and return the extended data in the extra reads. The wait for VBLANK is needed to allow the controller to reset for the next read. If you poll the controller too often (more than once each VBLANK), it returns indeterminate data. You can use the extra toggle/reads on 3-button controllers, but you get the same data on the extra reads. The undefined bits are defined to tell you what kind of controller is attached. I'd have to consult my notes again to tell you what bits mean what. The point is that the muxer has NOTHING to do with the way data is returned from SEGA controllers. It's merely the number of toggle/reads done each cycle.
As to the other points... if he's using multiplexed addressed ram, there are no 64K rams. When using a multiplexed bus, the size goes up by 4X, not 2X because each line represents two address bits. That's the whole point of multiplexing after all. ;D
I also don't see why static ram couldn't be used for the VRAM. Since he's making the circuits himself in the ASIC, there's no reason he shouldn't be able to use ANY kind of ram. It's just a matter of doing the circuits to use that type of ram instead of another. Personally, I'd have simply gone with one single big FAST static ram.
It seems you think he's using an ASIC pulled from the actual Genesis... I think he's making his own.
|
|
|
Post by jlf65 on Jun 25, 2007 15:16:36 GMT -5
some of the pins on the controller ports can be switched to rs232 signals through the use of software Uh - asynchronous serial. It'd take a level converter to make them into RS232 signals.
|
|
|
32X SCI
Mar 30, 2007 17:58:18 GMT -5
Post by jlf65 on Mar 30, 2007 17:58:18 GMT -5
Nope! Sorry. Pretty much what I understand is that the two SH2's are connected together via the SCI and can communicate that way, but it would be of limited usefulness given other methods of IPC.
|
|
|
Post by jlf65 on Mar 22, 2007 15:58:47 GMT -5
CDRs. What I'd love to do is make a 4MB RAM card that plugged into the 32X so that I had the ram that many programs need. Running from a CD is handy, but RAM is still an issue. Probably be easier to wire up a 30 or 72 pin ram socket to a bread board and have a whole bunch of memory available. Yeah... don't know if I ever will, but the socket method would be the most flexible way to do it.
|
|
|
Post by jlf65 on Mar 14, 2007 14:23:03 GMT -5
CDRs.
What I'd love to do is make a 4MB RAM card that plugged into the 32X so that I had the ram that many programs need. Running from a CD is handy, but RAM is still an issue.
|
|
|
Post by jlf65 on Mar 11, 2007 18:42:17 GMT -5
I use GensKMod 0.7, available at gendev.spritesmind.net That's an emulator. I doubt it emulates the SH2's so far as to simulate cache accesses. They would only have the cache-as-memory support.
|
|
|
Post by jlf65 on Mar 10, 2007 20:06:05 GMT -5
My english is not as good as what I've thought I mean, doing mov @r8,r7, when r8 = 0600 0000h, r7 should get the content of $0600 0000 and, somewhere in the cache, there should be 1 line of content : (0600 0000), (0600 0002), (0600 0004), ... (0600 000E) where (0600 0002) is the content of 0600 0002h. Shouldn't it ? Yes. How are you trying to determine if it's in the cache or not? I guess that's the question now.
|
|
|
Post by jlf65 on Mar 10, 2007 2:50:46 GMT -5
Thank you for your answer jlf65. R10 is here just to check the SH2 is actually running. I'm not trying to read the whole SDRAM. Moreover, if I increment R8 each time, the cache will be useless. Anyway, I guess that by just fetching the instruction, the cache should be filled, shouldn't it ? Uh, no. Just that location you're reading. When a cache miss occurs, it's doesn't fill the WHOLE cache. That would be silly and counterproductive. It fills one LINE of the cache... which is 16 bytes according to the SH2 manual.
|
|
|
Post by jlf65 on Mar 9, 2007 14:54:32 GMT -5
You should be incrementing R8, not R10.
|
|
|
Post by jlf65 on Mar 8, 2007 15:10:39 GMT -5
Z80: sound 68K: game control MSH2: rendering SSH2: geometry and lighting
;D
If you also had the CD, you could make the secondary 68K do the game control (since it's faster and has more memory), and make the primary 68K do the sound.
|
|
|
Post by jlf65 on Mar 7, 2007 16:14:18 GMT -5
68K: game control and sound MSH2: rendering SSH2: geometry and lighting
Don't forget that geometry and lighting... that's a big part of the equation, and probably what the manual means when it says "Within 2 SH2 units, it is normal for the master to control the entire 32X and the slave to restore the computing element inside SH2 and works expecially in numerical computing."
Computing the triangle data is almost as much work as rendering the triangles, which is why modern cards do this in hardware. I feel it's better to have the two SH2's concentrate on one task rather than swap off on alternating frames because it's easier on the cache. One SH2 always has the rendering code in its cache, while the other always has the GTL code in its cache.
At that point, the 32X is behaving as a simple 3D card, with a one pipeline GPU, and a one pipeline GTE.
As for texture correction, I'd have the GTL SH2 subdivide the triangles when they get "too big" while the GPU SH2 only does affine texture mapping. That is what good games on the PSX and Saturn did as both systems only support affine texture mapping. Once you have it going, you can experiment with the threshold used to subdivide the traingles to avoid warping while minimizing the number of triangles generated.
|
|
|
Post by jlf65 on Mar 4, 2007 1:21:04 GMT -5
Those VDP corruption issues could be a bug of the original VDP, if this is the case, a fixed/improved VDP could be implemented on the FPGAs. If the issue is located at game code level, the synchonization will be a major pain, and there is litte that can be done for it. If the synchronization was that much of an issue, you could always use two separate 68000's clocked at the proper speeds, switchable to higher speeds for software that supported full speed 68000.
|
|