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

[+Ksarul]

The TI 128K memory expansion card does bank switch the memory spaces in the PEB, including the DSR space, allowing them to be used actively by programs (and the card is aware enough to ignore DSR calls to other cards to avoid conflicts). I have a number of bare boards for this one that I did a while back. Paul Urbanus graciously rebuilt the PAL code for me so that I could do a new layout of these and build some of them. This card replaces the 32K card in the PEB.

[TheMole]

The TI 128K memory expansion card does bank switch the memory spaces in the PEB, including the DSR space, allowing them to be used actively by programs (and the card is aware enough to ignore DSR calls to other cards to avoid conflicts). I have a number of bare boards for this one that I did a while back. Paul Urbanus graciously rebuilt the PAL code for me so that I could do a new layout of these and build some of them. This card replaces the 32K card in the PEB.

 

Cool, I did not know the 128k allowed paging in that way. I always just figured it allowed paging of memory in the 'normal' 32k expansion space. A sidecar version of this would be really cool though.

 

Do you have docs on the card's operation? A workalike with modern components seems like a good approach for a sidecar version of it.

[+Ksarul]

I've got the complete set of developmental docs on this one, along with one of the original prototype boards done by TI. I used that data to do a complete layout of a new board for the PEB, as close to the original as I could make it. It was one of the first layouts I did for the TI other than some work I did on the 64K Guidry boards to tighten up the design for Jon (I wanted to make sure they'd fit into the cartridge case with everything socketed, as the 16K boards wouldn't do that).

 

Here's the data from the design specification showing how the board is supposed to work, along with the necessary PAL equations/truth tables to get there.

 

 

128K Extended Memory Option Design Draft.pdf

[Asmusr]

Just rambling a bit, but it seems to me that small sidecar RAM expansion would be the perfect starting point for implementing a Raspberry PI interface (as discussed in this thread), especially if the RAM board had a standard pin header connector that you could use for connecting to the RPi using some standard cable.

 

 

Could such a connector also be used for connecting to a real PEB through a thinner, more flexible cable?

[+mizapf]

 

0000-1FFF = System ROM / Shadow RAM

2000-3FFF = Lower RAM expansion

4000-5FFF = DSR ROM / Shadow RAM

6000-7FFF = Cartridge ROM / Shadow RAM

8000-9FFF = Memory mapped devices, GROM, PAD RAM, ...

A000-FFFF = High RAM expansion (24k)

 

I suppose you do not intend to modify the console. You could do many more things with a soldering iron, but I would not recommend to change the circuitry in the console.

 

The ROMEN* line goes active as soon as the address bus shows the values 0000-1FFF. If you follow that line on the schematics you will see that it directly turns on the system ROMs. Accordingly, there is no way to prevent the ROMs from being turned on, and so you cannot use the 0000-1FFF area.

 

The area 2000-3FFF is no problem, since it is assumed to be the RAM expansion anyway.

 

The area 4000-5FFF has the problem that I mentioned above. This area is used by the peripheral cards, and it is assumed that the memory area is turned on by setting bit 0 of the CRU base address 10xx (see e.g. TI Intern, address 0AC0 (XML 19, GPL DSRLNK)). You can design a RAM expansion at that address. However, you may run into trouble when you want to call a DSR from there. You must first jump out of the 4000-5FFF area, deselect it, and then call the usual DSRLNK. If that area is still active when you turn on another cards you will get a data bus conflict.

 

The area 6000-7FFF is available, but only if you do not plug in a cartridge. The address bus at the cartridge port lacks the lines A0, A1, and A2. They are decoded into the line ROMG*. This line will turn on the ROMs on the cartridge port - no way to prevent that. Again, if there are data from a peripheral card: bus conflict.

 

The area 8000-9FFF is used for memory-mapped devices. The respective devices are turned on, depending on the address. There should not be any other data in that location. As far as I know you can shadow the GROM data (which makes it possible to override GROM0, 1, 2), but this is a feature that was definitely not planned by TI.

 

A000-FFFF is again assigned to memory expansion.

 

On the bottom line, there is no good location for RAM outside of 2000-3FFF and A000-FFFF. You can, of course, use a CRU area and define a selector for different banks so that you can put RAM banks into the 8K frames as desired.

 

Also, you can put RAM into 6000-7FFF, but I would recommend to do that only from the cartridge port. If you have it in the P-Box (think of the HSGPL and how it works), you must not have a cartridge inserted in the slot.

 

8000-9FFF is forbidden area anyway. And 0000-1FFF cannot be shadowed because the system ROMs automatically shows up.

