TIPI - Geneve 9640 to Raspberry PI interface development

[+9640News]

1 hour ago, dhe said:

 

Hi @9640News,

  Can you post your PI.STAT?

  Do you recommend EAGER_WRITE=On for all?

 

 

I will try to remember this evening when I get home, so if you don't see something from me by 7:30 pm EST, hit me a note as a reminder.

 

As far as using EAGER_WRITE=on, I do recommend although there are very few applications where it is necessary to use.  Put it in your PI.CONFIG, and then you can just forget about it.

 

I do not know if there are any TI-99/4A programs impacted.

[+9640News]

PI.STATUS

 

PI.CONFIG

 

I left out for obvious reasons, WIFI_PSK and WIFI_SSID names from the PI.CONFIG file.

 

 

 

[+dhe]

To report in; using TSTAT I was able to upgrade from 2.28 to 2.35 and reboot with zero issues.

I modified PI.CONFIG to have EAGER_WRITE=on

 

 

[mvancopp]

Hi Everyone,

I have a TIPI running in the Geneve and was wondering about performance, it seems very slow. I have run a few comparisons:

Copying System-Sys (MDOS 7.30):

1. From HFDC HD to HFDC HD (same drive): 7 seconds (slightly ~ 3.5 secs for read and write)

2. From HFDC HD to 1.44MB floppy: 28 seconds.

3. From HFDC HD to 360KB floppy: 46 seconds.

3. From HFDC HD to TIPI root directory of G drive (TIP1 = G, TIPI with PI4, 32GB class 10 SD card, both 2.31 and 2.36): 35 seconds

 

As you can see, this is far slower than a hard drive and even slower than a 1.44MB floppy. Is this the expected performance of the TIPI on a Geneve?

I will be doing some speed tests on a 99/4A with a second TIPI+PI Zero2 for comparison, but these numbers seem slow.

 

Is there some possibility of a configuration issue?

 

Mark

 

[+jedimatt42]

Design decisions around speed were weighed against availability of GPIO ports for tinkerers, and reliability over sketchy cabling. I was quite happy to have achieved better than floppy performance with a 4A. Nothing about a Geneve is positioned to improve upon the speed of TIPI. 

 

7K a second load time was what I considered good enough. Most 4A programs then load in 1-3 seconds. 

 

 

 

 

[+9640News]

2 hours ago, mvancopp said:

Hi Everyone,

I have a TIPI running in the Geneve and was wondering about performance, it seems very slow. I have run a few comparisons:

Copying System-Sys (MDOS 7.30):

1. From HFDC HD to HFDC HD (same drive): 7 seconds (slightly ~ 3.5 secs for read and write)

2. From HFDC HD to 1.44MB floppy: 28 seconds.

3. From HFDC HD to 360KB floppy: 46 seconds.

3. From HFDC HD to TIPI root directory of G drive (TIP1 = G, TIPI with PI4, 32GB class 10 SD card, both 2.31 and 2.36): 35 seconds

 

As you can see, this is far slower than a hard drive and even slower than a 1.44MB floppy. Is this the expected performance of the TIPI on a Geneve?

I will be doing some speed tests on a 99/4A with a second TIPI+PI Zero2 for comparison, but these numbers seem slow.

 

Is there some possibility of a configuration issue?

 

Mark

 

 

I just ran a test to copy from HFDC with a head step of 0 from a DREM at 11 seconds and then to write the file to a TIPI with a PI 4B 8 GB, 128 SD card at 31 seconds for the write for a total of 42 seconds for the copy.

 

Copying from HFDC to HFDC at 22 seconds.

 

Copying from HFDC to SCSI (SCS2SD) at 22 seconds.

 

Everything is with a non-Genmod system if that makes any difference.

 

Beery

 

 

[mvancopp]

3 hours ago, jedimatt42 said:

Design decisions around speed were weighed against availability of GPIO ports for tinkerers, and reliability over sketchy cabling. I was quite happy to have achieved better than floppy performance with a 4A. Nothing about a Geneve is positioned to improve upon the speed of TIPI. 

 

7K a second load time was what I considered good enough. Most 4A programs then load in 1-3 seconds. 

 

 

 

 

 

2 hours ago, 9640News said:

 

I just ran a test to copy from HFDC with a head step of 0 from a DREM at 11 seconds and then to write the file to a TIPI with a PI 4B 8 GB, 128 SD card at 31 seconds for the write for a total of 42 seconds for the copy.

 

Copying from HFDC to HFDC at 22 seconds.

 

Copying from HFDC to SCSI (SCS2SD) at 22 seconds.

 

