Please look what is coming:

Maple Mini

http://leaflabs.com/2011/03/for-want-of ... aple-mini/

I'm starting to get interested in this platform because of the Ram. It has more Ram and is more powerful than the Arduino.

I found the Maple Native has Memory: 512KB Flash and 64KB SRAM

They have other models in the works.

It certainly is an interesting platform: note that it's a 3V3 platform, and only some of the I/Os are 5V tolerant. See docs.

http://leaflabs.com/docs/errata.html

I was interested in the old Chumby board but they said it wasn't for beginners:

http://www.adafruit.com/index.php?main_ ... cts_id=278

There is more documentation for the Leaf Maple M3 Cortex and with learning the Arduino tutorials, I feel that it will be easier for me to learn those chips than the 6502.

A lot of the stuff written for the 6502 is written by people who were looking at the Kim 1 but they were describing it to people like me who never had a Kim 1. I've always felt people were describing something I couldn't see so they were describing something and there were these gaps in my understanding. They expected me to make these leaps and the gaps are really great. That is why there needs to be tutors and online help.

You'll be better off learning with something you actually have in your hands!

I'd recommend starting with a low end board and doing what you can with that first. The maple offerings do look good.

I must say, you do find the coolest stuff!
Thanks for sharing here Chuck...

Also might be interesting: the LPCXpresso dev board is only EUR20. It is 3.3v, 120MHz ARM Cortex M3, 64k RAM, 512k flash, USB.

click to enlarge:


Edit: see also here for £20

What an utter load of rubbish. Slow an Athlon II (Representative ~3GHz, with 2.1Ghz DDR3) down to 200Mhz and its memory bus will still be running at 70MHz. This is a DDR3 memory bus runs double pumped, so thats 140MT/s. An Athlon II has a dual channel memory controller, so is capable of moving 16 bytes in a single transaction, bringing things to 2240MB/s peak. Average bus efficiency is 80% of theoretical, so practical bandwidth is 1792MB/s. Never mind the multiple layers of cache, so operations which hit the level 1 cache are as fast as RAM... and the Athlon's L1 cache is probably

Now lets move to the processor. Lets say we are dealing with a single core Athlon II for a minute... We are still talking about a three way superscalar architecture with an 128-Bit SIMD unit. This means that, on appropriate code, you can do two integer operations and 4 floating point operations. Most of these operations are single cycle, and those which aren't are relatively complex (i.e. do a lot) anyway. I don't think anyone can argue that a single 6502 instruction has anywhere near the capability of even one floating point single precision add.

I do low level development and optimization on a variety of architectures, and I despise the ugliness of x86, but nobody can successfully argue that Intel and AMD haven't made x86 fly. I think just about the only processor architectures which have been made to go faster are IBM System/Z (The z196 CPU is clocked at an amazing 5.6Ghz) and IBM POWER (Which is clocked very close these days)... which just goes to show, anything will go fast if you throw money at it.

(I realise this thread is old(ish), but I have been away for a while and am catching up)

Would that be 64-bit memory, transferring a 64-bit set with each clock edge? And if so, isn't that for bursts, where the first set (long word?) takes many clocks to retrieve, and then the rest (perhaps 7 more sets) can go at one transaction per clock edge? The fact that SRAM doesn't have the burst limitation means I was able to mix up the address lines to get better routing on my compact new 4Mx8 10ns 5V SRAM module [Edit: data sheet now available here]. It's sure more friendly to hobbyists and applications that aren't destined for volume production.

If we made a 65Org32 and did two memory accesses per clock like the Apple II did, that would be 8 bytes per clock; but in the case of small jobs that don't need to move more than 8 bits of data at a time, it would partly be wasted power, with no benefit. The idea of course is for when you regularly need 16 or more bits.

http://WilsonMinesCo.com/

A pair of 64-bit memory modules (Each is operated completely independently - including separate address busses)

Correct, there is latency (Generally 7 clock cycles for DDR3) between issuing the read command and the data becoming available (for DDR3, you get the data over the next 8 transfers). However, this bus time is not dead: memory controllers will pipeline accesses and interleave across banks in order to maximize the bandwidth usage. Memory controllers will also send requests in critical word first order, to minimize latency. It is possible to do a data transfer on every one of these cycles if you execute the right set of commands.

Memory standard and CPU cache evolution tend to occur in lock step. When it becomes necessary to move to a new RAM standard (because CPU bandwidth demands far outstrip the ability to make DRAM faster - instead, the internal buses on the RAM chip are getting wider and the aforementioned bursts get longer) the CPU cache line size tends to increase to match the new burst size.

Owen's point, I think, is that the modern x86 CPU has such a high clock rate relative to memory access time that it makes sense to spend huge effort and silicon area on mechanisms to keep the CPU from being idle.

If we scaled down the speeds but kept those mechanisms, we could have a much faster 65xx system. A 65xx system with a cache could clock faster than external RAM, and could therefore also make good use of much wider RAM and of burst accesses.

As for other mechanisms (branch prediction, speculative execution, register renaming) they seem too difficult to contemplate - although over the years ARM has developed from a simple pipelined machine to something much less simple.

Couple of references - sorry for the titles, but that's what they are called!
Numbers every programmer should know
What every programmer should know about memory

Cheers
Ed

Off-topic:
Where have you been? and welcome back.

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502

Distracted. I generally must have just forgotten about this place. With the amount of other things I juggle (of varying priorities), some things just get forgotten.