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

[mr_gw454]

On 1/5/2020 at 2:34 PM, arcadeshopper said:

This update takes a while. Be patient

Sent from my LM-G820 using Tapatalk
 

Hi Greg -- thanks for that heads up.  If you didn't mention it, I would have thought something was hung.  Upgrade worked perfectly.

 

Thanks, Matt!

 

[+9640News]

12 minutes ago, mr_gw454 said:

Hi Greg -- thanks for that heads up.  If you didn't mention it, I would have thought something was hung.  Upgrade worked perfectly.

 

Thanks, Matt!

 

 

When things print, also keep in mind it may take some time before the PI releases the TIPI so you have access to your program again.  I've gotten so used to things spooling with Windows computers, I forgot the speed of the TI was slower.

 

Now, I have no timing tests to confirm, but I would anticipate the faster the Raspberry PI, the faster the PDF is generated.  It appears the final rendering of the PDF is when the PI releases the TIPI returning to the program, at least on my Geneve in GPL/Rompage mode.

 

A 13 page source file took something like 3 to 4 minutes to render so don't think things have locked up, especially on bigger print jobs.  Nothing is seen in the PDF folder until everything is done, i.e., no temporary files are present from my observation.

 

Beery

[+arcadeshopper]

 
When things print, also keep in mind it may take some time before the PI releases the TIPI so you have access to your program again.  I've gotten so used to things spooling with Windows computers, I forgot the speed of the TI was slower.
 
Now, I have no timing tests to confirm, but I would anticipate the faster the Raspberry PI, the faster the PDF is generated.  It appears the final rendering of the PDF is when the PI releases the TIPI returning to the program, at least on my Geneve in GPL/Rompage mode.
 
A 13 page source file took something like 3 to 4 minutes to render so don't think things have locked up, especially on bigger print jobs.  Nothing is seen in the PDF folder until everything is done, i.e., no temporary files are present from my observation.
 
Beery

Yes the time it takes to print on the TI is the same as it was with a real printer

Sent from my LM-G820 using Tapatalk

[Omega-TI]

10 minutes ago, arcadeshopper said:

Yes the time it takes to print on the TI is the same as it was with a real printer

Back in the day the Triple Tech Card had a 64K printer buffer that sped things up a little, you could be printing and working in another program.  I found it kind of useful for things that required multiple copies.  I doubt emulating that would have any practical use or speed gain this case.

[+jedimatt42]

2 hours ago, BeeryMiller said:

Matt,

 

The server socket API idea looks pretty good for your proposal.  I believe the concept would work to turn a TI into a BBS with a TIPI.  I also see the potential someone could develop a TI based web server (not me though) from what you have proposed.

 

What I wonder is a situation where/how two or more inbound connections to the server side of things for the TI are managed or maybe just needs to be limited on the TI system by the user.  Here is where my thoughts are going.  For a BBS, all the software out there at present is a single connection.  There is no code for two simultaneous callers for existing BBS's.  Modifying the RS232 code and switching it over to a single PI socket would be the simplest.  Should a second individual try to initiate a connection, I think it would be the "bind" would not be accepted if I understand how things work if a second connection was made and not processed on the TI/TIPI.  This is sorta what we see now with WIFI modems to a BBS like Heatwave.  If this is how things would respond, then all is well.  If not, I do not know if there is any benefit to having a command that would limit the PI to a user set number of inbound connections.  

 

Beery

 

 

 

 

server sockets have a queue attached to them.  clients that have not been accepted just wait in the queue.  The queue is limited and if it is full, new clients arriving in queue are rejected. 

 

So to have code that only serves one session at a time... where the 'caller' has to hang up before another caller can be handled....  

 

Here is an example of how you'd use it:

 

  bind

CALLLOOP:
  caller = accept
  if exit bbs goto QUIT
  if not caller goto CALLLOOP

SESSIONLOOP:
  write
  read
  if goodbye goto GOODBYE
  goto SESSIONLOOP

GOODBYE:
  close caller
  goto CALLLOOP

QUIT:
  unbind

 

A multi-line BBS would be possible as shown below, but as shown above is not necessary to handle:

 

  bind

