PRU based Apple IIe videocard

GoogleGroups
1

Helllo Guys,
I just wanted to share the first steps of my project: take a look to my facebook post:

https://www.facebook.com/groups/5251478676/permalink/10159148656378677/

Best,
Tomas

2

Very neat Tomas!

A PRU is capturing the write to the video memory? Are you reading the data in via a parallel interface or serializing it?

Cheers, Dan

3

Thanks Dan!
Yep, I created two versions: one capturing READS + interpreting the video address, and another one capturing the 6502 writes. With the latter was much easier to tune the timings, so that’s what I’m doing.

I use 8 bits in parallel, hooking the BBB to the Apple II peripherals bus. I need 24 bits in total, so I use some electronics (a multiplexer and 3 buffers), and time everything to capture each byte at the right time (ADDRESS LOW, ADDRESS HIGH, DATA).

It’s a pity that HDMI on the BBB steel so many pins from the PRU, otherwise I could write to the bus, emulate audio on hdmi, etc…

PRU are amazing!

4

I agree. PRUs are an amazing resource in the beaglebone computers - and - it is unfortunate there aren’t more pins. I have an idea for a project along similar lines, to use the PRUs to emulate a bus master for a now obsolete workstation bus. It’s 32 bits wide and I was thinking of an approach similar to yours, using 8-bits of data and a bunch of latches. Good to know someone else has had success with this.

One last question. How are you sharing the data with the HDMI frame buffer?

Cheers, Dan

5

Hi Dan,

For HDMI I share memory with the ARM core and there is a program running in userspace and interpreting video memory. (I use SDL for output).

I suppose that your idea feasibility depends on the clock: with the 1Mhz of the apple ][ clock I had to capture 3 bytes in 489ns (half cycle). But selecting each bytes is slow.

In theory there is more than enough time, but there are a few delays:

  • Reading “pin to register” delay (signal on the pin → read from __R31)
  • Writing to “register to pin” delay (write to __R30 → signal on the pin)
  • Propagation of latches and demuxes
  • Write to shared memory

So, experimenting with timings I got to the conclusion that changing from one 75HC245 to the next took at least 75ns for reading. I didn’t test delays writing to pins yet, but I think itś higher (>100ns).

If you have more bits in less time (higher frequency), this approach unfeasible… but if the clock is low enough and you don’t need HDMI, you can play with PRU1 and use 16bits + some bits of control…

6

Hi!

7

On PRU-1 you can use 15 inputs and 16 outputs. Only on PRU-0 you can use the full set of PINS (16 IN/17 OUT). For the later case you have to build a custom SD-Slot connector.

Find details at http://users.freebasic-portal.de/tjf/Projekte/libpruio/doc/html/ChaTNT.html#SecPruGpio

Thanks for the info!

PS: Is it intentional that you exclude non-facebook-members from watching your project?

Of course not :smiley: I quickly shared what I posted on an Apple II enthusiasts FB group.
There are no details about the BBB, it’s just a video, but I wanted to share it nonetheless . Uploaded to youtube:

https://youtu.be/j8unb8AX6ng

Disclaimer: bad video quality, no details… I will share more when have some time :stuck_out_tongue:

8

@TJF, I’m a beginner here, and I used RemoteProc for PRU initialization…

I’m going to read in depth this thread from 3 years ago, to understand better your opinion as well :slight_smile:
https://groups.google.com/forum/#!msg/beagleboard/cYHCN3GWw_E/nfPhNHy0BQAJ