6502.org

I found some pre-built USB modules that use the same PIC device I was planning to use for my 65C02 emulator.

http://www.robot-electronics.co.uk/acat ... dules.html

You could easily simulate any 8-bit CPU with 64K of RAM on the same module (6502, 6800, 6809. 1802, 8080, Z80). I've ordered a couple to save me having to do any SMT soldering. All it needs is a base board with a MAX3232 and an SD card socket.

The PIC32 (MIPS) module would be faster but is extremely tricky to program in anything other than C.

Looks good - 30 pounds plus postage gets you a 50-pin DIL module with 16bit cpu and 96k RAM.

The MAX2323 should be optional I think - the USB can act as a COM port connection to a host.

(If programming in C isn't an obstacle, or if ARM rather than PIC is your thing, this cheap fast dev board by ST might look attractive. ChuckT found it.)

Cheers
Ed

USB drivers are not easy to write. The protocol responses have to be exactly right for the host driver to operate correctly and there isn't a generic CDC driver built into Windows as there is for other USB device classes. A simple UART connection is the easiest way to get started then I can use that to debug a dual channel CDC (one for the emulated device and one for the debugger)

Programming in C isn't a problem, it's just that I prefer bare metal coding. The ARM boards are nice but I'd need to retool to use them. I don't have a JTAG programmer.

I don't think there'd be any need to write a driver on the host side - there wasn't with the i2c adapter board I bought (from the same company.) Anyhow, you'll soon be able to find out, if the boards are on their way.

But perhaps I'm missing something, if there's a need to run a debugger over the USB port at the same time. I saw that there's an example program to exchange data over the USB to the PIC, so that seemed hopeful.

Cheers
Ed

Sorry I should have been clearer. I was refering to the USB driver needed on PIC side. The device contains a high speed serial engine that handles the transmission and receipt of USB command packets but you have to write the code to respond to the generic commands for device attachment/detachment and the specific class commands (Communciation, Human Interface, Disk Driver, Audio, etc).

Windows contains a generic driver that allows any HID (mouse or keyboard) or disk class device to be attached without any Windows drivers but there is not a generic CDC (serial, modem) driver. Microchip provide one for thier devices which you customise with sepecfic vendor and product identifiers (VID/PID) for your application.

I want expose my emulator as two USB based COM ports, one connected to the control interface of the emulator, the other viewed as a 6551 peripherial by the code being emulated. That way you can use one terminal to debug and one to view application output.

Having a real UART on the device will make debugging the USB code much easier during development. I can use it to dump the command packets back to a PC. If I had the cash I'd buy a USB protocol analyzer but they are a bit pricey.

No sign of the modules in the post yet.

Microchip does make a USB to UART MCP2200 and free USB drivers so Windows can see and communicate with the device. Are you aware of it already? Although it is a SMD (20-pin .050" SOIC), the pins are about 1/2 far apart as DIP pins so it's easy too solder without bridging pins. A 20-pin SOIC to DIP adapter is $6.50US.

Me too! I think I confused myself a bit. So, although you do get demo code to provide a single serial port over USB, you want to provide a pair - for good reasons - and an additional genuine serial port will help you debug that. Makes sense!

Cheers
Ed

My modules arrived last night so now I have no excuse not to make a start on the USB firmware (other than all the other projects I have, the software I'm supposed to be updating for my own company and the uncertainty at my day job caused by someone losing 2.3bn Euro - very careless of them)

I built a simple carrier for the module to hold the RS232 transceiver and drilled/filed some suitable holes in a ABS project box to hold the project.



First job is to get the module working with the serial connection. Then i can start with the USB interface and virtual serial ports.

It lives ...

Trace output generated via the UART

Excellent! Looks like a test suite...

Andrew (BitWise),

Did you publish this project (and source code) somewhere?

Cheerful regards, Mike

Sorry, no its closed source at the moment.

I've ported the code to a different device in the PIC24 family, added support for interrupts and a few bug fixes. I found some nice Arduino shield shaped PCBs with a bread board style layout on ebay for my latest prototype. The UART is connected to the usual Arduino RXD/TXD pins (lower right corner) so I will be able to stack my terminal shield on the top to add a display and keyboard. The only components needed to make this work are two decoupling capacitor, a tantalum for the core voltage regulator and a pull up resistor on the reset - Two more resistors are needed for the ICSP programmer. I'm using the internal fast RC oscillator and the PLL to increase the speed to 70MIPs.

At the moment I'm using a USB CDC adapter to connect it to my laptop. I've written an emulation of key parts of Acorn MOS 1.20 so that I can get BBC BASIC working. This device only has 8K of RAM so the recursive part of the bench test does not work yet - I'm waiting for a chip that will allow 16K of RAM to be delivered and later in the year there will be a device that will support 32K.

The results from the bench test so far are: The emulator supports all the 65C02 instructions and has a fully functioning decimal mode. Interrupts are trapped by the host and passed to the emulation for handling. Currently I'm only using a 100Hz timer interrupt but I will be adding a UART RX handler.

I use the 65C816 opcode (COP $02) to access the host processor. I currently have six functions (get last interrupt source, read memory, write memory, bit set, bit clear, get RAM size). You can see how these are used in the MOS listing.

All the unused I/O pins are available for use. Some changes are needed to the firmware to enable peripherals and select the pins that they will use.

Optimized the flag handling a bit more