TI-99/4A - Hookups for a good time! ;)

[+FarmerPotato]

9 minutes ago, GDMike said:

But it's $59 I can't handle that.

 

I make do with this:

 

 

https://www.goldmine-elec-products.com/prodinfo.asp?number=G19387

 

 

 

and this

 

https://www.mouser.com/Enclosures/Enclosures-Boxes-Cases/_/N-5g3p?P=1y8g1du&Keyword=project+boxes&FS=True

 

[GDMike]

1 minute ago, Omega-TI said:

HA! Well, it's still cheaper than some people are selling those old Radio Shack P-Box kits for on Ebait.  That $59.00 is for the starter kit, you don't have to buy that kit with all the pieces.  In fact he also sells a smaller one more reminiscent of the original P-Box << HERE >> 

No no..I wouldn't want smaller.

Not looking!

Ok, have it your way. The great news here is that, @FarmerPotato will share a programming skill with it. How cool is that!

[Omega-TI]

My kit should arrive in a couple of weeks, so I'll be posting a video on it shortly thereafter, so I'll address the hole spacing and other stuff as well.

Edited January 22, 2021 by Omega-TI

[+FarmerPotato]

13 minutes ago, Omega-TI said:

The board itself lends itself quite nicely to point to point soldering of discrete components as well as switches, knobs etc., and has mounting hardware to support RPi's, Arduinos, protoboards, small LCD monitors and the like.

 

I like it a lot, the more I look at it. 

 

[GDMike]

12 minutes ago, FarmerPotato said:

I make do with this:

 

 

https://www.goldmine-elec-products.com/prodinfo.asp?number=G19387

 

 

 

and this

 

 

We are old.... bwhahaha...

I was telling my son,19 yo, yesterday how I used to rebuild alternators and just get the brushes and clean up the armateurs.

He was like, whatever...we buy rebuilt ones from mexico dad.

Edited January 22, 2021 by GDMike

[GDMike]

2 minutes ago, FarmerPotato said:

I like it a lot, the more I look at it. 

 

If they came with the monitor, arduino, pi, I'd like it more.. sorry. It's fine. Make it work!! Whohoo

[Omega-TI]

10 minutes ago, FarmerPotato said:

I like it a lot, the more I look at it. 

 

Agreed!  One of the draws for me is that the entire project can mounted on it at one time and easily moved for storage when not actively being used.  It's also good looking enough to keep a completed project on for display. 

[GDMike]

18 minutes ago, FarmerPotato said:

I like it a lot, the more I look at it. 

 

Apparently, your more organized than me. So good for you on that. You picked a good product, now let's get it going!

Your calling it the,

not a cucumber counter,

right? Ok. I'm done...

Edited January 22, 2021 by GDMike

[+FarmerPotato]

21 minutes ago, GDMike said:

Apparently, your more organized than me. So good for you on that. You picked a good product, now let's get it going!

Your calling it the,

not a cucumber counter,

right? Ok. I'm done...

Recently, I started doing all my builds on a bona-fide, honest-to-goodness, breadboard. It's from IKEA. That way, I can move it all when I need the desk space. There's my big perf board on the left, with wire wrap pins sticking up. It connects into the backplane. The CPU card is on the right. There is a tiny perfboard hanging on a wire harness. It's all solder point-to-point. The silver box is a power supply and analog/digital scope.

 

[GDMike]

If some other country change the thickness of the chip pins, sockets and test leads, and it becomes widely adapted, were screwed.  Lol

Edited January 22, 2021 by GDMike

[wierd_w]

Ok...

 

A cartridge that:

 

Exposes a GROM address, as a GRAM, that is in actuality an SPI array, running at a slow speed, with a latch buffer.

 

Each byte location on the GROM represents a different SPI device, and its control wire values. The cartridge contains some GPL handler code that can be either called by assembler programs or from the built in BASIC.

 

The latch circuits catch bursts from the much faster spi devices and hold them for later manipulation by the TI.

 

