TIPI - Geneve 9640 to Raspberry PI interface development

[+jedimatt42]

Regarding R10, I guess I've been getting away with murder... The history of that goes to here:  https://github.com/jedimatt42/tipi/blob/6d40790b847d1f815375955a42511ea4aed03564/hardware/dsr/devices.a99#L80

 

But, yes, I don't see anything in this workflow that forces that... My own ForceCommand DSR doesn't for that setup... I've just been lucky that in everything I've tested the GPLWS R10 is already pointing at the GPLWS address when my code is entered.  Probably cause I always hit some level 3 routine first, and then it is just left that way. 

 

This probably adds all of us to that 5%, unless there is a faction that doesn't use directories... I bet this is why SID-Player on my 4A can't load songs from subdirectories, even though it navigates them, or loads when mapping a drive directly there.

 

So, a 4A problem... 

 

 

[+jedimatt42]

I have to concentrate more to understand the second problem with the file not found issue... 

 

Who knows, DM2K will probably work after I fix all these things ( except for directly with the 'TIPI.' device name )

[+arcadeshopper]

Weird as you saw me loading from TIPI.MUSIC.SID yesterday

Sent from my LM-G820 using Tapatalk

[+InsaneMultitasker]

I seem to be able to reproduce the >14 failure as follows:

 

1. Perform powerup

2. Setpath with known good directory, e.g., "TIPI.DSK5." (>17)  [no success/failure log entry]

3. Check parameters (>14) - success

4. Setpath with known bad directory,e.g., "TIPI.DSK6." (>17) - [no success/failure log entry]

5. Check parameters for known file (>14) - fail

6. Setpath to known good directory again, "TIPI.DSK5." - [no success/failure log entry]

7. check parameters for known file (>14) - fail

 

you mentioned level 3... I will test whether or not a level 3 call to "TIPI.DSK5." has any effect.

 

All tests were performed with a standard DSRLNK except for the addition of "LI R10,>83E0" as documented in the earlier post.  I haven't tested the same code on my TI as I got pulled into doing some work in preparation for tomorrow...

 

[+jedimatt42]

Ah, anything doing a LVL 3 operation first will cause the same thing as the LI R10,>83E0, cause my LVL3 ops all do a STWP R10 ( while workspace is set to GPLWS >83E0 )  So that's why I didn't see the bug... even DM2K stats dirs before trying to change to them... so that hid the issue... 

 

I capture this exchange from DM2K - with a directory on my TIPI called TMP  and DSK4. is mapped to '.' ( or logically TIPI. )

 

2020-05-25 17:43:59,633 TipiDisk    : INFO     Opcode 9 Status - DSK4.TMP.$COMINGINO
2020-05-25 17:43:59,633 Pab         : INFO     opcode: Status, fileType: Sequential, mode: Update, dataType: Display, recordType: Fixed, recordLength: 0, recordNumber: 0
2020-05-25 17:43:59,636 TipiService : INFO     Request completed.
2020-05-25 17:43:59,664 TipiDisk    : INFO     Opcode 9 Status - DSK4.TMP.
2020-05-25 17:43:59,665 Pab         : INFO     opcode: Status, fileType: Sequential, mode: Update, dataType: Display, recordType: Fixed, recordLength: 0, recordNumber: 0
2020-05-25 17:43:59,667 TipiService : INFO     Request completed.
2020-05-25 17:43:59,672 LevelTwo    : INFO     set path request
2020-05-25 17:43:59,674 LevelTwo    : INFO     unit: 1, path: DSK1.
2020-05-25 17:43:59,679 LevelTwo    : INFO     direct input
2020-05-25 17:43:59,683 LevelTwo    : INFO     unit: 1, blocks: 0, filename: $COMINGINO, startblock 0
2020-05-25 17:43:59,690 LevelTwo    : INFO     set path request
2020-05-25 17:43:59,693 LevelTwo    : INFO     unit: 4, path: DSK4.TMP.
2020-05-25 17:43:59,698 LevelTwo    : INFO     direct output
2020-05-25 17:43:59,703 LevelTwo    : INFO     unit: 4, blocks: 0, filename: $COMINGINO, startblock 12
2020-05-25 17:43:59,704 LevelTwo    : INFO     Accepting request
2020-05-25 17:43:59,712 LevelTwo    : INFO     set path request
2020-05-25 17:43:59,715 LevelTwo    : INFO     unit: 1, path: DSK1.
2020-05-25 17:43:59,720 LevelTwo    : INFO     direct input
2020-05-25 17:43:59,724 LevelTwo    : INFO     unit: 1, blocks: 12, filename: $COMINGINO, startblock 0
2020-05-25 17:44:00,329 LevelTwo    : INFO     set path request
2020-05-25 17:44:00,332 LevelTwo    : INFO     unit: 4, path: DSK4.TMP.
2020-05-25 17:44:00,337 LevelTwo    : INFO     direct output
2020-05-25 17:44:00,342 LevelTwo    : INFO     unit: 4, blocks: 12, filename: $COMINGINO, startblock 0

 