CHECKCALLERS:
  caller = accept
  if exit bbs goto QUIT
  if caller then callers.add(caller)

  foreach caller in callers:
    write
    read
    if goodbye goto GOODBYE
  goto CHECKCALLERS

GOODBYE:
  close caller
  callers.remove(caller)
  goto CHECKCALLERS

QUIT:
  unbind

 

 

-M@

 

[+jedimatt42]

Regarding printing time (to PDF), the time it takes is radically different than with a real printer.

 

First, everything is spooled to a file, this is as fast or slow as it would have been with a print buffer back in the day.

 

Then, after the spool is completed, not concurrently, the printing to the converter happens. This isn't fast, but is a lot faster than a dot-matrix. 

 

So in practice, for a full page of text, the end result is faster. For a few lines of text, it will be slower.

 

For graphics, it is always slower. The 4A software that I've tried feeds data out so slowly, that an old printer could typically keep up. So now we have that time plus the conversion time. 

 

So, in the end, it is different, just different.

 

-M@

[+arcadeshopper]

11 minutes ago, jedimatt42 said:

Regarding printing time (to PDF), the time it takes is radically different than with a real printer.

 

First, everything is spooled to a file, this is as fast or slow as it would have been with a print buffer back in the day.

 

Then, after the spool is completed, not concurrently, the printing to the converter happens. This isn't fast, but is a lot faster than a dot-matrix. 

 

So in practice, for a full page of text, the end result is faster. For a few lines of text, it will be slower.

 

For graphics, it is always slower. The 4A software that I've tried feeds data out so slowly, that an old printer could typically keep up. So now we have that time plus the conversion time. 

 

So, in the end, it is different, just different.

 

-M@

[+InsaneMultitasker]

Like mame's floppy simulates drive seek noises, add a "feature" to play a wav/mp3 sound file of a dot matrix printer on the pi while printing is happening.    (I'll go run and hide now).

[+9640News]

21 minutes ago, InsaneMultitasker said:

Like mame's floppy simulates drive seek noises, add a "feature" to play a wav/mp3 sound file of a dot matrix printer on the pi while printing is happening.    (I'll go run and hide now).

I have a laser printer, so may the sound o fa Jedi sword...…...

[Omega-TI]

14 minutes ago, InsaneMultitasker said:

...add a "feature" to play a wav/mp3 sound file of a dot matrix printer on the pi while printing is happening.    (I'll go run and hide now).

[+jedimatt42]

10 minutes ago, InsaneMultitasker said:

Like mame's floppy simulates drive seek noises, add a "feature" to play a wav/mp3 sound file of a dot matrix printer on the pi while printing is happening.    (I'll go run and hide now).

Yep, I read the first four words and my instinct was 3 4 letter words, then I glanced at who was sending it, and finished reading the friendly message. 

 

-M@

 

 

[+9640News]

I was thinking, there probably is the possibility of running multiple BBS's on a single system with just the revision of the RS232 to TIPI conversion.  However, that would only be possible on a Geneve where multitasking is possible without a major rewrite on any BBS software program.  One would have to run multiple copies of ABasic.  As time is on "slices", not sure how slow that response would be or if a caller would see the lag.  Technically, it is possible, though.

 

Beery

[+jedimatt42]

19 hours ago, wierd_w said:

Hey Matt, if I make a wrapper script for amidi that listens on a private extended range port, would you make a proper handler for it?

...

 

I'm confused, do you want a the TI to delegate to a command line tool for every midi message (will I do that? absolutely not, the outcome would be undesirable from what I've read)? or do you want it to send a TCP message to running midi service?  

 

If it is the latter, why not use the TCP features that already exist?

 

-M@

 

[wierd_w]

The latter;  Its a TCP message sent to the localhost on a port.

 

On the Pi, is a listening script that intercepts that message, interprets/unwraps it, then either interrogates the midi stack for its members/connections, hangs up the midi devices if they are stuck, or sends raw midi commands, as indicated.

 

The idea is standardization.  The amidi commandlet supports being fed a file, which means it can use a named pipe. A single instance running can handle an extended session with a device that way. 

 

It would be cleaner to, say, call ("TIPI.Midi.128.0") and feed it raw midi data, than it would be to call raw tcp.

[Omega-TI]

I made this tiny video about a year ago, after one run through it gets a tad irritating.

 

 

