Technical Inquiry - (Wireless P-Box?) or wherever the conversation takes us

[Omega-TI]

Okay, I dunno about you guys, but that bloody "fire hose" keeps getting in my way and looks ugly!

It seems to me that with all this cheap WiFi technology out there, one of the hardware hackers could come up with a matched transceiver pair.

 

EXAMPLE(s)

1a) The first unit would plug into the side of the TI and get it's power from the console itself.

1b) The second unit would plug into the PEB and get it's power from the PEB.

 

Now if 1b is too complicated, and alternate could be a box that plugs onto the fire hose and gets its power from a wall transformer. It would not be the best solution, but you could at least hide the damn thing.

 

I believer the current technology out there is faster than what the TI buss speed is...

Would anyone else be interested in giving the fire hose "the boot"?

[Tursi]

It wouldn't be trivial, to be 100% compatible you need to take nearly all the signals on the connector, serialize them, transmit them, and deserialize them on the other side. In real time, on a bus with a 3MHz clock (which is also transmitted on that bus). Since it's probably overly difficult to get the high speed clock across the line, you'd probably generate a new clock a the PEB side and synchronize yourself.

 

I'd expect basic devices like memory and RS232 to work (which is admittedly most of the cards), but timing critical things like the disk controller will be difficult to get working. Any serialization scheme will add latency to the signals, which may cause missed windows.

[Iwantgames:)]

How about just creating a smaller cable that would be easier to hide?

[+OLD CS1]

This thought was tossed around in another thread a while back. I pondered the idea of PEB-over-Ethernet or PEB-over-IP. It would be possible, but as Tursi said the sampling would need to be very exact on both ends. ISTR we figured that this would be best over gigabit if raw samples were to be sent bi-drectionally. I have been playing with a few ideas on how to compress the sample stream, maybe synthesize some signals on each end.

[atrax27407]

I just built a "porch" that snugs uo to the console and covers the cable. My mouse and mousepad are on it. Works for me!

[+arcadeshopper]

I just built a "porch" that snugs uo to the console and covers the cable. My mouse and mousepad are on it. Works for me!

 

pictures?

[Gazoo]

How about something simpler. Redo the design of the board in the 'foot' to fit in a speech synthesizer case. There should be plenty of empty ones with the Rave adapters, Triple-techs, and the new speech adapter board being developed. Have a round cable that comes out the back of the speech synthesizer case. There could even be a way to connect the cable to the existing pbox interface card to save a few bucks. It should be a fairly inexpensive venture, even if one were to make a new interface card for the pbox to connect the round cable to. Hell, you could even put a socket on the pbox interface card to plug in a 32k chip to do away with the 32k card in the box.

 

Gazoo

[Iwantgames:)]

How about something simpler. Redo the design of the board in the 'foot' to fit in a speech synthesizer case. There should be plenty of empty ones with the Rave adapters, Triple-techs, and the new speech adapter board being developed. Have a round cable that comes out the back of the speech synthesizer case. There could even be a way to connect the cable to the existing pbox interface card to save a few bucks. It should be a fairly inexpensive venture, even if one were to make a new interface card for the pbox to connect the round cable to. Hell, you could even put a socket on the pbox interface card to plug in a 32k chip to do away with the 32k card in the box.

 

Gazoo

I like this idea

[Tursi]

Smaller cable should work fine.. I've been running my PEB off a 6 foot ribbon cable that lets me hide the firehose behind the desk. I just don't like the lack of shield. If we got a rounded shielded cable, it should be possible to install it into a synth as Gazoo suggests, and maybe route it out the BACK instead of the side.

 

As for alternates, I did a lot of design work years ago on an Ethernet or USB based replacement -- in my design the far end was a PC emulating the devices, but there's no reason that PC can't be an embedded Linux board in the real PEB. Ultimately I tuned two interworking designs...

 

The TI side would require hardware (FPGA) support to be fast enough. It would also contain a microcontroller, 64k of memory, and of course the Ethernet or USB interface. The PC end (in my emulation design) was only software.

 

So the first portion of my design was the memory interface. My idea was to use the local RAM as cache, and implement a cache controller. Toggling CRU paging bits would invalidate cache, of course, and I did some research and wrote out some flowcharts for writeback and the like. The idea being that the system would always be able to access any CPU memory over the interface. The cache lets it run in near realtime, but there are cases where the CPU will be halted to update cache from the far end. In the case of 32k memory expansion, it wouldn't be necessary to update to or from the far end (but I did have plans to implement code to simulate the AMS card and debugging interfaces from the PC).

 

The second part was device interface, and this was performed by the system copying the PAB directly to the remote end, and letting it return packets indicating the VDP data to write based on the PAB. For my emulation concept, this was the simplest and most flexible approach. For using a real PEB, this approach gets more complicated... you'd basically need either drivers for the cards you want, or a 9900 emulator in the PEB to run the DSR code. Nevertheless, both approaches would only work with specific software support, and I think real hardware is harder than emulation.

 

Anyway, just the thoughts I had put down... I've not started this device nor do I plan any longer to do so.

[atrax27407]

Here's a pic.

[Omega-TI]

Here's a pic.

 

WHERE

[+OLD CS1]

