As I have a spare ATtiny13a, I would like to use it to generate for my 6509 some signals:

Reset: on power-up and if a button is pressed that is connected to AVR-Reset-In, it generates a clean ~250ms reset signal for 65xx.
Clock-Generation: if I would use the internal RC-Clock (~4MHz) and generate a fast PWM, it would give me up to 2MHz without the need of an extra oscillator. or if I would feed the AVR with a 20MHz oscillator can, it would allow me to have a variable clock (20Mhz/n) - granularity not too fine but might be handy.
Timer-IRQ: as I don't have a chip with timer yet, it would be nice if ATtiny could provide this function.

All this is quite simple to do on the ATtiny, but here comes the tricky part: it would be great if I can access AVR from my 6509, i.e. to change IRQ or clock frequency by software. But I only have one pin left. (VCC+GND, Reset In, Reset Out, Clock In, Clock Out, IRQ Out.) I came up with the following idea: re-using the IRQ-Line:

In times between generating IRQs ATtiny uses the pin as input and checks if it's pulled low from elsewhere - and elsewhere is CS coming from CPU. Of course this would generate an IRQ, so access has to be done after SEI. A0 from CPU will go to the unused pin. By that it could simply shift command bytes from CPU to ATtiny.

Does that sound too crazy or is there a better solution?

Do you mean D0 rather than A0? So the 6509 will bit-bang a serial byte into the ATtiny, by successive writes to whatever address your CS/IRQ signal decodes? That sounds workable to me. You might want to do something with start and stop bits to help with framing.

Oh, yeah, you are right.

Start-bit could be the IRQ generated by ATtiny - as it is supposed to.

In 65xx-ISR: check if there is data to send, write it bitwise to attiny-adr, so CS goes low and bit appears on d0
configure ATtiny for pin-change-interrupt on IRQ/CS (in between it's IRQs, and there has to be enough time for IRQ-Line to be pulled up again) - ouch --- there is a flaw in my thinking: no way to sample data from CPU for D0 changes all the time, and w/o extra logic I can't capture it's state during CS=lo --- I thought to do a simple pin change Int there too, but D0 changes all the time for data bus changes all the time. I could run CS&D0 through some leftover NAND (have to check if there is one left), then it would work with pin change.

Stop-Bit or even Bit-Ack could be done like this: ATtiny issues IRQ after each byte/bit, and CPU waits for it. And both have timeouts to restart from scratch. (so CPU does not mistake next AVR IRQ as Stop-Bit.)

Well, if the ATtiny has timers, you can cook up a baud rate... but really you just need the ATtiny to be able to measure a bit time, so it can delay a little after CS (but not too long) and sample D0 at a good time. Then it's "just software" for the ATtiny to put together a byte, optionally also checking that the framing is right. In fact, if the ATtiny's timing is tight, or especially if it is controlling the 6509's clock, you only need one interrupt/CS to get things started and then clock a whole byte in one go, using an agreed baud rate by cycle-counting.

I often use a ATtiny to generate various signals for the 65xx system. However I mostly use a ATtiny44, so I have enough pins. The interface with the 65xx system bus uses either a 74HCT165 (for data sent from the 65xx to the ATtiny) or a 74HCT595 (for data sent from the ATtiny to the 65xx system). The ATtiny connects to these ICs via the USI. Another advantage of the ATiny44 is the CKOUT option, then you can use the system clock pre-scaler to divide the clock by 2,4,8 etc. not really granular but sufficient for the purpose. This saves one timer. Of course the ATtiny44 will run as well with the prescaled clock, but we have no need for speed here (you just need to adjust the timer for the 65xx timer-interrupt accordingly). I have also written some code so the ATtiny can be used to connect a PS/2 keyboard to the 65xx system (using the 74HC595 as output register, because it has an /OE it interfaces very well with the 65xx system). Using a ATtiny13a makes the interface tricky and hard to debug.

For development I have attached an ATMega32, so I can capture 65xx bus and access it from PC via serial interface. But it don't want to include it permanently in the circuit. As I have two or three Attiny13A where I don't see much use for it, this was the reason for thinking that way.


The idea was to interact without the need for extra ICs. 13A takes 1/4 of space compared to 44+165.
(And... in the box of used chips are no shifting ICs.)


That definitely is true. I plan to first code on the ATMega where I have good possibilities for debugging and then moving the code to ATtiny. I hope that works.


I think I will experiment with both, 13A and 2313A - but first I have to finish the upgrade of my assembler.

I know what you mean. I'm also rather reluctant if it comes to add an additional chip or use more space. But the AVR MCU do not have any type of bus-oriented interface. In fact they are very bad if you want to use them as the slave. E.g. I2C or SPI slave is inefficient and slow. Also they do not have a decent bus interface where an external device can write (latching and having the AVR later fetch the item) or read (like from a latch with tri-state outputs with /OE controlled by the master). There are tricks with interrupts and snooping the 65xx system bus, but these solutions are slow in comparison to a normal register you can just read or write. Sometimes I wished that you can make a AVR MCU look like some IO registers and make their IO features available to the 65xx system. E.g. a ATMega644P would make a nice multi-purpose IO chip with ADC, Analogue Comparator, dual USART, SPI, I2C, Timers. And it could even provide a timer interrupt and generate the clock and reset or interface to a PS/2 keyboard. Even if it uses a DIP-40 at the end it would save a lot of space. Or is there any other microcontroller that provides such an interface that can be easily integrated towards a 65xx system? I don't know.

For my purposes speed is not really an issue. Even using the AVR as keyboard controller speed should be more than good enough.


Me neither.



I think I will use ATtiny2313A (I have some in my stock) instead of 13A - it should be possible to use USI for getting the data from 65xx-CPU to AVR: CS acts as Clock, D0 provides the data. If I'm not mistaken, it doesn't matter if D0 wildly changes between CS-Pulses, but on the falling edge of CS, D0 is shifted into AVR.
The other way round, it might possible to abuse the SO-Pin to get the data from AVR to 65xx, but I have to dig the timing diagrams to see if that can fly.

Some PIC 18F devices have a 'Parallel Slave Port' peripheral designed for integration with 8-bit microprocessors. You connect PORT D to the data bus and the PORT E pins become /CS, /RD and /WR. Internal latch registers hold the value supplied on the next read and latch any written data. Interrupts occurred immediately after a read or write operation to allow the latches to be read and updated.

Take a look at the data sheet for the 18F4680-I/P for example which is a 40 pin DIP device.
http://ww1.microchip.com/downloads/en/DeviceDoc/39625c.pdf

_________________
Andrew Jacobs
6502 & PIC Stuff - http://www.obelisk.me.uk/
Cross-Platform 6502/65C02/65816 Macro Assembler - http://www.obelisk.me.uk/dev65/
Open Source Projects - https://github.com/andrew-jacobs

WDC's own w65c265s microcontroller is seemingly able to reside on the bus of another processor (65xx or otherwise).

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html

Hi BitWise and Dr Jefyll,

thanks that was exactly what I was looking for.

Hobbit1972,

you could also use the USART in synchronous mode.

cheers

Peter