drogon wrote:
So 256 bytes of ROM then almost the full 64K for RAM minus a little for IO and off you go. Of-course microcontrollers would typically download into Flash to preserve the code at power-off - but again, I'd need to look closer at this project to see what it does....
I had only a quick look at it, but unless I'm missing something it's just a 6507, RIOT and 27C512 EEPROM. So the code is going into flash, unless I'm totally missing something here.
But the only RAM is from the RIOT, so all of 128 bytes there. From a note on the schematic, the RIOT's address map is $00-$7F for RAM and $80-$FF for I/O. A12 high selects EEPROM and A12 low selects the RIOT, so you have the RAM+I/O mirrored through the bottom 4K, flash EEPROM in the next 4K, and this pattern is repeated to the end of the address space.
So far, all good; we have a nice little base for an embedded system.
But now he talks about programming it in C. With 128 bytes of RAM shared between the stack and the heap, but at different addresses depending on whether you want to use it as zero page or stack. This sounds pretty dubious to me, but maybe he's smarter than I am, has written an appropriate little crt0.o to start the stack pointer at $17F, put the heap in the zero page, and has somehow told cc65 that $00-$7F and $100-$17F are the same area of RAM and it needs to take extreme care not to let the stack go down far enough to start stomping on the heap.
But then I look again at the schematic and there's no /WE signal on the EEPROM. Oh, right; the 27C512 needs an extra address pin, so JEDEC (or maybe Winbond) replaced Vpp with A15 and /WE with A14 and it's now programmed by bringing /OE up to 12 V and a pulse on /CE. But wait, on the schematic /CE is tied to ground, /OE is on a 74HC04 output, and there's not a trace of 12V to be seen anywhere anyway. This EEPROM can't be programmed in-system.
Yeah, I think his design got as far as, "can I fit it on a board this size and shape?" and he immediatey built that without taking the design any further.
And, while the 6502 is a fine little processor for its time, and even now if you're ok at writing assembler, it doesn't seem terribly fit for the Arduino ecosystem and its mass of bloated C++ libraries, where "blink a single LED" can be a 4K program. So what we have is:
- A CPU not well suited for C
- running at at least 1/8th, more likely 1/16th, the clock speed of an AVR
- that uses far more cycles than an AVR to do the same thing,
- has binaries rather larger than an AVR, and
- has a small fraction of the memory (both RAM and EEPROM) of most AVRs.
So what's the point? Building an embedded system that uses the least resources possible is certainly a standard thing to do for reasonaby competent engineers, but not for the kind of learners that Arduino is aimed at. Arduino (correctly for its audience) aims at ease of doing simple things for beginners at the cost of bloat, but that's not the 6502 world.
Someone mentioned that the 6502 is a simpler processor than the AVR (56 instructions vs. 131, etc.), which is true to some extent, but you never see that from C except occasionally in very painful ways, so I don't see any point there.
There's a good case to be made that a 6502 system can be a good way to learn low-level programming, but that's something that just doesn't mix with the Arduino world except in the most superficial ways.
This doesn't seem to be well thought through, and I would never have given it a prize. But I guess just slapping "6502" on something really, really pleases some people.