TIPI - Geneve 9640 to Raspberry PI interface development

[+arcadeshopper]

You can use the git client on the pi directly no ftp needed.. any folder on the pi can be synced to GitHub .. In fact the tipi software is done that way.

Theoretically you just have txt files on the ti side then telnet tipi and git commit then git push them.



Sent from my LM-V600 using Tapatalk

[+9640News]

3 minutes ago, arcadeshopper said:

You can use the git client on the pi directly no ftp needed.. any folder on the pi can be synced to GitHub .. In fact the tipi software is done that way.

Theoretically you just have txt files on the ti side then telnet tipi and git commit then git push them.

 

If I understand things correctly, what one does not get is version control and the files that are then stored on GitHub are TI Files (DIS/VAR 80, etc) with TI headers and not really readable.

 

 

[Nick99]

My Geneve boots up, I load MDOS and GPL 6.5 from DSK1., in GPL I load XBasic, it works fine, but...

I´m confused, in TIPI-config I can map DSK1., DSK2. and so on, but my TI-disk controller should be used as DSK1. and DSK2. with my disk drives.

As my Geneve responds now (in ROMPAGE) when I try to load from DSK1.and DSK2. in XBasic all I get is an immediate I/O ERROR 06.

The TIPI is set on highest CRU or what it´s called and CALL TIPI works perfect.

 

In TIPI-config, should I config DSK1. and DSK2. in a special way or leave it blank?

 

 

 

[+arcadeshopper]

If you have the cru set at 1800 it will never look at the TIPI drives just your real drives in the disk controller..

Sent from my LM-V600 using Tapatalk

[+jedimatt42]

9 hours ago, Nick99 said:

My Geneve boots up, I load MDOS and GPL 6.5 from DSK1., in GPL I load XBasic, it works fine, but...

I´m confused, in TIPI-config I can map DSK1., DSK2. and so on, but my TI-disk controller should be used as DSK1. and DSK2. with my disk drives.

As my Geneve responds now (in ROMPAGE) when I try to load from DSK1.and DSK2. in XBasic all I get is an immediate I/O ERROR 06.

The TIPI is set on highest CRU or what it´s called and CALL TIPI works perfect.

 

In TIPI-config, should I config DSK1. and DSK2. in a special way or leave it blank?

 

 

 

 

24 minutes ago, arcadeshopper said:

If you have the cru set at 1800 it will never look at the TIPI drives just your real drives in the disk controller..

Sent from my LM-V600 using Tapatalk
 

 

Trying to bring this conversation back to the correct thread:  

 

 

[+9640News]

I don't doubt there could be an issue with the TI disk controller in Rompage mode.  I do not specifically remember the TI disk controller not working, perhaps it may have just been in the format routine?????  

 

I'm wondering if you slowed the GPL speed down while in Rompage mode if the issue disappears with the DSR.

 

Beery

[GDMike]

I just read this entire thread. 

So when running geneve is there any compatibility issues for using tipi?

Is there a FAQ for geneve anywhere that might explain this?

Sorry, but I didn't see the different scenarios with tipi and geneve uses, ie;..

Boot from tipi mapped drive vs floppy.

Using telnet, URI mapping.

I know how this is done on the TI.

So if you just tell me, nothing changes. I'm good with that, lol

 

[+arcadeshopper]

Tipi only works in gpl rompage mode with the exception of the one application written for mdos which is the terminal that allows you to telnet from mdos

 

Sent from my LM-V600 using Tapatalk

 

 

 

 

[+9640News]

Matt,

 

I have downloaded and been going through your TIPI DSR code and trying to convert the code to DIS/VAR 80 files that can be assembled with GenASM.

 

I want to confirm something to make sure my understanding is correct with respect to the macros in your code.

 

You have a line of source such as listed below along with the macro definition:

 

 

 

	.setvdpwa R1
	; Macro - Set VDP write address
	.defm setvdpwa
	ORI #1,VDWRITE
	SWPB #1
	MOVB #1,@VDPWA
	SWPB #1
	MOVB #1,@VDPWA
	.endm

 

Now, if I understand things correctly, the macro .setvdpwa R1 would assemble inline as the following source:

 

     ORI    R1,VDPWRITE

     SWPB R1

     MOVB R1,@VDPWA

     SWPB R1

     MOVB R1,@VDPWA

 

If that is the case, then what I will end up doing is redefining it into a format for the GenASM macros.

 

Where I am going with all this is to explore having a modified DSR that can be embedded in MDOS to permit some limited file capabilities such as getting a directory, launching a MDOS program from the TIPI, and maybe some file copying.  In a sense, the code would embed as a new XOP.  Using some modified utilities (XDIR, XCOPY) with specific coding for the TIPI that recognize this new XOP, then one could have some limited file i/o on the MDOS side of things as a start as well as executing a MDOS program directly from the TIPI. 

 

At that point, then it lays the foundation for connecting the master DSR to the TIPI if it is possible.  I say "IF", because the coding on page boundaries is already tight with the HFDC, SCSI, and the CLI that tackling it straight on may be too big of an immediate step because too many things will break all at once.

 