I am certainly not turning this into a project which will see the light of day any time soon. I was thinking along the same lines in terms of hardware. I have given brief look-overs to the schematics and timing diagrams and believe it will be possible to synthesize some of the timing signals. Essentially I will be converting the hardware bus into simple data packets, with the PEB end being a synchronized 9900 buss "emulator," if you will. That way what I am sending is bus state data on both ends. As an example, we know there are certain conditions under which data is valid, both sending and receiving, and certain lines are active during certain cycles. Instead of sending the exact state of those lines we can send a packetized state between the ends. The CRU will be fun. I do not thing we would need a 9900 emulation on the PEB, though that opens an interesting avenue. Even if there is latency between the ends, so long as the state is exactly replicated on either end, neither end will know the difference.

 

In any case, I would love to see a switched network of TI and PEB

[Iwantgames:)]

 

WHERE

Its invisible, switch to invisa-vision

[atrax27407]

Maybe this time.

[Iwantgames:)]

Maybe this time.

Nice

[Omega-TI]

Oooooh!

[+OLD CS1]

Too lazy to dig... what is Bob's upgrade in the ROM?

[atrax27407]

It is actually Tony Knerr's upgrade. He did it for me when I was having trouble with the Winfred Winkler GROM0 for my HSGPL card. It seems that Winfred's GROM0 did some strange things in the upper part of memory that precluded DISkASSEMBLER and some other programs from running. So, Tony put together his version of GROM0 for me based on his earlier version.

[gregallenwarner]

In the past, I've considered what it would take to revamp the firehose connection, and I briefly visited wireless before realizing it would be a headache to implement and make sure the timings were exactly correct. My current idea is using a pair of MAX10 FPGA's, one on either side, sampling and serializing over LVDS with a shared clock to keep them synchronized. At minimum, it would require two twisted pairs (for full duplex), plus one more twisted pair for the clock signal. An ethernet cable would provide all the wiring needed, with one twisted pair left over. It's not a trivial project though. Getting reliable timing would be tricky. It'll be a long while before anybody can expect me to tackle a project like this, as I've lots of stuff lined up to do right after the speech adapter card is finished.

[Omega-TI]

 

In the past, I've considered what it would take to revamp the firehose connection...

 

...as I've lots of stuff lined up to do right after the speech adapter card is finished.

 

Yeah, I guess that idea while neat in concept, is not practical or good in practice. Pity.

 

Hmmm, do any of the projects you have lined up have anything to do with the TI? If so, care to elaborate?

[gregallenwarner]

I don't wanna hijack this thread or anything, but when the time comes (and I feel ready to reveal them) I'll start a new thread.

[Tursi]

Even if there is latency between the ends, so long as the state is exactly replicated on either end, neither end will know the difference.

I had thought that the TI Disk Controller required fairly tight timing from the CPU to handle reads and writes, so I went to look that up, and it appears I was wrong. From looking at it, it seems like the only common function that might suffer due to latency would be reading the index pulse manually -- and that's usually only done to measure the speed of the drive. One-way data means the latency shouldn't even break that! (jitter will though, but... small price to pay, I think.)

 

I can't think of any other things that might break with latency, so it may be more feasible than I thought. (Would probably still want your RAM on the TI side of the interface though ).

 

An interesting side benefit is by abstracting all the signals into a packet format like that, you could receive them at a real PEB or an emulated one, and the TI shouldn't know the difference. That would be neat to see.

[Omega-TI]

An interesting side benefit is by abstracting all the signals into a packet format like that, you could receive them at a real PEB or an emulated one, and the TI shouldn't know the difference. That would be neat to see.

 

Cool, so if an interface standard existed, there could be MULTIPLE ways to go about this WiFi-Ti.

 

First the transceiver on the TI console would be the same for any setup, while a secondary card would be required to interface to an actual TI-PEB. On the PC side, everything would be done in software and that opens up some interesting possibilities, one of which might be an updated version of Classic99. Most of what is needed is already in Classic99, just the addition of the communications and interface modules would be necessary. This might be the easiest route to the finish line.

 

Of course there are other interesting future possibilities too... for instance an APP for any Android enabled WiFi cellphone or tablet device. I sure someone out there could make an APP to emulate 32K and a single disk drive. Hell, before too long, I'm sure it would have feature creep like everything else and grow an RS-232, SAMS and maybe other stuff too.

[+OLD CS1]

Wireless is not feasible for a PEB expansion. It is too unreliable in any environment, even a perfectly clean one. 802.11ac may offer some releif, but wireless is still subject to extreme variation, IME. My design shoots solely for gigabit and above. I believe Michael put the bit rate necessary for raw samples at nearly 900Mb/s (pullilng from memory of a long-ago conversation, I would have to look it up.) Even with assumptive states and synthesized signally we could only get that requirement down to, as best, 2/3.

[Tursi]

The thing is, if you don't run the system RAM across it, you don't need to run the bus at 100% speed. (You don't even with system RAM, but it would be more noticeable). Additional wait states don't appear that they should hurt anything, who cares if the DSR is 10-15% slower (for instance)? If you cached blocks of 256 bytes or larger locally (which was my original plan), I'd be willing to bet that the performance impact would not even be noticeable.

 

Your figure seems larger than my calculated value from my notes, though, where I was expecting that a full-speed implementation would need to manage 1MB/sec (ie: 10Mb/s should be pretty close) for data transfer. That's not attempting to relay clocks or precise pulse widths, though, just data transfer, and I didn't take CRU into account in my design (a gaping hole that you have now shown me ).