Jump to content
BeeryMiller

TIPI - Geneve 9640 to Raspberry PI interface development

Recommended Posts

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

Share this post


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

  • Like 2

Share this post


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

 

  • Like 1

Share this post


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

Share this post


Link to post
Share on other sites

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

  • Thanks 1

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

 

 

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

Share this post


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

 

Share this post


Link to post
Share on other sites

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

 

 

Share this post


Link to post
Share on other sites
Posted (edited)
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 by BeeryMiller
  • Like 1

Share this post


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

  • Like 1

Share this post


Link to post
Share on other sites

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

 

  • Like 5

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