Beery

 

 

 

 

 

 

 

 

[+jedimatt42]

I use this macro assembler: https://endlos99.github.io/xdt99/#xas99

[globeron]

On 5/24/2020 at 9:03 AM, BeeryMiller said:

There was a MDOS program written back in the late 80's or early 90's that displays the Swan from the Swan eprom, same resolution.  I just searched for it on my BBS and it did not come up.  I'm sure someone has it if they read this area.

Beery

I would be interested  to know which program it is (for the higher resolution).

 

I found this one coincidentally when doing some configurations for the HRD3000Rambo device:

https://www.jedimatt42.com/9640news/volume2-4.html

(all disks: http://ftp.whtech.com/Geneve/9640 News disks v1-3/pc99 disks/)

 

but:

http://ftp.whtech.com/Geneve/9640 News disks v1-3/pc99 disks/9640V2%234.DSK

SECTORONE batch file has DISP as a loader for MYART file type "TITLE" (but only for low resolutions, so I still cannot load the SWAN)

but the concept is okay, load a picture, either wait a few seconds or press a button and continue in the .bat file)

 

Not sure if the DISP Source code can be altered for high resolutions to load the SWAN?  

(.cc @mizapf maybe also useful for the mess system?)

 

ARCHIVE OF SECTOR ONE
                                   Version 3.0
                                     7 Aug 91

Files included in this archive is

       1  -README        this file
       2  SODOC          SECTOR ONE docs
       3  SEC1           program file 1
       4  SEC2           program file 2
       6  SECTORONE      a batch file that loads TITLE then SECONE
       7  DISP           a Myart picture loader
       8  DISP_S         source code for DISP
       9  TITLE          Myart File
       10 FORMATIT       a formatter I wrote that verifies 1.44m floppies
                             (use with .97 MDOS or higher only)

 

 

[+9640News]

I just did a search on my bbs for the search term SWAN and did not find the file.  Not sure where it may be found.

 

I do know I have in my BIBLE program, code to display a Myart image.  It is in the BIBLE directory, file BIBLEMYART.  It has everything I think you are seeking to display in low and high resolution.  I have copied the code below as a TIFILES image DIS/VAR 80 file.

 

If you are looking for the swan specifically, I have an 8K dump of the Eprom plus a few lines from the eprom source that sets the video registers and copies the 8K image to VDP.

 

Beery

 

BIBLEMYART

[+InsaneMultitasker]

Just a bit of Geneve/TIPI integration  

 

        

@BeeryMiller and I have been playing around a bit.

Source from 6.50 was used as the basis for this work, for reasons discussed elsewhere. 

(Fixes from 6.70RC1/RC2 and 7.00 are not yet applied to this dev work)

 

[+9640News]

We need to give Tim a BIG BIG Thanks for his development work.  My contributions have been very minor compared to Tim's.  And, we both must acknowledge Matt's work on the TIPI and the publishing of the DSR on github that got us to where we are today.  I was able to take that source code, and convert it to DIS/VAR 80 files that was able to be assembled byte for byte equal to the original eprom code.  We mapped that source code into a new page of MDOS, and Tim has been busy adding the extra hooks to interface things in the Geneve's master DSR for both Geneve and TI-99/4A emulation.  That has been a monumental undertaking.

 

Initially, we thought we were going to have some side utilities like John Johnson's XDIR and XCOPY program for file directory listing and file copying, however as of yesterday

, modification's to the Command Line Interpreter's (CLI) DIR and COPY routines will likely be possible.  Still chasing down a few issues here with those two commands, however it appears Clint Pulley's Directory Manager (DM) allows copying of files to TIPI without issue as it uses a slightly different approach to file copying than the COPY command.  However, if you have 3000+ files in a subdirectory like I do for the AfterHours BBS program, there is a limitation on the number of files you can see before the buffer is full.  

 

Programs can be launched already from the TIPI from MDOS mode along with making and removing directories.  I have also successfully used the TIPI version of MyTerm to download files to the TIPI directly from MDOS.

 

As far as MDOS, it looks like we are going to drop two commands, DISKCOPY and DISKCOMPARE.  These two routines consumed around 4K of memory in the memory space allocated, and before removal, we only had 16 bytes of space left.  Addition of code to allow the use of TIPI in the DIR and COPY commands necessitated some cleanup and these two commands in today's world with the still existing user base, hard drives, and other mass storage devices, necessitated their removal for future updates.  If someone needs to do some disk copying which is less likely these days, then programs like HyperCopy and other disk managers are available.  I would have to doublecheck to see if DM2K or DU2K can do a disk copy, or if it is solely for other disk and file functions.

 

As far as the TIPI, only the TIPI device name, called TIP1 that is renamed in the communications with the TIPI to TIPI versus TIP1 is defined.  URL and other device names have not been established at this point.  First emphasis, get TIP1 100% working in MDOS and in GPL mode without Rompage.

 