General Idea:  each GROM address stack position returns 1 byte to the TI, like expected. That byte should be treated like a bitfield, with bits set to "select high/low nibble", "transmit latched byte", and then SPI control wire statuses on the other two, followed by the 4bits of nibble. Each byte location on the GRAM is a distinct SPI device.

 

The cart contains TTL logic that translates serial SPI into parallel bytes and back again.

 

This would allow the TI to interface with a rather large number of devices, and do so in an out of the way manner.

 

It would be slow as hell, but sufficient for serial consoles, small LCD indicators, low bandwidth sensors, etc.

 

 

Edited January 22, 2021 by wierd_w

[Tursi]

4 minutes ago, wierd_w said:

Ok...

 

A cartridge that:

 

Exposes a GROM address, as a GRAM, that is in actuality an SPI array, running at a slow speed, with a latch buffer.

 

Each byte location on the GROM represents a different SPI device, and its control wire values. The cartridge contains some GPL handler code that can be either called by assembler programs or from the built in BASIC.

 

The latch circuits catch bursts from the much faster spi devices and hold them for later manipulation by the TI.

 

General Idea:  each GROM address stack position returns 1 byte to the TI, like expected. That byte should be treated like a bitfield, with bits set to "select high/low nibble", "transmit latched byte", and then SPI control wire statuses on the other two, followed by the 4bits of nibble. Each byte location on the GRAM is a distinct SPI device.

 

This would allow the TI to interface with a rather large number of devices, and do so in an out of the way manner.

 

It would be slow as hell, but sufficient for serial consoles, small LCD indicators, low bandwidth sensors, etc.

 

 

Lots of room to add that to the UberGROM : https://github.com/tursilion/ubergrom

[wierd_w]

But you would have to add a great big pin header to the ubergrom, and route it out of the shell!

 

Otherwise you wouldn't be able to connect the 2-wire interfaces for the SPI devices. 

 

Does the UberGrom's micro have that much GPIO free? A GROM has 256 positions in its address stack, so the device would be able to specify and then work with 256 connected devices.  That is a lot of GPIO to expose.

 

At the absolute minimum, you would need a breakout that expands out to 512 pins; that means it has 10pins of GPIO, with 8 bits of "Select logic" wires, then 2 bits of SPI pass-through in the ubergrom's micro. You would need an additional 2 bits to get "SPI bus status bits passthrough" as well, if you bother to implement it.

 

IDEALLY, there would be latch buffers for ALL 256 devices, all independent from each other, so that the SPI devices can communicate with the interface multiplexer, and have their messages caught, without having to have focus.  I do not think the uberGROM could do that.

 

(The cartridge would be rather large. Thankfully, the "coffee warmer" area is rather large, so a very long, and tall cart is doable.)

Edited January 22, 2021 by wierd_w

[Omega-TI]

10 hours ago, FarmerPotato said:

Here you go:

 

https://hackaday.com/2018/12/14/retrotechtacular-remembering-radio-shack-p-box-kits/

 

 

All the stuff was inside the box, then you opened it up and built on it. The soldering is hidden inside.

 

Did you know that kit has been modernized complete with links in the remake of the manual for parts sources like Mouser & DigiKey?

 

 

 

3 Transister SW Radio.pdf

[+FarmerPotato]

2 hours ago, Omega-TI said:

 

Did you know that kit has been modernized complete with links in the remake of the manual for parts sources like Mouser & DigiKey?

 

Oh awesome!

 

 

 

[AwkwardPotato]

12 hours ago, wierd_w said:

But you would have to add a great big pin header to the ubergrom, and route it out of the shell!

 

...

Implementing SPI does not have to be this complex. No 512-pin breakouts or latches or buffers are needed -- the sensors/displays/etc will not compete for control of the SPI bus, since the AVR will only ever read/write to one device at a time.

 