Everything is with a non-Genmod system if that makes any difference.

 

Beery

 

 

Thanks for the feedback. At least I know everything is operating as expected.

 

Beery, Awhile back I was considering a DREM but decided not to go that route after the issues with HFDC and floppy emulators (they can read but not write using the HFDC). I'm glad I didn't spend the money on a device that is 3x slower than the old ST-225 I have on the HFDC now. Although the noise reduction would be nice (cooling fans and all). Not sure I understand why the SCI drive is also 3x slower. I retested to make sure my numbers were accurate and the HD time of 3.5 seconds is steady every time (~37k/sec).

 

Again, thanks for the information. I hope this is helpful to others.

Mark

 

[+InsaneMultitasker]

3 hours ago, mvancopp said:

Not sure I understand why the SCI drive is also 3x slower. I retested to make sure my numbers were accurate and the HD time of 3.5 seconds is steady every time (~37k/sec).

What revision SCSI card are you using and is it modified with the Michael Becker "pdma" updates?

 

Use CRCOS7 (included with the Os release) to load and verify the OS; time how long it takes to load the OS by watching the SCSI card LED.  It takes approximately 4 seconds to load the OS using my Revision F card, using either the SCSI2SD or EZ135 platter.  For reference, my card has the 'PDMA' modification.

 

3.5s seems way too fast for HFDC MDOS-based read or write transfer rates and is the speed I would have associated more closely with the SCSI card/drive.  10-15 seconds is more in line with what I see (and have seen) using the HFDC and ST251/225 drives.  Maybe there is a format parameter you have used to boost performance and if so, that would be great to identify.

 

You mentioned that the copy from HFDC to TIPI took 35s.  If we allow 7k/s for the TIPI that would be approximately 20 seconds write time, leaving 15 seconds to copy FROM the HFDC., and a value that is closer to what I expect for the HFDC/MFM. 

 

[+9640News]

7 hours ago, mvancopp said:

 

Thanks for the feedback. At least I know everything is operating as expected.

 

Beery, Awhile back I was considering a DREM but decided not to go that route after the issues with HFDC and floppy emulators (they can read but not write using the HFDC). I'm glad I didn't spend the money on a device that is 3x slower than the old ST-225 I have on the HFDC now. Although the noise reduction would be nice (cooling fans and all). Not sure I understand why the SCI drive is also 3x slower. I retested to make sure my numbers were accurate and the HD time of 3.5 seconds is steady every time (~37k/sec).

 

Again, thanks for the information. I hope this is helpful to others.

Mark

 

I don't know what specific floppy emulators you were referencing that did not work with the HFDC.  The DREM floppy emulation had been working without issue for the HFDC, then there was an update and it started having issues.  As I pretty much have given up use of floppies, I haven't worked with the developer to address the issue.  If you are referring to the Lotharek, it did read/write with the HFDC without issue.

 

To me, the big advantage of the DREM is that I can pull the SD card and make a backup of my hard drive image in a minute or two.  I will say that with GDM2K and a TIPI, one can make a backup of the HFDC (DREM or real MFM drives) to the TIPI with ease.

 

As far as my SCSI, it is a non-PDMA card so that is likely why my HFDC and SCSI copying tests are the same.

 

Beery 

[+arcadeshopper]

I don't know what specific floppy emulators you were referencing that did not work with the HFDC.  The DREM floppy emulation had been working without issue for the HFDC, then there was an update and it started having issues.  As I pretty much have given up use of floppies, I haven't worked with the developer to address the issue.  If you are referring to the Lotharek, it did read/write with the HFDC without issue.
 
To me, the big advantage of the DREM is that I can pull the SD card and make a backup of my hard drive image in a minute or two.  I will say that with GDM2K and a TIPI, one can make a backup of the HFDC (DREM or real MFM drives) to the TIPI with ease.
 
As far as my SCSI, it is a non-PDMA card so that is likely why my HFDC and SCSI copying tests are the same.
 
Beery 

Pretty sure goteks with flash floppy work fine too

Sent from my Pixel 6 Pro using Tapatalk

[mvancopp]

3 hours ago, 9640News said:

I don't know what specific floppy emulators you were referencing that did not work with the HFDC.  The DREM floppy emulation had been working without issue for the HFDC, then there was an update and it started having issues.  As I pretty much have given up use of floppies, I haven't worked with the developer to address the issue.  If you are referring to the Lotharek, it did read/write with the HFDC without issue.

 

To me, the big advantage of the DREM is that I can pull the SD card and make a backup of my hard drive image in a minute or two.  I will say that with GDM2K and a TIPI, one can make a backup of the HFDC (DREM or real MFM drives) to the TIPI with ease.

 