I'll have to try this 'TIPI.DSK5.' craziness.   Nope, it doesn't mind that at all... 

 

---

 

So what you describe implies that the result of setdir is only set if it fails... I'll have to write a test case... all my stuff performs lvl3 validations before attempting lvl2 IO. 

 

[+jedimatt42]

I think there is a bug here in the python: https://github.com/jedimatt42/tipi/blob/83ede5cccc1122ddb75999f4605622231a099bc1/services/LevelTwo.py#L111

It appears to allow setdir to receive anything, as long as the disk mapping points to a valid location. 

 

It should error in my opinion if you setdir to a dir that doesn't exist. I should be joining localname name and the passed in name (through some utilities) and testing that for existence. 

 

But I don't think that is quite the problem you are having.

[+jedimatt42]

See, a never ending project.

[+9640News]

Matt,

 

I thought I had the issue solved, but turned out it wasn't the case.

 

I CLOSE the port, run a timing loop, and then go to look for another connection to ACCEPT from a Windows Telnet client.  After the Windows Telnet connection reports "*DISCONNECTED*" and "Connection to host lost." and "Press any key to continue", if I do not touch the keyboard, I can not open another connection with the ACCEPT command from either a second Windows Telnet client on the same computer or a second computer with a telnet client.  If on the other hand, I immediately hit a key on the Windows Telnet client the is BBS is ready to immediately receive another connection.  I've got a portion of the log below, however, in both cases described above, the log is the same.

 

My ACCEPT code does look for 0, 1-254, and 255.  If the 255, then it goes through a CLOSE, UNBIND, BIND, and then an ACCEPT.  What I do not get is a 255 back to go through that loop.  

 

On another test case, if I get the "DISCONNECTED" from the Windows client, and then use your Telnet client to open a connection, it seems the TI-99/4A with the PI running the telnet client sits there for a minute, maybe more, and then eventually connects.  I'm thinking there is something going on with the Windows Telnet client and/or the TIPI CLOSE command where the connection is not actually closed/broken.  This is just a guess that may not be solvable from your end.

 

It is not a critical, it just adds a delay until the connection resets.

 

 

2020-05-25 21:03:49,504 Pab         : INFO     opcode: Close, fileType: Sequential, mode: Input, dataType: Display, recordType: Variable, recordLength: 80, recordNumber: 0
2020-05-25 21:03:49,505 TipiService : INFO     Request completed.
2020-05-25 21:03:49,583 TiSocket    : INFO     read 1 bytes from 1
2020-05-25 21:03:50,062 TiSocket    : INFO     read 1 bytes from 1
2020-05-25 21:03:50,414 TiSocket    : INFO     read 1 bytes from 1
2020-05-25 21:03:50,422 ClockFile   : INFO     clock mode:corcomp
2020-05-25 21:03:50,438 ClockFile   : INFO     close special? PI.CLOCK
2020-05-25 21:03:51,817 TiSocket    : INFO     closing socket
2020-05-25 21:03:51,818 TiSocket    : INFO     closed socket: 1
2020-05-25 21:03:55,032 TiSocket    : INFO     handleAccept
2020-05-25 21:03:55,033 TiSocket    : INFO     new connection handle: 1
2020-05-25 21:03:55,034 TiSocket    : INFO     accepting...
2020-05-25 21:03:55,035 TiSocket    : INFO     no connection available
2020-05-25 21:03:57,686 TiSocket    : INFO     handleAccept
2020-05-25 21:03:57,687 TiSocket    : INFO     new connection handle: 1
2020-05-25 21:03:57,687 TiSocket    : INFO     accepting...
2020-05-25 21:03:57,688 TiSocket    : INFO     no connection available
2020-05-25 21:04:00,332 TiSocket    : INFO     handleAccept
 

[+InsaneMultitasker]

