"BE" is "bus enable" though, not "bus relinquish." It could have been named "BR\" (pardon the lack of the overbar in forum formatting), "bus-relinquish-not," then asserting it would indeed be pulling it down.

_________________
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?

Yes, a pull down may be to slow to release bus enable. BE itself should react fast enough (30ns max according to the datasheet). You could try to pull down BE faster by putting a Schottky diode between -reset@ATMega (cathode) and BE@WD6502 (anode). Whenever -reset is driven low on the AVR, it pulls BE on the 6502 with it.

-reset --|<-- BE

_________________
6502 sources on GitHub: https://github.com/Klaus2m5

I'm afraid you got the wrong information. It's not the quiescent state which is the reference, it's whether the signal is active-low or active-high. The name of the signal is important, as Garth points out.

To reset the chip, you bring \RST active, which means take it low, and that is asserting reset.
To interrupt the chip, you bring \IRQ active, which means take it low, and that is asserting an interrupt request.
To signal that the memory or peripheral is ready, you bring RDY active, which means take it high, and that is asserting ready.
To enable the bus drivers, you bring BE active, which means take it high, and that is asserting bus enable.

In most of the designs we see, the reset and interrupt inputs are variable, and we tie off the RDY and BE inputs - but we are tying them off in their active state. They are asserted.

Cheers
Ed

Interesting. I did not realize that the pull down would inflict latency. What could be the expected pull down time for e.g. a 10K resistor resistor in this case?

