TIPI - TI-99/4A to Raspberry PI interface development

[Omega-TI]

25 minutes ago, arcadeshopper said:

Both of these won't pass audio though a speech synth without modification

Sent from my LM-G820 using Tapatalk
 

Luckily that is not an issue on my end as my speech is in the P-Box in a parallel arrangement as opposed to the sidecar serial configuration.

[+arcadeshopper]

you mean the GPIO connector? It doesn't provide any audio by default..  Bob needs some contractors.. 

[wierd_w]

The pi's audio is really just a PWM GPIO.

 

You can specify which pins are used in config.txt

 

https://www.raspberrypi.org/forums/viewtopic.php?t=215339

for details.

Edited January 10, 2020 by wierd_w

[+arcadeshopper]

Just now, wierd_w said:

The pi's audio is really just a PWM GPIO.

 

You can specify which pins are used in boot.txt

Have you tried this? How loud is it over the TI sound channel?

[wierd_w]

The Pi uses a simple highpass & Lowpass filter + amp circuit to improve quality, because it has to drive a speaker directly.

 

However, the TI's audio rail is sent to a TV, which has an amplifier.

 

See for instance, the circuit you need to add to a pi zero, because it lacks the headphone jack (and supporting circuit)

https://sudomod.com/forum/viewtopic.php?t=480

 

If it can work to drive speakers, it can drive the TV's audio.

[Omega-TI]

I think I'd prefer to plug in some << inexpensive black and silver >> amplified speakers like I already have.. assuming they would work okay with the RPi's 4 pole output.  Is a converter available?

[wierd_w]

Timidity sends audio to the default ALSA device.

 

If you don't jack with it, the RPi audio comes out two PWM pins that are not exposed on the GPIO header, and are instead routed to an integrated version of the circuit I just posted, which is connected to the headphone jack.

 

As far as the Pi is concerned, the config.txt entry just specifies which pins it wiggles to make audio.  Timidity does not care which output device is configured as the default alsa sink. It just produces PCM sound, and shits it to alsa.

[+arcadeshopper]

4 minutes ago, --- Ω --- said:

I think I'd prefer to plug in some << inexpensive black and silver >> amplified speakers like I already have.. assuming they would work okay with the RPi's 4 pole output.  Is a converter available?

the headphone jack works fine on a pi3/4 you just have to switch audio to it from the hdmi with a config change

 

[Omega-TI]

I guess in the end, I'll want to maintain 100% compatibility with whatever M@ releases and sends out in his updates.  It may get to a point where he does not want to overtax people's Pi's.

[Omega-TI]

Just now, arcadeshopper said:

the headphone jack works fine on a pi3/4 you just have to switch audio to it from the hdmi with a config change

 

Cool, if this comes about I'll have to learn how to do that... if it's simple.

[wierd_w]

I wouldn't recommend trying to play midi, run a BBS, print documents, and do some kind of serial file transfer at the same time-- no.

 

 

However, if you arent being crazy, it should work fine.

[+jedimatt42]

I'm not going to update the TIPI pcb design for audio in. If someone wants to white paper how to do it, that's fine. Just do it right. The pins are there. 

 

We also support the single core PI Zero W. So I like the idea of supporting USB midi cable adapters more than on board software synths. 

 

I'm still waiting to hear that the PDF thing runs out of memory on the Zero.

 

-M@

[+jedimatt42]

9 hours ago, --- Ω --- said:

Cool, if this comes about I'll have to learn how to do that... if it's simple.

No no no... we automate upgrade processes so it is taken care of that for you and everyone is working from the same configuration. 

 

-M@

[+jedimatt42]

TCP server example in TI XB, no assembly required LOL:

 

Server code in TI Basic:
 100 PRINT "TCP Server Test"
 110 LSOCK$="PI.TCP=*:9974"
 120 OPEN #1:LSOCK$&".BIND"
 130 INPUT #1:H
 140 IF H<>0 THEN 160
 150 GOTO 130
 160 PRINT "CONNECTION!"
 170 PRINT H
 180 OPEN #2:LSOCK$&"."&STR$(H)
 190 PRINT #2:"Hello I am a TI-99/4A"&CHR$(13)&CHR$(10)
 200 FOR I=1 TO 100 :: W=(I*2.2/2.2):: NEXT I
 210 CLOSE #2
 220 GOTO 130
 230 CLOSE #1

 