On another note, I've found my first program that will not load and run in TIPI or even the editing feature in Classic 99.

FORMSHOP is a dang picky program!  It has to be off floppy (real or HxC) to function.  

[+jedimatt42]

3 hours ago, wierd_w said:

The latter;  Its a TCP message sent to the localhost on a port.

 

On the Pi, is a listening script that intercepts that message, interprets/unwraps it, then either interrogates the midi stack for its members/connections, hangs up the midi devices if they are stuck, or sends raw midi commands, as indicated.

 

The idea is standardization.  The amidi commandlet supports being fed a file, which means it can use a named pipe. A single instance running can handle an extended session with a device that way. 

 

It would be cleaner to, say, call ("TIPI.Midi.128.0") and feed it raw midi data, than it would be to call raw tcp.

 

See, I know very little of how someone would program to midi... I have a PI setup with a Roland 32 emulator and Timidy, that I use to play sierra games on my Amiga.

 

What I learned setting that up is you send a MIDI message to a midi port, which is 'like' TCP, but not TCP... or is it? Can you telnet to it?  I don't actually care right now... My point is not knowing the domain makes it hard for me to define how you would program to it... Seems like that should be your job... but maybe you don't know the TI enough so we've got to meet in the middle...

 

If you want a TI DSR compatible interface I would think it looks something like this in BASIC, TIPI has an extensible model that allows easy addition of special file names and a python interface to them such that no TI assembly language / ROM update is required. These interact with Level 3 IO ( the open, close, read, write, save, load, status ) operations used universally in TI BASIC and any other language on the TI. So naively I would propose a couple special files:

 

PI.MIDI. - (in the form of a device name) to have control above the channel, such as introspection.

PI.MIDI.<midi-port>[.HEX] - connect to a midi port, and read or write data to it. .HEX option is just a suggestion, as a lot of other BASICs have PLAY commands that take a mini programming language instead of requiring CHR$(32)&CHR$(20) int to character string conversion. In our case, the language would be hex string like in CALL CHAR patterns, that is a standard MIDI message sequence.  Midi messages have well known sizes or delimeters in the case of SysEx, so we should be able to allow multiple messages per write or read. 

 

To list descriptions of available ports, the PI.MIDI. device could have a catalog like interface:

 

10 OPEN #1:"PI.MIDI."

20 INPUT #1:A$

30 PRINT A$

40 IF EOF(1) GOTO 60

50 GOTO 20

60 CLOSE #1

 

To write data to a channel:

 

10 OPEN #1:"PI.MIDI.128.0.HEX"

20 PRINT #1:"992340"

30 PRINT #1:"892300"

40 CLOSE #1

 

Maybe... 

 

Anyway, take a look at TcpFile.py  https://github.com/jedimatt42/tipi/blob/master/services/TcpFile.py  This represents the PI.TCP device, for Level 3 IO access to sockets.   Is copying this code structure and producing a MidiFile.py and submitting a PR in github, or even a .zip really outside everyone on this forums skill set?   You'd have to update SpecialFiles.py to register MidiFile.py  but that's it...  This was all meant to be super easily extensible, but I clearly missed the mark.

 

-M@

 

[+arcadeshopper]

25 minutes ago, jedimatt42 said:

 

See, I know very little of how someone would program to midi... I have a PI setup with a Roland 32 emulator and Timidy, that I use to play sierra games on my Amiga.

 

What I learned setting that up is you send a MIDI message to a midi port, which is 'like' TCP, but not TCP... or is it? Can you telnet to it?  I don't actually care right now... My point is not knowing the domain makes it hard for me to define how you would program to it... Seems like that should be your job... but maybe you don't know the TI enough so we've got to meet in the middle...

 

If you want a TI DSR compatible interface I would think it looks something like this in BASIC, TIPI has an extensible model that allows easy addition of special file names and a python interface to them such that no TI assembly language / ROM update is required. These interact with Level 3 IO ( the open, close, read, write, save, load, status ) operations used universally in TI BASIC and any other language on the TI. So naively I would propose a couple special files:

 

PI.MIDI. - (in the form of a device name) to have control above the channel, such as introspection.

