cc-40 / TI-74

[+dhe]

Supposedly the 99/4a was hampered because of it's display.

My question is what could you use the one line display offered up by the CC-40, and how would you use it?

dhe

[+Vorticon]

9 hours ago, dhe said:

Supposedly the 99/4a was hampered because of it's display.

My question is what could you use the one line display offered up by the CC-40, and how would you use it?

dhe

Here are a few examples  

 

[jrhodes]

A one line display?

Someone should program one-dimensional connect-four for it.

Description from boardgamegeek:

Quote

This is the traditional Connect Four, but played in just one dimension or line. Originally proposed by Angus Lavery in a Games and Puzzles magazine in 1994, the only known source as of now is an instructables article by "Kiteman"
The game consists of a line of 10 tokens in 2 colors that are arranged alternately. On her turn a player takes 3 tokens out of that line from any position and puts them back at any end of the line in the order they were taken. At least one token of the players color must be among these 3 tokens. The gap is closed by pushing the tokens back together. The goal of the game is, as in the original connect four, to form a line of 4 tokens of your color.

https://www.instructables.com/id/One-dimensional-Connect-Four/

Edited October 7, 2019 by jrhodes

[wierd_w]

Potentially, a more sophisticated display processor could be put on the cartridge port. (it exposes a raw address bus interface, which means additional RAM and a display processor chip could live there.)

