Matt Porter presented "What's Old Is New: A 6502-based Remote Processor" (pdf) at the Embedded Linux Conference - Europe

Attachment:

His project makes use of the two 32-bit 200MHz real-time cores on the ARM-based BeagleBone's TI chip as a bitbanger to control the pins on a physical 6502 on a breadboard hooked up as a peripheral. As he doesn't have quite enough pins, he uses 74-series octal bus transceivers to demultiplex(*). The 8k of RAM in the cores is used to populate the 6502's memory space: 4k at the bottom and 4k at the top.

At the software level, Matt has hooked up a driver to use Linux's Remote Processor Framework so the 6502 appears to Linux (on the BeagleBone) as a supported remote processor. He's got a 'virtual UART' to allow Linux and the 6502 to communicate with each other.

The net effect is that he runs Linux on the BeagleBone, where he can use cc65's tools to create a firmware image which can be loaded into the 6502 memory map, then start the 6502 and communicate with it over /dev/bvuart

Matt provides his Linux kernel tree on github here and his tools and examples here.

Matt also acknowledges Lyren Brown's Atari Beaglebone Expansion project, which emulates a 24k RAM expansion for the Atari 600XL (Announcement, github, video)

(*) as far as I can tell, the bus capacitance is used to stored the value. I might have this wrong(**)
Edit to add:
(**) Yep, I had it wrong! Nothing dubious going on. See below.

Hi, thanks for the mention of my session at ELC. I'm a long-time lurker here and love all the great projects coming out of this community...

I'm not sure what you meant by the value being stored by bus capacitance...however to clarify...

There's simply a bus transceiver for address high, address low, data in, and data out. The output enables for these 4 buffers are controlled from the PRU with the timing synced to the PHI2 and R/W signals. Incidentally, PHI2 is provided by a hardware PWM on the AM335x SoC but then also fed to the PRU core which controls sequencing of the address/data onto the 8 data in pins I had available. Address high and low are stored in a PRU register, then based on R/W either used to fetch data from the SRAM or store data to the SRAM. The PRU either drives the Datain output enable for a write cycle or outputs a fetched byte from sram on the data bus and drives the Dataout output enable to complete a 65xx read cycle. With this approach we can also emulate a number of different 65xx peripherals via the PRU or allow access to I/O running on the ARM Linux side of the part.

Lyren Brown really saved me a lot of time as he already had pretty much the same thing done...I was originally considering doing this with a dual port SRAM and the remoteproc approach but dual port parts are very expensive now.

One thing not mentioned in the slides is that I did a little demo of a port of the EWoz mentioned in the comments at http://jefftranter.blogspot.com/2012/05/woz-mon.html to this Bone-6502 platform. Although mentioned in the last slide, the h/w design info is at https://github.com/ohporter/b6502/wiki/Bone-6502-RemoteProc. Code is at https://github.com/ohporter/linux/tree/WIP/bone-6502-remoteproc and https://github.com/ohporter/b6502

-Matt

Hi Matt
good to see you here!

Ah, I now see my confusion. For some odd reason, I was supposing the BeagleBone needs to drive the 6502 Address bus, and it can't drive both halves at once. But that's nonsense: you are reading the Address bus, and you can of course sample the two bytes at slightly different times. It's only the Data bus you have to drive, and as it's only 8-bits wide you can drive it all at once just when needed.

I'll make an edit to my footnote.
Cheers
Ed

This is cool. Another 'sandboxing' project trapping the 6502 into the Matrix.

_________________
In theory, there is no difference between theory and practice. In practice, there is. ...Jan van de Snepscheut

It's a little bit like the http://propeddle.com/, except in this case the 6502 appears as a co-processor of a linux machine.

This is exciting news!

Right, the biggest h/w difference is the the ProPeddle has a discrete SRAM on it whereas the BeagleBone's AM335x has 28K of SRAM I can leverage and drop the SRAM from the design. The finished Cape design I'm working on will have a 65c22 VIA and a CPLD (mostly to use the SPI65/B controller at first). I like the idea of a mix of some discrete peripherals and the ability to emulate h/w using the ARM and PRU cores on the AM335x.

Sounds good!
Do you have any Beeb fondness? JGH has defined a protocol for Tube-over-serial - he's written a client too but it's in BBC Basic - seems to me like an interesting higher-level API for an attached 6502.
See http://mdfs.net/Software/Tube/Serial/

(There's a nice writeup at http://blogs.mentor.com/chrishallinan/b ... geek-toys/ )
"The room broke into applause when Matt hand-typed in a short assembly language program and ran it, without referring to a script or document. "