Trying to make a PIA tester with a STM32F103

[Elektraglide]

I'm building a little tester for 6821 PIA using a STM32F103.

I need to be able to write to the data bus of the PIA, and also read from it.  (6821 has 4 registers that are addressed using 2-bits input RS0,RS1).

So 8 GPIO pins for the databus.  And I use 3 more GPIO pins for RS0,RS1 and R/W pin.

For writing to the PIA:
I set the GPIO pins to output,  set the output pins actual data and then make R/W low for writing.

For read from the PIA:
I set the GPIO pins to input,  make R/W high for reading and then read the input pins..


Does that sound right?   I'm concerned about the timing between the GPIO data bus pins switching from output to input (and back)  and then toggling the R/W line to the PIA. 

Is all this switching even needed?  

[Elektraglide]

My Williams Defender interface board appears to have died so wanted a quick way of testing other 6821s I have lying around!    Any excuse to mess about with STM32 I will take it!  :)  


Got into trying to use every feature of the STM32F103 building this smooth scrolling, texturemapped demo without any bit banging - just DMA and timers.

https://www.youtube.com/watch?v=I8Wlj3myxoA

[Tesla DeLorean]

It's not my position that high interrupt rates are not possible, just they tend to saturate at scale. ie spend entire time in interrupt context and entry/exit. And that occurs into the hundreds on KHz.

F1 also has no caching mechanism so relative slowness of the FLASH is readily exposed. 

For a square wave with constant frequency and duty can be readily configure in the TIM hardware without interrupting at each cycle.

[Tesla DeLorean]

Stated is using in old arcade machine.

Also seem popular in the retro computing scene S means to test and identify chips quickly.

[mƎALLEm]

I can't see something related to E (Enable pin ) except this timing in the MC6821 datasheet:

So pulse width low and high are specified as minimum. I think no need to use a timer for that use a simple GPIO + delay and ensure you respect this timing.

To me the first post of @gbm is giving the right steps.

[Ozone]

> Irony is that I only starting building this because the PIA on my Williams Defender machine seems busted so wanted an easy way of testing the other 6821s I have lying around.

If you have them lying around its surely worth a try.

Alternatively, you might check for a more replacement IC, some distributors specialize in "old" stuff.

And, as another alternative, perhaps you find a functional replacement, like a FPGA or MCU-based emulation.
I have recently seen a video with a Raspberry Pico board (dual M0+) emulates a Z80 in realtime, inserted into physical "retro" machines like the ZX Spectrum.

I think I still have a few Z80 PIOs, SIOs and CTCs somewhere ...

[Ozone]

I don't know the F103 in detail, but you might get away with using the MCO output as clock signal.
Not sure about the configuration aptions, though.

[gbm]

From my experience, the way to go is to use hardware PWM output for E signal and do all the rest in timer's ISR - data bus direction, R/W, RSx lines and data input/output, as described in my first post. Ok, maybe it's easier to handle E in software to avoid worries about timing details. Minimum E frequency is 100 kHz, so you have plenty of time - 360 cycles for each E edge to be exact - enough for execution of at least 20 lines of simple C code. Just design a nice state machine for that. ;)

When connecting 5 V outputs to non-FT STM32 inputs, you only need to limit the injection current to the values specified in the datasheet. In most cases 1k5..3k resistor will do. In some STM32 there are some TT lines with no injection allowed - then, in addition to a resistor, a 3V3 Zener diode or a violet LED should be connected to the input.

[mƎALLEm]

---

@Ozone wrote:

I don't know the F103 in detail, but you might get away with using the MCO output as clock signal.
Not sure about the configuration aptions, though.

---

Not sure if it's something that could fit the chip requirement timings:

E, CS, RW signals needs to follow this diagram:

So I don't think using MCO + handling the GPIOs (set/reset) will fit this timing!

E determines a cycle of read/write here.

[Elektraglide]

---

@Tesla DeLorean wrote:

It's not my position that high interrupt rates are not possible, just they tend to saturate at scale. ie spend entire time in interrupt context and entry/exit. And that occurs into the hundreds on KHz.

F1 also has no caching mechanism so relative slowness of the FLASH is readily exposed. 

For a square wave with constant frequency and duty can be readily configure in the TIM hardware without interrupting at each cycle.

---

Absolutely,  and using h/w to do this beats the pants of getting software in the way.

FWIW,  I have all my ISR code decorated like this::

__attribute__((__section(".ramcode")))  void TIM4_IRQHandler(void)

with .ramcode defined as living in the 20K RAM  (rather than flash)  for better performance.

[gbm]

Overkill. F103 may handle MC6800 bus at up to 200 kHz using interrupts without any trick. :)