Things we don't "need", but want for the TI.. hey, it's a hobby... right?

[Omega-TI]

Our little TI has come a long, long way in the past few years...

 

We now have cartridges that run stuff that was unheard of just a few years ago, and games that have already been developed for them.

Many of us have 1 meg memory cards that in the future may still bear fruit.

We have the F18A that already has already had some stuff developed for it.

We have TIPI that gives us the ability to store more data than quite frankly most of us will ever need plus a lot of extras.

 

So, in the search for something new and cool to expand our machines even further, does anyone have any ideas for something we can't live without?

[AwkwardPotato]

In my opinion it would be really cool to see an accelerator for the TI (I've toyed around with some ideas for one). Not necessary at all and I doubt any software would take advantage of it, but hey, why not?

[8_is_enuff]

I don't know enough about hardware to know if this is a dumb idea. But a video card for the p-box with modern output options would be sweet.

[Opry99er]

An automated cassette changer.... could have really used that this past week. 30 cassettes, 4 minutes of fax machine noises per side....

 

record, rewind, test, swap, record, rewind, test, swap, rinse and repeat 30 times.

 

Then, flip each tape, rewind, record, rewind, test, fast forward, slap in a case, swap--rewind record, rewind, test, fast forward, slap in a case, swap, rinse and repeat another 30 times.

 

 

We need an automated cassette changer...

[jrhodes]

Opry99er, you need a cassette duplicator.

[HOME AUTOMATION]

I used to rewire dual cassette auto-reverse decks so that they would record both sides of the tape in a single pass(mono),12.5min. per tape. No need to flip. Only the heads need be rewired. Turned-up the motor regulator a little bit.

[Omega-TI]

I don't know enough about hardware to know if this is a dumb idea. But a video card for the p-box with modern output options would be sweet.

 

I was thinking along the same lines, but for audio, along the line of a "Sound Blaster" type card. With all these new mega games on mega cartridges... why not spruce up the audio too?

I have doubts the TI could play modern MP3's, but some of the older formats could be doable, assuming a PC based converter was developed. With all the storage space available to us with the TIPI, almost anything is possible!

[HOME AUTOMATION]

I for one have always wanted more sound channels with better frequency resolution in sinewave output.

[JB]

I don't know enough about hardware to know if this is a dumb idea. But a video card for the p-box with modern output options would be sweet.

Been done in the past with the 9938. It is almost trivial. Gotta solder one new wire from the console to the video card, and that's the only thing that keeps it from being "plug&play".

[JamesD]

In my opinion it would be really cool to see an accelerator for the TI (I've toyed around with some ideas for one). Not necessary at all and I doubt any software would take advantage of it, but hey, why not?

The most likely way to successfully do this would be with an FPGA implementation of the 9900.

A microcoded & pipelined version could execute instructions in as few clock cycles as are required for buss accesses.

If it were to start up in compatibility mode (adds wait states for each instruction to match 9900 timing) then you'd have the best of both worlds.

Definitely something that would be interesting!

If it included a 16 bit RAM upgrade, that would be really cool too.

 

 

A version of TI BASIC that uses 16 bit RAM rather than video RAM would be interesting.

It might or might not be a big deal with the standard CPU, but with a faster CPU it could make quite a difference.

 

 

I for one have always wanted more sound channels with better frequency resolution in sinewave output.

There's always the Yamaha OPN and OPL sound chips.

[+FarmerPotato]

The most likely way to successfully do this would be with an FPGA implementation of the 9900.

A microcoded & pipelined version could execute instructions in as few clock cycles as are required for buss accesses.

If it were to start up in compatibility mode (adds wait states for each instruction to match 9900 timing) then you'd have the best of both worlds.

Definitely something that would be interesting!

If it included a 16 bit RAM upgrade, that would be really cool too.

 

 

A version of TI BASIC that uses 16 bit RAM rather than video RAM would be interesting.

It might or might not be a big deal with the standard CPU, but with a faster CPU it could make quite a difference.

 

 

There's always the Yamaha OPN and OPL sound chips.

 

The TMS9900 is efficient with bus cycles -- it's the speed of 8 bit cartridge ROM and GROM that need to be improved. We've been actively discussing it on the Development board.

 

For example, reading an instruction word from the XB ROM (or any 8 bit memory) consumes at least 6 clock cycles, which could be shortened to 1 with 16 bit wide chips on the 16 bit bus. Setting a GROM address (in preparation to read) takes 30 clock cycles (I was horrified when I measured 10 microseconds of... waiting...) (1 clock cycle = 1/3 microseconds) This too could be reduced to 1. I'm working right now with a cheap 10ns 512k SRAM for everything.

 

The memory modifications have been accomplished in various ways by different people, but not widely available like a board you could drop into the 4A.

 

Having fixed memory to get the full potential of the TMS9900, one could then think about replacing the CPU.

[8_is_enuff]

Been done in the past with the 9938. It is almost trivial. Gotta solder one new wire from the console to the video card, and that's the only thing that keeps it from being "plug&play".

 

I have a video card in an old PC that can instantly switch between outputs to composite, vga, or hdmi. I would love something like that. Likewise, a sound card was also mentioned here, and that sounds pretty cool.

 

I always wished the expansion slots in our beloved TI got as much love as PC expansion slots, or even Apple II slots.

Edited January 7, 2019 by 8_is_enuff

[Omega-TI]

 

I always wished the expansion slots in our beloved TI got as much love as PC expansion slots, or even Apple II slots.

 

Ditto!

[Tursi]

 

The TMS9900 is efficient with bus cycles -- it's the speed of 8 bit cartridge ROM and GROM that need to be improved. We've been actively discussing it on the Development board.

 

For example, reading an instruction word from the XB ROM (or any 8 bit memory) consumes at least 6 clock cycles, which could be shortened to 1 with 16 bit wide chips on the 16 bit bus. Setting a GROM address (in preparation to read) takes 30 clock cycles (I was horrified when I measured 10 microseconds of... waiting...) (1 clock cycle = 1/3 microseconds) This too could be reduced to 1. I'm working right now with a cheap 10ns 512k SRAM for everything.

 

The memory modifications have been accomplished in various ways by different people, but not widely available like a board you could drop into the 4A.

 

Having fixed memory to get the full potential of the TMS9900, one could then think about replacing the CPU.

 

I'm of the opposite mindset... the fastest opcode is 8 cycles. The average is 10 (or 12? We worked it out once.) Memory accesses need 2 cycles in fast memory (the multiplexer adds 4). But if we got the time to fetch and process down to 2 clocks instead of 8 clocks, that's a 400% speed boost without changing anything else in the system.

 

The CPU spends more time processing the average instruction than actually accessing memory. But if I were to deal with memory, I'd still want to change the CPU. Removing the read-before-write on word writes would save four wasted cycles due to the multiplexer circuit. This could be done externally if there was only a way to know whether it was a byte or a word access. (For that matter, true byte accesses would remove the need to multiplex them as well, making them faster than word accesses like one might expect.)

 

Not that you can't get a good speed boost out of the memory access, and it's easier to do, I just don't think it's the tallest post (if theory is the criteria ).

[+jmazzy]

Would be nice to see a backlit 'dumb' replacement keyboard that can be fairly easily dropped into any console. I did some digging tonight, and I noticed several people expressed an interest in this about year ago. Even non-backlit, I agree with what a few others said about just having a new spare available.

[+FarmerPotato]

 

I'm of the opposite mindset... the fastest opcode is 8 cycles. The average is 10 (or 12? We worked it out once.) Memory accesses need 2 cycles in fast memory (the multiplexer adds 4). But if we got the time to fetch and process down to 2 clocks instead of 8 clocks, that's a 400% speed boost without changing anything else in the system.

 

The CPU spends more time processing the average instruction than actually accessing memory. But if I were to deal with memory, I'd still want to change the CPU. Removing the read-before-write on word writes would save four wasted cycles due to the multiplexer circuit. This could be done externally if there was only a way to know whether it was a byte or a word access. (For that matter, true byte accesses would remove the need to multiplex them as well, making them faster than word accesses like one might expect.)

 

Not that you can't get a good speed boost out of the memory access, and it's easier to do, I just don't think it's the tallest post (if theory is the criteria ).

I grant you have a better grasp of instruction cycle counts. Also, I might be reluctant to tackle the cpu.

Your idea of eliminating wait states on read-before-write. I think this is solvable (in a new mux, CPLD) by caching the instruction during IAQ. For starters, just recognize MOVB (Dxxx). The mux could then skip the second DBIN cycle when it is in 8 bit space, then write one byte on the WE cycle.

Imagine a new replacement board for the mux that adds fast 16-bit devices (RAM, 16-bit cartridge ROM), and forwards 8-bit memory accesses as usual (skipping bogus wait states on read-before-write.)

Alas, I'm back to work on using the side port as-is.

Edited January 8, 2019 by FarmerPotato

[Tursi]

Your idea of eliminating wait states on read-before-write. I think this is solvable (in a new mux, CPLD) by caching the instruction during IAQ. For starters, just recognize MOVB (Dxxx). The mux could then skip the second DBIN cycle when it is in 8 bit space, then write one byte on the WE cycle.

 

Oh, that's smart. I completely forgot we can detect the instruction fetch...!

[+pixelpedant]

While a backlit keyboard (mentioned earlier in this thread) isn't of any particular interest to me, a drop in keyboard replacement with alternate key mechanisms certainly would be. It would likewise be interesting to discuss possible modifications to the keyboard layout which remain harmonious with TI 99/4A usage (i.e., are not just an attempt to cram a pseudo-IBM keyboard into a TI 99/4A) but offer advantages over the traditional design.

[+arcadeshopper]

While a backlit keyboard (mentioned earlier in this thread) isn't of any particular interest to me, a drop in keyboard replacement with alternate key mechanisms certainly would be. It would likewise be interesting to discuss possible modifications to the keyboard layout which remain harmonious with TI 99/4A usage (i.e., are not just an attempt to cram a pseudo-IBM keyboard into a TI 99/4A) but offer advantages over the traditional design.

 

the keycaps are the tricky part.. the rest is just a layout and switches its a simple matrix keyboard.. design a board and do it..

[+FarmerPotato]

While a backlit keyboard (mentioned earlier in this thread) isn't of any particular interest to me, a drop in keyboard replacement with alternate key mechanisms certainly would be. It would likewise be interesting to discuss possible modifications to the keyboard layout which remain harmonious with TI 99/4A usage (i.e., are not just an attempt to cram a pseudo-IBM keyboard into a TI 99/4A) but offer advantages over the traditional design.

 

There's a project there for someone to work on. There was a PCB made and keyswitch buy at our hackerspace, so I've seen it done, and if you google "make your own keyboard" there are lots of hits, but they cost a pretty penny (up to $250.)

 

I see questions:

 

1. where a few more keys could be fit in? One more column would help accommodate the modern keycaps like Slash-QuestionMark, Quote-DoubleQuote, and Minus-Underscore. Arrow keys sure would be nice. Splurging on real estate for a whole row of FCTN keys, well, crazy talk.

 

2. Modern keycaps wouldn't have the front key symbols like ? painted on.

 

3. Should the electrical interface emulate the signals at the original TI connector? or should the ROM be changed to a new KSCAN? Perhaps, even both could be accommodated somewhat. (programs that poll CRU only to check for FCTN-4 for instance.) . What if the keyboard has the Slash-QuestionMark. Pressing ? would imply the signals for FCTN and I.

[+arcadeshopper]

 

There's a project there for someone to work on. There was a PCB made and keyswitch buy at our hackerspace, so I've seen it done, and if you google "make your own keyboard" there are lots of hits, but they cost a pretty penny (up to $250.)

 

I see questions:

 

1. where a few more keys could be fit in? One more column would help accommodate the modern keycaps like Slash-QuestionMark, Quote-DoubleQuote, and Minus-Underscore. Arrow keys sure would be nice. Splurging on real estate for a whole row of FCTN keys, well, crazy talk.

 

2. Modern keycaps wouldn't have the front key symbols like ? painted on.

 

3. Should the electrical interface emulate the signals at the original TI connector? or should the ROM be changed to a new KSCAN? Perhaps, even both could be accommodated somewhat. (programs that poll CRU only to check for FCTN-4 for instance.) . What if the keyboard has the Slash-QuestionMark. Pressing ? would imply the signals for FCTN and I.

 

limited realestate is the kicker there's just no room for what you are asking, you can use matt's usb to ti adapter to convert a usb keyboard into the TI, but it's going to be a hell of a lot cheaper/easier to just wire switches to the matrix and be done .. and limit yourself to the 48key layout.. maybe 49 or 50 if you hack a hole in the case, most people won't

[Omega-TI]

@arcadeshopper - This is unrelated to the keyboard topic, but when it comes to "limited real estate" in the TI's case for future internal expansions, there is a solution (waiting to be 3D printed). If a replacement for the bottom of the TI's case could be printed, an extra inch would raise the console up a little, but not too drastically. The result would be a butt-ton of extra room for projects. Now one would also need to print up a 'boot' for the leg of the TI's "firehose" (if they are not already using the 16" extension.

[+adamantyr]

In my opinion it would be really cool to see an accelerator for the TI (I've toyed around with some ideas for one). Not necessary at all and I doubt any software would take advantage of it, but hey, why not?

I recall in the 90s there was an accelerator card in the works... Looking it up in MICROpendium it looks like it was being made by Don O'Neil. It was eventually dropped, presumably due to some hardware issues.

[+pixelpedant]

Another crazy notion: build a laptop style keyboard which (with the original keyboard removed of course) sits right on top of the portions of the case surrounding the original keyboard, and has consequent key height slightly less than the conventional keyboard (due to much lower key height on the replacement board).

 

Doesn't offer the same tactile advantages as good modern desktop keyboard mechanisms, but I'd still prefer a nice modern laptop-style keyboard to my hugely worn out and mushy TI 99/4A mechanisms.

 

But more importantly (from the point of view of the outcome being interesting), it offers a lot more real estate in which to screw around with the key layout and add keys (mainly, the prospect of a sixth row), without damaging the unit.

 

So like this sort of placement, but with TI-appropriate keys and key arrangement:

 

 

Downside would surely be that sourcing DIY desktop keyboard parts is easy, while repurposing or sourcing laptop mechanisms is likely to be more of a nuisance.

Edited January 9, 2019 by pixelpedant

[+arcadeshopper]