6 minutes ago, jedimatt42 said:

So what you describe implies that the result of setdir is only set if it fails... I'll have to write a test case... all my stuff performs lvl3 validations before attempting lvl2 IO. 

 

Yea, I think you hit on an important point.  Now that I think back, many of my older programs perform a validation by trying to open the catalog before calling the >x7 routine.  It seems like the internal path is 'lost' and that tipi can't find its way back or correct itself once I pass the bad folder name. Does a log exist that shows the full path and filename on the RPi side?  That might be interesting to look at.

 

The HFDC manual doesn't specify an error condition is available, nor do I recall hfdc/scsi/ide reporting a bad directory.  I will definitely incorporate the validation step into my current program...

[+jedimatt42]

I should still fix it to validate, and not let you to set it to some otherwise completely crazy path... 

 

Testing some fixes...

[+9640News]

On 5/25/2020 at 10:14 PM, BeeryMiller said:

Matt,

 

I thought I had the issue solved, but turned out it wasn't the case.

 

I CLOSE the port, run a timing loop, and then go to look for another connection to ACCEPT from a Windows Telnet client.  After the Windows Telnet connection reports "*DISCONNECTED*" and "Connection to host lost." and "Press any key to continue", if I do not touch the keyboard, I can not open another connection with the ACCEPT command from either a second Windows Telnet client on the same computer or a second computer with a telnet client.  If on the other hand, I immediately hit a key on the Windows Telnet client the is BBS is ready to immediately receive another connection.  I've got a portion of the log below, however, in both cases described above, the log is the same.

 

My ACCEPT code does look for 0, 1-254, and 255.  If the 255, then it goes through a CLOSE, UNBIND, BIND, and then an ACCEPT.  What I do not get is a 255 back to go through that loop.  

 

On another test case, if I get the "DISCONNECTED" from the Windows client, and then use your Telnet client to open a connection, it seems the TI-99/4A with the PI running the telnet client sits there for a minute, maybe more, and then eventually connects.  I'm thinking there is something going on with the Windows Telnet client and/or the TIPI CLOSE command where the connection is not actually closed/broken.  This is just a guess that may not be solvable from your end.

 

It is not a critical, it just adds a delay until the connection resets.

 

 

Matt,

 

Just a FYI...…...

 

I looked through your commits for 1.62, and I do not see anything that would suggest you did anything on your end.  I upgraded from 1.61 to 1.62 earlier in the week, and now, the issue I was having looks to have just disappeared.  Perhaps there was a PI upgrade for something?

 

Anyways, on the setup I have running, and my test system, neither exhibit the behavior of the connection holding open for a short interval after disconnecting with a Windows Telnet client.  At least for now...……...

 

Beery

[+jedimatt42]

Correct, I did not do anything to help or hurt this issue. 

[GDMike]

Beery, you're a great QA 

[+9640News]

If QA, you mean Quality Assurance, I know sometimes those guys can bug the crap out of people <grin>.  I'm sure I have likely frustrated Matt with some of my questions, and sometimes, repetitive questions.

 

Matt developed a great project that has tremendous amounts of potential, much of which hasn't been fully realized and I am very grateful for what he has done.

 

A lot of things that are being done today could have never been considered in the 80's and 90's because the chips just did not exist.  I just wish we had all the other additional talent back in the 80's and 90's still around to develop software for the hardware that is out there now.  Unfortunately, many of those people are no longer with us or reached that point in their senior years where they now have other priorities.

 

PRESS with TIPI with the PI.PIO and mouse capability, the MK2, and SAMS or FinalGrom99 could have solved all of Charles Earl's issues as just one example.

 

Beery

 

 

[+9640News]

I should also add Matt did not promise all these extra features.  We are just very fortunate he has been gracious enough to expand the potential of his project and not to be confused with product using some of Matt's earlier words.

[GDMike]

Yes, but it's a good thing really. Matt is probably not to enthused with some of it, but I think if it doesn't detract him from real work then maybe he's ok, once in awhile with it. There is probably good stuff coming that Matt is doing.

But I think it's fair to ask questions in honest, modest terms. You guys are doing a lot for the community. I can't be the only one that salutes y'all.

Thanks to all of you. 

[+arcadeshopper]

Yes, but it's a good thing really. Matt is probably not to enthused with some of it, but I think if it doesn't detract him from real work then maybe he's ok, once in awhile with it. There is probably good stuff coming that Matt is doing.

