malducci

Ok, this should be the right section/forum... Rules here -> http://pcedev.blockos.org/viewtopic.php?f=4&t=42 Charles MacDonald and I (Tomaitheous) started a coding contest for the PCE. Putting your optimization skills to the test by running the processor only in slow mode - 1.79mhz. Anyone is welcome to enter the contest. I figured some of you Atari guys might be interested since the CPU is a 65C02 variant and close to home I can provide background/hardware docs/tutorials that I wrote and can also provide some hardware/assembler syntax example sources as well. -Tom

No no, this is all new code. A mini game preferably. And they run at 1/4 the processor speed - that's the challenge part. Ohh. I misread that as being all the subforums(being atari and coleco only). I'll try that out than.

Nobody/coders/etc interested, ehh?

Hope this is the right section... Rules here -> http://pcedev.blockos.org/viewtopic.php?f=4&t=42 Charles MacDonald and I (Tomaitheous) started a coding contest for the PCE. Putting your optimization skills to the test by running the processor only in slow mode - 1.79mhz. Anyone is welcome to enter the contest. I figured some of you Atari guys might be interested since the CPU is a 65C02 variant and close to home I can provide background/hardware docs/tutorials that I wrote and can also provide some hardware/assembler syntax example sources as well. -Tom

Which rom did you try? And you're using a US Turbo Duo?

Are you using that kisado adapter? Don't! The flash software should be swapping the bits into the correct order when you select TG16 as the destination console. Do exactly this (to the 'T'): Take a Japanese rom, select US as the target platform, write the rom to flash card, and try it on the US Turbo Duo without the adapter/converter. You might have to find the "sweet" spot in the cart slot like with NES game carts. I have to do this with my Tototek card. Report back the results here.

The problem with your assumption is that the 32x worked the same with CD games as it did with carts. This is not so. The 32x is basically crippled when running just from a CD game (more so than it already is). This is why you didn't see much 32x CD action. The 32x side only has a tiny amount of ram (256k) and without cart space to read from (which is already really slow to begin with) - it's crippled.

How is the 5200 a major console!? Major consoles: Atari 2600, ColecoVision, Intellivision Minor consoles: Atari 5200, Odyssey 2, Vectrex, Astrocade "Little league" consoles: Arcadia 2001, Channel F, RCA Studio II

The scan rate has nothing to do with the SNES heating up. Composite video isn't a two communication. That's not to say that there isn't something wrong with TV and than it isn't leaking voltage back through the connection. I had an old SDTV do this through the RF port some 20 years back. Fried 2 SNES and 1 Genesis over time (sticking your fingers on the RF connector, you could feel a slight shock/current). I would test out svideo from the SNES to the TV or other composite output devices. Sometimes, running composite through an old VCR will "correct" time base signals. Though I would be surprised if it was a signal timing tolerance problem. Most sets, be it SD or HD, usually have some room to work with for hsync, scanline length, vsync pulse, etc timings.

Oh you mean this game written by UK company Rare for the (USA) NES: Yep, spot on! Ah, but Rare also brought us Battletoads and RC Pro-Am. Make sure you tell this 'malducci'.....'soul-less/dribble' Frenchman! Rare was originally a UK company??? But yeah, there are always exceptions in life

IIRC (it's been a long time since I've done GBC dev), the GBA doesn't have access to the z80 when in GBA mode. Port accessed audio regs have nothing to do with a cpu, regardless if it's on the same dye or not. The GBA mode has access to those regs, not the z80. And *if* that's correct (my memory, that is), the missing z80 from the DS *is* the reason why (and possibly that GB/GBC video modes are not available either) GB/C carts will not run - regardless of the port. Maybe you're confusing the setup wit the Genesis and the z80 available for use in Genesis mode?

Then you mean the PC-Engine version. The PSP version is that version, not the SNES version. The SNES version is a re-imagined version of Dracula X for the PC-Engine. In other words, you're not going to find any rom or repo cart for it on the SNES/SFC.