Line 230 is never reached. But after breaking, I run close #1 in immediate mode and the listening port is all cleaned up.

 

The Level 3 DSR for PI.TCP now delegates to the TiSocket messaging interface, so this tests the proposal I wrote earlier. 

 

This is not yet released. 

 

-M@

[Omega-TI]

For the record, I'm VERY HAPPY with the PI.PIO setup in TIPI and enjoy the way it works, it's easy and effective, so it may be ill advised to even post this idea, but you know me, I cannot resist thinking about "what if's", as in,  "What if we took this to it's 'ultimate conclusion'."

 

What if, the RPi had a 'toggle' in the CALL TIPI screen to select "automatic printing" of PDF files upon completion of their creation?  Yeah, it would be neat to be able to directly print to a modern printer like in the old days, but I realized is was fraught with problems...

 

First, everyone seems to have a different printer requiring different drivers.  

Second this would require more overhead for the Pi to contend with, which might be problematic for ZERO users.

Third, it's not simple and easy to install all this extra stuff.

Fourth, peoples systems would start to fork from the norm which makes it easy to facilitate automatic updates.

 

In the end, M@ did it perfectly in my book (from the perspective of a mere user)... simple and efficient.  

 

[+9640News]

Yeah, I agree Matt did an amazing job.

 

I have no idea what would be involved trying to find printer drivers for all the various printers that exist that would work on the PI.

 

Another solution which may work for Windows users assuming something like this exists, would be to have a program monitoring the PDFS folder for a PDF file, and when one showed up, automatically print the file.  Matt, not suggesting this is something you should write.  Just suggesting to the above user something may already exists if he has a Windows system.  Granted, not everyone will have a Windows system, but some of us do.

 

Beery

 

[+arcadeshopper]

Yeah, I agree Matt did an amazing job.
 
I have no idea what would be involved trying to find printer drivers for all the various printers that exist that would work on the PI.
 
Another solution which may work for Windows users assuming something like this exists, would be to have a program monitoring the PDFS folder for a PDF file, and when one showed up, automatically print the file.  Matt, not suggesting this is something you should write.  Just suggesting to the above user something may already exists if he has a Windows system.  Granted, not everyone will have a Windows system, but some of us do.
 
Beery
 

This is a pi solution not a TIPI solution.



Sent from my LM-G820 using Tapatalk

[+jedimatt42]

3 hours ago, --- Ω --- said:

For the record, I'm VERY HAPPY with the PI.PIO setup in TIPI and enjoy the way it works, it's easy and effective, so it may be ill advised to even post this idea, but you know me, I cannot resist thinking about "what if's", as in,  "What if we took this to it's 'ultimate conclusion'."

 

What if, the RPi had a 'toggle' in the CALL TIPI screen to select "automatic printing" of PDF files upon completion of their creation?  Yeah, it would be neat to be able to directly print to a modern printer like in the old days, but I realized is was fraught with problems...

 

First, everyone seems to have a different printer requiring different drivers.  

Second this would require more overhead for the Pi to contend with, which might be problematic for ZERO users.

Third, it's not simple and easy to install all this extra stuff.

Fourth, peoples systems would start to fork from the norm which makes it easy to facilitate automatic updates.

 

In the end, M@ did it perfectly in my book (from the perspective of a mere user)... simple and efficient.  

 

 

I kind of don't want to do that for a handful of reasons... 

 

1) I don't want to be the cause of death for so many trees... Sure, I want to go to paper for a few things... retro birthday card for my Father, etc... but for most things I just want to archive off to PDF for the best electronic-paper experience. 

2) The code comes from RWAP, a guy running a business where one of the products is a thing that does that. retroprinter.com. 

