nesdev.org

byuu wrote:

Sik wrote:EDIT: talking about SA-1, these instructions are listed in the docs: http://srb2town.sepwich.com/junk/lolinstructions.PNG
(just mentioning for the sake of it, couldn't miss the chance XD)

Those are SuperFX instructions, but yes. I've tried to make a juvenile program, but haven't had much luck.

Gah. I hate going through the SNES docs to figure out to what does each thing belong, OK? =P (I guess I skipped where did the SuperFX stuff start)

byuu wrote:

Code: Select all

SexyPlot:
  STOP
  LINK
  WITH
  CACHE
  AND
  HAVE
  SEX
  OR
  ; ... I got nothin'

WTF?

TmEE wrote:

byuu wrote:You don't even want to know the bandwidth without DMA.

Hehe, must be really slow then

Well, if you want to do something completely useless like filling the v-ram with $05 without a DMA, using the fastest way method possible you can do this.


rep #$20
lda #$2100
tcd
lda #$0505
sta $18
sta $18
sta $18
sta $18
sta $18
sta $18
sta $18
sta $18
sta $18
sta $18...

In 16-bit mode "sta $18" takes 4 cycles and stores 2 bytes, so it takes 2 cycles to load 1 byte, which should be about 4kB.

In 16-bit mode "sta $18" takes 4 cycles and stores 2 bytes, so it takes 2 cycles to load 1 byte, which should be about 4kB.

SNES timing is best done in master clocks, not CPU cycles, since the cycle length varies depending on where the memory is.

Sik wrote:WTF?

I'll be nice:

I've tried to make a juvenile program, but haven't had much luck.
Maybe one of you can come up with a funnier sentence using only the above words.

In other words, as you astutely pointed out with your "lolinstructions.PNG" image, many of the opcode names sound rather dirty, or juvenile. So that was an example of trying to string multiple opcodes together in such an order that it comes off as if you were actually saying something dirty or offensive. I screwed it up anyway because HAVE isn't a valid opcode.

If you still don't follow, then I will quote Samuel L. Jackson from Pulp Fiction. You've been warned :P

SEX is an instruction. Oh my god. What were they thinking ??

Maybe the same thing as the 6809 designers? The 6809 also had a COMA instruction (which sadly doesn't put the processor in a hibernated state for an indefinite period of time).

blargg wrote:

In 16-bit mode "sta $18" takes 4 cycles and stores 2 bytes, so it takes 2 cycles to load 1 byte, which should be about 4kB.

SNES timing is best done in master clocks, not CPU cycles, since the cycle length varies depending on where the memory is.

I didn't touch work ram.

That wasn't his point. Point was that CPU Cycles mean nothing because depends on access to FastROM, SlowROM, WRAM, Registers, and Internal Operations the length of time taken will vary. And if you are concerned about the actual time you have in VBLANK to transfer data that matters.

sta $18

okay lets analyse this instruction

first cycle it accesses ROM (3.58 Mhz)
second cycle it access ROM again (3.58 Mhz)
third cycle it accesses v-ram data port (3.58 Mhz)
last cycle it accesses v-ram data port (3.58 Mhz)

I didn't touch anything that used 2.68 Mhz.

Anyway, my post was supposed to be a joke since nobody would ever use that kind of method in the first place.

blargg wrote:

Who knows, maybe Nintendo went with the 65816 rather than the 68000 because they had envisioned NES compatibility.

Or developer compatibility. By using a similar scheme as the NES, all the NES developers would be able to pick up the SNES more quickly. Same for the graphical scheme, which is quite similar.

That's what I thought as well. And probably the biggest reason why the Hudson chose to go with a 65x variant processor for the PC-Engine over a 16bit bus processor (as both the 16bit graphic chips support full 16bit data bus mode processor interface as well).

And the PC Engine has more colors but only one tilemap, and 8KB of RAM, and an 8-bit CPU, besides the fact that nothing was known about the SNES (was it even in active development or just research phases?).

I don't see what that has to do with Sega's decision on CRAM?

Like I said, it's very possible that CRAM memory actually ate up a lot of space on the die. CRAM memory needs to be fast so it's probably SRAM, which is usually implemented using complex gates (e.g. NOR gates), which eat up quite a fair share of transistors and thereby space. VSRAM may be the same too, which may explain why it has its own memory instead of being stored in VRAM (which is a separate chip in the original VDP).

And? By comparison, it's still only bytes, not kilobytes more (or more precisely, bits. I highly doubt CRAM is 16bit wide, but more likely 9bit internally). I highly doubt it would have broke the bank or come anywhere near that, to include another 64 entries of 9bit SRAM on the chip. Giving sprites access to either block and each layer access to either block. No external DAC needed.

Anyway, wasn't this thread originally about which system is easier to program for? Or did I miss something?

Not which is better, but which is easier or more straight forward:
Genesis:
68k;
A very lovely cpu. The instruction set is very powerful in that you don't have to write a lot of small logic. This translated into speed, of course, if it matches to what you need to accomplish. And at other times, it can be slow. But the main point, is that it's very nice. The addressing modes (EA) being the real bread and butter, IMO. Follow very closely with a straight linear address range. No banking or mapping. Pure bliss. I have to say, from the small projects I've done on the 68k - it was like I was on vacation (coming directly off of a 65x project). The downsides were small. Minding your WORD and INT boundaries, small set of address registers (depends on how you code, on the 65x I use a lot of ZP just for address registers - making the 68k feel a little cramped to me in that regard), and unable to create equates for address names (probably just a limitation of the assembler I used). The last one made my code less clear (again, coming from 65x my address regs had corresponding names and even normal zp variables did - ZP being uses a data register VS 68k's use of Dn, by comparison).

VDP;

Everything is straight forward. Nothing felt convoluted or restricted, much. You have a wide range of sprite sizes for any SAT entry. Tilemaps were easy to setup. Tiles and sprites used the same cell format. You're a little restricted as to where to place the tilemap pointers, but no a problem really. The only thing that I disliked, was the convoluted vram address setup for the COMMAND port. Not sure WTF they were thinking there. It was a real pain/chore first time around, getting used to it. Given how powerful the instruct set it, linear address range, powerful addressing mode, etc - makes it perfect for something like a C compiler. But where's the fun in that??? C for these old consoles? Pfft.

Sound;

Didn't really do anything in this department, but reading over the DOCs - the 2612 looks fairly simple to use (interface with, that is).

z80;

Haven't touched it yet. I've done some z80 work in the past, and it is what is it. Can't say that I'm a fan of the z80 ('cause I'm not ), but you're not going to be doing a lot with this little as either way.

SNES:

sPPU;

Very convoluted IMO. Lot of strict limitations too on the layout of things (tiles, sprites, formats, etc). Strange, both convoluted, kind of a mess, and strict about layouts, and yet very powerful and a lot of features.

sCPU;

It's 65x. Like all 65x based/similar processors, you need to learn to cut on teeth on these. In general, the processor itself isn't that hard to learn (IMO), but becoming really proficient is a whole 'nother story. You can really get some speed out of this arch, but the code almost always results in a convoluted mess of near unreadable code to most other coders. One of the reasons I love this processor. The rewards are worth the labor. But for any sort of speed related programming, definitely *not* a beginners processor. C compilers also suck for this arch (and understandably so).

SPC/DSP;

Haven't touched either. Sound registers look straight forward. I like the instruction set of the little processor I'd honestly take a 7.16mhz version of that little 8bit processor over the funky slow banked '816 as the main console processor, but that's just me

tomaitheous wrote:

And the PC Engine has more colors but only one tilemap, and 8KB of RAM, and an 8-bit CPU, besides the fact that nothing was known about the SNES (was it even in active development or just research phases?).

I don't see what that has to do with Sega's decision on CRAM?

They most likely thought that having two tilemaps made it superior to the PC Engine (which they didn't care so much anyways since they were looking at the NES), and they probably knew nothing about what the SNES would do with color, so they just stuck with that because it was better than both the Master System and the NES.

tomaitheous wrote:

Like I said, it's very possible that CRAM memory actually ate up a lot of space on the die. CRAM memory needs to be fast so it's probably SRAM, which is usually implemented using complex gates (e.g. NOR gates), which eat up quite a fair share of transistors and thereby space. VSRAM may be the same too, which may explain why it has its own memory instead of being stored in VRAM (which is a separate chip in the original VDP).

And? By comparison, it's still only bytes, not kilobytes more (or more precisely, bits. I highly doubt CRAM is 16bit wide, but more likely 9bit internally). I highly doubt it would have broke the bank or come anywhere near that, to include another 64 entries of 9bit SRAM on the chip. Giving sprites access to either block and each layer access to either block. No external DAC needed.

Actually, I'm not sure. I should check what happens when reading CRAM, it's possible that actually all 16 bits are stored. Pointless, but hey, this is Sega, they also screwed up majorly other things. I believe this is the same situation for VSRAM (despite the fact that only 10 bits would be needed).

tomaitheous wrote:and unable to create equates for address names (probably just a limitation of the assembler I used)

Yeah, definitely your assembler. ASM68K supports aliasing of registers.

tomaitheous wrote:The only thing that I disliked, was the convoluted vram address setup for the COMMAND port. Not sure WTF they were thinking there.

By doing it this way, the 68000 never gets direct access to video memory and has to go through the VDP. Then the VDP can decide if allow the access or make it wait because it needs the memory first.

tomaitheous wrote: Sound;

Didn't really do anything in this department, but reading over the DOCs - the 2612 looks fairly simple to use (interface with, that is).

Until you try to use the DAC. There's a complete lack of hardware timing, and no buffering at all, so you need to load samples at the exact moment they should play. Not fun at all. That's why many drivers are 68000+Z80, while some are Z80 only and hope it sounds decent, and some simply completely ignore the DAC.

tomaitheous wrote: z80;

Haven't touched it yet. I've done some z80 work in the past, and it is what is it. Can't say that I'm a fan of the z80 ('cause I'm not ), but you're not going to be doing a lot with this little as either way.

The Z80 is fine... until you stumble against bank switching. What was Sega thinking on? I know that 9 bits don't fit in one byte, but there wasn't any reason for having to write to an address 1 bit per time... that's extremely slow. Writing two bytes (separate addresses if needed) instead would have been much better.

Sik wrote:The Z80 is fine... until you stumble against bank switching. What was Sega thinking on? I know that 9 bits don't fit in one byte, but there wasn't any reason for having to write to an address 1 bit per time

Probably to save pin count, same as on MMC1. The MMC1's serial port allows connection to just D0 and D7 instead of D0, D1, D2, D3, and D4, allowing the IC to use the next smaller package size. Yet NES PCM engines worked around this limitation: how many words can you make before the sun goes down?

As for "complete lack of hardware timing", can't the Z80 see the HV counter?

That timing would be software based, and it would not be too useful... no more than YM2612 timers.

Regarding serial banker, pincount has nothing to do with it, Z80 is wired parallel to one of the ASICs, and all magic happens in that ASIC.

Something that was actually a good idea for Nintendo was having a 16x16 pixel tile mode. No longer a need for metatiles, and you can update a lot more onscreen tiles without running out of time. I wonder why this wasn't used much.

How do you know that it wasn't used much? I would imagine a fair number of games probably used it. Pretty sure BS-Zelda uses it.