Wow... 'lot of NES haters out there. I can see the generation that grew up on 2600 stuff not really caring for the NES. It happens with other generations too. I had a 2600/Coleco too(well, we borrowed quite often), but wouldn't touch it with a 10 foot pole anymore after NES came out. There was just no going back to such super simplistic games. And as for the UK/EU'rs NES haters... you guys love the soul-less/dribble software from other there. Man, there really is no accounting for tastes in gaming crowds across the pond <_<; Especially you Swedes. Always soo grumpy and hating anything Nintendo of that 8/16bit era UK'rs right behind them though. /jest off Also: d-pad > stick. Always.

Didn't care much for the original. A new reworked DS version (sequel) might not be such a bad idea though.

What's not as bas as the Gameboy's audio? The SMS/GG or the ST? kool kity89: The one thing about the GB's processor, is that it's not a real z80. It's a hybrid between an 8080 and a z80. Also, like the 8080, it take 4 clock cycles to do one machine cycle (M) and unlike the z80 which is variable and uses T cycles. That's a constant. So while you'll see it rated at 4mhz, a lot of docs will also rate it at 1mhz. 1mhz for GB and 2mhz for GBC. Which is more accurate. I did some dev on the GB/GBC years back. It's a fun little system. Very simple and easy to use hardware too.

Sure, it's not rocket science and but you still fail to understand CPU architecture. I provided facts (go back and re-read my post). Facts that show how the '816 is in fact 16bit. Do you have some other post I've missed or something? The only thing I see you mention is the fact that it has 8 DATA BUS lines "8 little slivers of solder". You're talking about a 'dumb device' with a latch system VS the 16bit ALU and to a lesser the 24bit PC with it's own 16bit ADDER. Do you realize how absurd that is? The 68000 isn't a 32bit system. Maybe you've confused the Falcon or whatever that's supposed to be a '030 (a true 32bit processor) on a 16bit bus (ofcourse that's heresy because I've only read that on this forum and have no direct experience with said system). Did you read any post I made in the past few pages explaining why the 68000 isn't a 32bit CPU? It's easy for someone to throw out generalized statements. Back it up with facts. Real facts. Not, "well so-and-so community says it is" or "it was marketed as such", etc. It's funny, because no one I've met regards the 68008 as an 8bit CPU. Save for Atariksi, but this comes from the guy that tries to use a rounding analogy as an analysis to deduce the inner or overall CPU architecture, for something he clearly has no grasp on (he thinks the "dumb device" of the bus+latch system hold as much weight as the ALU - because without that part of his argument, it completely falls apart). No only is his analysis method ridiculous and absurd (it's how someone with limited knowledge of a subject would perceive and/or go about deduction), but he also fails because he gives equal weight to the BUS as he does the rest of the processor - which is even more absurd than using some ridiculous analysis system on processors he has little grasp of knowledge on. There are two types of people that describe processor architectures. Software engineers and hardware engineers. Software engineer "I have 32bit instructions with 32bit registers. I don't care how it works internally or what the BUS size is or the ALU or anything, it codes like a 32bit CPU to me so it's a 32bit CPU". Hardware engineers, "It can only process at a maximum 16bits at a time. The 16bit ALU, responsible for ALL logical operations, requires multiple passes to perform wider sized arithmetic/logic operations for 32bit macro instructions". The hardware engineers designed the chip. Hehe. That had me actually laugh out loud. I need to prove that the analog filters give it an edge, among some of the other features of the chip? This is one few times where I'll just say "proof of the pudding is in the eating". I love chip music. All kinds. But there is nothing even close on the POKEY that I've heard that matches the versatile instruction sounds of the SID or the waveform complexity of the instruments. SID sounds like a real synth in capable hands, POKEY sounds like good PSG in capable hands. Next you're going to tell me POKEY is more advance than FM, right? As for games, I DO think only having 3 voices is a downfall for when you need to be able to play sound effects. Look at the NES (which is more capable than POKEY) with its native 5 channels and dynamic instrument drop for sound effects is pretty noticeable in most games. NOTE: Also, I edit my posted to add stuff because "double posting" or multiple postings in a row, is consider RUDE by the majority of forums on the net. Edit your post and add what you need to say, or what your damn turn and let someone else have a chance to respond or just post. I think this is lost on you.

