Genesis ROM speed

[kool kitty89]

The chips will not overheat.... there's a point where propagation delays got so high that successive clocks get missed and execution gets messed up, causing the chip to go crash and stop working properly until its reset. I can feed 100MHz to my 68Ks and none of them will get damaged from it...

Really? Interesting, so it's just stability then? (not even heat problems from older NMOS chips in VA0/1/2 boards? -though those are already several years newer than what you'd find with really early 68000s)
Hmm, then again, NMOS circuitry doesn't have the same sort of power dissipation curves as CMOS. (CMOS draws more and more at higher speeds, NMOS consumes a lot at low speeds, but not much more at high speeds -of course, it's so much higher consumption by default, that you'd need a really, really fast CMOS chips to actually consume more . . . let alone if there's a big disparity in interconnect size -ie CMOS chips would also tend to use newer, smaller processes -I believe most of the 68000s being produced by the early 90s were 1 micron)

There's just not enough silicon/logic used to have overheating problems, I guess.


It also seems like a surprisingly high percentage of old CPUs can be substantially overclocked without crashing (the systems themselves are generally the limiting factor, so with that aside, it seems like a lot of older CPUs are stable well above their actual ratings).
It makes me wonder why more manufacturers weren't overclocking CPUs as routine. (with any really unstable chips not meeting benchmark standards being used in down-rated systems -or just accepted the occasional return of a bad machine if the failure margins were small enough)

but if I feed 12V in it then we'll get some damage, and I'm quite sure 12V is the number 1 killer... people like following guides that use 7805 directly as source for power, and people also like to strip wires very long, or do mistakes, and then wonder why nothing works afterwards

Heh, you mean people trying to pull 5V from the 7805, but accidentally pulling the unregulated 9/10/etc external power instead?

Oh, reversed polarity and kill things too . . . even going through a voltage regulator, it can fry things on the system before the regulator blows. (that happened to some of the main chips on a VCS I have -literally blew a chunk off the package of one of them)

Heh, and then there's crazy stuff like this where the CPUs can self-destruct:
http://www.youtube.com/watch?v=4YEL7Jx26Wk

http://www.youtube.com/watch?v=mZ7pUADoo58


Yeah, just a minor engineering flaw, right?

What I'd like to know is how'd he get his hands on an iron like that? Irons with that high a wattage are for stained glass soldering (or maybe welding ), not delicate electronics soldering.

They're also good for general sheet metal soldering . . . not nearly hot enough to do any brazing (let alone welding) though. You can also use a blow torch for sheet metal soldering and such (also much too cool for brazing -unless you use MAPP gas and a swirl flame burner/nozzle -maybe propane with a swirly flame, but it will be slow going)
Oh, and then there's proper soldering coppers used with a small soldering furnace (we used those in metal shop back in middle school).

High wattage soldering irons are also good for wood burning. (for inscribing, stenciling, and such)




I really need a finer tip for our soldering iron, we probably have some somewhere, but I'm not sure where. (as it is, it's not too bad, but not great for really fine stuff)
One of those cold heat things might be good for really fine work too. (also less worry about burning the board or case)

[Chilly Willy]

Heh, and then there's crazy stuff like this where the CPUs can self-destruct:
http://www.youtube.com/watch?v=4YEL7Jx26Wk

http://www.youtube.com/watch?v=mZ7pUADoo58


Yeah, just a minor engineering flaw, right?

Yeah, that is TOTALLY due to software and NOT the 45V @ 4A applied to the boards as mentioned elsewhere.

Hint that it MIGHT be fake: the AVR doesn't even HAVE a divide instruction.

[villahed94]

A bit suspicious indeed, how can a Software error lead to Cpu´s self-destruction????

[TmEE]

On one video with DIP chip you could see one logic chip explode too... I guess the pwoer supply indeed got a stack overflow or division by zero in it :P

[kool kitty89]