PI.MIDI.<midi-port>[.HEX] - connect to a midi port, and read or write data to it. .HEX option is just a suggestion, as a lot of other BASICs have PLAY commands that take a mini programming language instead of requiring CHR$(32)&CHR$(20) int to character string conversion. In our case, the language would be hex string like in CALL CHAR patterns, that is a standard MIDI message sequence.  Midi messages have well known sizes or delimeters in the case of SysEx, so we should be able to allow multiple messages per write or read. 

 

To list descriptions of available ports, the PI.MIDI. device could have a catalog like interface:

 

10 OPEN #1:"PI.MIDI."

20 INPUT #1:A$

30 PRINT A$

40 IF EOF(1) GOTO 60

50 GOTO 20

60 CLOSE #1

 

To write data to a channel:

 

10 OPEN #1:"PI.MIDI.128.0.HEX"

20 PRINT #1:"992340"

30 PRINT #1:"892300"

40 CLOSE #1

 

Maybe... 

 

Anyway, take a look at TcpFile.py  https://github.com/jedimatt42/tipi/blob/master/services/TcpFile.py  This represents the PI.TCP device, for Level 3 IO access to sockets.   Is copying this code structure and producing a MidiFile.py and submitting a PR in github, or even a .zip really outside everyone on this forums skill set?   You'd have to update SpecialFiles.py to register MidiFile.py  but that's it...  This was all meant to be super easily extensible, but I clearly missed the mark.

 

-M@

 

 

yeah midi is basically serial comms so I'd think it would work pretty close to that

 

Greg

[Omega-TI]

A simplistic question from someone (me) who has never messed with anything MIDI before...

 

If this is implemented and I want to partake, will I...

 

A) ... have to buy a musical device to plug into one of the RPi's USB ports?  (If so, any suggestions for something cheap and simple?)

                                                   -- or --

B)... will it all be emulated in the Pi and only need to buy a set of amplified speakers?

 

<< RPi Audio/Composite Video Cable >>

[wierd_w]

In the example I made, the primitive would be closer to

 

PI.MIDI.<device#>.<Port#>

 

which then gets fed 2 values-- ([wrapperCommand],[message])

 

A calling program thus just needs to know what device to talk to (Timidity always grabs 128:0, 128:1, 128:2, and 128:3, so if you just want to assume timidity, just use 128:0 through 128:3 for your device and ports.)

 

The way midi works with the ID:port designation, is each device can communicate on its port, but only one way. EG, a port might be only input or only output.  Timidity has basically only inputs; it's not a keyboard, or other "meatspace" instrument, nor is it a sequencer.  You can think of it as an abstraction for a physical connection-- a port.

 

Some devices, like keyboards, will have ports that go in, (such as say, on a Roland synth-- So that you can plug a computer or external sequencer into it, and that sequencer can then write data to that port, and the keyboard will play the resulting sequence through its synthesis system) and some that go out (you press keys on the keyboard, and raw midi messages are generated, and sent to an external synth, such as an MT32, or to a recording sequencer.)

 

The basic functionality I want to be sure ends up in there is this--

 

1) Send one-off message to midi device at specified port (Invokes amidi without an input file, unwraps your single message and populates the amidi invocation with the message as an argument. amidi does its thing then terminates.)

2) Create long-duration session with a midi device at specified port (EG, create a named-pipe file in the /tmp folder, do all subsequent writes straight there with echo >> syntax, so that amidi just sends them to the device on a single invocation-- EG, amidi is trying to "play" the named pipe, and keeps running, trying to read the file. Plays messages as they arrive.)

3) Close long duration session with midi device at specified port (kill amidi, remove named pipe file)

4) Silence/reset midi device at port (write appropriate bytes as one-off messages to the specified devices and ports)

5) Query midi stack (Ignore device ID and port ID specified, return results of interpreted aplaymidi -o, which will list all currently available midi IDs and their port numbers, as a comma separated values string returned in the data variable for the function)

6) Collect data from device ID at port

7) Write data on established long-duration session to device at port (Unwrap message, and use echo >> to append to the end of the named pipe file. amidi then reads the "written" data, and does its thing)

 

And any other special operations I might need.  A whole byte is a lot to work with.

 

 

So, if you just wanted to play music through timidity in your program, you would just assume the device is 128, the port is 0, and then tell it to create a long-duration session, with midi messages to initialize the synthesizer (silence all voices, etc) then call again with the command set to "write on long-duration session", and just blast your midi data over it.

 

 