As far as my SCSI, it is a non-PDMA card so that is likely why my HFDC and SCSI copying tests are the same.

 

Beery 

 

3 minutes ago, arcadeshopper said:

Pretty sure goteks with flash floppy work fine too

Sent from my Pixel 6 Pro using Tapatalk
 

@InsaneMultitaskerI understand the DREM works for the HD part otherwise Beery couldn't test but it's good to know it has been stable until the update. Do the update failures/instability apply to the DREM HD, or the Floppy, or both?

 

@arcadeshopper, the Gotek drive with flashfloppy does not work with the HFDC, you can read from but not write to the drive. No errors occur but nothing is written. I have reported this issue and have been working with the flashfloppy person to resolve but resolution yet. This is with four different Gotek drives using v3.29, v3.30, v4.x. The Goteks/flashfloppy do work perfectly with a TI controller. I do not have a CC controller to try.

 

Mark

 

 

 

[+InsaneMultitasker]

19 minutes ago, mvancopp said:

@InsaneMultitaskerI understand the DREM works for the HD part otherwise Beery couldn't test but it's good to know it has been stable until the update. Do the update failures/instability apply to the DREM HD, or the Floppy, or both?

I do not own a DREM for my system, but I did have the chance to use one when I was updating @9640News hfdc a few years ago.  I would consider him the leading TI/Geneve DREM authority and he may be able to share further insight into the failures/instability you questioned

 

[+arcadeshopper]

[mention=25764]InsaneMultitasker[/mention]I understand the DREM works for the HD part otherwise Beery couldn't test but it's good to know it has been stable until the update. Do the update failures/instability apply to the DREM HD, or the Floppy, or both?

 

[mention=25598]arcadeshopper[/mention], the Gotek drive with flashfloppy does not work with the HFDC, you can read from but not write to the drive. No errors occur but nothing is written. I have reported this issue and have been working with the flashfloppy person to resolve but resolution yet. This is with four different Gotek drives using v3.29, v3.30, v4.x. The Goteks/flashfloppy do work perfectly with a TI controller. I do not have a CC controller to try.

 

Mark

 

 

 

I have used goteks with corcomps and they work fine

 

Sent from my Pixel 6 Pro using Tapatalk

 

 

 

[+InsaneMultitasker]

On 2/7/2022 at 10:32 PM, InsaneMultitasker said:

PEBKAC error in v.8 - I was calling a BL routine with one DATA element when it required two.  The first word of the subsequent instruction was being consumed by the BL routine, so depending on what was in memory at the time the program blew up 'randomly'.    Neat! 

 

v .9 fixes the bug, adds CTRL-C support to the restart/update operations (just in case), fixes the spinner for text/graphics modes, and enables the interrupt handler to service the sound list processor.  Without the last change, pressing "Y" (to restart or update) too quickly sounds the alarm tone until the TIPI has restarted! 

Updated in advance of the next MDOS/Geneve OS release.  TSTAT v1.0 detects the TIPI CRU address instead of using the hard-coded address of 0x1800. This is important because the next OS supports the TIPI at 'any' CRU address.

 

If the TIPI card is not detected, TSTAT exits gracefully.  The program title now reminds the user that '?' will list available options.

 

TIFILES Format:  TSTAT

 

 

[+9640News]

OK, this is a work in progress document on the TIPI XOP fully documented for use with the next release of MDOS, 7.40.

 

If anyone wants to look over it and see if there are features missing, something not fully understood, etc., then please speak up before the next release of MDOS occurs.

 

The specifications for usage only apply to MDOS 7.40 and above, as there are changes between the XOP calls between 7.30 to 7.40 to make it more flexible.  I think I have pretty much implemented everything @jedimatt42 has presently implemented according to his wiki page.

 

GenREF-TIPI.pdf

[+9640News]

@jedimatt42

 

Going to throw an idea out there to see if you think it would have merit.

 

Thinking of a PI.CONFIG setting for a "unique" folder (subdirectory) on the PI.  It is a bit of a lazy man's solution, but still, you may think it has benefit.

 

Any files output to a Specific folder that could have subfolders, the files would be written out using the .?W. native file protocol rather than having to insert the .?W. into the file path.  This would be good for projects with multiple files.

 

The benefit here is the Github Desktop can then update the github repository without having to step through any additional conversion functions.

 

Just an idea.

 

 

[+jedimatt42]

1 hour ago, 9640News said:

@jedimatt42

 

Going to throw an idea out there to see if you think it would have merit.

 

Thinking of a PI.CONFIG setting for a "unique" folder (subdirectory) on the PI.  It is a bit of a lazy man's solution, but still, you may think it has benefit.

 

