So, here is something that I have been tinkering with for the last 5 years. At first it started out as a board that I could use to test my CPU emulation for a product I am also working on called μDrive. This board (65xxT) emulates a 6502 (currently just the NMOS version, but other versions are planned). It uses a dual core microcontroller running at 90/100MIPS. I have a cache mechanism and variable timing for PHI1/PH2, with PH0 (1MHz) as the reference. I have a memory map table where I can adjust the timing to whatever is needed so that external chips can operate down to 1MHz if needed. You can shadow an external ROM internally (so it is off the bus). Any 6502 code running internally can execute up to 8 instructions per PHI0 cycle. This gives you anywhere from 4x to 48x the performance of a stock 1MHz 6502 and still retains the compatibility with old slow chips. I designed this to just drop in place of a stock 6502 in a Commodore VIC-20, Apple II, BBC, etc. I have been doing all of the development on a simple system - a Commodore 1541 disk drive. RDY and SYNC are not used with that, which made the bring up easier to deal with. I plan on having a 6510 version as well for the C64 (different pin and number of pins, so a different board). The NMOS version has support for all of undocumented opcodes and various bugs and quirks that it has. I could make a '816 version, or even Z80 and other CPU versions at this point - just different pinouts/number of pins.

Currently, the 2nd core is not being used at all and I am wondering if I should ditch it completely. I planned to use it for data manipulation (in the case of the 1541 I was going to use it for realtime GCR encoding/decoding). Can anyone think of any other uses for other systems?

SID emulation would be the obvious one. Or a graphics blitter.

Yes, something autonomous and asynchronous and complicated: perhaps a graphics output converter from native 6502 system to something modern like VGA. (Probably too difficult to use two cores to implement synchronous subsystems like VIA or CRTC.) Maybe emulate an Acorn-style second processor?

