Is it just me, or is anyone else excited about the Atmel 32-bit AVR? These things are REALLY low power and can provide a ton of 'umph' for just about any application. We're looking at 66MHz (some models even more), up to 512K of flash, and 64K of RAM with built-in ethernet (and enough horsepower to provide a nice emulation layer for CS8900A registers) as well as USB and a slew of other features. And they cost about as much as the 8-bit AVRs!

My first thought is for a standardized cartridge that uses one of these AVRs. Anyone wanting to develop a new cartridge (without electronics skills) could just buy one of these cartridges and pop into AVR Studio (free compiler and IDE) and program the chip from his PC via USB. Voila. New cartridge and all anyone has to do to get it is buy the standard cart and download the new binary to program into flash.

Some ideas off the top of my head:

- TPC/IP stack offload: C64 uses minimal memory and CPU power to do networking
- USB OTG connectivity: talk to PCs, USB hard drives, printers, flash drives, joysticks/gamepads, etc...
- REU: Some models of these have 24-bit addressing to external SRAM (16MB)
- Improved Audio: 16-bit stereo audio on-chip.

I'm quite confident that with the horsepower available in these that all of the above could be done in a single cartridge. With the right connectors, we could even port over the IEC bus and user port lines and make this do even more. tcpser connectivity over the user port, IEC talking to this chip to address the printers and drive capabilities, and so on.

Don't know if these have the features needed to run something like an embedded Linux, but if so, it gives us access to the drivers it has (filesystems, hardware, etc...) as soon as someone ports it. That could enable this to be used as a middle layer to talk to other devices for which Linux already has drivers. I know that kinda kills the Commodore geekery, but it was just a thought.

Anyway, I'm gonna go to bed and dream about the possibilities.

The problem is that 66MHz provides only ~ 30 cycles to do actual work if you're on the C64 bus, and that's barely enough time to do useful work.

I looked at it, but decided the best option was to use an FPGA for the registers, and stick with an AVR8.

Jim

Sorry! You lost me. Where does the 30 cycles come from?

The C64 operates at 1MHz. Due to the multiplexing of the address/data bus, you can utilize the bus for half of that time, or 500nS.

The AVR32 operates at 66MHz (some of the parts operate faster, but I'm using your example). Thus, that would be ~66 instructions for cycle, and ~33 per half cycle.

Now, in actuality, you have to wait until the VIC-II gets off the bus, and you have to get off right as PHI2 transitions back, so the actual time window is < 50%. I took 30 cycles as a generous estimate.

The fastest way to emulate a device on the bus would be to spin looking at PHI2. When it transitions high, grab the data and address, do your work, and decide how to respond. Such a spin might take a few cycles, so you're < 30 cycles at that point.

For a write operation, assuming you made the bus transceivers a bit smarter such that they could simply capture the address and data information, you can take the full 66 cycles in 1uS to do the work, but for a read operation, you have to deliver something on the bus in about 20 cycles, so that the 6510 has enough setup time to latch the data. The REU might be even more picky, I do not know.

So, by the time you factor in:

• 50% of a 6510 cycle is effectively your window of usage
• you'll need either 10-20 cycles for an IRQ service, or 3-6 cycles for a spin loop on PHI2 transition
• You must place the read data on the bus in enough time to stay withing the setup requirements for the 6510

You're going to be struggling to satisfy timing requirements on the bus interface. Mind you, the other 33 cycles can be used to do actual work (Ethernet, USB, etc.), but the bus interface will be tough to implement.

Jim

Ah! I see. Well, I was thinking that there would have to be some glue circuitry in there and that the atmel would not interface with the C64 directly. But I see what you're saying. Sounds like REU is definitely not a good idea here and some of the others would be difficult to implement without some significant circuitry, thus the reason for the FPGA.

Thanks! And especially, thank you for the detail!