Fire Hose to ribbon cable

[mnbvcxz]

One guys solution to the edge card connector appears to be the 'MODIFY & MELT' routine....

 

 

(Click on image to enlarge)

My nanopeb is like that, the connector is cut down from a larger size.

I would be suprised if any had a genuine 22 pin connector.

[slinkeey]

My nanopeb is like that, the connector is cut down from a larger size.

I would be suprised if any had a genuine 22 pin connector.

 

Why? Scavenged parts to keep the cost down?

 

I see 22x2 female edge connectors on the net.. Maybe the spacing is too hard to find?

[mnbvcxz]

You would need to ask the builder why he used cut down connectors, are they a common item?, maybe he could not afford to buy the minimum order quantity or maybe it is cheaper to cut down the connectors.

[+acadiel]

You would need to ask the builder why he used cut down connectors, are they a common item?, maybe he could not afford to buy the minimum order quantity or maybe it is cheaper to cut down the connectors.

No they aren't too hard to find...

 

http://www.newark.com/jsp/search/productdetail.jsp?SKU=42K9934

[Stuart]

No they aren't too hard to find...

 

http://www.newark.com/jsp/search/productdetail.jsp?SKU=42K9934

 

Availability: 0

Supplier lead time 15 weeks

Minimum order quantity 432!

 

I've had trouble finding these connectors as well, and have in the past done exactly as Jaime has done - cut down a longer connector, and use epoxy to mould an 'end cap'. Works fine, but visually may look a bit of a bodge. I've just ordered a 'proper' pack of 5 though from that link that someone posted a couple of days ago.

 

If you need a male part for this connector, I think someone in the past suggested cutting the edge connector off an old PC ISA card ...

 

BODGE = Bit Of Damn Good Engineering

[+acadiel]

 

Availability: 0

Supplier lead time 15 weeks

Minimum order quantity 432!

 

I've had trouble finding these connectors as well, and have in the past done exactly as Jaime has done - cut down a longer connector, and use epoxy to mould an 'end cap'. Works fine, but visually may look a bit of a bodge. I've just ordered a 'proper' pack of 5 though from that link that someone posted a couple of days ago.

 

If you need a male part for this connector, I think someone in the past suggested cutting the edge connector off an old PC ISA card ...

 

BODGE = Bit Of Damn Good Engineering

Digikey has 138 :-)

 

http://www.digikey.com/product-detail/en/5-5530843-4/A31723-ND/770549

[+Ksarul]

Here's a source with 50 of them for $35. These are right angle:

 

http://www.ebay.com/itm/321239023349?

 

And these are the straight ones--and they're just over $31 for a group of 50. . .

 

http://www.ebay.com/itm/321240738967?

 

The same source has the 36-pin cartridge port connectors in both variants as well.

[slinkeey]

 

Yep. Those could be quite easy to make in ExpressPCB. Just like a double sided set of cartridge fingers. <grin>

Veroboard (Stripboard) might be an alright option to make the fingers.. The pitch appears to be correct..

 

http://www.veroboard.com/double-side-4x10-4000l-epoxy-fiber-pitch-01-254mm-p-289.html?zenid=fug85tjg1e2s1jbod5vfna5vk0

[Ed in SoDak]

Those female card edge connectors are fine, but they're through-hole, not piercing for ribbon cable attachment. They are, however, what Jaime needs that would be far more professional than what he's doing now. I guess you could solder a ribbon to them, I've been known to do that in a pinch.

 

That particular Veroboard has only 15 conductors, we need 22. The board can't be too thick either.

 

So far, a match to the male end on my cable remains unobtanium.

 

Lacking that, may as well buy a cable like the one arcadeshopper has, at least it's ready to plug 'n' play.

 

 

-Ed

[atrax27407]

The crimp style female 44 pin connectors are hard to find as well.

[Ed in SoDak]

IDE drive cables for laptops use them, but yes, most are 40-pin.

[slinkeey]

No, that veroboard would need to be cut down..

 

Copper Strip Quantity: 40 Lines each side

[+Ksarul]

That's why I said I could do a quick layout in ExpressPCB to create one that works nicely.

[Tursi]

You think that's bad? Look at the people making Amiga DB23 female plugs by hacking off two pins of a DB25. Now, that is a hack!

 

