Re: Turbo232 UART Cart HDL

From: Nate Lawson <nate_at_root.org>
Date: Thu, 12 Dec 2013 12:05:41 -0800
Message-Id: <95763F62-C8EC-4168-8FED-1CA82D7F529D@root.org>
On Dec 12, 2013, at 11:35 AM, Jim Brain wrote:

> On 12/12/2013 11:39 AM, Gerrit Heitsch wrote:
>> On 12/12/2013 06:31 PM, brain@jbrain.com wrote:
>> 
>>> So, I thought about a CPLD solution that would "massage" the 6551
>>> registers to fit a 16550 or similar device.  But, then, I decided if I
>>> was going to massage an interface, why not massage the interface to a
>>> uC.  That would allow many peripherals to be created.
>>> So, that's my goal.  We'll see how far that goes.  I found some Verilog
>>> for dual port registers, which seems useful.
>> 
>> Don't forget, that when reading from the 6551-lookalike, you have less than 500ns (in a C64) to figure out what the 6502 wants and supply the correct data. Not a problem for the hardware, but if you want to emulate a 6551 in part with a controller, that's quite tight.
> My plan was to remove that timing concern by putting the registers in the CPLD.
> 
> To a large degree, I think one could treat the 6551 interface as a 4 byte dual port RAM.  At least registers 1,2,and 3.  Register 1 needs a bit of additional logic in that a write to it should reset the registers and cancel any interrupts.
> 
> Mainly, register 0 is the issue.  If you treat it as 2 RAM locations (write only register and read only register, then you only need to deal with the fact that a read from register 0 should return a 0 when no additional byte has been received.  So, a read from reg0 should put the value on the databus and a 0 into the register, unless the uC is currently storing a new value into the register.
> 
> But, if you implement 5 dual port registers, the uC can look at the data at a different time than needing to be involved only in 500uS intervals.  The trick is creating 5 lines that indicate when registers have been touched, and resetting those lines when the respective line is read.  My main concern is not the registers per se, it's the synchronization, as I understand such things are the "gotchas" of programmable logic.


The general design strategy is to get out of async land as soon as possible, registering events on a clock edge. I don't know the 6551 logic model, but it sounds like you could easily get by with a 4 or 8 Mhz clock if 500 ns is the fastest response time required. This means your entire design could be synchronous, making it much simpler.

Async logic is complicated in FPGAs, especially the more "@" signals you need to deal with. Those can end up with large fanout if you drive everything off those lines. There's a reason why clock distribution is a specialized part of FPGAs.

-Nate


       Message was sent through the cbm-hackers mailing list
Received on 2013-12-12 21:00:04

Archive generated by hypermail 2.2.0.