S-40/20 An 8/16 Bit Parallel Bus Concept for Teensy/Arduino/Pi

So, I might point out that for this application:

I2C would be limited because Phillips wanted to sell address of at the highest bidder, and that's all we usually get is a choice between two or three solder blobs.

SPI has some promise, but I have seen a few different schemes for multiple devices, from the simple such as just setting an en/dis able line--all the way to creating a multiplexer for the job. I am unsure how older machines would deal with the the overhead, and would likely require intermediate micro-controller to use a SPI bus. Like most modern peripheral buses, I am unsure of how it would handle latency.

Lastly, although I am stupid and grossly unqualified, there seems to be no other competing standard from anyone much smarter than myself : )
(nudge)

Also, in my spare time, I am recreating the CoCo 3 case, which could be 3D printed or moulded. It can be fitted with various hardware platforms. It's about 80% done. Anyway, I thought to myself, well, how would I hook more than one SD card, and a few other things to it. That's when I started thinking about a bus.

[I fancy OS9 Level II, which ran on the original, Unix-like, realtime-timeslicing, and multi-user on a 8-bit 1986 micro, yes. If the Teensy's SOC had 2 stack registers, or if they could be emulated, that in itself would be pretty cool. If such an operating system ran on the Teensy, it could boot before you leaned back in your chair to reach for your coffee.

When I was a kid, there were few microcomputers, and there was no retrocomputers, at all.

In the last few years, retro computing has really taken off. 8-Bit guy has 1.4 million subscribers. Adrian has 200,000. LGR has 1.4 million. Ben Eater, the designer of a breadboard computer, has 1.2 million subscribers. Usagi Electric has a good start at 76,000 subscribers. Besides myself, seventy six thousand people are looking at an old bitslicing mainframe computer used to keep track of oil wells, that they had likely never heard of--if it weren't for him. Well, and it features cute bunnies at the end, but oddly, that's not the only draw. NesHacker has 80,000 subscribers. I just found Noel's Retro Lab, such was in Spain, and has 62,000 subscribers. As you might have guessed, the Commodore 64 and Vic 20 are back in production. There are 3 new 8-bit computers also in production: the Mega-65, Commander-16, and the F256. Anyway....

In rekindling my interest in retrocomputers, I noticed some things:
They did not want you to copy media, and we obeyed by removing external removing drives from our computers.
We got used to computers that take minutes to boot.
We got used to software bloat.
We were so completely ushered away from writing code computers, that they didn't feel the need to ship a programming language with the computer so they can sell it to techno-peasants.

In some ways, I feel that we might have made a few interesting turns.
]

1707637385590.jpeg
 
Last edited:
That looks really cool. The build looks instrument-grade, like it should say NASA somewhere on it.
Were card guides added later? Those connectors look a bit pricey, though.

[I had wanted to create the "Matrix" sequencer as seen in Reason--in hardware. I also wished I could think of some crosspoint switch kind of thing to connect synth modules on a bus, so their would be blessed knobs--but no wires, and the patch could saved, but all analog.
The first synth I used...was a Paia Gnome : ) ]
That's nice of you to say, thank you. Front panel made from 2mm alu plate on my 3020 cnc, using a 2 flute bit and a very slow feed. SD card holder is a microsd to panel cable on a bracket, and power supply is basically a traco psu bolted to a blank eurocard. I do have some card guides for when it's a little further advanced - I've sort of piggybacked (in physical dimensions, anyway) part of the old eurocard standard, so I'm using an 100x160mm pcb, and 3U nvent/schroff/verotec card cages and guides for that size of PCB are fairly easy to get hold of. The DIN41612 connector is available in multiple configurations, as they're laid out in up to 3 rows of up to 32 pins each. Pin spacing is 0.1in, so easy to work with. For the retro nod, it was/is used in VME systems, and they're not unduly expensive connectors - around £1.5 each from aliexpress, just be careful of keyed ones :) The backplane I bought from a retro computer enthusiast, martenelectric.cz, for around £18, so not an outrageously costly build, just requires a fair bit of patient soldering. I thought of just using doepfer eurorack to begin with, but realised not enough bus wires for data and expansion, and too shallow a pcb to allow for clearance for either my fingers or deep components on the front panel. As I say, I'm envisaging a sort of modular midi controller, so I could build modules with front panel controls dedicated to a particular VST/VSTi, that will talk to "master teensy", then to pc/daw, so I could, for example, lay out a channel strip of hardware controllers for plugins in the same physical order as in the software. Patches/presets can be saved on i2c EEPROM or SD card. Just going to use midi protocol via the RX/TX for now, so each "slave" module will need to have jumpers to select which hardware port on the "master" to connect to. Considered bus systems, as midi is not exactly rapid, and may go that way in the future - and as you say, I2C addressing is an issue, certainly, but on the plus side it's potentially hot-swappable, and as the teensy has multiple I2C ports, when my knowledge has increased it should be possible to use different ports for devices within the module and external to master. Otherwise, canbus seems a little intriguing in possibility, but something about which I have no knowledge at present. I'm nowhere near as ambitious as you, though, in what you're trying to achieve. Very impressive. As for crosspoint switching of synth modules, gotta say that without using encoders or motorised pots, it's gonna be tricky to recall presets. I can remember when synths came with a printed out template of the controls for you to write the values down onto, gets complicated quick...
 
