Genesis Address Bus and Max RAM

[evildragon]

Something that has been bothering me, and really wanted to know.

Is the address bus in the Genesis 16-bit, or the full 24-bit that the 68000 had?

Because if it was 16-bit, technically, it can only address up to 64KB of RAM. (2 to the 16th power). But if it was 24-bit, then it could address up to 16MB of RAM.

But Sega said it's a 16-bit console. (which still makes no sense, because the 68000 is technically 32-bit, forwards compatible)..

And if it's a 16-bit address bus, with 64KB RAM max, how is it some people have did a 128KB RAM mod and it worked? Can it bank switch the RAM or something?

I'm missing something here.

[Jorge Nuno]

Yes you're missing something: MD has a FULL 24 bit address bus

ROM starts at 0, ends and 3FFFFFh
VDP is present at C0000Xh
RAM starts at E00000h, ends at FFFFFFh and it's repeated every 10000h

I just added some more in here, now atm is 256K and its repeated every 40000h. All games I have work because they don't cross the boundaries of 10000h...like accessing E00000h and next FF0000h and expecting the same data.


All these address are part of the 68K address bus, and it's heavily wasted like 400000h to BFFFFFh (there are some bits at AXXXXXh)

What you have to undersand is that address bus limits not only the max RAM possible but everything.
If you connect a 64K ram to the z80 (16bit ADDr) you can't access nothing more, because you don't have spare lines


Now this is true when you aren't playing around with swapping schemes...

[tomaitheous]

ED: It's a 16bit DATA BUS and a 24bit ADDRESS BUS.

Sega stated it as a 16bit console because the ALU's are 16 bit. It has multiple 16bit ALUs that can be used for handling 32bit operand (which take longer to execute), but it's not a 32bit processor with a 32bit ALU like the 68020.

[evildragon]

ED: It's a 16bit DATA BUS and a 24bit ADDRESS BUS.

Sega stated it as a 16bit console because the ALU's are 16 bit. It has multiple 16bit ALUs that can be used for handling 32bit operand (which take longer to execute), but it's not a 32bit processor with a 32bit ALU like the 68020.

But wikipedia said this:

The 68000 implements a 24-bit address bus, allowing it to address up to 16 MB of physical memory. Address storage and computation used 32 bits, however, with the high-order byte ignored due to the physical lack of pins. This allowed it to run software written for a flat 32-bit address space. By modern definition this meant that the 68000 was a 32-bit microprocessor.

If this is wrong, it should be corrected. Because it also says this:

The CPU had eight 32-bit general-purpose data registers (D0-D7), and eight address registers (A0-A7).

Registers and bus are the same, right? Or wrong? I don't know. (I'm more of a technical repair person, not an engineer)

[TmEE co.(TM)]

68000 is 16/32bit CPU, combination of both

[evildragon]

68000 is 16/32bit CPU, combination of both

Ok. I'll just leave it at that. I still prefer to call my Genesis the 32-bit system it never was. But I'll just keep that to myself then.

[Chilly Willy]

Gah! It's the old hardware vs software argument. To hardware engineers, the 68000 is a 16 bit CPU. Period. It only has a 16 bit ALU, and the ALU is the ONLY measure of a CPU to a hardware engineer. To software engineers, the 68000 is 32 bit. Period. It has 32 bit registers and can access a full 32 bit addressing range (the external bus just drops the top 8 lines), and the register width used in addressing memory is the ONLY measure of a CPU to software engineers. That is why people not on one side or the other call it a 16/32 bit CPU - it's 16 bit from one point of view, and 32 bit from another.

[tomaitheous]

The 68000 implements a 24-bit address bus, allowing it to address up to 16 MB of physical memory. Address storage and computation used 32 bits, however, with the high-order byte ignored due to the physical lack of pins. This allowed it to run software written for a flat 32-bit address space. By modern definition this meant that the 68000 was a 32-bit microprocessor.

If this is wrong, it should be corrected. Because it also says this:

The CPU had eight 32-bit general-purpose data registers (D0-D7), and eight address registers (A0-A7).

Registers and bus are the same, right? Or wrong? I don't know. (I'm more of a technical repair person, not an engineer)

That's some screwed up logic. Because the PC(program counter) is 32bits, the CPU is 32 bits? Than all 8 bit CPUs are really 16bit CPUs because they had 16bit PCs.

Same with the argument about the registers. There are 8bit CPUs with 16bit register (general purpose, indexing, or arithmetic), but that doesn't make them 16bit CPUs - nore does the BUS. It's the ALU that classifies the "bit-ness" of a processor.

The 68k was designed with seamless(or as could be) 16bit into 32bit migration/upgrade in mind for when 32bit platforms (68020,030, etc) were going to be cheap enough for implementation, adding forward compatible 32bit instructions. To me, it's more of a code saving feature on the original 68k. I can implement 32bit operations on a 16bit CPU without the need for extended code to support operations (i.e. using multiple variables and such).

I wouldn't take wiki too seriously. One wiki site said the 68k was a CISC processor. It surely was not. Apparently whoever wrote the article never seen a CISC instructions set. It might not be in what RISC is defined by todays standards(whatever the hell that might be), but it was sure as hell RISC in 1979.

[Chilly Willy]