Atariksi: I'm not going to continue debating what is already common knowledge and factual. There's no point in arguing with someone who clearly has some sort of mental disability. "I can never be wrong" syndrome? Something like that. Hehe. I had a good laugh at your multiple counter replies, though. Thanks That's funny you should mention that. I told some other people about this and they all had a good laugh. "But atari games are different", etc. Classic.

ADSR hardware doesn't mean much. Many synth engine's just do it in software without problem. 60hz tick is enough to handle it in software and takes almost no cpu resource to do in software. Hardware ADSR is great if you need to interface it in a standalone design (i.e. keyboard synth). Yeah, for only 3 voices there are some incredible songs on that chip. Those analog filters really give it an edge.

What are you rambling on about!? What does that have to do with anything in relation to a 16bit processor. The PC on the 65x is two paired 8bit registers. The LSB and the MSB. It has separate PC adder unit in that it doesn't have to rely on the ALU to increment the PC. This adder is 8bit. The ADDER will *NOT* add the carry to the MSB unless it is set. This was an optimization. How many time are you going to cross a page boundary (LSB of the PC overflows)? Again, it's an 8BIT ADDER for the PC. The 65816 also has a separate ADDER and it's 16bit. The PC is *24bit* with local 16bit optimization. The more you write about this topic, the more you make your self look bad. Just stop. You *really* have no clue what you're talking about. I've read every single page of this thread. This is but a *small* fraction of where the thread has gone off on a tangent. It's people like Atariksi who spread/post incorrect info is why we have such inconsistent facts/material across the web. Wiki is a prime example of this. Maybe you and others don't care, but I'm sick of people like him trying to post with authority when truly lack any real understanding of what they are talking about, and I'm gonna call them on it when I see it. A few last points I'm going to reply too and I won't continue this laughable debate any further. Again, doing two 8bit fetches for a 16bit operand is *NOT* "8bit operations". Why would you even think that? The processor is in no way doing any internal 8bit operations. The BUS interface system is fetching the needed WORD operand in a two bus cycle system. Not the ALU, not the PC, not anything else in the *processor* is performing multiple 8bit operations. I mean, do you really think the 68008 is doing multiple 8bit operations? Dude, you're just showing more of your ignorance on this matter, again. Again, you *COMPLETELY* misunderstand anything that I mentioned. That has... nothing.. to do with anything that I stated. Nothing. Where did you come up with that? I really think you are confusing bus fetches with internal operations... again. Again.. (sigh). The processor is not handling 8bits at a time on the 65816. Where do you get this stuff from? It's frustrating that you completely misunderstand cpu architecture on a hardware level and yet pull random stuff like this out of your.. whatever. Let me says it again (will it help, maybe... just maybe it will sink in this time 'cause I'm real sick and tired of repeating myself to you); the ALU is 16bit. The ALU is wholly responsible for adding, subtracting, logical operations such as AND/OR/XOR/ etc, bit testing, bit setting, bit clearing, processor status flag updating, incrementing, indexing, etc. The PC has its own 16bit ADDER. The PC is 24bit. Any LONG access is done with two 16bit ADDs on the PC. The BUS interface mechanism on the CPU side is 16bit, on the external side is 8bit. There is a LATCH for when it needs to fetch a 16bit operand. This means the PC and/or the ALU will wait 1 extra cycle for the BUS fetching mechanism to fetch the WORD. Opcodes are bytes. There's no reason to do a WORD fetch on an opcode fetch. *THIS* makes the 65816 efficient on a BUS that's not equal to the internal logic width. Another thing you totally FAIL to understand is that even with a half size BUS, but the 65816 can access the BUS on *every* CPU cycle. The 68000 takes 4 cpu cycles to access a WORD size element on the BUS. The 65816 takes two CPU cycles to access a WORD size element on the BUS. And only 1 cpu cycle to access the opcode. The 68000 takes 8 cpu cycles to load a register with a 16bit immediate (16bit opcode, 16bit immediate operand). The 65816 takes 3 cycles to do the same. 1 to load the opcode, 2 cycles to fetch AND put the 16bit immediate into the register. You keep equating a smaller size BUS with slower speed, yet you completely ignore the fact that speed is relative to bus size X the number of cycles per bus access. You failed to see how a 386SX with no wait states is just as fast as a 386DX with 1 BUS wait state. Do you know why I provided that example? Because it was a REAL WORLD example. 8086,286,386,485, etc. The BIOS controlled the wait states of the memory (some MB's used jumper pins instead) because fast ram that required no wait states was very expensive. I NEVER found any ram for my 386DX at the time that ram with 0 wait states. Most ram required 2 wait states else the system would randomly crash. But the only thing you say to that is (and I paraphrase) "Many people think the 386SX is more of a 16bit processor". Yeah, *many* people in the world are also wrong about *many* things. Majority of opinion does not cancel out FACT. It IS the core logic of a processor is the ALU. You have the ALU that performs all logical operations, a PC (some have its own ADDER for parallel incrementing), and opcode decoding unit, and a BUS mechanism. Some more advance processors have MAC/MUL units, vector units, etc. The ALU is at the heart and performs thee majority of the logical operations. The PC and the BUS mechanism are dumb devices. I've NEVER confused the ADDRESS lines with the DATA BUS. Your lack of reading comprehension skills are incredible. What!? I'm gonna have to write this in all caps for you... hold on a sec. A BUS FETCH IS NOT AN 8BIT OPERATION. NO WHERE, NO HOW, NOT CLOSE. The 65816 will perform those logical operations in a SINGLE cpu cycle of the ALU. The BUS might take 2 cycles to fetch the WORD operand, but that NOTHING to do with the LOGICAL operations of the ALU which is preforming those specific tasks. Task 1: fetch opcode and decode Task 2: fetch 16bit operand - BUS fetch two 8bit elements pointed by the address line - halt the ALU until the second byte is fetch - transfer the 16bit data to the internal B register for 16bit operation. - store result in destination register There's no multiple 8bit operations. There is two fetches from the external memory range by the BUS mechanism and transfered as a *whole* to the 16bit ALU. Hypocrite. You claim I'm twisting your words when I embolden them or underscore them? And yet you have no problem subjectively and *incorrectly* paraphrasing my own statements? You have some social issues that you really need to work out there. Oh, and look at that. I emboldened your text. You know why? Ehh? Sit down and I'll tell you. You see, sometimes there needs to be emphasis on what I'm replying to, but it still needs to be in context. If quote your whole paragraph and such, the emphasis into which I'm focusing my reply on is less apparent. ANY other people, with reasonable intelligence, would at least somewhat understand this. It's not difficult. You actually do what you claim others do. While you don't embolden or underscore, you snip pieces of other posters text to draw emphasis and it *can* totally change the context of that message. But you seem to have no qualms about this. Again, hypocrite. I think most people stop debating with you because they realize how immature you are. You can't even have a real debate without constantly shifting and changing the focus away from something that starts to look bad or not in you favor. The funniest thing is, you *accuse* others of doing just this. It just reveals and speaks volumes about the deeper inner workings of your own personality and how you think. You betray yourself. Fail. And oh, those aren't insults. Those are pure observations about you and your character/behavior. But knowing you, I'm sure you won't see that way.