Hmmm. I never thought about video, but I do have a complete color composite video generator I wrote for the same type of CPU, VGA is even easier. A blitter or some other type of data manipulator would be good. I have 30K of cache memory in one core and 16K of available memory in the other unused core. The 2nd CPU is asynchronous, but can be sync'd to any clock if needed. I don't have an "expansion" port of any kind (well, 2 single pin I/O don't count). I guess I can look at breaking out a few pins in a row for an external port. That way anything in the future could be added (composite, VGA, motor control, etc.) BTW, all of this code is written in assembly and I using literally 3% of the code space. I had to go with a bunch of program memory in order to get enough RAM available.

It's a great project!

Thanks! It's been interesting to learn the processor from the inside. I have been programming 6502 in assembly since the late 70's so I knew the quirks from a programmer's stand point, but I didn't know why those quirks existed from a hardware perspective. I forgot to mention that there is a connector for an optional OLED screen. With that and the two push buttons I can single step through the code. The PH0 clock is still used a reference so that PH1/PH2 are correct for the step. One thing I learned with the Apple II is that WOZ used PH1's state as part of the address decoder input so you can't just arbitrarily access the bus without paying attention to the clocks. Some oher systems don't use PHI1 (or even PHI2) to synchronize anything for reads, just for writes.

I was about to mention this sort of thing. Besides doing debugging, you could also maybe collect run-time info -- reference counts and other statistics.

Cool project!

-- Jeff

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html

Thanks! Yeah, I have a cycle counter, interrupt counter, etc. Just some basic logging info. One nifty thing that I can do (and have done) is stop the CPU and dump the RAM contents via the serial port. There is a mini OS that lets you communicate through a FTDI interface to a serial console. I have a memory capture/restore function that lets you save/reload a file via serial. When you load the file you can just continue on, much like a PC's hibernate function (or original "snapshot" or "freezer" type cartridges for the C64).

I use a lot of Microchip PIC24/dsPIC33 devices but I'd missed that one.

The dual core architecture is interesting. It seems you have to load the slave processors program into RAM (PRAM) and it only has access to its own private RAM area plus some of the peripheral. There are a set of FIFO channels between the master and slave, very much like the BBC's tube chip.

Its a shame that the more limited slave processor is the faster of the two.

Does the slave have access to the flash ROM and/or any of the masters RAM? I've only had a quick flick through the data sheet so far. It needs a thorough reading.

_________________
Andrew Jacobs
6502 & PIC Stuff - http://www.obelisk.me.uk/
Cross-Platform 6502/65C02/65816 Macro Assembler - http://www.obelisk.me.uk/dev65/
Open Source Projects - https://github.com/andrew-jacobs

The master and slave cores are completely separate and do not have direct access to each other's flash ROM or RAM , but there are "mail boxes" where you can share data, and you can even DMA blocks of data between each of the cores, making sharing data pretty fast (even large blocks can be transferred either direction).

The slave core's CPU code is loaded via "something". Initially, I was just using the master core to contain the slave's data (which is fine if you have enough program memory space in the master core). Later I made a tiny code stub that the master programs the slave with that allows the slave to fetch its core data from an external SPI flash ROM. The slave is faster because it runs out of PRAM instead of flash memory. There is a new series of single/dual/quad? core PICs coming that apparently will be all PRAM and you load the code externally like the slave core.

These new parts have a few extra instructions and a 6 cycle divide (down from 18 of the original 24/33 parts). Each core only has one dedicated timer, but there are a bunch of capture/compare timers that can be used as general purpose timers. The slave core has faster instruction execution too. If you look at the instruction execution times you will see anything memory related is twice as fast as the master core.

For my 1541 emulation I am using the master core for the 6502 emulation, SD card, OLED, and button inputs. The slave core contains the emulation of the two 6522's. There was not quite enough CPU power left in the master to handle all of the VIA timer and shift register cases. I was looking at adding a second PIC to handle the VIA emulation when the dual core parts came out. Great timing!

There is also the new CK series of parts which seem to be hybrid of the dual core die that self loads and has faster divide and instruction times. These all run at 100MIPS (I have run them to 140MIPs to see how fast they would really go overclocked).

Let me know if you have any questions about these. I spent the last 8 months figuring out their quirks.

Nice project!

You mentioned plans for a 6510 version to plug into a C64. It took a bit of tweaking to get the C74-6502 TTL CPU to work there — particularly when it came to interrupt handling. Happy to help if you run into any potholes with that implementation.

_________________
C74-6502 Website: https://c74project.com

Thanks for the offer! I looked at your info. Fortunately for me I can adjust cycle timing individually for each phase of the instruction cycle. So, I can "stretch" pulses to cover cases like you describe for the non-NMOS version.

I have a LOT of work to do still on this. When it works in an Apple II (with the DMA) reliably, I will call it good. I have several different USB 16 channel logic analyzers, but you can't run multiple simultaneous iterations of their software. Using two computers and trying to compare screens has driven me nuts! I finally broke down and ordered a 32 channel version so I can see ALL of the signals on the same screen at the same time.

Nice ... very handy! Do post up any gotchas you run across. I don’t have an Apple II, for example, so I would be very interested in any quirks and glitches you encounter with other machines.

I share your pain!

I have a 16 channel analyzer as well, and yeah, 32 would have been fantastic. Funny thing, I get so caught up in debugging, then end up getting the right tools only AFTER job is done.

I’d love to learn what you ended up with (kinda off-topic, so feel free to PM me instead).

Cheers.

_________________
C74-6502 Website: https://c74project.com

I certainly don't mind sharing my info. How fast can you run your TTL setup? I am now tinkering with the 2MHz and 4MHz machines to add support for those. I have geared everything around a typical 1MHz NMOS version.

I saw that you posted on the Analyzer thread that was just started. I took a look at the Hantek 4032L. Looks nice. Lots of memory and plenty fast. The TTL CPU tops out a 20MHz, so no issues there.

Btw, you mentioned above that 65xxT can perform up to eight 6502 instructions per PHI0 cycle. Not sure I quite understand, but it sure sounds interesting. Would you mind elaborating a bit?

_________________
C74-6502 Website: https://c74project.com