Connecting a RIOT 6532 to an Arduino?

[gmc]

I'm looking to start a project trying to connect a 6532 chip to an Arduino and before I go down the rabbit hole I want to first try and figure out on paper if this is even remotely doable.

I want to to be able to read/write to the RAM and use the I/O pins to drive something like LED's

Before you say why, I know there are easier chips to acomplish this and everything is build into the Arduino to do this, but this is for educational purposes. I have a few RIOT's lying around and wondering if this is even possible.

The ATmega2560 has enough pins and can output a 1Mhz clock to PHI0 via one of the timers so I'm thinking this is theoretically possible.
The 2560 runs at 16Mhz.

I've read through the datasheet here and have a idea of how it all works.
http://archive.6502.org/datasheets/mos_ ... b_1977.pdf

Have built lots of RAM Addons using 62256 and 6264 chips for the Arduino so know about reading/writing to addresses.

I've checked around on the interwebs and cannot find any examples of someone doing this so either
a) There is some reason why it won't work
b) No one is crazy enough to do this.

[fachat]

I believe noone is crazy enough to do this, esp as the 6532 is not produced anymore

Having said that, I don't think anything speaks against it of you
- provide a proper phi2 signal in/below the 1MHz range
- handle the address, data, and control lines (cs, r/-w, ...) appropriately
- and make sure voltages are compatible (arduino is still 5V, right?)

[BigEd]

(Some Arduinos are 3V3, I think, but the classic ones are still 5V)

[gmc]

Good point on the 3.3V and 5V Arduino's.

I've checked and have a 5V version. It sounds doable so will take a stab at getting the control lines and addressing all setup.

Time to take a deeper look into the datasheet.

[Proxy]

there aren't many 3.3V Arduinos, AFAIK only the ARM based ones are. so if you have an AVR one it's pretty much guaranteed to be 5V.

what exactly do you want to achieve in terms of functionality?

do you want to make a library so you can use the 6532's features for the Arduino, or emulate a 6502 on the Arduino and use the 6532 as the main external IO chip?

in either case the hardware part should be pretty straight forward. you just need to hook up every CPU side pin on the 6532 to the Arduino.
Ideally you'd have the whole Data Bus placed on the same Ports, so you can read/write whole bytes at a time and not deal with individual "ReadDigital"/"WriteDigital" function calls.
same for the address bus.
then you need 1 input for the IRQ line, and 5 outputs for PHI2, ~RES, R/~W, ~RS, and one of the 2 CS lines.

this adds up to 20 IO pins in total. an Arduino UNO can just barely be used as it has 14 digital pins and 6 analog pins that can also be used as digital ones.
that's why i like the Arduino MEGAs, as they're the same layout as an UNO but with an additional 32 digital pins.

so i'd recommend you look up which arduino board you have, if it has enough IO pins, and then check how the Ports are layed out to see where to best place the data and addres bus.
there are plenty of tutorials about Port manipulation (like this one), and i highly recommend using Ports as it's way more convienent and keeps the code cleaner, more readable, and faster.

[Alarm Siren]

If you're using the ATmega2560, I presume we're talking the Arduino Mega 2560? In which case I cannot foresee any hardware issues, except that you might want to check for CMOS/TTL level compatibility. If your RIOTs are NMOS/TTL then their output levels might be incompatible with the Arduino's CMOS input levels, but I have not checked the relevant datasheets. I expect they'd probably be fine in practice.

On the software side, I think it might be a push to reliably do a complete bus access with your simulated PHI0 at 1MHz. Remember that means you have only 8 clocks of the Arduino microcontroller to setup whatever needs to be setup before the PHI0 will move on to the next phase, and not all AVR instructions complete in a single cycle. Therefore I would suggest not to worry about PHI0; design your access software first at a very low PHI0 and then just crank up the PHI0 until it stops working.

Proxy wrote:

there aren't many 3.3V Arduinos, AFAIK only the ARM based ones are. so if you have an AVR one it's pretty much guaranteed to be 5V.

Actually the majority of currently available Arduino boards are now 3.3V based. Yes, the most commonly used variants, by units sold, are still the 5V ones, but if you threw a dart at a dartboard with pictures of all the currently produced models of Arduino, you would be more likely to hit a 3.3V one.

[gmc]

Proxy wrote:

what exactly do you want to achieve in terms of functionality?

I've got a arduino mega 2560 so there are more than enough pins. I want to be able to r/w to the 128 bytes of RAM, and as a bonus be able to use the PA and PB I/O ports.

Will wire up the address/datalines etc to the use the full ports as going to be using port manipulation as the digitalwrite is way too slow.

Alarm Siren wrote:

On the software side, I think it might be a push to reliably do a complete bus access with your simulated PHI0 at 1MHz. Remember that means you have only 8 clocks of the Arduino microcontroller to setup whatever needs to be setup before the PHI0 will move on to the next phase, and not all AVR instructions complete in a single cycle.