Again, you miss my point. I said nothing of removing the 32bit macro instructions. What I said was relative to accessing the upper WORDs of the corresponding 8/8 registers independently because the minimum WORD length for the 68000's instruction provides enough room for that as part of the effective addressing mode. The 68000's biggest weakness is the slow bus access (4 cpu cycles). Ton's of article's show the great performance of register-to-register operations and that's true but the limited number of registers prevents it from actually making such real world performance. The processor definitely needs more address registers especially when most optimizations come from 'reserving' registers, i.e. not having to load and unload those registers. The DATA bus is nothing more than external communication to... external ports/memory/registers/etc. Imagine that! Wow. The processor itself (the ALU which is the heart of the processor) doesn't care what the method is for retrieving requested data. It could 1bit serial data at super fast blazing speed (remember RAMBUS?). The ALU *is* the deciding factor of the bit-ness of a processor. The ALU is separate from the module that fetches/writes to the external bus. The ALU operates independently and in parallel. When it can't, it's halted until the BUS module can finish its request. They are independent. 16bit registers have nothing to do with the D0-D15 (or D1-D16 of 68k schematics). There really isn't anything to argue here. I don't care if you adjust your code or not for page boundary optimization. How is that relevant? I don't see what this has to do with how crossing a page boundary DOES take an extra cycle to increment the MSB of the PC reg. It's not a 16bit reg, it's an upper and lower 8bit pair of regs. The PC has its own adder separate from the ALU, bit it's still 8bit. That's why it's able to increment the PC in parallel of the ALU performing an operation. I don't know how else to explain this to you. This is common knowledge of the 65x architecture. No, you're only concentrating on the size of the BUS. The data bus is one of the least important parts of the processor, relatively speaking. The bus doesn't have to be symmetrical. There are processors with a wide data bus than what the processor is (ALU wise). Ugh. It's like talking to a brick wall. Do you even know what hell an ALU is? Do you know what it does? Do you understand that if the bus logic requires two fetches at the half the internal element size, it's still a fraking 16bit read/write internally to the ALU? Do can you fathom that? It's compressing the bus. And you totally ignore the fact. And you still can't grasp the fact a compressed 16bit bus to an external 8bit bus can and is at times faster than a 16bit bus on other processors. But oh, no... it's an 8bit bus and that's really what makes it an 8bit processor... Jesus Christ, man. Wasn't supposed to be in there. Your own response to the original question was speaks volumes about your own fault in logic than anything I could add.. I'm not disagreeing that a half size data bus isn't slower or effect performance (of the same family of processors). You're problem is that it equates to an 8bit processor when technically it's nothing more than a means of communication to external devices. It doesn't change the processor to an 8bit system/function internally. You need to separate the two. Yup. There are people that think all kinds of thing because they lack any true understanding. Imagine that. Heh. But hey, any type of majority of opinion always overrides fact, right? It's not a freaking algorithm. It's 16bit processor running on a half bandwidth bus. How hell is that an algorithm!? You mean to tell me you don't know the difference between what a hardware macro instruction is and what a compressed bandwidth bus is!? Come on, man. It's not that hard. The external data BUS has N-O-T-H-I-N-G to do with the internal operations of the A-L-U. Nor does it have ANYTHING to do with a macro opcode. A hardware macro instruction serves two purposes. TWO. 1) It save cpu cycle overhead because a second instruction doesn't need to be fetched to perform the operation like it does with a software macro. 2) Being that VERY same macro instruction contained WITHIN a single opcode; future model processors can be upgraded to execute the same macro instruction as a native instruction because the ALU size has been increased and reduce cycle times even further. It reduces code size. It future proofs that it will work on n-bit upgraded versions of the processor and at a faster speed. It's called a forward thinking model. That's great. Because ZP registers are not analogous with MOVEM. They are analogous with the 32bit registers of the original 68000. They are analogous to register pairing of BC, DE, etc on the z80. ETC. That's great. Good you for you. Also, I'm not sure what "true" 16bit processor the '816 is inferior to. It definitely is not the 68000, that's for sure. The 65816 is quite a bit faster than the 68k at the same clock speed. Well, unless you're a 68k fanboy - then nothing beats it You've yet again proven your ignorance and lessen your credibility on the understanding such technical side of things. Thanks. I came to this forum looking for people posting knowledge insights and facts about the A8 home computer. But if this is any sort of trend from you, I'll be taking what you say about the A8 technical strengths and such with a dubious eye. Thank god some of the other forums members appear to be really knowledgeable.