Theoretically, to implement this you'd connect the 3 SPI lines (SCK, MOSI, and MISO) from the UberGROM's AVR to each SPI device in parallel. Each device does NOT need its own SCK/MISO/MOSI. An individual Chip Select for each device can either come straight from the AVR, or from a demux if you run out of I/O. If I'm not mistaken, the UberGROM could use the READY line on the cartridge port to slow the TI down for slow SPI accesses.

 

With this method, you would need a total of 7 wires coming out of the cartridge for 4 SPI devices. If you wanted even fewer wires than that, you could use I2C instead of SPI, allowing access to up to 128 devices with only 2 wires.

[Omega-TI]

23 hours ago, Omega-TI said:

My kit should arrive in a couple of weeks, so I'll be posting a video on it shortly thereafter, so I'll address the hole spacing and other stuff as well.

 

Scratch that!  It's currently set to arrive on the 27th... MY DAY OFF!  Yessssssss, so the video might be done and posted by the 28th! ?

 

 

[+FarmerPotato]

@AwkwardPotato I’m pondering the idea of connecting CRU to SPI for max throughput. 

CRU solves two problems: clocking SCLK quickly and maintaining CE low across 8 or 16 bits. (I forget whether multi byte commands require CE low across all.)
 

The slow alternative is to bit bang a couple CRU bits with SBO and SBZ. This is how existing I2C implementations do it (See Stuart Conner’s I2C) 

 

in my scheme, it takes two ‘138s to decode a CRU base and 4 chip selects from the address bus. Say >1700 for base and >1740 for the second device etc. A15/CRUOUT goes to MOSI, CRUIN goes to MISO and WE/CRUCLK goes to SCK. 

 

QI consoles removed CRUIN from the cart port btw. 
 

The annoyance is SPI is MSBit first while CRU is LSBit first. With this scheme you read/write 8 or 16 bits at once. so I suggest a lookup table of 256 reversed byte values. 
 

the 4A doesn’t clock CRU reads, so this scheme would get you writes. Not a big problem: you use a 259 to catch MISO for eight bits. After all you have to write to SPI to get bits out. Then you read the 259 through a 251. This is all standard CRU register stuff found on many PBOX cards. and the chips are inexpensive. Double chips to make 16 bits. 
 

So, a 6 chip SPI interface, that writes 1-2 bytes at optimal speeds. It gets kind of bulky for a cartridge. 
 

something close to it is going into my SD card interface for Geneve2020.

 

[wierd_w]

12 hours ago, AwkwardPotato said:

Implementing SPI does not have to be this complex. No 512-pin breakouts or latches or buffers are needed -- the sensors/displays/etc will not compete for control of the SPI bus, since the AVR will only ever read/write to one device at a time.

 

Theoretically, to implement this you'd connect the 3 SPI lines (SCK, MOSI, and MISO) from the UberGROM's AVR to each SPI device in parallel. Each device does NOT need its own SCK/MISO/MOSI. An individual Chip Select for each device can either come straight from the AVR, or from a demux if you run out of I/O. If I'm not mistaken, the UberGROM could use the READY line on the cartridge port to slow the TI down for slow SPI accesses.

 

With this method, you would need a total of 7 wires coming out of the cartridge for 4 SPI devices. If you wanted even fewer wires than that, you could use I2C instead of SPI, allowing access to up to 128 devices with only 2 wires.

The intent with the large number of latches was more to catch the returns of many connected devices after switching focus.  The idea was to get the most bang out of the slow speed of the bus, by not requiring focus to catch the last written byte.  You can fire off a transaction then switch focus to the next device, and the buffer will catch the device's response, while you work with the next device on the chain.

 

The intent was more like with HomeAutomation's love for talking with sensors.  He could fire off a queue of "Give me the temperatures in all the rooms" outputs, the sensors all respond, then he can collect and handle the returns sequentially, by moving the focus over the latched returns.

 

Otherwise, he has to do a full transaction sequence with each sensor.

 

 

[Tursi]

On 1/22/2021 at 12:40 AM, wierd_w said:

But you would have to add a great big pin header to the ubergrom, and route it out of the shell!

 