Same with the argument about the registers. There are 8bit CPUs with 16bit register (general purpose, indexing, or arithmetic), but that doesn't make them 16bit CPUs - nore does the BUS. It's the ALU that classifies the "bit-ness" of a processor.

That's how I feel about it, but then, I'm a hardware guy. It's the ALU that defines a CPU.

I wouldn't take wiki too seriously. One wiki site said the 68k was a CISC processor. It surely was not. Apparently whoever wrote the article never seen a CISC instructions set. It might not be in what RISC is defined by todays standards(whatever the hell that might be), but it was sure as hell RISC in 1979.

Now that I don't agree with. The defining characteristic of a RISC architecture is that has a load/store architecture - you load data to registers, perform the operations on the registers, then store the registers back to memory, all with separate instructions. The 68K was like other CISC processors, operating on memory directly as much as registers. There are very few "purely" RISC or CISC processors, but the 68K is clearly closer to CISC than to RISC. Look at it's characteristics: it's microcoded, it has a VERY orthogonal instruction set, and it was capable of doing most operations on memory. Those are ALL CISC characteristics.

[tomaitheous]

Ohh? It was microcoded? Maybe that would explain the slow memory access (4cycles). That's strange they did that considering the 6800/6809 series wasn't microcoded.

Anyway, I always considered it RISC in that it had a small library of instructions, had a large array of registers(compared to other CPUs in 1979), and the build/structure of the opcode.

[Fonzie]

I thought microcoded CISCs just appeared "recently" (early 90's)... Shit on me ^^

[Chilly Willy]

Microcoding has been around a LONG time. The CMOS version of the 6502 was microcoded. I built a microcoded CPU in a digital logic class in college back in '84. In the 80's, microcoding was considered the end-all, be-all of computer technology. It was going to change the computer world. Then Intel started the MHz race and microcoding was seen as a hinderance to higher frequencies. CPU makers have since moved to RISC cores with some microcoding for instructions considered non-critical to performance. The dual approach seems to work fairly well.

One more thing that clearly shows the 68K is not considered RISC - RISC CPUs all use a SINGLE word of a fixed size for instructions. The 68K uses variable numbers of words for instruction encoding, another key characteristic of a CISC processor.

[tomaitheous]

The MOS version of the 6502 was not microcoded, either was the CMOS version (65C02). I don't think any of the license cores were microcoded back then either (GTE65CS02, 65CE02, HuC6280) as they have the same opcode timings. That's one of the reasons why the 65xx series are so fast in comparison to the z80, 8080, and other microcoded processors. Microcoded processors use a logic rom instead of being hardwired, increasing the execution times.

The father of the 6800 left Motorola after designing it and created the 6500 series. The original 6800 wasn't microcoded and the designer(forget his name) carried the this over to the 65xx and later the 65xxx.

True the 68k doesn't have fixed length opcodes, but in comparison to other processors of the time, it more closely resembles RISC opcode structure. Besides, the definition of what we know as RISC today, wasn't so back in the late 70's - early 80's. To me, the 68k definitely fits in the pre-runner category of RISC processors. At the very least, it's definitely somewhere on the blurred line

[Chilly Willy]

The MOS version of the 6502 was not microcoded, either was the CMOS version (65C02). I don't think any of the license cores were microcoded back then either (GTE65CS02, 65CE02, HuC6280) as they have the same opcode timings. That's one of the reasons why the 65xx series are so fast in comparison to the z80, 8080, and other microcoded processors. Microcoded processors use a logic rom instead of being hardwired, increasing the execution times.

I have the technical documentation on the R65C02, and it is INDEED microcoded. Rockwell brags about how microcoding allowed them to easily add the extra opcodes, but did alter some of the instruction timings.

True the 68k doesn't have fixed length opcodes, but in comparison to other processors of the time, it more closely resembles RISC opcode structure.

No, it doesn't. I've worked on assembly on many RISCs and CISCs, and the 68000 instruction format is clearly more CISC than RISC.

Besides, the definition of what we know as RISC today, wasn't so back in the late 70's - early 80's. To me, the 68k definitely fits in the pre-runner category of RISC processors. At the very least, it's definitely somewhere on the blurred line

No, it isn't.

RISC has been around since the 70's, and the definition hasn't changed in the slightest. I don't think you really understand the definitions for CISC and RISC.

[tomaitheous]

I have the technical documentation on the R65C02, and it is INDEED microcoded. Rockwell brags about how microcoding allowed them to easily add the extra opcodes, but did alter some of the instruction timings.

That's the first that I've heard of that. And the opcode timings are very close to the WDC versions? All the docs I have list the Rockwell version as having the same timings. That has me wondering about the 65CS02 and the HuC6280 with it's addition opcodes.

No, it doesn't. I've worked on assembly on many RISCs and CISCs, and the 68000 instruction format is clearly more CISC than RISC.

You're right. I was confusing the 68k opcode structure with the ARM thumb set (being 16bit) - writing an assembler at the time. I remember thinking it was similar to the 68k opcodes as the time.

No, it isn't.

RISC has been around since the 70's, and the definition hasn't changed in the slightest. I don't think you really understand the definitions for CISC and RISC.

I was referring to the MIPS R2000/R3000. I don't remember processors before that other than what RISC was being defined as in theory. My recount of history is from memory and it been a long while (maybe too long). I don't have a lot of experience with RISC other than minor work/hacking with NEC v810 and ARM.