Good point there. I'll start with the lowest clock speed I can get away with, thougth looking at the datasheet the Tcyc min is 1uS so not sure how much lower I can go. Will experiment.

Proxy wrote:

there aren't many 3.3V Arduinos, AFAIK only the ARM based ones are. so if you have an AVR one it's pretty much guaranteed to be 5V.

I've tested the voltages on the I/O ports of the mega and it's 5V so all good there.

[GARTHWILSON]

gmc wrote:

Good point there. I'll start with the lowest clock speed I can get away with, though looking at the datasheet the Tcyc min is 1uS so not sure how much lower I can go. Will experiment.

1µs min means 1MHz max.  (You probably already realized that by now though.)  I can probably go quite a bit faster; it's just that it's not guaranteed to.  You can definitely go slower.

[gmc]

Thanks, I was a bit puzzled by that. Good to know it can be run slower.

[drogon]

gmc wrote:

I've checked around on the interwebs and cannot find any examples of someone doing this so either
a) There is some reason why it won't work
b) No one is crazy enough to do this.

I suspect the latter...

But I don't see why not...

Things that I'd b thinking about...

The clock - Sure, trivial to output a free-running clock from the ATmega, but is that what you want? The reality is that you'll have to synchronise the other signals to the clock, so here I'm wondering if the 6532 might have a fully static design or does it need a clock to wiggle away to keep some internal registers refreshed - data sheet says the RAM is static, but what about the data direction registers - the output register and maybe the clock/timer registers (although personally I might just quietly ignore those - at least to start with).

If it can work statically then it becomes quite easy. From the ATmega side: Keep clock (ph2) output low, Keep R/W High. You can hard-wire CS1 and CS2, RS Low, send it a reset pulse (from the ATmega) then you can test reading/writing the internal RAM:

Output address
Output Data
Set R/W output Low
Pulse Clock from Low to High then to Low again - High time must be at least 10µS.

Repeat that with a different data pattern (e.g. the inverse of the address).

Then read it back in a similar manner

So you can then do a simple RAM test with the device effectively running in a static mode.

You can do similar to write and read the IO ports, again with an effective static clock.

And if that works, well, you have a GPIO expander for the ATmega - although one that needs some 20 IO pins on the ATmega to give you 16 output bits, but that's progress for you

Might actually make a good RIOT tester device - maybe that's your aim?

Of-course if it all just doesn't work because it needs a dynamic clock then you might have to formulate a plan B - I'd be looking at a timed ISR on the ATmega side to wiggle the clock and look for commands passed in via some shared RAM so the ISR can set the right data/address/RS/RW just before it sets the clock high...

-Gordon

[gmc]

drogon wrote:

The clock - Sure, trivial to output a free-running clock from the ATmega, but is that what you want? The reality is that you'll have to synchronise the other signals to the clock

That is the one thing that's messing with my head. How to sync the clock. I'll try just a slow free running clock and see if I get some meaningful results, though if that doesn't work will have to try and sync it.

Eventually I would like to build some sort of RIOT tester but how I would even start to test the timer function is a story for another day.

Thanks, some very useful info you have given me.

Quote:

Of-course if it all just doesn't work because it needs a dynamic clock then you might have to formulate a plan B - I'd be looking at a timed ISR on the ATmega side to wiggle the clock and look for commands passed in via some shared RAM so the ISR can set the right data/address/RS/RW just before it sets the clock high...

My head just exploded Let's hope it doesn't come to that.

[pjdennis]

gmc wrote:

That is the one thing that's messing with my head. How to sync the clock.

One way to approach this given that the clock is controlled by the Arduino, is to write straight-line Arduino code to implement a clock cycle based on the RIOT timing diagram. Assuming initial state of:

• Clock output low
• R/W output low
• Arduino data line direction set to output
• Chip selects set to deselect the RIOT chip

Then to implement a read cycle:

1. Set address output to the address to read from, set ram select (RS) to access either ram or registers, set the R/W output to high (for read) and set chip select to enable the RIOT chip
2. Wait for at least TWCR/TACR (180ns) to cover setup times - delayMicroseconds(1)
3. Set direction for data lines to input
4. Set clock to high
5. Wait for at least TCDR (395ns) for output from RIOT to become valid - delayMicroseconds(1)
6. Read from data lines
7. Set clock output to low
8. Set R/W output back to low, chip selects back to deselect the RIOT chip and set data line direction back to output

In this way the clock is explicitly synchronized with the other activities. You can then run multiple clock cycles within a loop, for example to read a series of bytes from consecutive addresses. A write cycle would be similar, and you can of course implement a clock cycle without enabling and reading/writing from the RIOT.

You can implement your code within the Arduio loop() function (which is automatically called in a tight loop) to run one or more clock cycles, and you can use the micros() function to keep track of the current time if you want to produce regularly spaced clock cycles (e.g., for the RIOT timer functions.)