_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

Texas is one of the states which have adopted the horizontal arrangement for traffic signals. Most of the cities have given in to current state DOT standards.

It has been decades since I had to take defensive driving, I should go and do it for a discount on today's high auto insurance rates, but I hate to forfeit that "get out of jail free" card, but I digress...

I suppose a useful mnemonic device is rightmost light means you have the right of way.

The problem I have is the current fetish for flashing yellow arrow instead of a solid green light for left turn permitted but yield to oncoming traffic. A solid yellow light or solid yellow arrow is the warning that the red is coming. It is difficult to tell at a glance whether the yellow is flashing or solid so they install two yellow arrows, one flashing and one solid. But some intersections have a combination of red, flashing yellow and solid green arrow, sometimes more than one of them at the increasing number of intersections with multiple left-turn lanes.

I am just thankful that Texas has banned red-light enforcement cameras. I got dinged once for turning on red because I misjudged which yellow was lit.

Any traffic light controllers still use a 6502?

[quote="Michael"]The 6551 (faux) pinout is nice. Have you implemented serial buffers by any chance?\]

Yes Michael, but tx/rx buffers are on AVR side

p.s. my apology for colored drawings, next time I will put only B&W PDF/JPG here..

André,
both side of communication are buffered to ensure minimal use of 6502 time and resources..

To write one char just put on BaseAddress (latch U3) your data and one Interrupt occour on AVR to move your byte to AVR_TxBuffer

To read one char from AVR_RxBuffer you have 2 chance:

- with interrupt generated from AVR when AVR_RxBuffer is not empty , just read BaseAddress+1 (Latch U1) and AVR after a very short time put one new data (if exist..) on Latch U1
- with polling , checking BaseAddress+4 (for COM1) or BaseAddress+5 (for COM2) to see if there are data inside AVR buffers before access to latch U3

Using a single port with interrupts is easy to send an receive data at over 200 Kbytes/sec (1,6 Mbit/s) , with 2 ports or with polling transfer speed is reduced (performances tested with 65C02 running at 1.8432 Mhz and AVR running at 18.432 Mhz); this architecture allow minimal use of 6502 time for mid lenght data packets, in my applications less than 16 bytes are sent every millisecond end I have two terminator to start real AVR transmission:

- when AVR receive one CR or LF (for ascii string)
- after 100 uS from last char received (for binary packets)

For high speed use , engaging AVR UART only when AVR_TxBuffer is ready with all data grant that AVR process IRQ from 6502 and transfer U1 data in 4 uS (without extreme optimization of code..) and 2 Mhz 65C02 spent more time to send 1 byte of packet:

LDX NumChars ; load numebr of bytes to send
LOOP
LDA MyTxBuffer,X ; pick up data
STA AVR51 ; and store in U3 latch
DEX ; decrement pointer
BNE LOOP ; repeat up to end job

more or less 15 cycles at 500nS , more than AVR_IRQ time ; one 16 bytes telegram cost 120 uS (12% of 65C02 time with 1mS cycle)
Note that AVR must send out data at 230Kbit to allow this data rate and perform other tasks (for transmission phase local UART are engaged for 70% of time but AVR for less than 10% allowing RX for ack/nack of receiver)

Low speed or multichannel can be programmed with different logic for basis performances.

I've used IrfanView, Convert to Grayscale, then tweak Brightness & Contrast. Doesn't always give the best White background. I'll try Saturation next time.

No kidding, especially the often-seen dim, gray alphanumeric characters. (A problem Michael's schematic does not have.) What an unhelpful combination.

_________________
"I am endeavoring, ma'am, to create a mnemonic memory circuit... using stone knives and bearskins." -- Spock to Edith Keeler

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

very interesting project!
sometimes i lie in bed and wonder what could've been if WDC were to release an updated 65C51 that not only fixes the hardware bug but also included hardware SPI and I2C master/slave functionality. then i'd actually buy one of those

day dreaming aside, i took a look at the schematic and compared it to the 65C51's pinout, and a few things confuse me.

first one, the 65C51 has 2 Address lines, but in your circuit you seem to be using CS0 (Chip Select, Active High) as a third Address line? if you were to replace a real 65C51 that would cause U4 to only ever have Y4-Y8 (100, 101, 110, 111) selected as BA2 is always pulled high when the chip is selected.

and second, pin 28 on the 65C51 is the R/~W signal from the CPU, but in your schematic it's completely unusued? how does your circuit differentiate between reading and writing from/to the same address? or what if you were to try to write to a read only address? would it cause bus contention because the AVR and outputs data regardless what the CPU is doing on the bus?

on another note, i like the idea of using a latch for the input, as that gives the AVR more time to take in data without having to worry about doing it in half a CPU clock cycle. i've would've tried to use a single bi-directional buffer like a 74x245 and then just use onboard clock stretching for faster CPUs but obviously that doesn't work if the MCU is on a seperate board and designed to plug into existing systems.

but on the same note, why is the output from the AVR to the CPU also a latch? wouldn't a tri-state buffer fulfill the same purpose? because the AVR can't really pre-load the latch as by the time the CPU wants to read from it the data has to be there within half a CPU cycle.

that also reminds me, the 328p's maximum clock speed without overclocking is 20MHz (though you mentioned it running at ~18MHz, why's that?), so what's the maximum CPU speed you can pair this with before you need to add wait states on the CPU side?

