Jump to content
jedimatt42

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

Recommended Posts

2 hours ago, jedimatt42 said:

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

 

[email protected]

 

Load soundfont needs to be available. Modern synth devices (including Timidity, The same file can be used to make timidity use less resources; see up at the top. This is why I dont consider timidity a deal breaker.) support sending entire packs of compressed PCM samples to the synthesizer for custom instruments. The standard format is Creative Lab's .SF2 format.  These can be tiny, at 512kb, and huuuuuge, at over 100mb, and anything between.  Loading soundfonts permits abuse of MIDI to play discrete sound effects as well as music. (that is essentially what a percussion instrument is.) MIDI can be a one-stop solution to many sound issues on the TI, if soundfont support is provided.

 

I was going to write a routine in the wrapper to load/unload soundfonts. The backend that sends midi messages to the specified device is immaterial, as long as one exists. rtmidi would service that need just fine, but needs python and the appropriate libraries installed.

 

Otherwise yes--

 

Send midi to a device

Get midi from a device

Load a soundfont

unload a soundfont

 

 

Edited by wierd_w

Share this post


Link to post
Share on other sites

Matt,

 

I've been continuing to read your notes on server sockets and I think I have cleared up a misunderstanding on my part.

 

I am summarizing some things from your initial release, and adding some additional comments from things previously I have learned. If I have misunderstood anything here, please correct me.

 

1. Client socket is not the same as server socket.

2. It is possible to open multiple client sockets with a range of 0 to 255.

3. It is possible to bind multiple server sockets with a server-byte range of 0 to 255.

4. It is possible to unbind a single server socket with a server-byte range of 0 to 255 and not unbind other multiple server sockets.

5. The accept server command returns a 0 if no incoming socket is connected on the server socket.

6. The accept server command returns 1 - 255 if an incoming socket is connected.

7. The accept server command will not return a client socket 0x00 as the range is only 1 to 255.

 

Hopefully, I got this right.  

 

Beery

 

 

  • Like 1

Share this post


Link to post
Share on other sites

Matt,

 

I've got code running at the assembly level that is Binding a socket and presumably functioning, as if I have not initiated the bind code, a Windows telnet client immediately returns versus if it is binding, it is waiting for a response from the Geneve server code.

 

My code is following your example of binding a socket at "*.9974      " using the 0x22 0x00 0x05 "*.9974" string.  Right now, I am presuming at the assembly level, I do not preface the string with PI.TCP as "PI.TCP=*.9974" as think the PI.TCP is for DSR calls unless I am mistaken for XB.

 

I then follow it up with an accept command of 0x22 0x00 0x07 string.  I poll the DSR code looking for a single byte from the routine at >4010.  If it is 0x00, then nothing has connected.  If non zero (single byte), I modify the handle-byte for a client socket command to match byte received from the accept command.

 

This is where I believe I am having my problem.  Looking at your extended basic code, do I need issue a client socket command for open before I write?  

 

I'm also trying to figure out in your XB program the purpose of line number 200.  Is this a timing loop?

 

Beery

 

 

Share this post


Link to post
Share on other sites
5 hours ago, jedimatt42 said:

It should be a colon not a period between the interface and port number.

 

[email protected]

I am at work today (Off on Saturday - Monday).  I think that was a typo on my part for the posting here, but I will confirm this evening just to make sure.

 

If it wouldn't be too much trouble, if you could post the source to a working TI-99/4A "C" version of the equivalent Extended Basic program, I can confirm I am following the same logic.  If it's too much trouble, no problem.

 

Beery

Share this post


Link to post
Share on other sites
7 hours ago, BeeryMiller said:

I am at work today (Off on Saturday - Monday).  I think that was a typo on my part for the posting here, but I will confirm this evening just to make sure.

 

If it wouldn't be too much trouble, if you could post the source to a working TI-99/4A "C" version of the equivalent Extended Basic program, I can confirm I am following the same logic.  If it's too much trouble, no problem.

 

Beery

 

You don't want equivalent C program.. You want a program that uses the messaging interface, vs. the DSR interface. 

 