If you just use raw tcp handler, you have to also specify which remote host you are talking to, and what TCP port it is listening on. More complicated than it needs to be for somebody that just wants to play a little music.

 

@Omega--

 

A) No. Timidity++ is a software only based midi synthesizer that runs on linux. It is a device that can realistically be always expected to exist.  It supports loading soundfonts and other fun things. It's a very versatile synthesizer.  HOWEVER!! If you should say-- Own something like an MT32, or a Roland keyboard, or some other hardware synthesizer-- You can use one of these cables to attach it to the USB port on the PI, the Pi will recognize it as a midi device, and give it an ID.  Your software could then call THAT ID instead of 128, and you could make THAT device play your music for you.

 

B) The idea is to connect the Pi's audio leads to the TI's sound channel header on the sidecar, so that the audio comes out in your TV.

 

 

By structuring it the way I am initially proposing here, it would be possible to sequentially write to several connected devices with the same calling convention; You could have several instruments playing through timidity, be playing back some PCM samples you uploaded (using the one-off message mode) to an MT32 for sound effects, playing the harmony track on your Roland keyboard, etc--- just by specifying which device ID and port ID you are sending your data to.

 

It's simple, but you can do a whole hell of a lot with it.

Edited January 10, 2020 by wierd_w

[Omega-TI]

12 minutes ago, wierd_w said:

@Omega--

 

A) No. Timidity++ is a software only based midi synthesizer that runs on linux. It is a device that can realistically be always expected to exist.  It supports loading soundfonts and other fun things. It's a very versatile synthesizer.

 

B) The idea is to connect the Pi's audio leads to the TI's sound channel header on the sidecar, so that the audio comes out in your TV.

 

Sounds interesting, especially if it can all be done with an automatic update. 

 

I'm using a PEB TIPI, but am I safe to assume it's the same hookup method and easy to accomplish?

 

I can only imagine the next generation of games and ports if something like this came about.

 

One extra question:  Would a monitor for the Pi be a required option to fully use Timidity?

[+arcadeshopper]

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

Sent from my LM-G820 using Tapatalk

[wierd_w]

Timdity is a system daemon. it runs headless. No monitor needed.

 

 

(Speech needs sound rail passthrough wires)

Like people aren't already passing +5v with a passthru already...

[+arcadeshopper]

4 minutes ago, wierd_w said:

(Speech needs sound rail passthrough wires)

Like people aren't already passing +5v with a passthru already...

Yep but if you don't say it up front, you spend hours trying to figure out why sound isn't working later. 

[+9640News]

If there is any requirement to do soldering on the TIPI to access the TI sound channel on the sidecar (or PEBox), I think people making the modification will be few and far between.  I would think if it is possible, it would be better to have sound play out the PI.  Speakers are cheap at <$10.  To me, if someone is going to use MIDI with games for some kind of music, sound, etc. and you want people to see your work, the software would receive a wider audience of use if there were no hardware mods required on the TIPI.

 

Not sure if it would offload 9900 CPU processing time/power, but if the command line passed to the PI had the ability to specify a path to a file to play within the TI device mapping of the TIPI, the TI would not have to pump any data out to the PI other than the "play" command for a MIDI file.  That way, just send the "crash" or "die" sound file path and let the PI do its thing.  Or, if during a game scene, play some kind of sound track file and when the particular scene/level is completed, send a "halt" command.

Just my 2 cents.

[wierd_w]

IIRC, they are exposed on the jedi-matt connector.  You just need 3 female-female jumper wires, attached to appropriate spots on the connectors of the PI hat connector, and the Jedi-matt connector. Bob's your uncle.

 

You could always just plug speakers into the Pi's headphone jack instead of course. Your music would come out there, and the TI's chiptune would come out the TV.

 

 

You could already do what you are suggesting with Timidity++.  It supports soundfonts, and the Pi supports telnet.  Your program just sends an .sf2 file to the Pi into its /tmp folder, then modifies the Timidity .conf file, and restarts timidity.  That .sf2 file contains all your samples.  Then you just call it with an instrument and note syntax. BONUS-- you get pitch variablity and other fun stuff.

Edited January 10, 2020 by wierd_w