That's what I did back in the day!

 

Also, my CF port connector is chopped too, though I can't get at it for a photo right now.

[+acadiel]

That's why I said I could do a quick layout in ExpressPCB to create one that works nicely.

If you do, throw it my way, please, so I can hack at it and make my sidecar board too. :-)

 

Thanks!!! :-)

[+acadiel]

 

That's what I did back in the day!

 

Also, my CF port connector is chopped too, though I can't get at it for a photo right now.

Was Commodore the only one that used those nonstandard DB 23 connectors? I wonder if they got a huge lot of those suckers at a basement bargain price and just decided to use them because of that.

[+Ksarul]

You know I'll make extras for mangling, Acadiel--that is what they are for in any event!

[Ed in SoDak]

I guess the pic of the Veroboard didn't match the description. I counted only 15 conductors, so I guessed the "lines" thing meant 40 holes.

[MoreBITS]

Has this tooic died? In interested in making a y adapter with a card to mount a nano peb but also have a pass through for the standard peb.

[+Ksarul]

I would not say that it has died--I still have to do the quick layout for a connector end. I'll try and get that done this weekend, making a finger board set with two box headers on it so that a pair of cables can be easily attached.

[+acadiel]

I would not say that it has died--I still have to do the quick layout for a connector end. I'll try and get that done this weekend, making a finger board set with two box headers on it so that a pair of cables can be easily attached.

 

Yeah what he said. Too many squirrels, so little time....

[matthew180]

For that matter, what about putting the PEB protocol over Ethernet (not necessarily switchable, mind you, but possible.) That way we can convert the entire protocol (encode all lines) into a single packet) and work bi-directionally. I can see where CRU timing might be an issue, but not an insurmountable problem. The speed of modern technology should easily allow conversion between equipment and medium.

Similar to what Mizapf already said, you have to understand that the 99/4A expansion port (and the cartridge port as well) is a computer *bus* extension. It does not work based on a protocol like Ethernet, USB, SATA, SCSI, etc. A communication channel like those just mentioned have the advantage that the devices attached to them are not expected to answer in a fixed amount of time. You send a command and at some point in the future you get a response and usually a block of data. USB, for example, has the bandwidth once data is flowing, but you can only initiate a transaction every *millisecond*.

 

A computer's internal data and address bus are a fixed synchronous system that requires devices to receive information and respond within very specific amount of time. Even in our seemingly slow (compared to today's computers) system with a 3MHz clock, that is still a 333ns (nanosecond) clock period. When the 9900 puts and address on the address bus, it expects the data at that address to be read (appear on the data bus) or written within 2.3us (without any wait-states). This is way to fast to get a read or write request through a protocol stack.

 

Serial protocols like USB, Network, SATA, etc. are geared for transferring large blocks of data from consecutive addresses, not for random access to single bytes or words. If you were to send single bytes of data per packet over USB or Ethernet, you would find them to be extremely slow.

 

I think Tursi mentioned this already, but to get the expansion bus into fewer wires you would have to multiplex the bus lines and demultiplex them on the other end. You could probably use CAT6 and borrow ideas from the Ethernet physical layer to get the bandwidth. The design would not be trivial though.

 

You could eliminate 10-pins (7 ground, 2 +5V, and the CLK) from the 44-pin connector. The clock can be recovered, but the audio line might be a problem and require special sampling and conversion. Alternatively a separate analog audio line could be run.

 

CAT5/6 is rated at 125MHz per pair and FPGAs have differential line drivers that can handle that speed. Borrowing an encoding method from Ethernet you could get 2-bits sent per clock. So, the 34 lines / 2-bits per clock = 17 clocks. Divide that by the 4 pairs in the line and you get 4.25 clocks to send the data, but round up to 5 for some margin. To send a 333ns clock you need to send at half the period, or 166.6ns min, but lets round down to 160. Divide that by the 5 clocks to send the data, you get: 160ns / 5 = 32ns. 32ns / 1 = 31.250MHz to transmit the data. That is very feasible with a small FPGA or CPLD.

[+OLD CS1]