You are correct that with the messaging interface you do not prepend the DSR device name to the `interface` : `port` string. 

 

There are byte-for-byte examples in the docs:  https://github.com/jedimatt42/tipi/wiki/Extension-TCP

 

[email protected]

 

Share this post


Link to post
Share on other sites
1 hour ago, jedimatt42 said:

 

You don't want equivalent C program.. You want a program that uses the messaging interface, vs. the DSR interface. 

 

You are correct that with the messaging interface you do not prepend the DSR device name to the `interface` : `port` string. 

 

There are byte-for-byte examples in the docs:  https://github.com/jedimatt42/tipi/wiki/Extension-TCP

 

[email protected]

 

Hmmm, you just said something I just remembered as it had been quite some time since I was last in my code.  I had copied your messaging system into my code as it seemed like there was some kind of issue (speed probably) last year when running the code on the Geneve with certain parts of the messaging system under MDOS mode.  Not sure where the issue was, but I may have may have left certain parts active in my code (read/write/open/close), while relying on the messaging system within the DSR code itself in other areas.  I will need to investigate, as I block copied a few sections to minimize typing yesterday and I may have interchanged on-chip DSR code utilization vs. copied in-Geneve memory code links.

 

I know my current bind/unbind/accept is doing a BL to code on the actual DSR for these three routines and I should have changed that to code running from the Geneve with the sendmsg and recvmsg routines I copied out of your DSR code.

 

Beery

 

 

  • Like 2

Share this post


Link to post
Share on other sites

Matt,

 

I reviewed my code last night, and I need to correct a statement I made earlier.  Turns out, I was indeed using all my own sendmsg and recvmsg routines all of my code.  I had the onboard DSR addresses in the code, but it was not executed as it was just a register  loaded with the address that was never executed.  I seemed to have forgotten to remove a few instructions in some earlier development efforts.

 

I'm in the process of debugging my "server" code.  I can bind, and the Accept command does see when a connection is attempting to be made.  I am still testing the socket to see which socket it is connecting too as my attempt to write a string out seems to be choking.

 

So, my question is this.  OK, the Accept on the server side of things tells me a socket returned as a single hex byte from 1 to 255.  Do I need to Open a Client side connection on that socket first before trying to write to the socket?  If I do, what would my open URL be with say Port 9978 and 0x01 socket?

 

The reason I am asking is the second Open instruction in your XB program and the concatenation of the port and socket into a string has me wondering if I am not setting up an Open Client connection improperly (if needed) or if there is something else going on.

 

If I do not need to open before writing, then I need to chase my issue down another direction.  

 

Beery

 

 

Share this post


Link to post
Share on other sites

From messaging you shouldn't 'open' the accepted socket. You just use the byte returned from accept as the handle_id for the read/write/close operations.

 

XB has interface constraints I had to adapt to. The message interface does not have those same constraints.

 

[email protected]

Share this post


Link to post
Share on other sites
26 minutes ago, jedimatt42 said:

From messaging you shouldn't 'open' the accepted socket. You just use the byte returned from accept as the handle_id for the read/write/close operations.

 

XB has interface constraints I had to adapt to. The message interface does not have those same constraints.

 

[email protected]

Thanks.  Just got the code to work from MDOS mode.  The Accept function was giving me an issue until I realized I was passing back the wrong variable contents.

 

Beery

 

  • Like 1

Share this post


Link to post
Share on other sites

Matt,

 

Once an Accept command has been established, and read/write commands are being used, is there a way to determine if the Client has closed their connection on their end?  I can create an activity timer that resets itself as one option for something like a BBS situation where no key is pressed as an alternative solution.  Just did not know if there is a quicker way to determine a loss of connection.

 

Beery

 

 

 

 

  • Like 1

Share this post


Link to post
Share on other sites
2 minutes ago, jedimatt42 said:

You will eventually get an error if they have disconnected and you write to them.  So a BBS, should nag them for input if possible.

 

[email protected]

OK, that will work.  Thanks.

Share this post


Link to post
Share on other sites

I realized it is a DSR file type access.  I thought if someone had already written a piece of code and shared, it is not something I would have to write.


Beery

 

  • Like 1

