PRU based Apple IIe videocard

42 views
Skip to first unread message

Tomas Espeleta

unread,
Nov 20, 2019, 11:19:44 AM11/20/19
to BeagleBoard
Helllo Guys,
I just wanted to share the first steps of my project: take a look to my facebook post:


Best,
Tomas

Dan Julio

unread,
Nov 21, 2019, 11:24:15 AM11/21/19
to BeagleBoard
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

Tomas Espeleta

unread,
Nov 21, 2019, 11:44:04 AM11/21/19
to beagl...@googlegroups.com
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!

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/040e4533-bba5-4ee7-8fd8-3ff776e8db63%40googlegroups.com.

Dan Julio

unread,
Nov 21, 2019, 1:06:17 PM11/21/19
to beagl...@googlegroups.com
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

You received this message because you are subscribed to a topic in the Google Groups "BeagleBoard" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/beagleboard/E5eIu-Qo_xg/unsubscribe.
To unsubscribe from this group and all its topics, send an email to beagleboard...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/CALNrYmvc6rFSpxC3kNbODw%2B%3DU-Zhvj1TqCck%3D_3bx5Wmz7fXkw%40mail.gmail.com.

Tomas Espeleta

unread,
Nov 21, 2019, 1:43:49 PM11/21/19
to beagl...@googlegroups.com
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....


TJF

unread,
Nov 22, 2019, 10:49:42 AM11/22/19
to BeagleBoard
Hi!


Am Donnerstag, 21. November 2019 19:43:49 UTC+1 schrieb Tomas Espeleta:
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....

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.


Regards

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

Tomas Espeleta

unread,
Nov 22, 2019, 11:19:46 AM11/22/19
to beagl...@googlegroups.com
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.


Thanks for the info!
 
PS: Is it intentional that you exclude non-facebook-members from watching your project?

Of course not :D  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:


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



Tomas Espeleta

unread,
Nov 22, 2019, 11:39:22 AM11/22/19
to beagl...@googlegroups.com
@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 :)

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/e5056e57-105c-4aaa-a561-0d728fd38a6a%40googlegroups.com.
Reply all
Reply to author
Forward
0 new messages