Yep. That just goes to show you're not I just described to you how it's irrelevant and that's your counter argument? Let me say it again in hopes that you'll get it this time. The internal functions of the processor have no idea that the external bus is 8bits. It is made to wait until the data is fetched. This is no different than if you have a 16bit data bus and an internal(or external) 1 wait state or if you if you have an 8bit data bus and the internal system is halted until two fetches were made. What don't you understand about that? It's data bus compression. It saves cost because of the use of narrower width memory and less address bus lines to interface - at the cost of a second fetch which is cheaper than doing slower 16bit memory and a wait state system. Let me put it another way, if a processor requires two clock cycles to access a 16bit bus in a single action *OR* two 8bit fetches at 1 cycle each, what's the difference? Again, the answer is nothing. I'll repeat this again, the data bus size is irrelevant for deciding the 'bit-ness' of a processor. How long it takes to fetch data is directly relative to speed, not the 'bit-ness' of a processor. You want another example? 386SX 16mhz with no wait states on the memory VS 386DX 16mhz with 1 wait state on the memory. Umm, that's the only way to look at it. If the ALU is 16bit, it can only processor 16bit arithmetic/etc operations at a time. You think the 6309 in native mode is a 32bit processor because it has a macro instruction on the hardware level that enables it to do some 32bit arithmetic operations? It has an 8bit ALU and the macro instruction performs the instructions in multiple passes over the 8bit ALU. It's still an 8bit processor. 1) You've obviously never heard of a compressed data bus via half pins. 2) You're 16bit math 'example' has nothing to do with what I mention and proves you fail to understand the concept. 3) The difference is external, not internal to the instruction and processing unit. It makes no difference to the ALU. The ALU is not going to start processing an ADD until it receives the complete 16bit data. An 8bit ALU will immediately start the ADD on the fetch of the LSB and continue the operation on the MSB (example: relative branch or incrementing of the PC reg). It always happens on an ADD to the PC. Loading of the PC is not an ADD, but it does happen on a JMP. If the instruction starts at the end of a page, there WILL be an extra cycle for crossing that page boundary because the PC has to be incremented on each byte fetched of the instruction. It happens on any instruction and any time the PC is incremented and overflows on the LSB. If you have "opcode (zp),y" there's a chance you'll get two extra cycles added to the instruction; +1 if the instruction itself crosses a page boundary and +1 if Y added to the base address from ZP/ZP+1 overflows in the LSB of the PC. ZP,X doesn't have the +1 cycle because the carry flag detection is ignored when adding the index register to the LSB of the PC. I know many people consider the 68000 a 32bit processor. Those same people also can't fathom that the 65816 is faster and that even the 65c02 is faster in a lot of operations. Those are considered "software" guys because they don't understand or even care about the hardware level. It has 32bit registers, so it's a 32bit processor - never mind the fact that those are actually paired 16bit registers and that motorola did a dis-service not giving direct access to that second set of 16bit regs (I mean common, 16bit wide instructions is more than enough to cram in 16 Data registers and 16 Address registers). There's also a bit of arrogance that goes along with the hardcore 68k crowd. The 68020 is a 32bit processor, not the 68000. Because the instructions are backwards compatible, software guys often get confused And I already explained it to you. Both processors execute 16bit operations internally as a single operation. You're equating bus size with performance, which is fine, but like I've explained clearly and with facts - that it doesn't describe the processors 'bit-ness'. Do you think the Hitachi SH line is 16bit because all instruction are compressed to 16bits? Or that it can operate on a 16bit bus? Or the v810 32bit RISC by NEC? Because it can also operate on a 16bit bus and 32bit bus? And what if you interfaced a 68000 with 8bit wide ram with a wait state and latch? You think I've contradicted myself only because you fail to understand. The 32bit register is pair of 16bit register because of the ALU operation. Updating the upper WORD is still a separate ALU operation. Whether it's a load, arithmetic, shift, whatever. Many 8bit ALU processors had paired registers to make up larger registers, but that doesn't make then 'greater' than 8bit. Hell, the 65x has 128 16bit Address register if you used all the ZP registers. Surely a processor with that many 16bit registers should be labeled 8/16bit (/sarcasm off). A macro instruction has the same functionality on a hardware level as it does on a software level, with the exception that it saves a overhead of fetching second instruction. Both require a second or more pass on the ALU to support a wide element operation that was is natively supported. On a hardware level, it saves the size and cycle cost of fetching another instruction - but that doesn't change the fact of what it is. The z80 had 16bit macro instructions. The 6309 had 16bit/32bit macro instructions. The 65CE02 had 16bit macro instructions. But that doesn't change anything.

