That idea to treat some memory regions (e.g. memory mapped IO areas) as "external memory" which cause the CPU to run at the system clock speed (instead of the much faster "internal clock") sounds like it could also work well for (software) emulators.
However for "highly integrated" home computers like the Atari 8-bitters and C64 I guess this wouldn't be of much use, because most games and demos depend on proper CPU timing, even when not accessing memory mapped IO regions (for instance in wait-loops to get to the right raster position before reprogramming the video output).
There's a lot of discussion of wait stating and slow-clocking of 6502 and accessories over at 6502.org. In particular, many 65xx series accessories still need a common/regular clock signal to keep their internal timers going, even if the CPU is running faster/slower than normal for a specific access.
This ends up becoming a very fun design problem when you do it with integrated circuits!
Well, it's not new in the 6502 world either. The Apple IIGS has to do just this to clock down its 2.8Mhz CPU selectively to work with the floppy drives and such, outside of doing that to run as an Apple II.
Beyond that, a 6510 isn't the only thing you really need to emulate a Commodore 64. You also need a SID Chip (MOS 6581) for sound and a MOS VIC-II for display and a number of other things.
The cpu in the article is real hardware and pin compatible with the 6502, and they use it by putting it into 6502 sockets on old hardware, so no need to emulate the SID chip or anything else--there would be a real one available.
It would be quite easy to modify the design to full 6510, which just has a few more pins dedicated to IO. The biggest issue is properly emulating the bank switching, which they have done for other hardware, but the 6510 has a more complicated scheme.
The C64 bank switching is trivial - the 6510 has a few IO pins mapped to address $1, and a few of them are used for the bank switching.
The bigger problem is that all the RAM is really used for "IO" (in theory anyway) on the C64, as the VICII can remap the character generator (font) location, where it pulls sprites from, and where the screen content is stored.
So a static memory map is insufficient if you want it to just plug into the CPU socket and work.
I always wondered in those days why the disk drives for 8-bit computers were so crazy expensive. In Holland they cost more than the computers they were meant for.
But only later I learned that they were basically another whole computer themselves. Plus the drive mechanism of course which also wasn't cheap (but not nearly as expensive to warrant the high price).
It was the same for the Atari 800XL I had, I never owned a commodore 64.
It's all the odder when you consider the Apple II.
It came out before any of those other home machines, and yet had the cheapest floppy disk storage from 1978 onward. That was largely due to Steve Woz's brilliant disk controller design, which did away with everything but some simple glue logic and a couple ROM chips, lifting everything else in software.
Of course, the Apple II had real expansion slots, obviating the need for using a serial connection, too.
From what I can tell, while the Apple II family had a much higher up-front cost, the more serious you were about computing, the more the low-priced home machines with expensive peripherals worked against you in the long run.
I'd agree with that. The case size, open design, accesible FW, etc. made it really easy to add custom HW to the Apple ][, I got a lot of joy out of mine. I have to admit to being a bit jealous of the C64 and Atari kids with their better gaming capability.
> and yet had the cheapest floppy disk storage from 1978 onward.
OTOH, the time-critical hack that allowed it also made it nearly impossible for Apple to upgrade the II without breaking backwards compatibility. The only Apple II with a faster 6502 is the //c+, and that because it has the crazy Zip Chip acceleration logic on the motherboard.
> I always wondered in those days why the disk drives for 8-bit computers were so crazy expensive. In Holland they cost more than the computers they were meant for.
The mechanics were also somewhat expensive. In Brazil, an Apple II drive was often as expensive as an Apple II clone.
What makes the intelligent drives a great idea is how easy it is to emulate them - you emulate a nice protocol. When you have to emulate, say, an Apple II drive, you need to emulate the delays the drive mechanics introduce, as well as the head electronics, because the Apple II's 6502 is reading the head and assembling the bits. That's also why accelerating an Apple II requires you to slow it down for a longer time every time it accesses the IO region - because the disk needs to revolve in the exact time the 6502 takes to run some amount of code. With an intelligent peripheral, it doesn't matter you don't wait several seconds between commands, as long as you only issue them at the required speeds.
Here's a demo running directly on the 1541 disk drive. It generates video by hacking the serial cable that's usually used to connect to the computer, and audio from the drive motors.
We have breadboarding (ben eater and someone basically do a sort of os to ease the pain of doing rom etc check YouTube) and many just arudino mega hacker (one of this but there are many : https://www.instructables.com/6502-Minimal-Computer-with-Ard...).
And if not hardware easy6502 is a very good software assembler and simulator using JavaScript and canvas no less
They're compatible enough you can drop a 6510 into it with no problems (I tested that, to my parents great despair). You can also swap the IO chips I think, with various effects (you at least can drop the Amiga CIA chips into a C64 - you lose the realtime clock nobody uses, but gain timers).
Putting a 6502 into a C64 may or may not work for some values of work or not at all - I don't recall what the default for the bank switching would be, but the tape drive certainly wouldn't work (the gpio lines on the 6510 is used for bank switching the ROM, and for the tape). But it should be quite easy to make it work except for the tape drive. You just need to ensure the right voltage on 3 pins for the ROM bank switching (various software that expect to be able to change it will fail though)
The only difference that matters is the IO pins mapped to address $01. Given this is an FPGA based project it likely would be pretty trivial to make it work in a C64 as well.
Depends. Some Atari 8 bit games used the display interrupts for timing, so those could run as fast as possible so long a the display interrupt happened at a consistent 60hz. (now that I think of it, I think some games has issues in countries with 50hz updates)
This is true for a lot of older and simpler games for the C64 as well, but at the same time for most of them you'd see absolutely no benefits, since it's common for everything to hang off the interrupt.
A few games that glitches when there's too much stuff going on at the same time might run smoother.
Demos are likely to mostly not work because any remotely fancy effect tends to depend on much more precise timing, though.
There’s plenty of games and demos that require the exact amount of raster time to function. If you want to display things in the left and right border you have to switch something at exactly the time the graphics chip is displaying the right border. That’ll never work if the timing changes.
However for "highly integrated" home computers like the Atari 8-bitters and C64 I guess this wouldn't be of much use, because most games and demos depend on proper CPU timing, even when not accessing memory mapped IO regions (for instance in wait-loops to get to the right raster position before reprogramming the video output).