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

[+OLD CS1]

I was thinking about how to implement a simple cache for PEB RAM, irrespective of the address space in use. The CRU might also be able to be cached.

[TheMole]

WiFi isn't necessary for me personally, but some form of PEB-over-UTP would be super. That would make the Rpi-as-a-PEB idea immediately feasible, and at the same time would provide a software extensible replacement for the nanoPEB. If someone is willing to build the hardware for this, I will commit to help out with the Linux software side of things.

[Omega-TI]

WiFi isn't necessary for me personally, but some form of PEB-over-UTP would be super. That would make the Rpi-as-a-PEB idea immediately feasible, and at the same time would provide a software extensible replacement for the nanoPEB. If someone is willing to build the hardware for this, I will commit to help out with the Linux software side of things.

 

Oh yeah, I can see this...

Tursi mentioned having the 32K out of the P-Box, this could utilize an empty speech box with the 32K combined with the interface unit and possibly even cached, like OLDCS1 mentioned. One would be able to use a much smaller Ethernet cable going out the back of speech box to a replacement for the FLEX card.

 

Once Greg releases his speech interface for the P-Box, there should be plenty of empty units available for this potential new PCB to take it's place. Also, this will open up an extra slot in the P-Box for another toy if the 32K can be removed.

 

So a design like this (on the TI-side) would cover two different expansion methods, the P-Box and the Rpi. I like it, and it would probably bring more people into the active group.

[Iwantgames:)]

I'd definitely go for this once the speech adapter is done I'd have a empty speech case then

[Tursi]

Probably not super useful, but these are the notes I saved off ages ago when I was thinking about this. There's not much besides discussion of cache procedures, and they aren't complete. But maybe it'll spark ideas.

 

TursisNetworkPebNotes.txt

[Omega-TI]

This is just too weird... but I'm tired and have been up for way too long, but... if this could be done, a guy could plug his TI in at a friends house across the country and access his TI's PEB at home.

[+OLD CS1]

Were I to implement a PEB-over-Ethernet or PEB-over-IP, I would not have any special hardware implemented (unless space and processing time are available, MAYBE a 32k in the TI side but switch-able.) Anyway. Another thought I just had would be to make such a device UPnP compatible as a utility device, that way you could also implement automated find-and-use within an emulator. The protocol is expected to be UDP. *sigh* This is more thought than I want to put in considering that I am not planning to build, at least not in the next 12 months.

[Omega-TI]

Were I to implement a PEB-over-Ethernet or PEB-over-IP, I would not have any special hardware implemented (unless space and processing time are available, MAYBE a 32k in the TI side but switch-able.) Anyway. Another thought I just had would be to make such a device UPnP compatible as a utility device, that way you could also implement automated find-and-use within an emulator. The protocol is expected to be UDP. *sigh* This is more thought than I want to put in considering that I am not planning to build, at least not in the next 12 months.

 

Honestly, I think people would be happy if the device just plugged directly into the PEB from the console itself. Making it IP compatible is a little overkill I agree. Now, that being said, I would like to see this device COMBINED with the new SD card based HD idea. It could still have a second connector on it, a USB to connect to the PC. You would have the drag and drop capability for shared files, and get rid of the fire hose at the same time, and of course with a user switched 32K on the TI-side of the device, you would kill three birds with one stone.

[Asmusr]

Just curious, how much circuitry besides a 32K [edit: or 64K?] static RAM chip is needed to make a sidecar 32K expansion?

[Omega-TI]

There are three schematic diagrams << HERE >> on the topic, although I thought I saw something elsewhere with more modern components that looked easier.

[+Ksarul]

Actually, this would be a modification of the 32K in the console thing. It shouldn't need much in the way of additional chips at all--buffers, some switches to set the CRU address, and a bit more. The hardest part would be making sure enough real estate remains clear to allow the bus to pass through. . .

[Asmusr]

There are three schematic diagrams << HERE >> on the topic, although I thought I saw something elsewhere with more modern components that looked easier.

 

I think the original 32K is using DRAM. AFAIK it would require fewer chips to use SRAM. I'm just thinking that a small, cheap 32K expansion would be useful in some cases - if such a thing was possible. Sorry for hijacking the thread, this has nothing to do with the wireless PEB.

[Willsy]

I think it could be done with two chips. A single SRAM and a chip for the address decoding. I'm not sure if the fact that the memory expansion had to respond to two memory regions complicates the address decoding but a single PAL/GAL could easily handle it.

[Omega-TI]

 

Sorry for hijacking the thread, this has nothing to do with the wireless PEB.

 

NO PROBLEM! I've changed the thread name! I'd like to see these ideas morph, develop and eventually come to fruition. In this case, I'd hate to see a thread name stifle good ideas. Keep on going, wherever it takes us.

