Jump to content
BeeryMiller

TIPI - Geneve 9640 to Raspberry PI interface development

Recommended Posts

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... 

 

 

  • Like 1

Share this post


Link to post
Share on other sites

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 )

  • Like 1

Share this post


Link to post
Share on other sites

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...

 

Share this post


Link to post
Share on other sites

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. 

 

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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
 

Share this post


Link to post
Share on other sites
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...

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...