Mizapf threw up some good numbers in another thread about this, and I have been noodling on it ever since. Your numbers just add fuel my fire. Here is the thing about the synchronous requirements: it does not have to be real-time on both sides. The man-in-the-middle, so to speak, can do a lot of interpolating on what is happening on the other side. If the translator knows what is happening at a given time, it can reduce the data being transmitted down to a subset of signals related only to that particular transaction, then a good bit of information can be synthesized on the other end with potentially little to no lost time.

 

As a pseudo-example, we know that certain control lines have to be in certain states in order for data to be valid for a write. Those lines do not have to be sent, just a control code telling the PEB end that this is a valid write cycle with data. Other unrelated lines do not have to be sent at the same time. I do not expect timing to be much of an issue, but only experimentation will show.

 

As for audio, I would try a simple AMR codec to handle incoming audio from the PEB. A mid-quality setting (7.4kbps) should be sufficient to reproduce speech, and even a high quality setting is fairly low bandwidth (12.2kbps.)* Other sound sources, like from a SID card if it uses AUDIOIN, will probably need a better codec to be satisfactory; how many PEB cards send audio to the console, anyway?

 

Another nice thing about having smart translators at both ends is the ability to cache information. For instance, it is unnecessary and horribly redundant for a disk DSR to be shuttled across the connection every time the CPU executes it. Instead, why not load the entire DSR into the console side and feed it back locally when requested? Then the only information which needs to be sent down the pipe is drive commands and read/write data. Even if I/O timing to the disk controller is sensitive, I believe the ad-hoc compression of the interconnect by eliminating and synthesizing control lines could overcome timing differences.

 

Using a proprietary media layer to accomplish this has advantages and disadvantages over Ethernet. A big advantage is that we have full control in the communications method, including speed and protocol and packet overhead, as well as the small payload dilemma. An advantage of using Ethernet and IP is we have an established standard to build upon and doing so would make it possible to have multiple devices in a given network, easily operating in a one-to-one, one-to-many configuration. With a little work it might be possible to devise an arbitration system to allow a many-to-one or many-to-many configuration. A disadvantage to the proprietary media layer is the work required to implement such an animal. Some disadvantages to Ethernet and IP is packet and protocol overhead and cheap consumer equipment.

 

I have given some though to whether the protocol of choice should be UDP or TCP. Initially I thought UDP because of its simple nature and that in a local environment we should not experience packet loss, and it would address the small payload dilemma to some degree. But I have given more thought to TCP as it has built-in integrity checking and a connection can be made once and left open essentially forever, and re-establishing a lost connection should be fairly transparent to both ends. I also like the option of making them UPnP compliant.

 

* Audio could be sent down the pipe as out-of-band UDP. Though a quick read on AMR indicates that encoding is heavily licensed. Might need more research as I have on-hand at least three different free encoders capable of AMR output.

 

And perhaps one day if home Internet access reaches a reasonable reliability and speed, we can use a PEB across a VPN

 

AND! I just though of a couple more crazy ideas. There is nothing to stop us from using a proprietary protocol over Ethernet and IP: I used Scapy to put together a TCP-like protocol which might be perfect for sending words at a-time with integrity checking (more for ensuring sequencing and re-transmission.) And, say for a moment that Ethernet simply will not work: there are numerous other media layers we could use which would have hardware drivers available, already. Fiber, for instance, is not all that expensive. We could also find some esoteric media for embedded implementation.

[matthew180]

Here is the thing about the synchronous requirements: it does not have to be real-time on both sides.

If it is not real-time on both sides then you are going to crash the console in 1.2us. A simple read from the 32K RAM requires 16 address lines, 8 data lines, and a few control signals. That is almost the full complement of signals. If you design an intelligent system with cashing and such, then why have a PEB at all? You defeat your own purpose. Also, what you describe would be very complex. Knowledge about what is going on inside a computer based on the bus signals and data sniffing would require an expert system that would take a very long time to write.

[Willsy]

I think it would be simpler to design a single board that sits on the side of the console and replaces the PEB completely. With today's RAM and programmable logic densities I would imagine it would be relatively easy to provide a single board the size of CF7 that could act as SD card storage, serial I/O, parallel I/O, 32K RAM, SAMS expansion RAM, RAM disk, speech synth, and IDE controller, all on a single board. Actual development of it is another matter entirely of course, but I think it could all fit on a single board, rendering the PEB obsolete. I like the PEB, but they take up an awful space, and a fully populated PEB is a fairly major power hog!