How many sprites can the Neo Geo update per frame?

[Pokun]

Yeah I seldom need RAM registers larger than 16 bit in games (but I also haven't really made very advanced games yet), and 32 bit for me seems huge. Even 8 bit is enough in most cases.
I have never worked in 3D though so I can't compare with that.

The zero page addressing was indeed supposedly designed to use the first page of RAM as general purpose registers due to the low number of internal CPU registers of the MOS 6502 (or rather the Motorola 6800 which did it first). I think zero page registers are still a lot slower than the internal CPU registers though.

I guess the 68000 may seem more CISC because it has slower instructions that do more work while 6502 requires more combining of instructions. I would still call both CISC however.
RISC to me work like PIC, ARM and MIPS where you generally have quite a few general purpose registers instead of one or more accumulators (though PIC also has an accumulator), some formally or informally doubling as CPU registers like stack pointers, return addresses and parameters or return values for subroutines. And more importantly RISC instructions are carefully designed, based on research, as primitives that can be used on their own or combined into "full" instructions like logical building blocks. In the case of PIC they are designed to all uniformly take 1 cycle each (except jumps which takes 2) and for (classic) ARM all instructions are exactly 32 bit large (and 16 bit large for THUMB instructions).
The 6502 is merely a simplified 6800 where the most unnecessary instructions are removed in order to make it cheaper to produce. It does require combining more instructions to do things no longer possible in a single instruction, but instructions still vary greatly in timing, size and in what type of work they do, so it's still no doubt CISC.
I'm not familiar with modern CPUs though, maybe this definition is more blurred now.

[stan423321]

Oh, for @#$%'s sake. Fiskbit is going to hate me for replying to this argument again, but since it is brought up again, I kind of have to: "RISC" and "CISC" are marketing labels (by RISC teams, of course) without much concrete meaning behind them that is really agreed upon, especially across the time that passed, and in context of an 8-bit processor the little concreteness that is there goes away.

There are certainly some analogies to be drawn between original 6502 and various commonly-agreed-to-be RISC instruction set architectures, but there is at least a comparable amount of blatant differences. 65c816's additions are very much not in the RISC camp.

68k is indeed considered CISC, because it was one of the known ISAs extant when RISC crowd was starting trying to do something different. However, it isn't really the archetypical CISC monstrosity that was IA-16, and IA-16 apparently wasn't the worst. If you asked proponents of particular RISC ISAs what features make 68k CISC, you would get somewhat different sets of answers. Some of them would be extremely applicable to 65c816 and 6502, some less so.

Realistically, though, if you find someone who directly writes some type of RISC assembly and give them the choice of coding for 68k or 6502/65c816, I doubt you'll find someone who says the latter is more like their specialty.

[aa-dav]

Well, I wat to say too.

First of all - 6502 is very generic architecture of 197x years.
It's 'accumulator-memory' architecture. Every instruction has memory cell address which is used in conjunction with single accumulator.
It's not RISC in any meaning, it's just typical CPU of 197x with one important note: BYTES.
It's byte-oriented, so there is no 'machine word' with some unnatural bit width in today's terms, but just bytes, so instructions has unfixed size.
And in unfixed instruction sizes it was very logical to intrduce zero-page for one-byte addressing.
However it is not changing 'accumulator-memory' architecture. It's just it.

What is RISC really about? It's about pipeline.
The main idea is: make every instruction to fit linear pipeline. Every instructions are fit in pattern 'fetch-decode-(fetch)-compute-(store)' and these separate stages of previous instructions do not mess with stages of next instructions. This pattern makes 'reduced' set of instructions (there are no monsters which make dozens of fetches or dozens of computing in single instruction), however this is complicated question I do not want to deep in now.
Anyway - RISC is about pipelining and fitting instruction stages into pipeline.
RISC also made some important pattern: ALU operations are register-register only. It is important for prevent memory access stalling. These type of architectures are called 'load/store'. Because we load values from memory to registers (additional fetch stage in LOAD instruction), make operations with them in registers and store result to memory (additional store stage in instruction). No instruction can fetch and store in one time to not overburden pipeline.
Modern ARM 64 is a excellent example of clean and strong 'load/store' architecture - everything is best-fit in it. We can even load two separate 64-bit registers from memory, but it must be one 128-bit memory location to fit in single fetch.
6502 is not RISC in any term from birth, it's just typical accumulator-memory architecture from 197x.
It's really very simple arhitecture, but it's core is against RISC - almost every instruction takes second argument from memory and stalls hypotetical pipelining. Also it has instructions which reads/writes to/from memory in one instruction.
However there is pipelining in modern MCU's with similar architetures - simplicity is good for this - separation of program memory vs data memory is good way to make pipelining work in this scheme.

[turboxray]

Obviously though Ne Geo has a fast (12Mhz) 68000 which helps here.

There are bus wait states or congestion (I forget which) that brings that 12mhz number down tho.

What is RISC really about?

I've seen a lot of people try to describe the essence of RISC is many different ways. But they gloss over why RISC was created in the first place, and instead end up talking about attributes of RISC.. when really those are just natural side effects...by-products of the design, but not the core itself. You DON'T need a pipeline for a processor to be RISC.. you don't even need to be performant or fast.. to be RISC. You CAN have a slow RISC design/processor. It might not be desirable, but it doesn't make it not RISC.

RISC's primary purpose was to decouple the processor instruction set from higher level languages (which, before the term was coined, "CISC" was definitely heading in that direction). The complexity of optimization was put solely on the software (compiler), and instructions weren't tied or influenced by any specific language. The 2nd purpose of RISC, was that it created a much small transistor foot print; lower cost, lower heat, lower power, better potential yields, etc. Things like pipelines, number of registers (and actual "general purpose" registers.. I'm looking at you, x86! and all your lies), etc - those are not unique attributes to RISC. They existed before RISC.

I've seen people make the claim that 6502 inspired RISC. Maybe it did.. maybe it didn't. I mean, I'm sure ALL known processor designs influenced its research, design, and approach. I find it difficult to believe that you're into micro processor design, but are ignorant of other designs.

That said, I can see why people feel like the 65x has the "spirit of RISC".. small, simple, fast instructions. Sure, it doesn't force everything through registers (what registers haha).. and it's extremely bus hungry because its focus/reliance on direct memory addressing modes, but you can feel the parallels between the organization and building up of complex logic from the simplest instructions. By comparison, the 68k.. feels like a high level language compared to the 65x. And that's not an exaggeration. And the x86? That just feels like crap hahah.

[aa-dav]

RISC's primary purpose was to decouple the processor instruction set from higher level languages

Never it was.
Look at the first real RISC processors - it's never was something about 'just do CPU simple'.
Simple is not the goal. This goal was always from birth of CPUs as such.
From first scratches it was the goal and it's not something which determines 'RISC vs CISC'.
Simple CPU is not obligated to be RISC.
For example: my virtual CPU SimpX 4 is extremely simple: it has just 16 instructions every of which are 'R = Y op X', but it's not RISC in any way.
Simplicity of instructions has nothing to be common with RISC idea.
Why it's not RISC? Because every of three parameters can be indirect memory location and this involves additional fetches.
RISC is about pipelined (and aligned with pipleine) instructions. It's about how complex fetching/storing data is and how many cycles instruction can take from ALU and all of this is about pipeline.
And that's it.

[aa-dav]

ARM made really holy mess with Thumb instructions which made ARM CPUs in thumb mode CISC as such.
It's just holy mess.
In ARM 64 they returned to RISC in full glory.

[creaothceann]

[...] The design was based on a study of IBM's extensive collection of statistics gathered from their customers. This demonstrated that code in high-performance settings made extensive use of processor registers, and that they often ran out of them. This suggested that additional registers would improve performance.
Additionally, they noticed that compilers generally ignored the vast majority of the available instructions, especially orthogonal addressing modes. Instead, they selected the fastest version of any given instruction and then constructed small routines using it. This suggested that the majority of instructions could be removed without affecting the resulting code.
These two conclusions worked in concert; removing instructions would allow the instruction opcodes to be shorter, freeing up bits in the instruction word which could then be used to select among a larger set of registers.

That's why it's called Reduced Instruction Set Computer.

[aa-dav]

[...] The design was based on a study of IBM's extensive collection of statistics gathered from their customers. This demonstrated that code in high-performance settings made extensive use of processor registers, and that they often ran out of them. This suggested that additional registers would improve performance.
Additionally, they noticed that compilers generally ignored the vast majority of the available instructions, especially orthogonal addressing modes. Instead, they selected the fastest version of any given instruction and then constructed small routines using it. This suggested that the majority of instructions could be removed without affecting the resulting code.
These two conclusions worked in concert; removing instructions would allow the instruction opcodes to be shorter, freeing up bits in the instruction word which could then be used to select among a larger set of registers.

That's why it's called Reduced Instruction Set Computer.

Why you do not write it to the end?

1986, which turned out to be a commercial failure

This design was fail and history is just: it is fail.
No term was dervived from this fail. You are just wrong.

[Pokun]

I've seen a lot of people try to describe the essence of RISC is many different ways. But they gloss over why RISC was created in the first place, and instead end up talking about attributes of RISC.. when really those are just natural side effects...by-products of the design, but not the core itself. You DON'T need a pipeline for a processor to be RISC.. you don't even need to be performant or fast.. to be RISC. You CAN have a slow RISC design/processor. It might not be desirable, but it doesn't make it not RISC.

Sure but as long as RISC is considered a "genre" of microprocessors and there is no exact definition, we can only talk about characteristics that are typical for the genre by looking at existing MPU designs. That doesn't mean RISC MPUs requires them nor that CISC MPUs can't also have them, only that they are more typical for RISC than CISC.
I don't feel small and fast instructions is enough for it to be RISC. GP-registers (despite the CISC 68000 also having them) and pipelining are very typical RISC characteristics however.
Now, I admit that I don't know a ton of MPU designs, so I might not be the right person to judge what characteristics counts as CISC and what counts as RISC.

ARM made really holy mess with Thumb instructions which made ARM CPUs in thumb mode CISC as such.
It's just holy mess.
In ARM 64 they returned to RISC in full glory.

Heh and that mess was Nintendo's "fault". Nintendo asked them to solve the problem that the 32-bit instructions were too large for their purposes in GBA games (they took up too much ROM space which would make games too expensive), so Acorn invented the 16-bit THUMB instructions specifically for the GBA CPU.

[stan423321]

I've seen a lot of people try to describe the essence of RISC is many different ways. But they gloss over why RISC was created in the first place, and instead end up talking about attributes of RISC.. when really those are just natural side effects...by-products of the design, but not the core itself. You DON'T need a pipeline for a processor to be RISC.. you don't even need to be performant or fast.. to be RISC. You CAN have a slow RISC design/processor. It might not be desirable, but it doesn't make it not RISC.

RISC's primary purpose was to decouple the processor instruction set from higher level languages (which, before the term was coined, "CISC" was definitely heading in that direction). The complexity of optimization was put solely on the software (compiler), and instructions weren't tied or influenced by any specific language. The 2nd purpose of RISC, was that it created a much small transistor foot print; lower cost, lower heat, lower power, better potential yields, etc. Things like pipelines, number of registers (and actual "general purpose" registers.. I'm looking at you, x86! and all your lies), etc - those are not unique attributes to RISC. They existed before RISC.

Everyone has their own opinion on what's RISC movement's primary purpose was, what the "side effects" were, and what stuff was impure. One Wikipedia definition (since Wikipedia rightly notices the issue is murky) involves a pipelining and compiler optimization friendly design, for instance.

The attributes an ISA ends up with can be at least observed somewhat objectively. The "primary purpose" aspect, beyond "let's make chips cheaper, faster, less power hungry, and less buggy" which indeed really applies to most processors, is more of a quote hunt than design analysis.

I have seen many claims that RISC involved removing or decomposing complex instructions that were not used by higher level language compilers - presumably, in part since the compilers weren't optimizing for size and some simple instruction sequences were faster assuming cache hits and known constants; in part because the faster complex instructions like decrement-and-maybe-branch were hard to generate automatically; in part because some operations like BCD addition were just wacky; and in part because the high level semantics encouraged certain operations, like full width integer addition, over others - but this is the first time I've seen "decoupling" from high level languages mentioned. I think this would require some specifics to evaluate, since high level languages are also varied and there's no universal agreement on what is an HLL feature (stack?). In general, I would say early RISC ISAs are more coupled than CISC with some arbitrary non-specific HLL existing, due to their "no guardrails" manual pipelining with branch delay slots, load delay slots, arithmetic delay slots, etc..

---

I'm not going to evaluate claims of particular RISC being possibly RISC-ier than another RISC here. It has less to do with Neo Geo than with arguments over superiority of Easter over Christmas.

[turboxray]

RISC's primary purpose was to decouple the processor instruction set from higher level languages

Never it was.
Look at the first real RISC processors - it's never was something about 'just do CPU simple'.
Simple is not the goal. This goal was always from birth of CPUs as such.

Dude. It's in the name.. "Reduced". And the ISA is simple.. so rudimentary simple in fact that instructions like "LD #imm, <reg>" didn't even exist in most RISC. It's a macro in the assembler.. it's usually just ADD instruction. And on top of that two instructions: ADD low and ADD high because they're limited to 16bit immediates and not 32bit immediate.

RISC is about pipelined

What is your obsession with pipelines. ALL processors advanced the to a pipeline architecture. It's a natural evolution/progression of all processors. Next you'll say RISC is about cache. If you're trying to say that RISC design is/was more adaptable to pipelining that CISC, then sure.

GP-registers (despite the CISC 68000 also having them) and pipelining are very typical RISC characteristics however.

The 68k doesn't have "general purpose" registers. It has data registers and address registers. A general purpose register allows any operation on it; address vectoring, logical operations, etc.

I think it's pretty evident that the 68k was designed for a more advanced shared bus systems (more advance systems than your typical micro). The expansion of registers to keep workload to register-register, and off the bus. The more powerful instructions meant less time fetching numerous instructions on the bus for the same operations (especially the 32bit operations).

RISC MPUs requires them nor that CISC MPUs

You can't just call them CPUs like everyone else? Lol I had to look up "MPU".


No mention of the 3-operand format for instructions for RISC processors either? I think that's a pretty defining characteristic of RISC design. It was the first thing that jumped out to me when delving into RISC assembly years ago. A pretty big departure from the 2-operand instructions of the 68k. The first thing that you notice about RISC in writing assembly, is the 3-operand format... and then the realization of all the direct addressing modes are gone (everything is through address vectoring via register). Not pipelines, or cache, or whatever. Edit: I'm sure there's at least one RISC processor that doesn't employ 3-operand instructions (Hitachi?).



Side note: I don't know why the thread is hyper focused on the 68k for the CISC example. The x86 was widely more popular and in use. Get into the 386/486 side, and you got not only prefix instructions, but also post-fix bytes/instructions... before you even get to the operand itself (something that's not exposed to you on the assembler level itself). And x86-64 has additional post-fix bytes on top of the original existing post-fix bytes. If you want to talk about CISC vs RISC.. it should be x86 as CISC. If you ever had to deal with x86, outside of an assembler, on a binary/byte level.. it's straight-up disgusting. I had to write a realtime instruction decoder for x86-64 for a custom segfault handler last year.. and it was the worst and most frustrating experience dealing with instructions ever. Vastly different from the PPC and ARM instructions I had to deal with at the same time.

[Pokun]

GP-registers (despite the CISC 68000 also having them) and pipelining are very typical RISC characteristics however.

The 68k doesn't have "general purpose" registers. It has data registers and address registers. A general purpose register allows any operation on it; address vectoring, logical operations, etc.

Right, my bad.

No mention of the 3-operand format for instructions for RISC processors either? I think that's a pretty defining characteristic of RISC design.

Sure, there are probably many others too.

Side note: I don't know why the thread is hyper focused on the 68k for the CISC example. The x86 was widely more popular and in use.

Why would we talk about the x86? This is a Neo Geo thread and the RISC sidetrack discussion started with someone saying 6502 is more RISC than 68K which I feel is quite commonly stated, and may be considered technically correct, but mentioning both RISC and 6502 in the same sentence doesn't feel right to me. It's a bit like saying that chess is more of a platform game than pachisi. Chess is 2D and pachisi is 1D but neither is a platform game and saying one is closer is kinda stretching things unnecessarily.
The x86 is indeed a traditional accumulator-based CISC microprocessor and no one has said anything else.

[turboxray]

Why would we talk about the x86? This is a Neo Geo thread

Because the thread has devolved into something that has nothing to do about the NG - but just RISC in general and what makes RISC... RISC. If you're talking about RISC, and CISC, then you need some concrete examples of what both are.

[Pokun]

That was not my point.

[NeoOne]

Yeah I seldom need RAM registers larger than 16 bit in games (but I also haven't really made very advanced games yet), and 32 bit for me seems huge. Even 8 bit is enough in most cases.
I have never worked in 3D though so I can't compare with that.

The zero page addressing was indeed supposedly designed to use the first page of RAM as general purpose registers due to the low number of internal CPU registers of the MOS 6502 (or rather the Motorola 6800 which did it first). I think zero page registers are still a lot slower than the internal CPU registers though.

Yes 8 bit variables good for many things although on 68000 I don't think byte operations are any faster than 16 bit ones.

I was reading somewhere recently that all N64 games run in 32 bit mode. Just because there was no real point to using 64 bits. 32 bits is accurate enough! Even 3D had its limit back then

Why would we talk about the x86? This is a Neo Geo thread and the RISC sidetrack discussion started with someone saying 6502 is more RISC than 68K which I feel is quite commonly stated, and may be considered technically correct, but mentioning both RISC and 6502 in the same sentence doesn't feel right to me. It's a bit like saying that chess is more of a platform game than pachisi. Chess is 2D and pachisi is 1D but neither is a platform game and saying one is closer is kinda stretching things unnecessarily.
The x86 is indeed a traditional accumulator-based CISC microprocessor and no one has said anything else.

Yes i think people missed what I was saying. I wasn't saying the 6502 *was* a RISC processor I was just saying that's what it *reminds* me of. E.g. on 68000 you have a MUL instruction to multiply and a DIV instruction to divide but on 6502 you have to write those out all in the little individual steps by adding or subtracting or whatever. I don't know much about RISC CPUs at all.


BTW on the (Simple) Neo Geo Game I am working on, it can now display (+ collision check) up to 140 enemies, 153 enemy bullets and 21 player bullets. In total it displays and updates 349 sprites (including background sprites) per frame at 60fps. It's a terrible game though! (I am just optimizing it for a challenge).

Weirdly there has been no sprites dropping out yet (due to the horizontal sprite limit). It's just the way the sprites arrange themselves on screen. The actual sprite-update routines themselves don't take up much time. I haven't measured them exactly yet but they easily fit inside the 40 line vertical blank period. The game currently updates the x coordinate of *all* 380 Neo Geo sprites at the moment, even though not all of them are used. I just coded that for convenience and never took it out.