Note that the same exact configuration works with a 74HC541 (which has a typical propagation delay of 10ns), but not with the BE pin of the W65C02S, so some detail must differ. (of course the sense of the pin is inverted, BE vs. /OE but that's an easy change to the ATmega firmware). 30ns sounds like it should be fast enough, though, so I don't know what it is.

Hopefully the logic analyzer arrives soon, so I can take a closer look. Now I'm just shooting in the dark…

Using a Schottky diode is also an interesting idea. I will rummage through my parts bin and try this if I have one.

Without doing the actual math, the pull (up or down) resistor and the stray capacitance of the signal path form a low pass filter and the expected time to reach the low level of the BE input could reach some microseconds.

However, that would be identical to a pullup on -OE for a 74HC541. There is most probably another problem on the BE signal path. I would manually tie reset of the AVR to ground and measure the logic level on BE with a multimeter wether it reaches a proper low logic level (< Vdd*0.3). A common error would be to leave an originally needed pull up resistor in the circuit.

_________________
6502 sources on GitHub: https://github.com/Klaus2m5

Hi all! I haven't yet had time to debug the BE problem further. However I've written a new blog post with some info about the progress. There is also an updated schematic.

http://petenpaja.blogspot.fi/2014/12/er ... grade.html

I also got interfacing between the 6502 and ATmega working. A region in 6502's address space gets copied to the internal SRAM of the ATmega so the 6502 can now print stuff on the screen

A new blog post is up! It's about making the 6502 and the ATmega communicate with each other.
http://petenpaja.blogspot.fi/2014/12/er ... rface.html

A short video showing the 6502 updating the screen:
https://www.youtube.com/watch?v=eMqzmynKRAk

Hope you like it! I'll probably add keyboard support next…

An interesting project, it looks very similar to Libby8 (the 2010 precursor to FIGnition), but done with a 6502:

https://sites.google.com/site/libby8dev/libby8/concept

Libby8 is simple enough to be done on Veroboard

https://sites.google.com/site/libby8dev/libby8/circuit

Libby8 (on both a Z80 or 6502) wouldn't drive the address bus; instead it would initially use /Reset to force the target CPU to start executing code at a known address and disable /OE from SRAM in order to be able to inject instructions straight from the AVR's data bus.

The primary instruction stream gets the target CPU to write its own bootstrap (and kernel/OS) to SRAM and then jumps to it. Communication between the two is then handled by interrupts. Bitmapped video is handled ZX81-style, by getting the CPU to jump to the video buffer; whereupon the AVR replaces the actual bytes read with NOP instructions. Even on ERIC-1, the AVR should be able to read in bitmapped data and output it to the USART in real-time (16-cycles is ample time to input a byte from external SRAM and output to the USART).

Going a step further than ERIC-1 and eliminating the extra address latches would be beneficial if the machine isn't too crippled by that, because a simpler machine is more buildable.

Note also, the 65816 is fast enough to copy bitmapped video using MVP instructions, which means the AVR wouldn't have to mess about with substituting instructions from external SRAM.

Interesting approach to reading the video memory!

I can see only two problems with that approach: when the AVR is accessing video memory, the 6502 would be massively slowed down, especially with the 400 pixel horizontal resolution of ERIC-1. Also the clock frequency of the 6502 would have be locked with video output which I'm trying to avoid. I'm planning to run the 6502 eventually at 8 MHz.

I'm currently halting the CPU momentarily on scanlines 0-12 so that the AVR can transfer the contents of the screen memory from external RAM to its internal RAM. During those scanlines the 6502 spends about 63%* of the time halted. The 6502 is currently clocked at 1 MHz, so with 63% halting on the 13 scanlines the effective clock frequency is about (1 MHz * 299 + 1 MHz * 0.37 * 13) / 312 = 0.97 MHz. At 8 Mhz, the effective clock rate would be 7.79 MHz.

Clocking the AVR faster would make the wait states shorter but it would probably also make the pixels non-square.

* the 63% figure is an estimate for the final version, at the moment the AVR can't access the external SRAM quite that fast because of breadboard capacitance effects.

EDIT: fixed math

Thanks for replying, and they are good points. However, firstly, the reason why you only need to halt the 6502 for 12 scan lines is because you're using a text mode which can entirely fit within the AVR's SRAM. If you were using bitmapped graphics you'd find that the extra bandwidth would slow down your 6502 much more anyway. That's OK, because at 8MHz (why not 10MHz?) a 6502 would still have plenty of CPU, we'll see how much a bit further down.

Secondly, just because the 6502 would be reading video from SRAM doesn't mean it has to be in lock-step with the video output. It's perfectly possible to buffer data from 6502 into the AVR while the AVR outputs previously buffered data to the USART. I'm assuming you have a 10MHz USART bitrate with a 20MHz AVR, because of your 400 pixel/scan resolution. So, there are 16 clock cycles per output byte. A 6502 (temporarily) at 5MHz would deliver a byte every 4 AVR cycles, and so would be able to fetch 4 bytes in the time the AVR needs to output 1 byte. Total AVR clocks needed would be:

4*1 for the in instructions + 4*2 for the std instructions + 2 to load from the AVR buffer +2 to store to the USART

=16cycles. PORTB here is used as the data bus port.

in r16,PORTB ;first byte.
st r16,Y+ ;dest buffer.
in r16,PORTB ;second byte
ld r15,X+ ;AVR buffer
st r16,Y+ ;dest buffer.
in r16,PORTB ;third byte
st r16,Y+ ;dest buffer.
in r16,PORTB ;fourth byte.
st r16,Y+
sts r15,USART ;output video.

In addition, the 6502 could load bytes outside of the visible video area; which leads to a maximum of 5MHz*64us = 320 bytes per scan.

Because the 6502 would be loading in 4 bytes for every output byte, it could resume normal execution for most of the next 3 scans, at 10MHz while the AVR empties the buffer. Its effective performance would be 7.5MHz in the visible part of a frame.

Thus we can calculate the rough performance of the 6502: 312 lines in a PAL frame and with 200 for video = 112/312 lines at 10MHz and 200/312 at 7.5MHz = 8.4MHz. A 16% performance loss is pretty good!

The question is then, how do we prevent the 6502 from executing video memory as instructions? One solution is to set PORTB as an input with pull-ups and generate a 10MHz signal on an AVR port that disables /OE on the SRAM synchronised to the latter part of each 6502 cycle. The AVR would read the SRAM data earlier but the 6502 (you need a 65C02) would interpret the now pulled-up data bus as a sequence of 0xff 0xff instructions: BBS7 -1 . If ACC is set to 0 beforehand, the 6502 won't take the jumps (note, you need a different technique for a 65C816).

Hi! Good stuff! But I think your math is a bit off. A 400x256 resolution image (the resolution of ERIC-1) takes 12800 bytes so it can fit into ATmega1284P which has 16K of SRAM. At 320 bytes/scanline it would take 12800/320 = 40 scanlines to copy the image. The entire screen buffer could be thus copied during the top border:

in r16,PORTB ;first byte.
nop
st r16,Y+ ;dest buffer.
in r16,PORTB ;second byte
nop
st r16,Y+ ;dest buffer.
in r16,PORTB ;third byte
nop
st r16,Y+ ;dest buffer.
in r16,PORTB ;fourth byte.
nop
st r16,Y+

(with this version the in instructions are evenly spaced so it has a better chance of working )

(Note this means that the HSYNC signals would have to generated using two hardware timers/counters toggling the SYNC pin, since the AVR does not have time to do anything else during the copy mem lines)

During those 40 lines the 6502 would be busy updating the screen, so the remaining 312-40 = 272 lines could be used to execute application code. Thus the effective clock rate of the computer would be (assuming 10 MHz at normal operation): (272 * 10 MHz + 40 * 0 Mhz) / 312 = 8.71 MHz. Which I guess is not that bad considering the amount of bytes moved.

All in all, this is a very interesting technique. However, losing the 6502 during those 40 lines is quite a large tradeoff, imho. Also losing the benefits of character based screen modes is even bigger turn off for me personally. The 6502 even running at higher clock rates is still not that fast updating the 8 times larger screen... I guess the VIC-20 and C64 still have a strong influence on me

Also I would still argue that with this technique you are lock-stepping the 6502 with the AVR. During the copy men lines, the 6502 timing has to be exactly right.

Misc notes:
- I'm running the AVR at 16 Mhz with 8 MHz USART rate. At this rate the pixels are very close to being square. With higher frequency they would appear too narrow.
- For the same reason max clock frequency for 6502 is 8 MHz.

Just for the exercise, with a 6502 running at 8 MHz, the numbers would be:
4 MHz * 64 us = 256 bytes/scanline

Copying 400*256/8 bytes would thus take 12800/256 = 50 scanlines. Effective clock rate: (262 * 8 MHz + 50 * 0 Mhz) / 312 = 6.71 MHz. Ouch!

Same math with character based screen mode:

50*32 bytes, 6.25 scanlines. Effective clock rate: (305.75 * 8 Mhz + 6.25 * 0 Mhz) / 312 = 7.84 MHz. Better! And the 6502 is happy updating the 50*32 screen ram

EDIT: just for the record, the AVR can read a byte from external SRAM in 5 cycles when doing block transfers:

out PORTA, ZL ; set lo8 address
addi ZL, 1 ; increment address
in r24, PINC
st X+, r24

So the speed difference with the two techniques is 4 vs. 5 cycles per byte. Roughly, because I still need to increment the page address every 256 bytes.

The project got mentioned on Hackaday! Congrats phvic!

http://hackaday.com/2014/12/10/the-eric ... ocomputer/

(Note to self, I really should finish the write-up of my L-Star project at https://github.com/JacGoudsmit/L-Star )

===Jac

Thanks Jac! Glad to get some coverage, although the project is still far from finished. I'm implementing a keyboard controller using ATtiny2313 at the moment. Should be ready in a couple of days. I'll probably add two joystick ports too, so I can implement a two player game at some point.

L-Star is definitely Hackaday worthy project! Just give them a tip when you are ready

It's getting bigger! Keyboard input works and just finished wiring logic for 2 atari joystick ports. Keyboard input is processed by ATtiny2313A and send to ATmega1284P through data bus. The ATmega1284P writes the keyboard input as ascii to a SRAM location. 6502 simply reads the data and writes back zero so that the ATmega knows that it's ok to write another character.

Greetings Petri,

May I ask... are you stopping the 65C02 when the '1284 is collecting keyboard data and writing it into memory?

Happy Holidays. Cheerful regards, Mike...