[Asmusr]

I think it could be done with two chips. A single SRAM and a chip for the address decoding. I'm not sure if the fact that the memory expansion had to respond to two memory regions complicates the address decoding but a single PAL/GAL could easily handle it.

 

If you use a 64K SRAM (wasting half of it), would you still have to decode the address? I'm revealing my complete lack of hardware knowledge here, but I have no idea what is takes to distinguish RAM access from access to ROM or memory mapped devices.

[Stuart]

I think it could be done with two chips. A single SRAM and a chip for the address decoding. I'm not sure if the fact that the memory expansion had to respond to two memory regions complicates the address decoding but a single PAL/GAL could easily handle it.

Two chips should be possible. A 128kx8 RAM (the next 'size up' from 32k, and only a couple of quid) and a 74LS138 address decoder (to enable the RAM only when addressing the 8K blocks occupied by the 32K RAM expansion). Plus four diodes to OR together the CS signals plus four pull up resistors.

Edited November 28, 2014 by Stuart

[+OLD CS1]

 

If you use a 64K SRAM (wasting half of it), would you still have to decode the address? I'm revealing my complete lack of hardware knowledge here, but I have no idea what is takes to distinguish RAM access from access to ROM or memory mapped devices.

 

In theory, without look at the schematics, so long as the RAM honored the incoming select signals, you could overlay a 64k SRAM on top of the computer's busses. If the select signals are honored, it would only react when a read or write operation is within the >2000->3FFF and >A000->FFFF ranges, and the contents of the RAM would also reflect that assignment. That should leave the rest of the "wasted" RAM available of specific off-computer purposes* (timing aside.)

 

You will likely need some kind of logic to handle the conversion between busses, so you might as well go ahead and program in some logic to make the segregated address spaces in the TI universe contiguous in your expansion, giving a fully contiguous 32k for the TI and 32k for other purposes*. For example, with a little CRU magic and contiguous 32k space on the expansion, you can now create a two-bank bank-switched 32k expansion. With a little more CRU magic, you could make upper and lower areas independetly bank-switched.

 

If you are planning to just graft a 64k SRAM onto the bus, going back to my first bit above: provided there are select lines for both 32k address spaces, and provided your RAM expansion honors those, I am thinking it should work.

 

* assuming you will have some kind of secondary microcontroller on the expansion.

[Tursi]