Share this post


Link to post
Share on other sites
4 hours ago, BeeryMiller said:

I realized it is a DSR file type access.  I thought if someone had already written a piece of code and shared, it is not something I would have to write.


Beery

 

Maybe someone has a p-code card, wouldn't the code for the clock be about the same? I don't know anything about those, but I was just reading yesterday and there was an rtc in some of those..

Edited by GDMike

Share this post


Link to post
Share on other sites
6 hours ago, BeeryMiller said:

I realized it is a DSR file type access.  I thought if someone had already written a piece of code and shared, it is not something I would have to write.


Beery

 

I was thinking there are dozens of examples out there of reading a record from a file. You just have to change a few parameters. 

 

[email protected]

Share this post


Link to post
Share on other sites

I'm not sure who can answer this.  Thinking out loud here on how to share files on the Raspberry PI with multiple users where a TI-99/4A and TIPI setup writes a file out a TIPI path, but another TIPI can retrieve them off my system.

 

Here's the scenario.

 

Individual writes message on my system through the BBS.  I make text based copies of that message and write the file to subdirectories on the TIPI for BBSSYSOP1, BBSSYSOP2, BBSSYSOP3, etc.

 

The Sysop on the other end, does a directory on my TIPI folder looking for any waiting messages.  If there are any, they are retrieved and the message files are deleted after retrieval.  This necessitates each folder should have username and password security and to no access to other paths.

 

On TIPI side, I see no issue saving the individual messages.  Trying to understand if a DSK1 type folder can be redirected to a shared path on the Raspberry PI and how this may be done and/or if a URL connection by the Sysop on the receiving end can get a directory listing of files so they can retrieve them by name with automated software.  I am trying to avoid the TI-99/4A acting as the server and handling the file transfer, but rather the PI acting as the source to client taking the TI-99/4A completely out of the picture of the file transfer oblivious to message/file transfers.  

 

Would this be the simplest of FTP file transfers?  Can the PI within the current TIPI architecture for FTP pass a username/pwd?

 

In the grand scheme of things, I would anticipate needing to two directional transfer of messages with at least for now, my system as the hub.

 

Anways, just thinking of how to manage this.  Any feedback appreciated.

 

Beery

 

 

 

  • Thanks 1

Share this post


Link to post
Share on other sites
2 hours ago, BeeryMiller said:

I'm not sure who can answer this.  Thinking out loud here on how to share files on the Raspberry PI with multiple users where a TI-99/4A and TIPI setup writes a file out a TIPI path, but another TIPI can retrieve them off my system.

 

Here's the scenario.

 

Individual writes message on my system through the BBS.  I make text based copies of that message and write the file to subdirectories on the TIPI for BBSSYSOP1, BBSSYSOP2, BBSSYSOP3, etc.

 

The Sysop on the other end, does a directory on my TIPI folder looking for any waiting messages.  If there are any, they are retrieved and the message files are deleted after retrieval.  This necessitates each folder should have username and password security and to no access to other paths.

 

On TIPI side, I see no issue saving the individual messages.  Trying to understand if a DSK1 type folder can be redirected to a shared path on the Raspberry PI and how this may be done and/or if a URL connection by the Sysop on the receiving end can get a directory listing of files so they can retrieve them by name with automated software.  I am trying to avoid the TI-99/4A acting as the server and handling the file transfer, but rather the PI acting as the source to client taking the TI-99/4A completely out of the picture of the file transfer oblivious to message/file transfers.  

 

Would this be the simplest of FTP file transfers?  Can the PI within the current TIPI architecture for FTP pass a username/pwd?

 

In the grand scheme of things, I would anticipate needing to two directional transfer of messages with at least for now, my system as the hub.

 

Anways, just thinking of how to manage this.  Any feedback appreciated.

 

Beery

 

 

 

That is NOT is scope for TIPI development, take it elsewhere.

 

That is general linux software development question. And in my opinion an abuse of TIPI. 

 

If you want to talk about having the 4A use the socket API to connect to the other server, and then use the TI DSR file access to load and transmit the file, then that would be on track.

 

[email protected]

  • Like 1

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...