Alternatively, a custom hex-bus connector to a multiline LCD display (same type as the builtin kind, just multiline. Say a matrix monochrome LCD?) should be doable. (It's a "highspeed serial" connection, so something designed to display data makes sense as an accessory. Especially since it was semi-intended for mobile businessmen. Something that could display more complex data without using the printer makes a lot of sense.)

 

But-- You can still use the one-line display to do an oldschool text adventure, you would just need to move the input cursor way to the end of the line, and be careful how long your output lines are.

 

EG-- Output something like this:

 

 

HELLO AND WELCOME TO ADVENTURE! WHAT IS YOUR NAME?        <input text appears here>

(new line)

HELLO $NAME, GIVE ME A MOMENT TO THINK OF A STORY...

(RNG story generator runs, new line appears)
YOU AWAKE IN A STRANGE PLACE. IT IS DARK.                            <Text input commands type way over here>

 

 

etc...

 

 

"Sideways ASCII hangman" is an option too.

 

EG, something like

|--O+=      _ _ _ _ _ _ _  ENTER GUESS <input appears here>

 

 

Edited October 7, 2019 by wierd_w

[+FarmerPotato]

20 hours ago, dhe said:

Supposedly the 99/4a was hampered because of it's display.

My question is what could you use the one line display offered up by the CC-40, and how would you use it?

dhe

I used the CC-40 to call BBSes whenever I was in another town. The Memo Processor cartridge telecom mode held a buffer (24x80 I recall) through which you could scroll. Since I was used to reading 80 column BBSes on a 40 column screen with paging, it was not a stretch. I used it to call local BBSes for a bit, including the library catalog. 

 

I can't remember what all I wrote on the CC-40 on long car trips. I know it was a lot of code, and I was sad when the batteries ran out.

 

I made one type of game where it allocated a 5x5x5 array (or whatever it was that would fit). As you explored each location, it filled with random things and 1-3 possible directions between locations. The one line reported your status after each move, until you escaped out an edge. There could be exits at level 4 but you would fall from level 5 and up.

Something like this:

[NSU] You find 5 gold. Total 12 gold
N
[SEU] You encounter a Wisp. [any key]
[SEU] You slay the Wisp. You find 3 gold. Total 15 gold.
E
You have escaped the cave.
You fall from a height of 30 meters. You die. [any key]
Play Again? (Y/N) \!-/ (spinning cursor)

 

The other thing I would do is program 1-line dungeon games where you adventured as pi π-> and monsters were ¥ for lack of more interesting chars. That pointy stick is your weapon. You ran toward the monster with arrow keys until you managed to run into it. Combat rolls were simple, and the odds were against you surviving two monsters or more.

 

Every time somebody brought their TI-74 onto the bus, I would write this game again.

 

[cbmeeks]

I bought a near-mint CC40 (never used) in box a few years ago.  It's such a beautiful little machine.  However, I don't have any peripherals for it and always wondered what I should do with it.  Typing in these BASIC programs might be fun.  But I wonder how I could save them?

 

 

[+Vorticon]

On 10/7/2019 at 6:29 PM, wierd_w said:

Potentially, a more sophisticated display processor could be put on the cartridge port. (it exposes a raw address bus interface, which means additional RAM and a display processor chip could live there.)

Alternatively, a custom hex-bus connector to a multiline LCD display (same type as the builtin kind, just multiline. Say a matrix monochrome LCD?) should be doable. (It's a "highspeed serial" connection, so something designed to display data makes sense as an accessory. Especially since it was semi-intended for mobile businessmen. Something that could display more complex data without using the printer makes a lot of sense.)

 

But-- You can still use the one-line display to do an oldschool text adventure, you would just need to move the input cursor way to the end of the line, and be careful how long your output lines are.

 

EG-- Output something like this:

 

 

HELLO AND WELCOME TO ADVENTURE! WHAT IS YOUR NAME?        <input text appears here>

(new line)

HELLO $NAME, GIVE ME A MOMENT TO THINK OF A STORY...

(RNG story generator runs, new line appears)
YOU AWAKE IN A STRANGE PLACE. IT IS DARK.                            <Text input commands type way over here>

 

 

etc...

 

 

"Sideways ASCII hangman" is an option too.

 

EG, something like

|--O+=      _ _ _ _ _ _ _  ENTER GUESS <input appears here>

 

 

There is one already. See post #2 above.

[+FarmerPotato]

Talking about a display peripheral for CC-40... The ExelVision extended the CC-40's architecture of TMS7000 with the TMS3556 videotex processor. It reminds me of a VT340 terminal, but also with bitmapped graphics in 8 colors or greyscale. I spent a pleasant afternoon learning all about that chip when humeur posted the ExelVision thread.

 

 

 

 

I found a thread indicating the TMS3556 appeared in the Roland S50 Sampler. http://www.vintagesynth.com/roland/s50.php
 

https://www.ebay.com/itm/ROLAND-S-50-Sampler-Keyboard-Original-Main-Mother-Board-Works-Great/183926272091?hash=item2ad2dc305b:g:ENsAAOSwZF5ctZe9

 

Despite my childhood hours spent with the CC-40 I have no desire to work on it.. unless someone were to perfect a HexBus mass storage device, in which case I might get back into HexBus in 2021! I looked for the HexBus buffer chips, but they seem to have vanished in 1983  without ever going into wider distribution.
 

 

[wierd_w]

55 minutes ago, FarmerPotato said:

Talking about a display peripheral for CC-40... The ExelVision extended the CC-40's architecture of TMS7000 with the TMS3556 videotex processor. It reminds me of a VT340 terminal, but also with bitmapped graphics in 8 colors or greyscale. I spent a pleasant afternoon learning all about that chip when humeur posted the ExelVision thread.

 

 

 

 

I found a thread indicating the TMS3556 appeared in the Roland S50 Sampler. http://www.vintagesynth.com/roland/s50.php
 

https://www.ebay.com/itm/ROLAND-S-50-Sampler-Keyboard-Original-Main-Mother-Board-Works-Great/183926272091?hash=item2ad2dc305b:g:ENsAAOSwZF5ctZe9

 

Despite my childhood hours spent with the CC-40 I have no desire to work on it.. unless someone were to perfect a HexBus mass storage device, in which case I might get back into HexBus in 2021! I looked for the HexBus buffer chips, but they seem to have vanished in 1983  without ever going into wider distribution.
 

 

 Neat.  I figured such a thing would have to have been made at some point.

 

Concerning a disk controller..  Bitbang'ed SDCard is probably doable. (You can talk to an SD card on 2 pins, if you can control them individually. From a cursory browsing of the pinout of the hexbus, it appears to be a parallel type interface, so driving two of the leads in the correct fashion seems doable in theory.)

 

OH YEAH-- A thought occurs to me!

 

There's a serial connection style floppy drive that was used with knitting machines. (Conveniently battery operated!) It's a little bit bizarre in that it only uses a single side of the diskette, and is pretty limited capacity wise-- But then again, the CC40 isn't exactly a supercomputer anyway.  It's basically the same drive as was used on Tandy 100 systems. Since it is a serial interface, something could possibly be done in the form-factor of a custom hex-bus cable. (An IC, --possibly a microcontroller of some kind-- that sets up the hex-bus for the CC40 and pretends to be a wafertape drive, then brokers all the transactions with the diskette drive-- could live in a little plastic package inline on the cable.) Capacity wise, it is probably similar to the wafertape drives, so emulation of one might be doable. (With the benefit of being more reliable than a tape, with faster seeks)  There is one currently available (but pricey) on ebay right now, but you would probably have to get it before one of the old knitting ladies does.

 

[humeur]

The Tms3556 was intended especially for videotext,  a module was present in some TV look the documentation. http://bitsavers.trailing-edge.com/components/ti/_dataBooks/TMS3556_Mar84.pdf

There was in France a magazine that had made a video card based on this video circuit

For HexBus circuit request on the forum some have to have some.

 

 

Jean Louis

[+dhe]

For a brief time, I had the development system for the cc-40. It was a Video Interface - I think it was composite out and gave a vt100 like typing experience.

 That coupled with the editor assembler module, and a hexbus drive (ti used those with all hexbus systems) made a solid e/a development platform for the cc-40.

 

  I believe these were given to a university in texas for their interns to develop all the modules for the cc-40. (Kind of like developing on your macbook air or your iphone! ? )

 

  O'well, maybe one day Michael Becker or Michael Bunyard will awake and say - you know I could make one super hexbus device with a Raspberry PI! ?

 

Maybe I should be looking a cross development. Is there a software emulator for the cc-40?

 

Thanks,

Dano

[+Ksarul]

I have a lot of Hexbus chips in my stock of interesting TI bits--at least 500 of them, as I found a source a few years ago that was selling them by the tube for a very reasonable price. The source had no idea what they were, and probably bought them as a speculative purchase at a surplus auction. I bought most of their stock (a few tubes went to other TI users between my purchases) over the course of a year or so as I wanted to make sure they didn't disappear. I posted a link to the source here between my first and final bulk purchase of the chips, but only two or three people actually bought any during that period (I believe Fabrice was one, as he needed some for his Hexbus Floppy project).

[+Vorticon]

11 minutes ago, Ksarul said:

I have a lot of Hexbus chips in my stock of interesting TI bits--at least 500 of them, as I found a source a few years ago that was selling them by the tube for a very reasonable price. The source had no idea what they were, and probably bought them as a speculative purchase at a surplus auction. I bought most of their stock (a few tubes went to other TI users between my purchases) over the course of a year or so as I wanted to make sure they didn't disappear. I posted a link to the source here between my first and final bulk purchase of the chips, but only two or three people actually bought any during that period (I believe Fabrice was one, as he needed some for his Hexbus Floppy project).

More than enough to cover currently active CC40 users. All we need is someone with the skills to use them to create a modern storage device for the CC40... 

[+mizapf]

3 hours ago, dhe said:

Maybe I should be looking a cross development. Is there a software emulator for the cc-40?

Yes, in MAME.

[wierd_w]

I am reading the hexbus specification document.

 

From what I am reading here, a computer on an LPT port could fake being all manner of devices.  Alternatively, an SBC with enough gpios (like a beaglebone or an RPi) could do the same. 

The HexBus communicates in 4 bit nibbles, with 2 additional signals to control bus activity (BAV and HSK). It uses a packet communication format that is dirt simple.  A genuine LPT port is basically 8 GPIOs, with some extras, which is more than adequate for this purpose. Emulating a storage device to be able to get and send data to/from a CC-40 over an LPT cable looks doable. 

 

Because it uses a packet communication system, and the kinds of operations that can be sent are abstractions for something a computer would be needed for (Literally, one of the command messages is "Open a file"), you would need either a robust microcontroller, or an SBC to effectively communicate on this thing (in a portable manner. Again, a PC with a real LPT port should also be adequate at the lowest speed mode). Thankfully the command set is very limited (255 operations + the null operation).  I think Python can handle RPi GPIOs sufficiently quickly to be able to make a hexbus communication library. (The specification says that the HSK signal can be held for as long as 20ms, and that the minimum In-Spec transfer speed is 3000 bit/sec. I think RPi GPIOs can go that fast, and if not, then the PWM pins could, you would need only 4 of them) 

 

The way the bus is designed, multiple devices can be attached to the bus at the same time.  The system differentiates them with an identifier value in the packet.  All messages are brokered by the master of the system; If a device wants/needs to get the system's attention, it pulls HSK low, which prompts the master to pull BAV low, then poll for devices it has registered as being allowed to call it in this fashion, by sending packets in a sequential manner addressed to each device it has registered.  There is also an option for the master to relinquish control of the bus, and give it to another device. Reading the list of device IDs and their role allocations, one set is for having multiple CC-40s connected to each other. This message is for the purpose of the slave CC-40s to give control to the bus master, so that they do not attempt to manage the bus.

 

Since all devices listen to the control message preamble of each packet sent by the master, (To see if it is addressed to them), then a device sitting on the bus (Say, something like a "TiPI for hexbus"...) could respond to multiple device IDs, and (To the CC-40) appear to be several distinct and separate devices on the bus. It could thus simultaneously be a disk controller, a display device, a serial port, and a printer -- for instance-- all at the same time.  Since no two devices ever communicate at the same time (since the shared bus's nature is ALWAYS master-initiated on all transactions), There's really no reason that this couldnt be done.

 

A raspberry pi could be the single device you ever need to connect to your CC-40, which would then provide service roles for basically anything the CC-40 was designed for.  (Including attaching a display (Device codes 30 through 33 are earmarked for color television display device and 40 through 43 are earmarked for black and white television display device.) -- the idea here is to use python and SDL to create an opengl rendering pipeline that produces output on the pi's hdmi lead, based on the command messages received-- and RAM based file devices (IDs 240 through 244 are reserved for "RAM file manager"); You would tell the pi to create a filesystem with zram or something, and then work with it using the command set.)  The real limitation would be the selection of DSRs baked into the CC-40.

 

 

If I had one of these things, I would start working on a Raspberry Pi software-based solution.  

 

For reference, the hexbus specification is here:

http://ftp.whtech.com/hexbus_cc40_ti74/Hex-Bus Specifications.pdf

 

 

Sadly, I don't have one of these little toys to play with (and really don't have an urge to buy one. My curiosity is sated just by reading this spec document.)

 

 

 

 

 

 

 

[+mizapf]

I already went through all that stuff and implemented it in MAME in the way I understood it. Maybe you can draw some more information for such a project.

 

https://github.com/mamedev/mame/tree/master/src/devices/bus/hexbus

[wierd_w]

Some digging gives me some benchmarking that helps confirm my hypothesis of using RPI gpio with python.

 

https://rpiai.com/raspberrypi/gpio/

 

The benchmark done suggests that the python libs are (at best) ~20x faster than the minimum required signalling speed of 3khz.  (close to 60khz max write on gpio pins with python)  That gives ample room to set some modes and introduce wait-states.  Reading is slower (some arguments I have read say 3x slower).  It may be necessary to implement a transistor based hold for the messages if the hexbus shoots them too quickly to test reliably. (I am thinking a set of logic gates that sets 2 flipflop arrays to all zeros before disabling themselves (logic gates) when BAV goes low, catches the first nibble than does a NAND against the stored value(s) to catch when it changes (when it drops the data pins it would go all 0s, which would trigger the switch before the next nibble arrives), switches out the flipflop array with another one to catch the next nibble, then present the whole word to the PI on the GPIO pins.  This would effectively double the time allowed in which to read the values being sent, and would hold the message bits sent until the next BAV cycle. The bus master holds BAV low while it is waiting for a message, if I am reading correctly. I could thus use BAV-LOW as a signal to sustain the captured message, then reset to all 0s when it goes back high.) I could implement those with some bog-standard transistor package ICs.)

 

Other than maybe needing that buffer, it looks like a python script on a Pi would be sufficient.

 

C would be much faster, possibly eliminating the need for the buffer circuit (if it is even needed in the first place), since reading and writing on the GPIOs is closer to 50mhz when done with compiled code-- Just that is less approachable for hacking new features on later. (If I WERE to undertake this, I would want to use some of the reserved ID space-- [TI is NOT going to release new peripherals in that space!]-- to implement 3 new device classes; PCM wave device, tone generator, and midi device.  This is because there are zero audio devices in the CC-40, but with the Pi attached, you would have a display device, disk device, and an IO device. Might as well have an audio device as well.  The lack of storage has produced a dearth of incumbent software, so such a solution would quickly become the de-facto standard for making these things do fun things, and giving the option for audio seems sensible. Using the Pi as the audio renderer makes sense; It would also be the enhanced display device, and would output over HDMI to a connected TV.  For PCM device, since sending samples all the time is very foolish due to the way the bus works, creating a "wave sample hold, play sample on demand" implementation seems appropriate (Think a software-based, stripped-down version of the SNES SCP. Hell, we could GIVE a software SCP if we really wanted; That would turn it from a PCM device into a sampler device, with pitch, sustain, reverb, and pals).  That way a program would first feed its samples into the PCM device into some playback banks, then it would just blurp out a message like "Play bank 1" when it wanted to make that sound. It would need commands to store a PCM sample, to play a sample, and to delete a sample. Tone generator and MIDI device are pretty straight forward. You just send message for either sinewave type, voice number, value, volume, and duration-- for sound generator-- or just forward a raw midi command word for the midi device.  There's apparently community desire to make these small computers do fun things, might as well give a full toolbox.)  It is this potential for easily hacking stuff on that makes python attractive.  It looks fast enough for function while being transparent enough for easy hacking.

 

 

[+dhe]

 mizapf - I've never seen it done in real life, but it seems like one should be able to plug a Hexbus floppy HX5102 in to a CC40. Does that work in mame?

Thanks,

Dan

 

[+mizapf]

10 minutes ago, dhe said:

mizapf - I've never seen it done in real life, but it seems like one should be able to plug a Hexbus floppy HX5102 in to a CC40. Does that work in mame?

It could work, it is intended to, but hap (the guy who wrote the cc40 emulation) currently only has it on the TODO list.

See https://github.com/mamedev/mame/blob/master/src/mame/drivers/cc40.cpp

 

As it seems, he implemented the NVRAM, so programs will remain in memory when shutting down the emulation.

[+acadiel]

You guys mean something like this?  They were prototyped, and went over Hexbus.  The Editor Assembler for the CC-40 can use it.  Michael Becker of SNUG actually rebuilt the prototype.  Someone, somewhere has the schematics (like the guy who sent me these pictures.)

 

[+Ksarul]

The only Hexbus peripheral I don't have in my set. . .

[+dhe]

Speaking of Michael Becker. He had a number of my items in the magic basement in for repair.  He stopped answering emails all together.

My last communication with him was - If you don't want to do the repair thing anymore, please let me know, I understand.

I'd ask only that you take all my stuff to a shipping shop. Let them package it all at my expense, I will call or write them and pay for the packaging and shipping for get my stuff back. (tried that by both email and snail mail) - never heard back. It was all very odd.

Thanks,

Dan

[+acadiel]

Speaking of Michael Becker. He had a number of my items in the magic basement in for repair.  He stopped answering emails all together.
My last communication with him was - If you don't want to do the repair thing anymore, please let me know, I understand.
I'd ask only that you take all my stuff to a shipping shop. Let them package it all at my expense, I will call or write them and pay for the packaging and shipping for get my stuff back. (tried that by both email and snail mail) - never heard back. It was all very odd.
Thanks,
Dan

If you are on Facebook, try bugging Berry H or another one of the European users in the TI’ers group. They might be able to help get it back.

[fabrice montupet]

On 10/11/2019 at 3:37 PM, Ksarul said:

I have a lot of Hexbus chips in my stock of interesting TI bits--at least 500 of them, as I found a source a few years ago that was selling them by the tube for a very reasonable price. The source had no idea what they were, and probably bought them as a speculative purchase at a surplus auction. I bought most of their stock (a few tubes went to other TI users between my purchases) over the course of a year or so as I wanted to make sure they didn't disappear. I posted a link to the source here between my first and final bulk purchase of the chips, but only two or three people actually bought any during that period (I believe Fabrice was one, as he needed some for his Hexbus Floppy project).

I confirm. I bought a lot a Hexbus chips for the Hexbus Floppy disk controller I made and for some others projects. Sadly, this fully working floppy controller is always in a prototype stage, I had never found enought time to finalize the PCB...  So, I made a decision, I would like to devote my free time for the computers I like the most.  In consequence,  I am thinking about to get rid of all the old computers other than the TI-99 computers, Exelvision computers and the Apple computers before 1986. They represent about 100 units and they are taking me so much time to keep them in a working condition.
I hope that we could find the schematics of this video controller for the CC40,  I would like so much to build one! However, I have one slight reservation concerning the performances of this controller, Hexbus is known to be a slow interface due to is 4-bit transmission .  That said, its a really cool stuff!

[+mizapf]

2 hours ago, fabrice montupet said:

However, I have one slight reservation concerning the performances of this controller, Hexbus is known to be a slow interface due to is 4-bit transmission.

 

Hexbus is, however, a lot faster than I expected first; for the floppy transfer on the 99/8 you do not notice a slowdown compared to the PEB cards. You have min 8µs per nibble (HSK period), i.e. 16 µs per byte, which makes (max) 62500 byte per second.