Otherwise you wouldn't be able to connect the 2-wire interfaces for the SPI devices. 

 

Does the UberGrom's micro have that much GPIO free? A GROM has 256 positions in its address stack, so the device would be able to specify and then work with 256 connected devices.  That is a lot of GPIO to expose.

 

At the absolute minimum, you would need a breakout that expands out to 512 pins; that means it has 10pins of GPIO, with 8 bits of "Select logic" wires, then 2 bits of SPI pass-through in the ubergrom's micro. You would need an additional 2 bits to get "SPI bus status bits passthrough" as well, if you bother to implement it.

 

IDEALLY, there would be latch buffers for ALL 256 devices, all independent from each other, so that the SPI devices can communicate with the interface multiplexer, and have their messages caught, without having to have focus.  I do not think the uberGROM could do that.

 

(The cartridge would be rather large. Thankfully, the "coffee warmer" area is rather large, so a very long, and tall cart is doable.)

 

This is exactly what the UberGROM is for - not multicarts, but hardware interface. It already has support for the UART and many people have used that - doing SPI in place of the UART was an early plan that was dropped due to lack of interest.

 

It's got 4 dedicated GPIO for doing your selects, that could be decoded to 16. Most of the UberGROM devices use the entire "slot" of memory (6k) for device access so that you don't have to reset the GROM address every read or write - speeds things up a bit. 

 

256 devices? No, not with the 1284. But show me your 256 device plan before I lose any sleep over that. Most people who would be putting SPI into a TI cartridge are likely to have only one SPI device in mind for that cartridge.  (My thinking was an accelerometer, LCD screen, or SD card).

 

Edited January 23, 2021 by Tursi

[Tursi]

14 hours ago, AwkwardPotato said:

If I'm not mistaken, the UberGROM could use the READY line on the cartridge port to slow the TI down for slow SPI accesses.

Like all GROMs, the UberGROM already does this. You can't see it with RAM or ROM access, since that completes faster than the real TI, but flash and EEPROM writes are much slower, and so extend the cycle until they're done.

 

[Tursi]

1 hour ago, wierd_w said:

The intent with the large number of latches was more to catch the returns of many connected devices after switching focus.  The idea was to get the most bang out of the slow speed of the bus, by not requiring focus to catch the last written byte.  You can fire off a transaction then switch focus to the next device, and the buffer will catch the device's response, while you work with the next device on the chain.

You could design such a device, but nobody does SPI like this. I think you'd find it more complex to get reliable than it seems on the surface, and SPI is so simple that when people need parallelization, they just use another SPI bus.

 

[AwkwardPotato]

5 hours ago, wierd_w said:

Otherwise, he has to do a full transaction sequence with each sensor.

You have to do a full transaction with each sensor to properly implement SPI. Sensors will not report data back to the AVR on their own; the AVR is responsible for clocking the data out of the sensors. The time it would take to query a single sensor is so small that parallelization is impractical.

[Omega-TI]

On 1/21/2021 at 5:50 PM, GDMike said:

But it's $59 I can't handle that.

I think that's me though, I find everything expensive.

You know, I was pondering what you said there, and I realized it's not really that bad.  I'll use 1977 as an example, only because that was my peak P-Box building year...

 

 

But this is for the whole kit with reusable stuff like Arduino or RPi frames, mounting brackets, on a much improved and larger build platform.

 

Now say for a second you wanted to permanently use one of these tops for a project...

 

 

Now if you simply wanted to make an "official sized" recreation of a kit, you could order the small sized one in red...

 

 

I think that puts it into perspective a little bit better. 

[Omega-TI]

4 hours ago, Tursi said:

It's got 4 dedicated GPIO for doing your selects, that could be decoded to 16. Most of the UberGROM devices use the entire "slot" of memory (6k) for device access so that you don't have to reset the GROM address every read or write - speeds things up a bit. 

 

So the UberGROM really could easily track temperature, humidity and barometric levels (_{^{with supporting circuitry and components}}).  +1