Any files output to a Specific folder that could have subfolders, the files would be written out using the .?W. native file protocol rather than having to insert the .?W. into the file path.  This would be good for projects with multiple files.

 

The benefit here is the Github Desktop can then update the github repository without having to step through any additional conversion functions.

 

Just an idea.

 

 

 

That's a good idea. Captured.

[+dhe]

@9640News - Any luck with using the new TIPI image 3.5 on the Geneve?

[+9640News]

6 hours ago, dhe said:

@9640News - Any luck with using the new TIPI image 3.5 on the Geneve?

Works fine  

[+jedimatt42]

On 4/1/2023 at 3:21 PM, 9640News said:

@jedimatt42

 

Going to throw an idea out there to see if you think it would have merit.

 

Thinking of a PI.CONFIG setting for a "unique" folder (subdirectory) on the PI.  It is a bit of a lazy man's solution, but still, you may think it has benefit.

 

Any files output to a Specific folder that could have subfolders, the files would be written out using the .?W. native file protocol rather than having to insert the .?W. into the file path.  This would be good for projects with multiple files.

 

The benefit here is the Github Desktop can then update the github repository without having to step through any additional conversion functions.

 

Just an idea.

 

 

I'll be working on this, this weekend.

 

I'm thinking, set PI.CONFIG by writing a line like:

 

NATIVE_TEXT_DIRS=TIPI.SOURCE.GIT.,TIPI.EBOOKS.,etc

 

Where the value of NATIVE_TEXT_DIRS is a comma separated list (if you only need one directory, use no comma) and if the device name (drive, directories, and filename) being opened on the 4A is prefixed by one of those directory entries, then the ?W native file flag will be applied. 

 

This means it will be applied to any file in the listed directory, including descendant directories...

 

Hmmm... you guys in this thread use TIP1 instead of TIPI for the device name... that's just... I know there were reasons... So, I'll amend this example... to reduce your our cognitive load.

 

NATIVE_TEXT_DIRS=SOURCE.GIT.,EBOOKS.,etc

 

You will be able to omit the TIPI. part, it will be implicit, you can include it though if you like... I will also add a trailing directory separator '.' if it isn't provided.

 

The implementation will resolve to real Linux paths before checking the descendancy... so drive mappings like DSK1-4 will also work. But the setting should, as shown, be in 4A style directories.  

 

There will not be any escaping logic for directories that have a comma in their name from the 4A perspective... 

 

Any explicit native file handling flags specified in the operation device name will take precedence over the directory implying the ?W flag. 

 

Let me know, if any of that sounds off target...

[+9640News]

@jedimatt42

 

I think that sounds on target.  

 

As far as TIP1 instead of TIPI, I think the "1" was required for the device ID for the master DSR as it needed to be a digit and would not handle anything else without really complicating a lot of other code.  I know @InsaneMultitasker can explain it better.

 

Thank you for this work!!!

 

[+InsaneMultitasker]

Like the /4A, the Geneve is using TIPI. to communicate with the PI and TIPI device, and TIPI. is to be used for any of the TIPI configuration files and low level interaction.  The TIP1. device name is only there to bridge a gap due to the OS-enforced naming convention of a three-character device + device number. That may change in the Geneve OS in a future release.

 

Edit: the original response was intended to elaborate on @9640News 'explanation redirect' for TIP1. I removed the quoted fragment and simplified my response. 

[+jedimatt42]

My communication style failed. 

 

Anyway, for the Geneve userbase's ears, the PI side of TIPI does not know anything about TIP1. So settings in PI.CONFIG, or raw file access over messaging that I have recently documented, all have to pretend to be a 4A. 

[+InsaneMultitasker]

I shortened my reply based on a re-read of the last few posts.  In my mind, I had agreed with @9640Newss comment about being on target and had thought your post was easy to understand.  Instead of writing that, I brought a shovel and dug myself into a device naming convention rabbit hole.

[+9640News]

3 hours ago, jedimatt42 said:

My communication style failed. 

 

Anyway, for the Geneve userbase's ears, the PI side of TIPI does not know anything about TIP1. So settings in PI.CONFIG, or raw file access over messaging that I have recently documented, all have to pretend to be a 4A. 

Thanks for that reminder.  I might have fallen into that trap, though it should have been obvious to a few of us.  I am unlikely to have more than one or two directories, and maybe this will be answered after you have completed the code.  If there are multiple paths specified with the  upcoming configuration and it extends beyond 80 characters, will it use the underscore key to wrap to the next line, or just continuous text onto the next line?

 

Beery