3) On Ubuntu, printers like my color canon laser are just auto-discovered. On raspbian, and worse, cause I give you raspbian lite, the basic ability to print to a line printer probably isn't there... CUPS is pretty standardized, and capable, but then you'll need a bunch of interface to determine printing modes... A ton of effort for almost negative value.  I bring you back to item 1... open the PDF, and ask, do I really need this one to go to paper?

 

-M@

 

[+jedimatt42]

13 hours ago, jedimatt42 said:

TCP server example in TI XB, no assembly required LOL:

 

Server code in TI Basic:
 100 PRINT "TCP Server Test"
 110 LSOCK$="PI.TCP=*:9974"
 120 OPEN #1:LSOCK$&".BIND"
 130 INPUT #1:H
 140 IF H<>0 THEN 160
 150 GOTO 130
 160 PRINT "CONNECTION!"
 170 PRINT H
 180 OPEN #2:LSOCK$&"."&STR$(H)
 190 PRINT #2:"Hello I am a TI-99/4A"&CHR$(13)&CHR$(10)
 200 FOR I=1 TO 100 :: W=(I*2.2/2.2):: NEXT I
 210 CLOSE #2
 220 GOTO 130
 230 CLOSE #1

 

Line 230 is never reached. But after breaking, I run close #1 in immediate mode and the listening port is all cleaned up.

 

The Level 3 DSR for PI.TCP now delegates to the TiSocket messaging interface, so this tests the proposal I wrote earlier. 

 

This is not yet released. 

 

-M@

 

This server socket feature is now released... see this post:  

 

 

-M@

 

[+9640News]

Going out to get it now Matt.  Thanks for the update!!!

 

Beery

[+9640News]

Matt,

I ran the Extended basic program as a test program, and was able to communicate with the server.

 

Will try to do the same thing now within Geneve MDOS assembly.

 

Just for the information for others...….It wasn't immediately obvious when I first setup my router for port forwarding.  If you have a firewall, you have to port forward to a specific device.  My case, the "tipi".  I opened a port at 9938.  Now, the extended basic program is listening on Raspberry port 9974 in Matt's example, so the Base Host Port is 9974 while the Global Port Range is 9938 to 9938 as I configured it in my Custom Services on my AT&T router.

 

If this helps anyone, good.  If not, disregard <grin>.

Beery

 

[+jedimatt42]

Regarding midi integration, using something like this library makes far more sense than the amidi cli: https://spotlightkid.github.io/python-rtmidi/usage.html

 

What are the use case goals? Not the laundry list of possibilities, but what is actually desired? 

 

Direct 4A controlled timing of midi messages?

Recording of events in 4A software?

Handing a sequence off to be dispatched to midi device in the background by the PI? a.k.a. A PLAY like language for BASIC

 

-M@

[+jedimatt42]

The more I think about it, it would be nice to have a CALL LINK library abstraction cause it's be faster than all the DSR overhead for generally small messages in the case of MIDI. 

 

I should learn how to do that so I can finish providing a mechatronics compatible API for mouse.

[+9640News]

Message has been deleted

 

Edited January 13, 2020 by BeeryMiller
Misunderstanding

[+9640News]

I have another question, and this is in regards to the client write command.

 

I had a case on some terminal software code that was sending a single byte out at a time. I was not getting the response back from a server I was expecting.  In my particular case, I was single byte writing out three bytes >1B, 91 (decimanl), 'D'.  This was an ANSI sequence for ANSI LEFT, I also had ANSI Right (change D to C), ANSI Left (Change D to A), ANSI Up (A), ANSI Down (B), ANSI PageDn (6), ANSI PageUp (5).

 

If I wrote the ANSI sequence out with three separate calls to send out the >1B, 91 (decimal), and then the third character, I did not get the proper movement of the cursor.  If I sent the characters out as a continuous string, I did.  Is there the possibility a nul character is being sent after a single byte or something else is going on I may not be aware?

 

As I did not write the BBS server code and don't know what is happening behind the scenes, I guess it could be possible the single byte writes may have a delay that ended up ignoring the individual characters, but not when they are pretty much sent in a faster loop.

 

I solved the issue on my end, however, if there is something going on that shouldn't be, I wanted to point it out.

Beery