But I think it's fair to ask questions in honest, modest terms. You guys are doing a lot for the community. I can't be the only one that salutes y'all.

Thanks to all of you. 

I'll also remind you guys that this entire project is pretty much written in Python and is easily extendable it's all in github open source. Matt is happy to look at any additions or bug fixes or add-ons or whatever and consider merging them into the master source.

 

There was some big talk about adding MIDI but no project plan was made that I see and no forum post in the development section so I'm assuming that was just talk. This should be reasonable easy considering it's all supported in Linux.

 

Sent from my LM-G820 using Tapatalk

 

 

 

[+9640News]

57 minutes ago, GDMike said:

Yes, but it's a good thing really. Matt is probably not to enthused with some of it, but I think if it doesn't detract him from real work then maybe he's ok, once in awhile with it. There is probably good stuff coming that Matt is doing.

But I think it's fair to ask questions in honest, modest terms. You guys are doing a lot for the community. I can't be the only one that salutes y'all.

Thanks to all of you. 

Matt's the key to the whole process, and Greg needs to commended as well as finding manufacturing support so that the TIPI continues to grow in numbers.

 

I'm really eager to see what Tim accomplishes with trying to interface the TIPI to the Master DSR of the Geneve.  That will only open more doors for easier development.

 

Myself, I have been trying to interface RS232 based software to the telnet protocols.  I've got MyTerm in a good position as a good MDOS Telnet client now for the TIPI, and with AfterHours, hopefully others will setup their own system.  I've got a few ideas with Afterhours that will expand potential for others, but just not quite there yet with the existing code. Still toying with approaches...……...

 

Beery

 

 

[GDMike]

I was just wondering, is there almost enough hardware out now to make a new entirely new computer altogether?

Edited May 29, 2020 by GDMike

[+jedimatt42]

2 hours ago, GDMike said:

I was just wondering, is there almost enough hardware out now to make a new entirely new computer altogether?

There always has been, so you need to be more specific... New different, or new the same?

[GDMike]

Well, I wasn't sure if I should ask here in the beginning, just a question.  as the basic questions come to mind for everyone, do we want a processer that is capable of reading old 4A programs, then if not, what should it be? If so, what design, what os? Do we just expand geneve? It opens a big can.

Edited May 29, 2020 by GDMike

[GDMike]

I, personally, would love to see geneve expanded out, as in, a whole complete case package and not the size of a cell phone, but a PC, and for games and desktop publishing, oh, Linux does that? 

But Linux doesn't run native TI SW.

I'd love to see a Geneve - II(call it something)

[+jedimatt42]

5 hours ago, GDMike said:

I, personally, would love to see geneve expanded out, as in, a whole complete case package and not the size of a cell phone, but a PC, and for games and desktop publishing, oh, Linux does that? 

But Linux doesn't run native TI SW.

I'd love to see a Geneve - II(call it something)

Oh, then you should read the Geneve 2020 thread.

[+InsaneMultitasker]

10 hours ago, BeeryMiller said:

 

I'm really eager to see what Tim accomplishes with trying to interface the TIPI to the Master DSR of the Geneve.  That will only open more doors for easier development.

 

I spent the evening reading through old email and correspondence from 2002-2010.  I have not been able to locate the 6.70 RC1 source files; it seems I did not retain them in the release like I did for RC2.   The next version was close at hand, needing only to address a few problems that Gazoo had identified.  Alas, my job role changed in 2009, placing me into a completely new department which I later discovered was a strategic move to ensure I was not severed in the not-too-distant future. (My manager knew he -was- going to be severed).  I digress.  

 

Tomorrow I will page through the two large 3-ring binders containing the complete MDOS 6.50 source code to look for clues.  Next will be the decision of where to start the rebuild process: version 6.50, 6.70RC2, or 7.00.  TIPI GPL mode is mapped out; MDOS mode requires more research due to the architecture.  It may also be time to remove some lesser used commands and code, such as Disk Copy, Disk Compare, the Rave Ramdisk IO, and some other items I consider non-essential to make way for improvements.

 

Anyway, I'll start an MDOS / Geneve OS development thread when things are a bit further along.

 

 

[RickyDean]

How would a disk image be labeled for this source code version, I do have a  lot of stuff on hard drive and dvd storage,  and it could be that I may have gotten this from somewhere online an stored it. Because even though I wasn't really active again till a few years ago, I played with Mess, Classic99 and Win994a. And was trying to save disks till I started working overseas as a contractor. Could have it?