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

[wierd_w]

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

 

-M@

 

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 January 13, 2020 by wierd_w

[+9640News]

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

 

 

[+9640News]

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

 

 

[+jedimatt42]

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

 

-M@

[+9640News]

5 hours ago, jedimatt42 said:

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

 

-M@

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

[+jedimatt42]

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

 

-M@

 

[+9640News]

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

 

-M@

 

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

 

 

[+9640News]

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

 

 

[+jedimatt42]

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.

 

-M@

[+9640News]

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.

 

-M@

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

 

[+9640News]

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

 

 

 

 

[+jedimatt42]

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.

 

-M@

[+9640News]

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.

 

-M@

OK, that will work.  Thanks.

[+9640News]

Has anyone written any assembly language level code yet to read the TIPI clock?  If so, could you share?

[+jedimatt42]

It is a file device. You must go through standard DSR file access routine. There is no lower level interface provided. 

 

-M@

[+9640News]

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

 

[GDMike]

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 January 21, 2020 by GDMike

[+jedimatt42]

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. 

 

-M@

[+9640News]

Content deleted

 

Edited January 24, 2020 by BeeryMiller

[+9640News]

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

 

 

 

[+jedimatt42]

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.

 

-M@

[+InsaneMultitasker]

Hi Matt.  I added PI.CLOCK support to one of my programs tonight.  I am using the OPEN opcode to check for "PI.CLOCK".  Upon return from the DSRLNK call, I am checking the conditon bit as follows:

 

 -- Set PAB to OPEN opcode, set 8356

 -- BLWP @ DSRLNK

 -- DATA 8

 -- JEQ  NOTFOUND

 

My routine is taking the NOTFOUND branch after opening PI.CLOCK.  When I remove the JEQ NOTFOUND and fall into the READ opcode routine, the time/date are read properly. This to me confirms the PI.CLOCK device is open and working.  It seems the condition bit is being set (as if this is a non-existent DSR) even though PI.CLOCK is opened successfully and time/date are read.   Please advise at your convenience.

 

 

[+jedimatt42]

10 hours ago, InsaneMultitasker said:

Hi Matt.  I added PI.CLOCK support to one of my programs tonight.  I am using the OPEN opcode to check for "PI.CLOCK".  Upon return from the DSRLNK call, I am checking the conditon bit as follows:

 

 -- Set PAB to OPEN opcode, set 8356

 -- BLWP @ DSRLNK

 -- DATA 8

 -- JEQ  NOTFOUND

 

My routine is taking the NOTFOUND branch after opening PI.CLOCK.  When I remove the JEQ NOTFOUND and fall into the READ opcode routine, the time/date are read properly. This to me confirms the PI.CLOCK device is open and working.  It seems the condition bit is being set (as if this is a non-existent DSR) even though PI.CLOCK is opened successfully and time/date are read.   Please advise at your convenience.

 

 

I don't set the condition bit as a result of any of my DSR routines. I never saw any documentation on expectations of the condition in the status register.

 

The docs I read say the result of a dsr routine should be in the flags byte of the PAB. The top three bits of that. 

 

If you have other specification you can point me at I'd be happy to update the ROM. 

 

-M@

[+InsaneMultitasker]

I will spend some more time on this tonight to review beyond the tipi.  (I have used this same detection method in the past for other devices, though perhaps its success is DSRLNK code dependent.) 

 

That said, based on the "TI file management specification" documentation, I was not expecting the condition bit to be set when PI.CLOCK is found and valid. Here is the excerpt from the document where it describes the condition bit and error-code. 

 

 

[+InsaneMultitasker]

I had planned to do some more DSR testing tonight but ran into a head-scratcher.  I was copying files from my ramdisk to TIPI via Fred's DM2K, something that has been working just fine however, as soon as DM2K hit a certain file, the system locked with the TIPI PEB card illuminated.  I finally realized that there was a subdirectory on the TIPI that was the same name as the "bad" file I was trying to copy.  The condition cleared as soon as I powered off/on the TI ( the TIPI PEB light stayed on when I turned off the console; the card reset when the TI was turned back on).   I renamed the ramdisk file and was able to successfully copy it.   I tried to save an XB program using the same name, resulting in an IO error 66.