Actually Atariski is correct on most occasions But his posts are so frequent and long that I lost the will to read them about 100 pages ago. Since I saw the IIgs mentioned... I'm not a big Apple fan, but it's nice that somebody made a full-on 65816 machine, even if it wasn't very competitive with 68000 based machines like the ST and Amiga. On that I agree, a very graphically powerful 8-bit! What's 8bit? IIGS processor can be considered 8-bit although some say it's 16-bits. And why is that exactly? Lasted I checked it had a 16bit ALU, 16bit registers, and 24bit addressing. The data bus is irrelevant (and no, the original 68000 isn't a 32bit processor regardless of the 32bit 'macro' instructions). Data bus is relevant. The D0..D15 lines are PHYSICALLY on a true 16-bit processor; they use up more pins than D0..D7. So this is less than a 16-bit processor. Also note that 6502 also has 16-bit register (PC) and is updated using 16-bit ADD. It's not a macro instruction when you write a 32-bit data to a memory location on 68000; it's same as writing 16-bit data on 65816. They both get multiplexed into two write cycles. So by your logic a 68008 is an 8bit processor? The data bus is irrelevant. What happens on a register/register level and the ALU is was determines its 'bit-ness'. What's the difference between a 16bit processor fetching two BYTEs in sequence VS a single WORD fetch bit with an extra 1 bus cycle wait state? Nothing. And even with an external 8bit data bus, the 65816 is still faster than the 68000 at the same clock speed. The 65x series might have a 16bit PC, but it still has an 8bit ALU and that's why you get an extra cycle when crossing a page boundary(256bytes) - because it has to do a separate add on the MSB of the PC on the carry detect. On the 68k, it is a macro instruction in that it requires two 16bit read or write cycles to move 32bit data. Macro on the hardware/microcode side. Same with any 32bit arithmetic/shifts/compare/etc on the original 68000. The operation is performed twice on the 16bit ALU. It's like calling the z80 a 16bit processor. The 32bit instructions were forward thinking for when the 68k family would include a real 32bit ALU, while still providing backwards compatibility.

