RetroBrew Computers Forum
Discussion forum for the RetroBrew Computers community.
Home » RBC Forums » General Discussion » General Instrument CTS256A-AL2 vs. Microchip CTS256AL2
CTS256 resurrection from old 70xx & SP-0256* too?! [message #10657 is a reply to message #10655] Thu, 04 April 2024 08:56 Go to previous messageGo to previous message
jayindallas is currently offline  jayindallas
Messages: 110
Registered: June 2021
Senior Member
1). "CTS" meant "CODE to SPEECH" per General Instruments documentation.
2). "SPO-250" and "SPO-256" was actually "SP-0250" and "SP-0256."
. . So "SPO" was "Speech Processor dash ZERO TWO FIVE ZERO" etc.

Re: TMS/PIC 70x1 as a CTS256 in Microprocessor Interface Mode

CTS256 Maintaining the SPO256 Timing:
As the CTS256: (1) is the same device thus same architecture/features as the 70x1, (2) is only acting as an in-stream data converter, and (3) the downstream SPO256 has a buffer on its input stream, its very likely to maintain adequate flow rate for the SPO256 in simple serial-in to serial-out interface configuration because the UART will handle the timing transfers.

Allophone (segments of speech/sound) duration timing for synthesizing human speech doesn't require much timing precision. We can understand human speech over a wide rate of enunciation speeds. So its generally not a "real-time" issue.

To most accurately perform like the CTS256, which is a good project goal, you'd have to be aware of 70x1 clock ranges in various device versions. I have not seen the deeper timing specs on the 70x1 architecture; my manual only gives it 5 or 6 printed pages in the appendix. The real factor to check, is the timing differential to access code/data externally. What I've read on the Microprocessor Interface Mode, suggests that the access speed of the internal ROM, is/was slower than most PROM/RAM chip access times. The examples pointed out that using cheaper/slower external memory chips might as well be designed in, as the access wouldn't be taking advantage of the faster access memory devices (BIG CLUE).

Serial-In to Serial-Out Interface:
For Serial-in To Serial-out, its less likely to impact pinouts due to the purpose of the CTS256. It simply reads an input stream and modifies it, then sends the new data to the output stream; as long as it can do the modifications slightly faster than the downstream needs it (with buffering), then the CTS256 is in real-time aspects, transparent; a finite automoton that maintains the stream rate. Its function in serial-in to serial out, therefore minimizes its external pinout requirements.

Other Stream Interfacing:
The possible problem would be the reassigned pin-functions when using Microprocessor Interface mode. When supporting various parallel interfaces upstream and/or downstream, there may be a need to change some of the code to workaround pins that are re-defined in Microprocessor Interface Mode. This needs to be confirmed for all supported CTS256 interface options.

Can the CTS256 Maintian Stream Flow Rate USING External Access to Memory?
It would be wise to use the external access time calculations for the 7{0,7,0C,7C}x{0,2} devices to calculate what performance changes may occur among these devices. In general, the CMOS speeds tend to use slower clock rates than the NMOS. So this will be step 1 when looking at the other possible substitute devices in Microprocessor Interface Mode. Most likely, the processor will still convert enough in-stream data to maintain some buffering.

Likely necessary code changes in the 7{0,7,0C,7C}x{0,2} would be due to CLOCK, TIMERS, UART, possibly INTERRUPTS and maybe pin assignments altered by the external pins repurposed to interfacing external memory. This would mostly be in initialization parts of the code. The conversion algorithm and buffer control code should be adequate within voice tolerance timing.

I'll start getting familiar with the GitHub CTS256 dissassembly code, over the next few weeks, and then begin looking for necessary code changes.

[Updated on: Thu, 02 May 2024 11:18]

Report message to a moderator

[Message index]
 
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Previous Topic: Dave Runkle's front panel for the SBC6120-RBC
Next Topic: Resurrecting EaZy80, a forgotten glue-less 22MHz Z80 SBC.

[ Syndicate this forum (XML) ] [ RSS ] [ PDF ]

Current Time: Fri Sep 26 20:01:33 PDT 2025

Total time taken to generate the page: 1.19552 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.9.
Copyright ©2001-2018 FUDforum Bulletin Board Software