6502.org

The thing about the x86 architecture is that it actually works. It may not be beauty to look at, but the designers have done a lot of things right in order for the architecture to survive all these years, and beat a lot of competing architectures (including Intel's own).

<disgress>AFAIK, Intel did not win the mobile application processor war if we count by numbers instead of by revenue. By numbers of deployed units, ARM and all it licensees are leading the way by a factor of ten or more</disgress>.
One thing the Intel designers did wrong was the CPU frequency race they forced us to arbitrate (Intel, AMD, Citrix an dso on...) in the last ten years.. hopefully they fall back to designing multi-core architectures just before hitting the wall of reality physics for serving more usage oriented needs (multi-applications).

Sure, Intel has not won the mobile war, because there weren't really competing in it. They have been competing in the high performance, general computing, war, and have solidly beaten everybody else. Also, ARM is in a completely different business, because they're selling IP, while Intel is selling chips.

<disgress>Yes it's true that their MID (mobile internet devices based on Intel technology) have'nt invaded the shops and the Atom processor more likely fits low profile desktops/laptops and TV setup boxes than smartphones and tablets, and from a marketing point of view, I think it competes with the Core i3 CPU we can now find within "ultra books".</disgress> <disgress>TI, Freescale, Qualcomm, Samsung, STM, NXP, all ARM licensees, are chip manufacturers, the number to consider is the sum of chips sold by each of such companies.</disgress>

Off topic, but back to hard tech:
Grant Searle has posted some nice scope photos illustrating the zx80 display scheme - this design makes use of the z80 in a very cunning way:
http://searle.hostei.com/grant/zx80/zx80ScopePics.html
The photos are also excellent illustrations of bus activity generally.

I was originally wondering about the very small RAM in Sinclair's machines: lo and behold, they are of course SRAM, for the low chip count. I had somehow imagined that the Z80 offers a multiplexed address bus, but of course that wouldn't work well for ROM or peripherals.

Cheers,
Ed

Cunning indeed! But, just for the record, the scheme has much in common with Don Lancaster's "cheap video" technique -- a technique applicable to a variety of processors including 6502.

"To display a line of characters the CPU jumps to the start of a line of characters to in the ghost image of it above the 32K boundary to "execute" it. When execution is called above the 32K boundary, hardware intercepts the opcode fetch and the Z80 CPU "sees" a "NOP" instruction on the data bus and executes it." This explains how a Z80 (or 6502) can be tricked into producing a rapidly ascending sequence on its address bus. Part of the memory map (not necessarily above 32K) is a ghost image where the cpu sees NOPs rather than the actual memory data. But the latter gets grabbed by hardware and squirted out as video.

There's another devilishly clever bit that is Z80 specific, as it makes use of the refresh counter. I won't rehash the author's explanation, but it's an optional extra for conserving ram, and isn't fundamental to producing a display. Thanks for the link, Ed!

-- Jeff

Very good point - allow me to link to your take: http://laughtonelectronics.com/arcana/B ... aster.html

Nice, I see Dr. Jeff has been working on his website. Looks good, even better than before.

Someone's error here of making the NOP op code E9 instead of EA pointed out to me that E9 E9 (SBC #E9) would be twice as fast at getting through the range of addresses if "rapidly ascending" were super important. SBC# (and several others) take two clocks for a two-byte instruction, so you get an address increment and read with every single clock.

Nice observation!

Right; yes - for 6502 it's preferable to use one of the immediate mode instructions because they scan faster than the "official" no-op ($EA). But what you're doing is a no-operation in the sense that the result is a don't-care and really you just want to occupy some time and memory space. Of course there are several immediate instructions to choose from. C9 C9 (CMP # C9) is a good choice since it preserves all the registers (except flags). Something like 29 FF (AND # FF) or 09 00 (ORA # 0) also would preserve the reg's, but C9 C9 (both bytes identical) is simpler for the hardware to fake. E0 E0 (CPX # E0) or C0 C0 (CPY # C0) are also good candidates.

Using a 32-column display as an example, the memory cycles for one scan line (seen from the cpu point-of-view) would be:

• 15 instances of the two-byte, two-cycle instruction C9 C9 (CMP # C9)
• 1 instance of the one-byte instruction $60 (RTS). Luckily the cpu fetches the following byte, too, since we need that final cycle to complete the line. But actually the 6502 always ignores the second fetch of any one-byte instruction. IOW it doesn't matter what the hardware sends to the CPU on that cycle, but probably it's easiest to just send the $60 again. That concludes the scan line. The final 4 cycles of the RTS don't participate because then we're accessing stack, not the special address region that triggers the video shift register, the ghost image and the phantom "nop" instructions.

As the 6502 has the 65816, so the Z80 has the Z180. The approach to addressing more than 64k of memory is interesting, and minimal: nothing changes in the instructions or operands, but instead mappings are applied to two areas in the 64k space. From address 0 to the first area is not mapped, so you get 3 regions in all, conventionally called
- common 0
- bank 1
- common 1
Common 0 is indeed common to all maps - if different mappings are different processes, then they share some lower part of memory space. In the Z80, low memory is for ROMs, vectors and OS, so this is like sharing the top of memory in a 6502 system.

(I don't see that Common 1 is actually common between maps. Also note that common 0 can be empty, with bank 1 starting at address 0)

The granularity is 4k, so only 4 bits are needed to define each of the two boundaries. So there's a single mapping register of 4+4 bits for that. The mapping registers are 8 bits(*), so the physical address gets 12 bits from the logical address, and 8 bits as a result of adding the map to the logical address.

(*) Maybe only 7, but they could have been 8!

The total exposed interface to the MMU then is just 3 8-bit registers: CBAR for the bounds, CBR and BBR for two base addresses.

See http://www.ganssle.com/articles/ammu.htm and http://www.miredespa.com/sb180/HD64180.WS for more. The second of those contains some diagrams such as this: As we know, the 65816's banking approach gives access to a 24-bit address space. To do the same here would require some adjustment and some more width in the MMU registers.

Having read through the thread, I have a few comments:

1) Speaking of cunning, the 6502 is a bit tricky with the cycle counts. I will risk starting a terrible debate by saying that what's referred to as 1 cycle on the 6502 is really 2 internal cycles. The address bus outputs the address, and the memory is read in the same cycle? I would really call this 2 cycles. Don't take it the wrong way, the 6502 is by far my favorite processor.

2) E9 E9 as a fast nop was my slip. More on that subject at pagetable.com

3) 'Fast' command... Back in the 80's I co-wrote a BASIC interpiler(compterpreter?) for the Atari ST (it had a forth-like engine, allowing it to appear interactive while compiling and linking lines of BASIC instantly). Alongside the 'run' command it had a 'fly' command. 'fly' executed the already fast compiled code really fast by turning off all dynamic error-checking, often faster than the C compiler for the ST. If memory serves me right, you could fly some code and switch to 'run' inline.

4) Outside the outright speed comparison... There is something incredibly pleasant about the 6502 instruction set. Even in the midst of a horrible debugging session from hell complete with self-modifying code, I feel really happy working with this chip. Nothing else even comes close. Z80 is OK, but 6502 is really nice. It's a zen practice for me, seriously.

Since someone had mentioned the ARM chips, ARM Thumb2 is exactly the opposite of the 6502. It's just disgusting to write assembly for the Thumb2, and writing any kind of a compiler, even a simple native Forth code generator, is a painful, stressful experience. Many people mentione the ARM as some kind of 6502 descendant, but I really have to object. There is nothing about the arm that looks to me like a feature inspired by the 6502.

Yes, it is.
In that case I have two bridges you may be interested in.

Lee.