From 8bit breadboard to 6502

[nei02]

cool! Thank you!

[nei02]

I made some progress.

VIA and ACIA are working. I can receive bytes via terminal emulation on my Mac.

But ...

This only works if the clock is < 1,8 KHz. (555 based clock / adjustable with potentiometer)
With an Oscillator can 1MHz nothing works. Even id I divide this frequency with a 74HC74.

I am using high quality solderless breadboards.
And the wiring is tidy.

A bit disappointed!

[nei02]

[BigDumbDinosaur]

nei02 wrote:

I made some progress.

VIA and ACIA are working. I can receive bytes via terminal emulation on my Mac.

But ...

This only works if the clock is < 1,8 KHz. (555 based clock / adjustable with potentiometer)
With an Oscillator can 1MHz nothing works. Even id I divide this frequency with a 74HC74.

I am using high quality solderless breadboards.
And the wiring is tidy.

A bit disappointed!

Posting a complete schematic would be helpful.

[nei02]

I will try to make a schematic.

[GARTHWILSON]

The connections are way, way too long, especially the ground connections. From what I can see in the picture, it looks like the ground connection from the oscillator to the processor is nearly a foot long, and from the processor to the VIA is a whopping 20" long! This makes for a lot of unwanted inductance. Start by bringing the black and red vertical wires on the left over to the right about an inch and three quarters, or even running them up the middle, between the ICs. If you really want them on the side, put them up the right side as well. Put a capacitor across the ACIA and one across the VIA also, from the power pin to the ground pin, with connections as short as possible, like you did on the processor and memory.

For some help understanding AC performance and what goes on in the high frequencies involved (not just clock speed, but 100MHz and more, involved in the switching speeds), see the AC-performance chapter of the 6502 primer at http://wilsonminesco.com/6502primer/construction.html and the references at the bottom of the page, and our sticky topic at viewtopic.php?f=4&t=2029 .

[dwight]

There is a chip on the same strip as your Atmel part ( flash or EEPROM ) that looks like
a skinny SRAM part. It looks to have the capacitor attached across the wrong pins.
Fix that first.
As for neatness. Good signal integrity don't give a hoot about neatness.
You shouldn't run clock leads and qualified write strobes out to
those strips on the left and right. It is cleaner to loop them as short a distance
as possible across the center of the chips.
Dwight

[nei02]

Good Morning for all your replies!!

Will do the following:

Fix the wrong connection of the capacitor
Put capacitors onto VIA and ACIA
Ground direct connection from a central point as short as possible
Same for clock (white) and write (yellow) signal

[nei02]

It was the wrong connected capacitor!
Thank you soooo much!

Of course I will optimise the ground & signal routing now as well.

Danke
Ralf

[dwight]

An alternate way to do things is to have 64K of RAM.
You have a simple circuit that shadows the ROM over
the RAM during boot. The ROM would copy it self into
some RAM space for the monitor code. It would then
access some particular address that would cause it to disable
the ROM. You'd then be 100% RAM for applications.
You'd only keep the parts of ROM you'd use in the application,
such as serial I/O or something application specific.
That way you could have a more complete monitor with things
like assembler and disassembler that you could dissable
while running the application.
On capacitors being wrong, years ago when working at
Intel, the boards we used to control the UPP product had
a hole for a feed through, right next to the hole for
the capacitor. About every 20 or 30 boards through production
would have the bypass capacitor tied to a data bit line.
As you can guess, it didn't work too well.
Dwight

[nei02]

Yes! I would like to go this way! But I don't know how to start.

First step would be to change to address decoding.
But what would be a simple first step to get a Programm into RAM.

Currently I have an issue with the terminal program.

CoolTerm receives the character but then applies hundred of dots to it.
SerialTools stops after receiving the first 50 characters although I transfer them very slowly.

I should fix this before I go to next steps.

[floobydust]

nei02 wrote:

I made some progress.

VIA and ACIA are working. I can receive bytes via terminal emulation on my Mac.

But ...

This only works if the clock is < 1,8 KHz. (555 based clock / adjustable with potentiometer)
With an Oscillator can 1MHz nothing works. Even id I divide this frequency with a 74HC74.

I am using high quality solderless breadboards.
And the wiring is tidy.

A bit disappointed!

Well, looking at the picture, you're using the latest WDC65C51 chip which has a bug on transmit. This explains why it won't run at a CPU clock rate higher than 1.8KHz. The CPU runs slow enough to allow the 65C51 to finish transmitting a character before the CPU can check the status register and write another byte to the chip.

See this thread for more details: viewtopic.php?f=4&t=2543

[dwight]

Rather than a program delay, why not make a non-retriggerable
one shot using the start bit from the UART. You could then use
that to generate an interrupt to send the next byte.
For now, increasing the delay between characters would be
easiest.
The 1.8KHz issue was the capacitor.
Dwight

[nei02]

Yes! the problem with higher speed was the capacitor.

I have found an terminal program which works. Minicom - It has no GUI but I like it.
For the next step I'm planning to read a character and store it in RAM

I think something like this could work:

Code: Select all

START:
ldx #$00


OUTPUT: 	lda hello, x
			sta ACIA_DATA
			jsr DELAY
			beq INPUT
			inx
			bne OUTPUT


INPUT:		lda ACIA_DATA
			beq INPUT				; if no data try again
					

ECHO:		sta ACIA_DATA
			jsr DELAY
			lda #$00	
			beq	START

DELAY:		ldy #$ff
	DECREMENT:	dey
				bne DECREMENT
			rts  



hello:  .byte "Input Please:", 0

[dwight]

I don't believe the data port will return 0 if there is no
data.
Most of these chips requite you to read the status port.
The data port will usually have the last byte received
or possibly garbage if you catch it while being updated.
I doubt your delay will be enough for transmit.
I don't think you need any delay on receive if you use the status
register.
I'm also assuming you've initalized the serial chip.
Dwight