I took Tim's PFM split program for PFM modified Geneve's and have modified it to work with the Geneve as it needed to compensate for the addition of an extra 8K page in MDOS.

 

There are still things to do, but things are definitely looking good.  There is only one person in the community that could have made this happen.  Many thanks to where we are now Tim!!!

 

 

 

 

 

 

 

 

 

[+InsaneMultitasker]

8 minutes ago, BeeryMiller said:

As far as MDOS, it looks like we are going to drop two commands, DISKCOPY and DISKCOMPARE.  These two routines consumed around 4K of memory in the memory space allocated, and before removal, we only had 16 bytes of space left.

(For those who might question this move, dropping one or both of these two commands has been on the radar for some time now and was not solely precipitated by TIPI integration. )

 

We'll continue to deep-dive the DSR over the holidays.  Assessing and possibly adding full support for GPL Level 2 IO for the scsi/hfdc/etc is on the radar again, though with some caveats due to the very poor decision made by either TI or Myarc when the lvl2 opcodes were extended for the hard drive devices. 

 

As far as the integration is concerned, it in no small part due to Beery's continued interest and vested enthusiasm over the last 1-2 years (DREM, TIPI, MXT, MyTerm, BBS, etc) that has kept me engaged, wheels turning, digging more deeply than ever into the impressive code beast that is MDOS.

[GDMike]

So if Chris gets my geneve operational I'll somehow be able to use the tipi I have installed? Or is this just a test and it's not happening yet? Or is there a particular MDOS that it will run on?

Sorry, just getting into the Geneve side and I think I asked this last month, been beezy I can't remember, so sorry, but was told no it's not tipi compatible yet, that last statement I remember clearly.. ?

But Ill catch up...

[+arcadeshopper]

This is in development. Not released yet

Sent from my LM-V600 using Tapatalk

[+9640News]

Tim and I are working on trying to get as much usage as possible from the TIPI with the Geneve.

 

There are still issues, but significant headway is being made.  As one thing is solved, we are moving to solve the quirks.  Will all DSR features available to 4A users be available in the "master" DSR, likely not.  First step is getting File I/O operational on both the 4A and the MDOS side of the Geneve.

 

Many things are done with no issues.  The most difficult two functions, we are trying to overcome command line interpreter issues. 

 

Will a TIPI version of MDOS boot from Eprom?  Unknown and no work is going on in that direction as other efforts look to have priority first.  However, once MDOS boots, it will at least have mass file storage capability.

 

Beery

 

 

[GDMike]

Thank you for that clarification.

 

[+InsaneMultitasker]

To clear up any potential misconceptions about the state of the TIPI DSR/Geneve OS development, here is where things stand at a high level:

 

1. The Geneve's TIPI DSR code is incorporated into the OS.  There is currently no pass-through to the EPROM.  Some of the code comes directly from the TIPI DSR; the rest of the code has been written over the past few weeks.

2. Level 3 implementation is about 95% complete, i.e., opcodes 0-9 (open,close,read,write,restore,load,save,delete,restore,status) function both in the Geneve OS and /4A modes.

3. Level 2 implementation is nearly complete for Geneve OS mode, i.e., direct input/output, protect, rename, create directory, delete directory.

4. Level 2 implementation for /4A mode is on hold for the moment.

5. Devices implemented:  TIP1 (TIPI), URIx, PI.   The DSKx devices are under review for possible REMAP integration.  All devices are currently accessible from Geneve OS and /4A modes, with restrictions as noted.

6. The hard-coded well-known addresses are under review for linkage with the /4A DSR header at "0x4000".  

7. We are identifying commands that need to be adjusted to work with the new device names.

 

As alluded to elsewhere,  my individual goal for the holidays is to rebuild the Geneve OS to a known state using 6.70x and 7.00 updates..  The TIPI work is helping to enable that much-needed task.

[+jedimatt42]

for consideration, "TIPI." is unit 0 on the python side of lvl2 operations, wouldn't "TIP1." cause more problems with other conventions? "DSK1." is unit 1 on the TIPI python side.

[+InsaneMultitasker]

3 hours ago, jedimatt42 said:

for consideration, "TIPI." is unit 0 on the python side of lvl2 operations, wouldn't "TIP1." cause more problems with other conventions? "DSK1." is unit 1 on the TIPI python side.

Yes, very good consideration.  Differentiating TIP1 vs. TIPI helps to ensure the wrong DSR isn't called by test programs.  There is also the matter of the OS being littered with device name tests and unit# tests   

 

To your point, under the hood the DSR checks for device "TIP1" and if found, replaces "1" with "I" and forces the level 2 unit # to 0 before proceeding.

 

I'll add this to the tracking list right now before I forget.

[+InsaneMultitasker]

Just a bit of OS-based TIPI fun... 

 

 

[GDMike]

Whoa!! How sweet

[Omega-TI]

On 12/22/2020 at 7:52 PM, GDMike said:

Whoa!! How sweet

Yeah no kidding!  I hope he posts the file that genetated it... and here is hoping it's not Geneve specific.