On one video with DIP chip you could see one logic chip explode too... I guess the pwoer supply indeed got a stack overflow or division by zero in it :P

Heh, I thought that smoke was from a capacitor at first, but it looks like it actually burnt that other chip.

[tomaitheous]

Well, it is an MCU. Maybe the stack overflow or whatever software crash, cause code to execute that turn input ports to output ports and high or low state causing havoc on some external components, 'round robin coming back to damage the chip (as well as some other circuit devices). It's possible (no, I didn't watch the videos).

Back on topic, what if a specific game only DMA'd from work ram? Thus you could get away with slower rom, right? I mean, if the VDP isn't trying to access the rom at faster than specific speeds (and at all), then I don't see why local vDMA would be an influencing factor.

[Chilly Willy]

Back on topic, what if a specific game only DMA'd from work ram? Thus you could get away with slower rom, right? I mean, if the VDP isn't trying to access the rom at faster than specific speeds (and at all), then I don't see why local vDMA would be an influencing factor.

I think someone mentioned something similar earlier in the thread. Yes, if you put the data in the work ram and DMA'd it from there, the rom could be slower. The rom needs to be faster if you DMA straight from rom.

There's also another reason the rom should be faster - there's a bug in the IO hardware where if the Z80 is accessing the rom while the 68000 accesses the controller ports, the Z80 rom accesses will be shortened from then on. The short access cycle WILL cause slow roms to fail on the Z80 access. For slow roms where this is a danger, SEGA recommends requesting the Z80 bus before you read the controller ports, then release the Z80 when done. All the example SEGA code for reading the pads all do this as a result. If you use a faster rom, the short Z80 access won't cause a problem, so you don't need to request the bus from the Z80 before reading the IO.

[kool kitty89]

Back on topic, what if a specific game only DMA'd from work ram? Thus you could get away with slower rom, right? I mean, if the VDP isn't trying to access the rom at faster than specific speeds (and at all), then I don't see why local vDMA would be an influencing factor.

I mentioned that earlier, but wouldn't that also involve the CPU copying data to work RAM beforehand -and then more overhead -CPU halted- for DMA to copy that to VRAM? Why not just have the CPU directly copy data to VRAM during vblank instead? (unless you could optimize the game's code better by having the CPU copy data to work RAM when it was more convenient -rather than only in vblank- and spend significantly less time "stuck" in vblank due to DMA's much faster copy rate -still more CPU time down to updating VRAM, but potentially more conveniently spread out, potentially avoiding certain performance bottlenecks)

Plus, if you had the data compressed in ROM, you'd probably end up decompressing it into work RAM before dma'ing it to VRAM. (granted, you'd probably only manage fairly simple compression schemes on the fly -like RLE- unless perhaps you did very gradual updates and could thus do more intensive schemes without heavy continuous overhead)

[tomaitheous]

I think someone mentioned something similar earlier in the thread. Yes, if you put the data in the work ram and DMA'd it from there, the rom could be slower. The rom needs to be faster if you DMA straight from rom.

There's also another reason the rom should be faster - there's a bug in the IO hardware where if the Z80 is accessing the rom while the 68000 accesses the controller ports, the Z80 rom accesses will be shortened from then on. The short access cycle WILL cause slow roms to fail on the Z80 access. For slow roms where this is a danger, SEGA recommends requesting the Z80 bus before you read the controller ports, then release the Z80 when done. All the example SEGA code for reading the pads all do this as a result. If you use a faster rom, the short Z80 access won't cause a problem, so you don't need to request the bus from the Z80 before reading the IO.

Ahh. I remember reading that Sega recommended halting the z80 before reading the I/O ports, but I didn't remember any particular reason for it (just something about a potential lockup, but no specific details). So that's why. Interesting and good to know.

I mentioned that earlier, but wouldn't that also involve the CPU copying data to work RAM beforehand -and then more overhead -CPU halted- for DMA to copy that to VRAM? Why not just have the CPU directly copy data to VRAM during vblank instead? (unless you could optimize the game's code better by having the CPU copy data to work RAM when it was more convenient -rather than only in vblank- and spend significantly less time "stuck" in vblank due to DMA's much faster copy rate -still more CPU time down to updating VRAM, but potentially more conveniently spread out, potentially avoiding certain performance bottlenecks)

Plus, if you had the data compressed in ROM, you'd probably end up decompressing it into work RAM before dma'ing it to VRAM. (granted, you'd probably only manage fairly simple compression schemes on the fly -like RLE- unless perhaps you did very gradual updates and could thus do more intensive schemes without heavy continuous overhead)

It's extremely common for games to compress sprite and tile data, as well as tile map data. Almost all Genesis games I've seen mentioned with compression schemes, use an LZ variant for tile/sprite data. That can't exactly be decompressed fast enough for realtime/single frame requests. And if it did, normally it still needs a full area in ram to decompress to - unless to you use a circular buffer and directly write to an I/O port but this means the CPU writing to the port or calling the vDMA in small bursts as aligned segments are decompressed into the ring buffer. Either way, it's slow going and requires ram (small circular buffer or full decompressed area needed). Tilemaps can usually get away with RLE variant compression and can be made direct port write friendly if needed. But if you got free cpu resource during active display, then no reason why you shouldn't decompress to ram and just vDMA during vblank. I think the only exception where most developers probably wouldn't compress data would be palette blocks. The overall palette data to rom size is incredibly tiny. Probably less than 1% of 1%. If a developer is choosing to use a slow rom, then they only have to make sure to copy the CRAM data using the cpu or copy it to ram first before vDMA. Not a big deal IMO.

[Sik]

There's also another reason the rom should be faster - there's a bug in the IO hardware where if the Z80 is accessing the rom while the 68000 accesses the controller ports, the Z80 rom accesses will be shortened from then on. The short access cycle WILL cause slow roms to fail on the Z80 access. For slow roms where this is a danger, SEGA recommends requesting the Z80 bus before you read the controller ports, then release the Z80 when done. All the example SEGA code for reading the pads all do this as a result. If you use a faster rom, the short Z80 access won't cause a problem, so you don't need to request the bus from the Z80 before reading the IO.

Only that access gets shortened if I recall correctly, not all following accesses. Also, I was under the impression that the problem wasn't slow memory response but the slow processor (basically, Z80 tries to read from memory, but 68000 stomps into place and changes the bus contents while the Z80 is still on its reading cycle, causing the Z80 to read garbage).

Plus, if you had the data compressed in ROM, you'd probably end up decompressing it into work RAM before dma'ing it to VRAM. (granted, you'd probably only manage fairly simple compression schemes on the fly -like RLE- unless perhaps you did very gradual updates and could thus do more intensive schemes without heavy continuous overhead)

UFTC =P

Also quoting myself from another topic:

Also just now I bothered to do a stress test of UFTC, I had forgotten to do it >_> Tested against Stephany sprites in Project MD, which seems like a good candidate for this thing:

• Uncompressed size: 44,576 bytes (100%)
• Compressed size: 19,482 bytes (43.7%)

Well, it isn't much, but it's still some important saving =| This also goes to prove that UFTC works well when used in the domain it was designed for.

[Chilly Willy]

Ahh. I remember reading that Sega recommended halting the z80 before reading the I/O ports, but I didn't remember any particular reason for it (just something about a potential lockup, but no specific details). So that's why. Interesting and good to know.

Yeah, there's a tech bulletin about it that goes into it at some depth, even showing how it occurs and how much the Z80 cycle is shortened. They include the latest recommended pad read code that halts the Z80 before reading. I had a talk with Steve Snake about that years back over at SpritesMind over whether that halt is really needed or not. With "modern" (for the mid-90's) roms and flash cards, it's not. But if you were trying to use as slow a rom as possible for some reason, it would be something to keep in mind. The bulletin was more trying to explain why some devs lost sound WAAAAAAAAY back in the stone age of MegaDrive development.

[kool kitty89]

It's extremely common for games to compress sprite and tile data, as well as tile map data. Almost all Genesis games I've seen mentioned with compression schemes, use an LZ variant for tile/sprite data. That can't exactly be decompressed fast enough for realtime/single frame requests. And if it did, normally it still needs a full area in ram to decompress to - unless to you use a circular buffer and directly write to an I/O port but this means the CPU writing to the port or calling the vDMA in small bursts as aligned segments are decompressed into the ring buffer. Either way, it's slow going and requires ram (small circular buffer or full decompressed area needed). Tilemaps can usually get away with RLE variant compression and can be made direct port write friendly if needed. But if you got free cpu resource during active display, then no reason why you shouldn't decompress to ram and just vDMA during vblank.

Yes, anything loaded ahead of time (between levels, before a boss fight, etc) would be heavier/more optimal stuff, but decoding-resource-light compression could be an attractive alternative to areas you'd otherwise have to use uncompressed textures. (be it an RLE derivative or something else . . . or perhaps use column or line based RLE selectively on a per-texture basis -you'd really need textures catering well to RLE for decent results in either case -the examples of, apparently, RLE encoded FMV on the MCD obviously use almost a complete lack of dithering and possibly additional preprocessing to cater even better to RLE, and use full-frame bitmaps rather than smaller textures, so much tending towards better compression ratios, plus you have the sub-CPU and ASIC to help out there too)
Doing a 4-bit specific RLE format could be particularly attractive for smaller/medium sized objects (or anything that doesn't have considerable amounts of solid color lines -or dithered pairs if you did RLE on a paired pixel basis) since you could use 1 byte with the 1st nybble defining the color and the 2nd defining the length of pixels to fill (1 to 16) and only wasting 4-bits for each case of a single pixel rather than 12 (compared to uncompressed 4-bpp graphics), and you'd rarely need more than 16 pixels in a row anyway.

But back to the issue of slow ROM, that's also where DMA directly to VRAM would be important (games with lots of on the fly animation with VRAM maxed out, so no compression or light compression). I think it was mentioned that SFII uses a ton of uncompressed sprite animation that gets DMA'd straight from ROM . . . so if DMA DOES ever need ROM faster than the 68k needs, you might have some games where you couldn't DMA graphics from ROM. (of course, most such games would be rather large in general, and thus tend to be later games, facilitating faster ROM at low cost, with most small/early games tending to load everything into VRAM beforehand)

And yes, CRAM updates would be trivial to buffer as mentioned before. (also noted was that CRAM DMA would need significantly faster access times than normal graphics block transfer)

[bloodflowers]

I just reprogrammed a Mega Turrican US cart so that it works on a Japanese unmodified console - problem is I'm seeing odd instances of full screen corruption like it didn't read the tiles or map data quickly enough - just does it for a frame. Do you think it might be EPROM speed? I used a 27C800-120 chip. Just ordered a few 100s but I keep reading that 150 'should' be OK.

Has anyone seen this happen before? I suppose it's possible I have a somewhat flaky C800 but..

[TmEE]

150ns is on the bleeding edge for DMA, 200ns will have faulty DMAs. 120ns and lower should work fine

[bloodflowers]

150ns is on the bleeding edge for DMA, 200ns will have faulty DMAs. 120ns and lower should work fine

Well I swapped it for a 100ns chip, seems less glitchy but still the occasional glitch on screen and hangs from time to time. It's a strange one, I took the Mega Turrican US rev, changed the region and fixed the checksum, byteswapped it and am running it on a known good system. I'd love to know just how fast the original ROM was, but there's no part number on it - just the datestamp and EPR number.

Maybe it's the make of chip - what are people using these days? Does anywhere sell dev boards with on board flash I could use instead? It needs to fit inside the original cart casing though with no modifications.