Actually Atariski is correct on most occasions But his posts are so frequent and long that I lost the will to read them about 100 pages ago. Since I saw the IIgs mentioned... I'm not a big Apple fan, but it's nice that somebody made a full-on 65816 machine, even if it wasn't very competitive with 68000 based machines like the ST and Amiga. On that I agree, a very graphically powerful 8-bit! What's 8bit? IIGS processor can be considered 8-bit although some say it's 16-bits. And why is that exactly? Lasted I checked it had a 16bit ALU, 16bit registers, and 24bit addressing. The data bus is irrelevant (and no, the original 68000 isn't a 32bit processor regardless of the 32bit 'macro' instructions).

Actually Atariski is correct on most occasions But his posts are so frequent and long that I lost the will to read them about 100 pages ago. Since I saw the IIgs mentioned... I'm not a big Apple fan, but it's nice that somebody made a full-on 65816 machine, even if it wasn't very competitive with 68000 based machines like the ST and Amiga. On that I agree, a very graphically powerful 8-bit! What's 8bit?

Oh. My. God. H-o-l-y-s-h-i-t. Atariksi, you are never fraking wrong. Eeeevvvvveeeeerrrrrr. Jesus Christ..... But hey, you're entertaining - so keep it up This thread should definitely be renamed "Atariksi". Classic.