USB doesn't count?
Well, do you think it would be practical to implement it on old computers?
Or would it be easier to use a parallel bus?

Apparently, even USB has latency issues( --and there's not locking feature on the 'FN connector : P )
 
Last edited:
That's nice of you to say, thank you. Front panel made from 2mm alu plate on my 3020 cnc, using a 2 flute bit and a very slow feed. SD card holder is a microsd to panel cable on a bracket, and power supply is basically a traco psu bolted to a blank eurocard. I do have some card guides for when it's a little further advanced - I've sort of piggybacked (in physical dimensions, anyway) part of the old eurocard standard, so I'm using an 100x160mm pcb, and 3U nvent/schroff/verotec card cages and guides for that size of PCB are fairly easy to get hold of. The DIN41612 connector is available in multiple configurations, as they're laid out in up to 3 rows of up to 32 pins each. Pin spacing is 0.1in, so easy to work with. For the retro nod, it was/is used in VME systems, and they're not unduly expensive connectors - around £1.5 each from aliexpress, just be careful of keyed ones :) The backplane I bought from a retro computer enthusiast, martenelectric.cz, for around £18, so not an outrageously costly build, just requires a fair bit of patient soldering. I thought of just using doepfer eurorack to begin with, but realised not enough bus wires for data and expansion, and too shallow a pcb to allow for clearance for either my fingers or deep components on the front panel. As I say, I'm envisaging a sort of modular midi controller, so I could build modules with front panel controls dedicated to a particular VST/VSTi, that will talk to "master teensy", then to pc/daw, so I could, for example, lay out a channel strip of hardware controllers for plugins in the same physical order as in the software. Patches/presets can be saved on i2c EEPROM or SD card. Just going to use midi protocol via the RX/TX for now, so each "slave" module will need to have jumpers to select which hardware port on the "master" to connect to. Considered bus systems, as midi is not exactly rapid, and may go that way in the future - and as you say, I2C addressing is an issue, certainly, but on the plus side it's potentially hot-swappable, and as the teensy has multiple I2C ports, when my knowledge has increased it should be possible to use different ports for devices within the module and external to master. Otherwise, canbus seems a little intriguing in possibility, but something about which I have no knowledge at present. I'm nowhere near as ambitious as you, though, in what you're trying to achieve. Very impressive. As for crosspoint switching of synth modules, gotta say that without using encoders or motorised pots, it's gonna be tricky to recall presets. I can remember when synths came with a printed out template of the controls for you to write the values down onto, gets complicated quick...


[That is a really nice CNC. It's not large, but they look well made. Hmm. The axis Y moves like a 3D printer. Perhaps some way covers could be made from upholstery vinyl. On mine, I notice that I spent a lot of time staring on ways and screws, waiting for something to get in them.

The connector is interesting. For (sort-of) high-speed, the ground pins could be in the center of two rows. To look at it, I would think that it's "unduly expensive." It's cool that it is not. The old OS, I adore so, also ran on VME backplane computers.

Perhaps, a 3D-printed cartridge could be made for your patches, wavetables, and whathaveyou to protect the board and help guide it?

Someone should make a new high-speed music serial bus. The powers that be never considered latency, bursty yes, but not low latency. It would seem that it would need a clock, running all the time, too.

Canbus is interesting. Oddly, my CNC has (Modbus over) RS-485 for the VFD. The cool thing about RS-485 is: "It is generally accepted that RS-485 can be used with data rates up to 10 Mbit/s[a] or, at lower speeds, distances up to 1,200 m (4,000 ft).[2] Okay, let's see...that's more than a 1/2 mile : O ]
 
Last edited:
Using the CMD line, the bus could support video cards which accept up to 255 commands. Lines, boxes, whathaveyou may be drawn using the commands, and passing parameters using the DAT 0-7 lines. Perimeters may then be passed. screen captures could be addressed similar to memory.

These command could be used to invoke drawing commands, such as point, circle, box, filled in box, and then the data could follow depending on the parameters. A get-put buffer or a screen of data could be read like the extended memory addressing below.

If the latency is not bad, the bus could be used for audio chores. While there are DA/AD converters available for the Teensy4.1, there could be a plug-in one, perhaps with a 3D printed case, like a cartridge.

While memory expansion wasn't the top priority, this scheme should work to do either 32 or 64-bit address, by clocking out either 4 or 8 bytes for the address, and then the data byte to be sent or read. That should give either 4GB or 18 Exabytes per card.

So generally, there would be selectable modes
1.) CMD Command mode, for operating the card/device
2.) ADD Address of a memory read/write. The address would be clocked out a byte at a time, for a maximum of 8-bytes for 64 bit addressing.
2.) DATA information passed along the bus

It also has the CLK line a bit guarded on 3 sides, and the INT also so guarded.
It would have an CMDEND command, which would latch memory in a video card, or tell a graphic card to draw, execute, and so-forth. The CNDEND is an attempt to make the latch invocation more generic.

With 8 each of SEL and INT, that would still be 34 I/O pins to run a full bus.

I am trying to figure out how to use this with an 8-bit vintage computer that don't have a lot of pins. Perhaps if there was a way to exclude perhaps 5 bytes of memory and map it. It would take a bit of glue logic, but the CoCo SDC is way more sophisticated than this.

Edit: Included pinout in screenshot, numbered as Kicad's footprint.
1708579354488.png
 
Last edited:
Back
Top