.

overall pretty cool project, and giving me a few ideas for directly putting an MCU on a future SBC as Co-Processor and boot ROM. something like a CH32V103, it has the power of an SMT32 (except RISC-V), but can run at 5V like an AVR, plus they're dirt cheap.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

i guess that's sort-of true, but an FPGA is not the same as having a discrete purpose made IC in DIP/PLCC/QFP package like the other 65Cxx chips.

and yes i know of the gargantuan cost different between making an FPGA softcore and an actual physical IC.

though i hope that someday in the future (hopefully within my lifespan), there will be companies similar to PCBway and JLCPCB except for semicondutors. with user friendly interfaces, design upload, and easy ordering compared to how it currently works. obviously i wouldn't expect them to be as cheap as current age PCBs or even have similar yield rates, they'd probably still cost hundreds to thousands of <currency> for like 25-50 ICs and i'd be happy if like half of them worked.
but having prices come down at all while making them more accessible to the general public, similar to how it happend to PCBs within the last few decades, would still be a massive step forward in my opinion!

anyways, sorry for rambling, i just really want to see the day where i can hold a custom made IC in my hands without having spend my life savings on it.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

It's called MPW - multi-project wafer - and we have a thread on affordable silicon fabrication:
Custom chips at $100 each (or $30, or $20 at quantity)

i know multi-waver projects are a thing, but even nowadays they're still not quite what i would consider "hobbyist viable", expecially in terms of price. that's why i hope that as time goes on older processes like that will just keep getting cheaper and cheaper. (and man if only they came in packages like QFP that you could actually solder by hand without extra tools)

and i feel like this is getting quite a bit off-topic, sorry about that!

CS0 signal is active low to select base address for device access, pins 13-14 (BA0 - BA1) are used to select 4 "pseudo" registers; BA2 at pin 2 is a further addressing to allocate more 4 bytes for polling flags



R/W lines is not mandatory, bus contention is not possible because both latch U1 and U3 are adressed throug U4 ; trying to write to read only address (U1 device) dont crash anything



Use of latch grant bus separation and allow use of this solution in any existing board, no clock stretching is required for 6502 cpu and no wait state or NOP are necessary, please see sample code on my previous post



Latch on AVR side allow use of this solution without interrupts on both side and ensure bus separation



To avoid any error at 230Kbaud 18,432,000 Hz is the maximum clock below 20Mhz ; using oscillator insthead resonator should be possible to overclock AVR at 22,118,400 hz with zero error

I'm also curious about the maximum CPU speed... TIA...

check the datasheet again, the 65C51, similar to the 65C22, has 2 chip selects: CS0 (pin 2) is active high while CS1 (pin 3) is active low. so the chip is only "selected" when both CS0 is high and CS1 is low.
but on your board only CS1 (pin 3, renamed to CS0) is being checked while the original CS0 (pin 2, renamed to BA2) is repurposed as an address line, which can and likely will cause issues in existing systems.
so overall it's not actually 65C51 pin compatible.


how does that work though? if BA0-2 is set to 001, CS0 is pulled low, and BO2 (PHI2) is pulled high, then U4's Y1 output (PB1_RXREG) is pulled low, causing U1 to pass it's incoming data onto the CPU's data bus. but if the CPU is currently writing as well, then you have potentially colliding data on the bus (which doesn't necessarily crash, but should still be avoided).
at what point in the circuit is that being prevented without checking the CPU's R/W pin?


interesting! i knew AVRs generate the baud rate internally, but i thought they just had a hardwired oscillator for that and didn't make use of any external clock. i guess it makes sense that they do use faster external oscillators.