No, that's the 50% bus duty cycle feature/quirk/whatever of the 6502 I mentioned earlier. Practically *every* 6502-based home computer uses it, the BBC Micro included. Dual-Ported VRAM is something *completely* different.
Note that in most computers that *don't* use the 6502 and have to use bus arbitration for DMA video it's generally transparent to the programmer as well, it just has some side effects with regard to instruction timings. Broadly speaking the system is going to run slightly slower than its clock speed would indicate compared to a system that doesn't share RAM with video. Whether the impact on instruction timing is 100% predictable or not and of what magnitude depends on the hardware design. For example: the Mac Plus benchmarks slightly slower than a Mac SE despite both using the same CPU at an identical clock speed, and the reason is that the simplistic method used in the Plus to share RAM between CPU and video hands the bus over to the video output 50% of the time while the SE trims that closer to the ~25% it actually needs. The SE isn't half again faster than the Plus because the 68000 itself only needs the bus some of the time, thus the greater utilization doesn't impact it quite as much as the numbers would suggest.
Anyway. Blawblawblaw.
Heh. Well... that's certainly a nice part, but scanning the data sheet it doesn't look like it's much more than a buffer/latch with some provisions for automatically cycling the latch based on a clock input. To make it into a bus you need to design a bus protocol and controller to implement it. Buffered pins are a start, but you'll need a clock source and work out how you're going to phase data transfers, IE are you going to need an address for every transfer or are you going to favor "bursting" bytes/words across it? With only 30-something pins obviously you'll have to multiplex data and addressing over the same pins, you'll need to work out the timing for that, and what about interrupts? Or arbitration? Etc, etc. A bus controller is a complicated piece of kit and it'll have to be fast if you're going to hang it off the RAM bus of a 70+Mhz SoC. And of course, on each card you'll need an IC to demultiplex your complicated and fast bus. Honestly that really doesn't sound very "hobby-friendly" to me. The reason systems like S-100 and the Apple II were successful and "easy to use" was that they presented a bus which didn't have the complication of asynchronous burst transfer modes, multiplexed address/data lines, etc, etc. Notice how *nobody* is turning out NuBus cards as a hobby these days? That's because NuBus is "hard", and I can't help thinking your bus sounds "hard" too. Maybe I'm just too intimidated by the "big and fast" that seem to naturally come along with 32 bit CPUs.
If you were using a SoC with a lot of GPIO pins you could, I suppose, just slap some buffers/line drivers in front of them and provide the cycling for a sort of "synthetic" bus in software. Obviously that's going to consume CPU cycles and you won't get DMA, but if what you really want is a parallel channel for "tinkering" that could work pretty well. (Actually, doing a quick Google it looks like some of the "Stellaris" ARM Cortex CPUs do essentially that, offering a glob of GPIO pins that can be configured to run as a bus called "EPI".) But... do you really have in mind a solid idea what sort of bandwidth numbers you hope to achieve and what your real-world use cases are? Most of what I think of when I think of "modern hobby computer" are people are doing cool things with easy-to-use MCU frameworks like Arduino, and terms of bandwidth and computational ability those compare pretty evenly with the hobby computers of the 1970's and 1980's. The big breakthrough is instead of needing a $2000 Apple II and a wire-wrapped PIO interface card to interface to and control "X" you can simply fit the programming, computer, and I/O controller into a single chip so cheap it's practically disposable . (And if you want a graphical interface to control X then you provide it by tethering your device to a laptop over serial/usb/bluetooth/whatever.) For that sort of fiddling both an ARM SoC is serious overkill and a bus actually gets in your way. You want cheapness, accessibility, and GPIO pins, the rest is fluff.
*snicker* I'm sorry I've sounded so down on your Dream. I do think, however, that you might be having an issue with defining what your dream actually *is*, since it seems like it's somewhat all over the map.Side note: My friends used to call me the "dream crusher" because I would bring harsh reality to their wild plans. So... I guess this is fair. Dream crusher.:lol:
Are you chasing the dream of coming up with your own super-cool hardware platform, or is it the all about software framework idea. Is this something just for you or something intended to be shared with the world as an open platform... or what? You mention the Apple II as inspiration, but then seem to hyper-focus on performance (without setting an actual goal) and sort of freaked out at the idea that you might be "wasting" CPU power if you did X instead of Y. Hobby computers aren't about maximal performance, CPU efficiency or even necessarily design cleanliness. Heck, the Apple II is a poster child for a brand of engineering that actually trades gobs of theoretical performance for minimal hardware requirements, even at the cost of relying on ugly, arcane and difficult to understand software to drive parts of it. (Like the disk controller.)
One of the things that makes the Raspberry Pi interesting is it actually seems to provide the hardware you really want, IE, something that *does* include the peripherals you need for a graphical operating environment but is still designed to allow some simple real-world interfacing. The Pi is designed to be an educational toy; the inspiration is actually the BBC Micro and it's successor the "Archimedes", and in fact Risc OS and the accompanying BBC BASIC are available for it, for free. (Some of the examples for using the GPIO pins on the project's wiki are written in BASIC.) That's why I suggested you might be best off tackling the software side first on the Raspberry hardware, since it seems other than this "parallel port bus" thing it's a darn close fit for what you want. I assume you have notes, or at least an idea in your head, what your "toolbox ROM" is going to consist of? Something like an ARM port of Applesoft BASIC around a simple monitor/kernel of some sort? The Pi appears to have sufficient documentation available to write "bare metal" OSes for it, and if you make it go on the Pi and later decide you simply must make your own board featuring the expansion bus of your dreams it'll probably be easier to port your working code to a different SoC than it would be to start with a naked chip and have to bring it all up from scratch. (Most computers are bootstrapped by writing code on other computers early in their development, after all.)
But again, that's just my best guess. If I'm totally wrong then don't let me discourage you from attacking this your own way.