[+mizapf]

The TI 128K memory expansion card does bank switch the memory spaces in the PEB, including the DSR space, allowing them to be used actively by programs (and the card is aware enough to ignore DSR calls to other cards to avoid conflicts). I have a number of bare boards for this one that I did a while back. Paul Urbanus graciously rebuilt the PAL code for me so that I could do a new layout of these and build some of them. This card replaces the 32K card in the PEB.

 

As far as I could see in the draft specification, the 4000-5FFF area is said to be ignored by the DSR search as long as there is no AA byte at the first address, but this is a different problem than the one I mentioned. Suppose that we turn on bank 3 by setting CRU 1C00 to 1. Now I place a BLWP @DSRLNK into location 4100. I would expect that the standard DSRLNK will now start turning on the cards at CRU 1000 ... 1F00. I suppose you would need a full CRU decoding on the 128K card to detect when a different address has been set so that it is automatically turned off in time before we get a conflict. Who's going to turn it on again?

[TheMole]

Thanks for the info Michael, looks like shadowing system ROM is a no-go then.

 

I still think there's merit in doing a memory expansion unit that shadows DSR and cart ROM spaces. Of course, the shadowed RAM should be disabled by default, and only enabled by software that is aware of it. For the DSR part, it would be useful for programs that don't use DSRLNK at all (you'd be writing software specifically for this type of memory expansion anyway in that case, so that's not a stretch). Same goes for shadowing the cart RAM, classic carts that bring their own ROM in that area wouldn't be able to use this of course, but they would still function since the shadow RAM would be disabled until software specifically written for it turns it on.

[TheMole]

I've got the complete set of developmental docs on this one, along with one of the original prototype boards done by TI. I used that data to do a complete layout of a new board for the PEB, as close to the original as I could make it. It was one of the first layouts I did for the TI other than some work I did on the 64K Guidry boards to tighten up the design for Jon (I wanted to make sure they'd fit into the cartridge case with everything socketed, as the 16K boards wouldn't do that).

 

Here's the data from the design specification showing how the board is supposed to work, along with the necessary PAL equations/truth tables to get there.

 

Thanks for the document, very usefull stuff. Shame it doesn't allow paging in cart RAM, but still...

Would you happen to have a schematic for the 128k cart?

[+Ksarul]

I've got the schematics and the JEDEC code for the two PALs used on the board, as well as a full layout (and about 20 of the bare boards).

[TheMole]

If you can share them, I wouldn't mind taking a look at the schematics. As I said before, I'm not a hardware guy but I'm interested in learning. This seems like a simple enough project to get started with, especially if I can learn from the TI schematics.

[wyerd]

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.

 

I found this @@@@@SUPER RARE@@@@@ NOS PEB expansion cable on eBay last weekend. It's only 18" long, but hopefully I'll be move the firehose foot somewhere out of the way once I've installed all the goodies in the PEB.

[atrax27407]

It's nor "super rare" - just order one from IEC.

[atrax27407]

You can find IEC at:

 

http://www.iec-usa.com/Browse05/MCOlderTI.html

[+Ksarul]

Amazingly enough, IEC still makes cables for the TI. Wyerd's cable is the harder-to-find variety that has the manufactured cable end on both ends--the ones they make now have to put the female connector on both ends with a set of finger boards inserted into one socket to allow it to connect to the PEB cable. It is definitely a good find--and I bought one of the ones that were available this week because they were the more robust type, as the one I have already has the finger boards and it works, but it is more sensitive to cable motion.

 

And Wyerd, 18" is about as much as you would ever want to try to extend the PEB cable--much more than that and you start running into data loss issues, with anything up to 18" being in the sweet spot for good signal strength.

[wyerd]

It's nor "super rare" - just order one from IEC.

 

I know - it was tongue in cheek, although I didn't know about IEC still being in business. That's good to know and thanks for the link.

[wyerd]

Amazingly enough, IEC still makes cables for the TI. Wyerd's cable is the harder-to-find variety that has the manufactured cable end on both ends--the ones they make now have to put the female connector on both ends with a set of finger boards inserted into one socket to allow it to connect to the PEB cable. It is definitely a good find--and I bought one of the ones that were available this week because they were the more robust type, as the one I have already has the finger boards and it works, but it is more sensitive to cable motion.

 

And Wyerd, 18" is about as much as you would ever want to try to extend the PEB cable--much more than that and you start running into data loss issues, with anything up to 18" being in the sweet spot for good signal strength.

 

I'll change the post to @@@@@SUPER HARD TO FIND@@@@@ :grin: