TIPI - Geneve 9640 to Raspberry PI interface development

[+9640News]

10 hours ago, InsaneMultitasker said:

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.

 

 

I looked through my files.  I'm guessing you should have these, but not sure.  I have two 720K disks.  The RC2 disk has a SCSI2 folder, and a CHANGES folder.  Not sure if that helps bridge the gap between 6.50 to 6.7, or not.

 

I'm going to check some of my MESS images to see if you may have sent me something as a backup in the past.

 

Beery

 

 

mdos670beta-720k.DSK mdos670betaRC2-720k.DSK

[+9640News]

10 hours ago, InsaneMultitasker said:

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.

 

 

Tim,

I have a MESS image, not tested under MAME, that has a date stamp of 10/17/2010.  I had to use the chdman tool to update it the version of MESS I have on my system.  In the folder MDOSGPL\MDOS, there is source code.  According to the HVERSIONS, it is 6.71 source code.

 

The zip of that file is here.  Hopefully, the board can handle 11 MB files.

 

Beery

 

 

MdosGpl1.zip

[+InsaneMultitasker]

21 minutes ago, BeeryMiller said:

Tim,

I have a MESS image, not tested under MAME, that has a date stamp of 10/17/2010.  I had to use the chdman tool to update it the version of MESS I have on my system.  In the folder MDOSGPL\MDOS, there is source code.  According to the HVERSIONS, it is 6.71 source code.

 

The zip of that file is here.  Hopefully, the board can handle 11 MB files.

 

Beery

 

 

MdosGpl1.zip 11.27 MB · 1 download

thank you, Beery. This appears to be Tony's/Gazoo's version of MDOS that allows for a resident GPL.  When he created this, I "warned" him that I was not interested in maintaining this fork. This moves MDOS closer to simply emulating a TI. If you want to do that, you need only load GPL once, and you could also use the GPL Cheater program to speed up a GPL restart, so I did not agree with this approach within the OS itself.  I'll take a look at it for source and re-assess my stance at that time. 

 

On a related note I looked at the 6.70RC1 and RC2 disks again.  It seems the RC2 change folder might be inclusive of RC1s updates. I need to do a bit more digging to be sure...

 

[+arcadeshopper]

@InsaneMultitasker are you going to set up a repo say on github for mdos/geneve source?

 

Greg

[+InsaneMultitasker]

55 minutes ago, arcadeshopper said:

@InsaneMultitasker are you going to set up a repo say on github for mdos/geneve source?

 

Greg

Yes, that is the long-term plan.

 

I was thinking the other day that it would be very helpful if someone with the requisite skills could write a command line utility for batches of files (or folders) to convert from TIFILES DV80 format to .TXT file format, from one folder to another, on the PC.  Something like "XCOPY" that could do current folder or all subfolders.   For example, I could maintain the source on the Geneve, copy to the PC via TIPI, convert, and sync.

 

Or, is there some sort of process that could be written and run on the TIPI  RPi to automatically perform a conversion/sync like this to another TIPI folder?  Thus keeping the TIFILES and .TXT files always in sync, which would then (theoretically) allow one to sync with github?

 

There is no assembler/linker that can handle MDOS code with exception of GenProg.  A compatible PC-based cross-assembler and linker does not exist. 

[+arcadeshopper]

Both.. git works great on the pi. That's what matt uses to maintain the TIPI sw on the pi.

You could even make folders in TIPI then telnet to the pi from your TI or geneve or ssh from the pc. Login as TIPI user then Cd /home/TIPI/tipi_disk/folder and run git commands from there.. easy

I'm sure we could do a meet on Google and walk you though it if you need.. Lmk

Sent from my LM-G820 using Tapatalk

[+arcadeshopper]

I think Matt may have a way to make the files work either way as well.. or a script can easily convert back and forth

Sent from my LM-G820 using Tapatalk

[+jedimatt42]

I automate that stuff all the time, using xdm99.py  from Ralph B.  I would be glad to help out with that... 

 

I could also extend TIPI to save certain file name patterns if being written as DV80 to plain linux text files. I already provide loading of them that way for BLAH/XB, BLAH/BAS, BLAH/A99, BLAH/TXT

Although I would be hesitant for some of the strange naming patterns the TI allowed.. 

 

But, for simplicity, let's just start with a script... I know @InsaneMultitasker has xdm99.py installed. So, PM me with more detailed requirements, and I can put an example together... 

 

 

[+jedimatt42]

Since there is no cross assembler at this stage, there should also be a script in the git repo to import them into TIFILES or .DSK images, so they can be brought back into a Geneve or MAME for building... 

[+InsaneMultitasker]

Thanks @arcadeshopper and @jedimatt42.  I'll reach out when I am a little further along and can better visualize next steps, though I may need help with that,too

[+mizapf]

I have a script support in TIImageTool, but I'm afraid this does not help sufficiently here (you'd need some automatism over a set of files).

 

java -classpath tiimagetool.jar de.mizapf.timt.CommandShell type mame/disks/tests/bqtest1.dsk BQTEST_S

 

This prints the contents of the D/V80 file named BQTEST_S on the disk image bqtest1.dsk into stdout (can be redirected into a file).

[+jedimatt42]

36 minutes ago, mizapf said:

I have a script support in TIImageTool, but I'm afraid this does not help sufficiently here (you'd need some automatism over a set of files).

 

 

java -classpath tiimagetool.jar de.mizapf.timt.CommandShell type mame/disks/tests/bqtest1.dsk BQTEST_S

 

 

This prints the contents of the D/V80 file named BQTEST_S on the disk image bqtest1.dsk into stdout (can be redirected into a file).

 

Yep, I used tiimagetool's CommandShell as the foundation for producing this: https://www.jedimatt42.com/9640news/

 

[+mizapf]

I added an "export" and an "import" function to the CommandShell; "export" saves all files from a disk image (or a directory in there) to the file system as TIFILES, while "import" does the opposite. Maybe this could be helpful. But you still need a tool that converts a text file to a TIFILES file.

 

java -classpath tiimagetool.jar de.mizapf.timt.CommandShell export somedisk.dsk

java -classpath tiimagetool.jar de.mizapf.timt.CommandShell import anotherdisk.dsk

 

 

[+9640News]

5 hours ago, jedimatt42 said:

Since there is no cross assembler at this stage, there should also be a script in the git repo to import them into TIFILES or .DSK images, so they can be brought back into a Geneve or MAME for building... 

There is probably less of an issue with the assembler, than there is with the linking process for something like MDOS.

 

It is within the linking I am going to guess there are 50+ object code files that are pieced together across 15+ 8K memory pages and all REF/DEF's worked out for each fragment.  

 

The linker is probably the challenge.

 

Beery

Edited May 30, 2020 by BeeryMiller

[+jedimatt42]

11 minutes ago, mizapf said:

I added an "export" and an "import" function to the CommandShell; "export" saves all files from a disk image (or a directory in there) to the file system as TIFILES, while "import" does the opposite. Maybe this could be helpful. But you still need a tool that converts a text file to a TIFILES file.

 

 

java -classpath tiimagetool.jar de.mizapf.timt.CommandShell export somedisk.dsk

 

 

java -classpath tiimagetool.jar de.mizapf.timt.CommandShell import anotherdisk.dsk

 

 

 

 

The xdt99 suite is not just an assembler suite, it provides xdm99 which is a great scripting-first command line toolset for importing and extracting data to and from TIFILES and V9T9 FIADS, as well as sector dump DISK images.

[+InsaneMultitasker]

Tonight I played around with MDOS a bit.  I grabbed the MDOS 6.50 source DV80 files and forced a full assembly.  I then added the passthrough routines for the low level 4A DSR. When a 4A program executes its DSRLNK against the master DSR, the OS sees "TIPI" and executes a second DSRLNK for the device CRU.  The biggest challenge is available program space to retain these enhancements and re-introduce the MDOS 7.00 changes.  Tonight's adventure was meant to confirm the passthrough would work in MDOS 6.50; now I need step back again to do more research...

 

[+InsaneMultitasker]

Ok, I re-learned something tonight.   Since putting my Geneve into a PC Tower in the 90s, I only ever see its peripheral card LEDs when the case is opened for troubleshooting. 

 

My current TIPI test setup is a standard PEB.  I spent a good portion of the evening trying to determine why my TIPI passthrough code was failing to work within the MDOS 7.00 codebase. The TIPIPEB LED was illuminating but no activity in the RPi3 logs!  I took a break for dinner then returned to find that I had typed "TIP1" not "TIPI" in the Geneve's DSR device list.   Arrgh.  I changed the device name and now the TIPI device responds to level 3 IO calls.

 

What I had forgotten is that if a device is not found in the Geneve's master DSR* at the first CRU, the TI program continues to iterate through all remaining device CRU addresses.  Sure enough, if I enter a silly device like "PLOP" I see the TIPI, floppy, SCSI, and ramdisk devices all light up 16 times looking for the nonexistant device.  Why?  *The Geneve's master DSR presents all level 2 and level 3 devices at the same CRU so if it isn't found at >1000, it won't be found at >1100, >1200...etc but it will turn on the card at that address.  What I don't yet understand is why each card is activating for every CRU address.

[+InsaneMultitasker]

@jedimatt42 - does the facility/ability exist to pass the creation/update dates of the files via the level 3 catalog file routine?

 

Example: screenshot from MyWord's  (S)how (D)irectory command in GPL /without/ rompage.    

 

[+jedimatt42]

30 minutes ago, InsaneMultitasker said:

@jedimatt42 - does the facility/ability exist to pass the creation/update dates of the files via the level 3 catalog file routine?

 

Example: screenshot from MyWord's  (S)how (D)irectory command in GPL /without/ rompage.    

 

One would have to update https://github.com/jedimatt42/tipi/blob/master/services/ti_files/CatalogFile.py  to recognize some other open mode or record length or whatever the extension was. And then provide the alternative record encoding.

[+InsaneMultitasker]

20 minutes ago, jedimatt42 said:

One would have to update https://github.com/jedimatt42/tipi/blob/master/services/ti_files/CatalogFile.py  to recognize some other open mode or record length or whatever the extension was. And then provide the alternative record encoding.

Thanks.  Optimistically speaking, when I integrate the TIPI file IO into the native Geneve OS side of the house, it would be nice to have this functionality.  Knowing it is possible is good enough for me right now.   The mechanism used to pass the values via the DSR is an additional 12 floating point integers in the catalog record, each representing an integer value DD/MM/YY  HH:MM:SS for the Creation and Update date/time.   Why strings were not used is beyond me; possibly DSR space limitations related to constructing the string. 

[+jedimatt42]

13 hours ago, InsaneMultitasker said:

Thanks.  Optimistically speaking, when I integrate the TIPI file IO into the native Geneve OS side of the house, it would be nice to have this functionality.  Knowing it is possible is good enough for me right now.   The mechanism used to pass the values via the DSR is an additional 12 floating point integers in the catalog record, each representing an integer value DD/MM/YY  HH:MM:SS for the Creation and Update date/time.   Why strings were not used is beyond me; possibly DSR space limitations related to constructing the string. 

 

So, I haven't been able to find info that says how the extended timestamp info is requested...  Surely if the catalog is opened with a recordlength of 38, it should not.. and if with a recordlength of 146, it should... but what is the behavior when that is opened with a recordlength of 0? Does it default to the legacy 38 mode, or default to the timestamped mode? 

 

How many VDP buffer overruns occurred in legacy software if the default was to include the timestamps? 

[+InsaneMultitasker]

55 minutes ago, jedimatt42 said:

 

So, I haven't been able to find info that says how the extended timestamp info is requested...  Surely if the catalog is opened with a recordlength of 38, it should not.. and if with a recordlength of 146, it should... but what is the behavior when that is opened with a recordlength of 0? Does it default to the legacy 38 mode, or default to the timestamped mode? 

 

How many VDP buffer overruns occurred in legacy software if the default was to include the timestamps? 

I inspected the C source for Directory Manager by Clint P. and found the same date/timestamp floats are passed in native MDOS mode as they are in TI Mode.  Was this a special hack for MyWord that was propagated to other apps?   Keeping in mind that the visual representation of the date/timestamps are almost exclusively seen in catalog routines and that some of those programs parse the data from the FDR directly with sector IO, it is hard to know for sure.   The following code from the OS seems to confirm that when no record length is specified, the OS defaults the length to 146.  I would have expected the opposite. 

 

This routine from common DSR code defaults to 146 if reclen==0 but does allow reclen==38 if specified in the PAB. 

 

L8.OPEN&LS2: 

DIRP5  MOV  @OPCODE,R5
*      ANDI R5,>FFFE          don't care if relative or sequential
*                             ALSO don't care about parse flag 8-26-89
       ANDI R5,>FF7E          don't care if relative or sequential
       CI   R5,>000C          open, fixed, internal, input ?
       JNE  B2JMP             nope...
*
OPNDIR LI   R6,146
       MOV  @LRECLN,R5
       JEQ  OPDIRX            assume new directory info  
       C    R6,R5
       JEQ  OPDIRY            they want new directory info
*
       CI   R5,38             do they want old directory info?
D38    EQU  $-2
*
       JNE  B2JMP             nope...bad open
       JMP  OPDIRY

OPDIRX MOV  R6,@LRECLN        give them the info count

 

This second routine from hard-drive specific code is more concerning as it seems to prohibit a 38 byte reclen. 

DFOPN  LI   R0,>4000          BAD PARMS
       CI   R6,>000D          ACCEPT INTERNAL,FIXED,INPUT,RELATIVE
       JEQ  DIREA1            BRANCH IF CORRECT PARMS
       CI   R6,>000C          ACCEPT OR INTERNAL,FIXED,INPUT,SEQUENTIAL
       JNE  BAD010            BRANCH IF BAD PARMS
DIREA1 MOV  @LRECLN,R11       LENGTH IS char length 11,and (3+6+6)*9
       JNE  DIREA2                    or 11+15*9=146 or >92
       MOV  @H0092,@LRECLN
       JMP  DIREA1
*
DIREA2 CI   R11,>0092
H0092  EQU  $-2
       JNE  BAD010

 

Testing is necessary to confirm the behavior follows what is found in these two snips of code.  I have been tricked by 'dead' code in the past. Still, MyWord and Directory Manager strongly suggest the above code is active. 

 

 

[+jedimatt42]

Thanks, that tracks with what is recommended by TI, and suggested by Fred Kaal's documentation. 

 

One of these days:  https://github.com/jedimatt42/tipi/issues/137

 

[+InsaneMultitasker]

21 hours ago, jedimatt42 said:

Thanks, that tracks with what is recommended by TI, and suggested by Fred Kaal's documentation. 

 

One of these days:  https://github.com/jedimatt42/tipi/issues/137

 

Thanks and agreed.  I will look at the HFDC DSR later this week to inspect how it handles the record length since its DSR predates the Geneve.   @F.G. Kaal's documentation states "On some peripherals the record length is 38 bytes but when the peripheral is capable of time stamping the record length is 146."   It still seems incorrect to me that the newer peripherals would default to the larger record size, though maybe I'm forgetting something important?

 

I completed an initial review of the Geneve DSR to determine what space is available.  One of the critical DSR segments has less than 32 bytes free in its 8k page.  This is not a good thing; I'll need to do a deeper analysis before I can even attempt to implement anything beyond the current level 3 operations.  Sigh.

[+9640News]

There has been some discussion in another topic area about using GitHub as a repository for source files and development.  GitHub works fine if you are using non TMS9900 (i.e., Windows, Linux, etc) apps for the assembly editing process to generate code for the TI99.

What doesn't work is if you are using TI or Geneve apps like the Editor/Assembler or GenProg to assemble your program and you want to remain more pure TI/Geneve.

 

Retroclouds has demonstrated he can load a text file from GitHub which I presume he used the URI features of TIPI.  As Matt has already pointed out, the TIPI does not have support for saving back to the website.

 

I inquire if it may be feasible to approach this from another direction.  This is just an idea that is beyond my capabilities, but maybe someone with the skills and interest could turn my concept, or something similar, into a viable path forwards.

 

Here's my idea.  One would telnet into the PI from a telnet client on a TI/Geneve as localhost. One would initiate a transfer to a path on the PI\TIPI that would convert our DIS/VAR 80 files into GitHub text files, and then convert them back into DIS/VAR 80 files on the retrieval side marking files that needed to be committed to the repository or retrieved.  

 

I'm thinking perhaps some kind of Python script to do all the transferring????? Grasping at a few straws here as I think the screen display interface would need to be controlled at a 40x24 text mode basis.  Maybe separate scripts for F18A and 9938 if someone was really industrious?

 

Another option is the "telnet client" running on the TI sends the appropriate commands (ftp???) to transfer files to the PI to make the transfers???  Here, my thinking is you are using the Telnet client as just passing commands to the PI prompt and let the PI do the work.  Two steps, run something to convert the file to txt or DIS/VAR 80, the other step to send/receive the file with the order of the step dependent upon the direction.

 

Anyways, just floating the concept.

 

Beery