My design for discrete logic inside the console uses two chips (and a couple of signals from inside the console, so it wouldn't work outside.. you could do it with one more 378 though.) You could also use programmable logic to replace the two discrete chips.

 

http://harmlesslion.com/text/TI%2032k%20Mod.pdf

[TheMole]

I've always wondered about how DSR memory actually works on the TI. Can one simply add new DSR's by making them available on the bus at 0x4000? If so, would a 64k SRAM chip that decodes in that space when selected (how? via CRU?) allow for adding new (software-only) DSRs to the system? I could imagine simple devices (like an RTC or a ramdisk) being emulated by a DSR in this way...

[+mizapf]

DSR memory space (4000-5fff) is supposed to be mapped into the address space by setting a CRU bit; on the TMS9900 the highest possible CRU address is 1ffe, while on the TMS9995 you can go up to fffe. The DSRLNK routines assume that the activation bit is at an address xx00. Accordingly, you can only have addresses 0800, 0900, 0a00, ... , 1f00 on the 9900 as different devices.

 

If you intend to provide a new DSR you should find a free CRU range (or make it configurable with a dip switch). If you position your device before the others (e.g. at 1000), you can shadow existing DSRs (like for DSK1).

 

It is essential that the device is only active when turned on by CRU. Otherwise there will be conflicts on the bus when another device maps into 4000-5fff.

 

The data structures for DSRs are pretty simple; have a look at the commented listings on Thierry's page.

Edited November 28, 2014 by mizapf

[+OLD CS1]

My design for discrete logic inside the console uses two chips (and a couple of signals from inside the console, so it wouldn't work outside.. you could do it with one more 378 though.) You could also use programmable logic to replace the two discrete chips.

 

http://harmlesslion.com/text/TI%2032k%20Mod.pdf

 

 

In the TI console, the lines corresponding to RAM addresses, specifically

>2000,>A000,>C000 and >E000, are not connected. The 32k card in the PEB uses it's

own

decode logic to decide when to respond. This lets us lift the signals for our own use. Of the

32k, the range >2000

-

>3FFF represents the “low” 8k of RAM, and >A000

-

>FFFF is the “high”

24k of RAM. So we need to respond to all of these signals.

 

Answers one of my questions.

[TheMole]

DSR memory space (4000-5fff) is supposed to be mapped into the address space by setting a CRU bit; on the TMS9900 the highest possible CRU address is 1ffe, while on the TMS9995 you can go up to fffe. The DSRLNK routines assume that the activation bit is at an address xx00. Accordingly, you can only have addresses 0800, 0900, 0a00, ... , 1f00 on the 9900 as different devices.

 

If you intend to provide a new DSR you should find a free CRU range (or make it configurable with a dip switch). If you position your device before the others (e.g. at 1000), you can shadow existing DSRs (like for DSK1).

 

It is essential that the device is only active when turned on by CRU. Otherwise there will be conflicts on the bus when another device maps into 4000-5fff.

 

The data structures for DSRs are pretty simple; have a look at the commented listings on Thierry's page.

 

So, given that the DSR ROM range is addressable over the peripheral bus, it must be fully decodable there. Would one be able to overlay 8k of RAM in the 0x4000-0x5fff area by simply reserving one CRU address for it, latching a select/enable bit high on CRUOUT and pulling it low on CRUIN on that address? I doubt it can be that simple, as I would assume someone would've come up with a 40k RAM expansion with a contiguous 16k area, and a contiguous 24k area by now already. Or even better, a 56k expansion that also masks the 8k cartridge ROM area and the system ROM area with RAM? We'd almost be in C64 territory with that...

 

As far as I know, only the 8k between 0x8000 and 0x9FFF are off-limits due to the memory mapped VDP, sound, GROM, etc... right?

[+mizapf]

Have a look at

 

www.mainbyte.com/ti99/man/ti99_tech.pdf

 

Page 24: Locate U504/U505 left from the center of the page. These are the decoders in the console. You see that ROMEN*(U504) is active (low) when the address bus is set to 0000-1FFF; Y1* would be for 2000-3FFF, but there is no decoding. MBE* is 4000-5FFF, ROMG* is 6000-7FFF, and MB4* is 8000-9FFF. MB4* also goes to U505 which decodes further to 84xx, 88xx, 8Cxx (typo in the schematics!), 90xx/94xx, and 98xx/9Cxx. That's all.

 

MBE* goes to the I/O port, but as I found (missing in that document), MBE* ends in the firehose plug, so you need to decode once more on the peripheral card.

 

The fact that there is no further decoding means that you could, in theory, build a card that answers on all addresses, but it will collide with other components in areas that are already in use. For that reason it suffices for the memory expansion to decode 2000-3FFF and A000-FFFF and react on those addresses, as no other card is supposed to be there.

 

BTW, the HFDC and the SAMS memory both use CRU-paged memory in the 4000-5FFF area. The HFDC has ROM from 4000-4FFF (with the controller ports mapped to the last addresses), and RAM from 5000-5FFF which is selected via some CRU bits (four frames 5000-53FF, 5400-57FF, 5800-5BFF, 5C00-5FFF, and each using five CRU bits to select one from 32 banks).

[+mizapf]

I doubt it can be that simple, as I would assume someone would've come up with a 40k RAM expansion with a contiguous 16k area, and a contiguous 24k area by now already. Or even better, a 56k expansion that also masks the 8k cartridge ROM area and the system ROM area with RAM? We'd almost be in C64 territory with that...

 

Do you mean that:

 

2000-5FFF 16K RAM

A000-FFFF 32K RAM

 

Problem: The standard DSRLNK routine is not designed to first turn off all devices. It seeks the specified device by turning on one device after another and traversing the list in the header of the DSR ROM, then turning it off. So you would first have to unselect that RAM area before you call DSRLNK, and hope you never forget that!

Edited November 29, 2014 by mizapf

[TheMole]

 

Do you mean that:

 

2000-5FFF 16K RAM

A000-FFFF 32K RAM

 

Problem: The standard DSRLNK routine is not designed to first turn off all devices. It seeks the specified device by turning on one device after another and traversing the list in the header of the DSR ROM, then turning it off. So you would first have to unselect that RAM area before you call DSRLNK, and hope you never forget that!

 

Well, no, I would see it as follows (in 8k chunks):

 

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)

 

With system ROM, DSR ROM and Cartridge ROM paged out for an environment that doesn't use anything from the system ROMs and GROMs (think along the lines of a Geos alike environment, or maybe an MDOS port for the TI). I'm not sure how you would bootstrap the system this way (in software), but I'm sure there's be a way.

 

With just the DSR ROM paged out, you could create apps that don't interact with hardware once loaded (e.g. arcade games). And with the cartridge ROM paged out, everyone with a simple EA cart could use it somewhat like a supercart, or you could simply create disk-based EA programs that can access 48k of RAM total.

 

Sounds very powerful to me, and I don't think such a 56k sidecar design would be overly hard to design... I'm going to read up on that doc you referenced in your other reply to see how feasible it would be.