TIPI Usage and Support

[+9640News]

@jedimatt42

 

I am attaching a tipi.log file.

I used GDM2K with window 1 pointed at folder MDOS740DIS and window 2 pointed at MDOS on the TIPI.  The MDOS directory is the native file directory.

 

The log shows reading both directories, reading the file,  and then the file write is still outputting a DIS/VAR 80 file.  It is trying to copy a 500+ sector file with a 2 sector output file.

 

 

tipi.log

[+dhe]

1 hour ago, jedimatt42 said:

I had code that was always rounding up to the next block size

Block;s instead of bytes, I guess that's why no one ever wrote a good hash utility for the TI to make sure files hadn't gotten corrupted...

[+jedimatt42]

18 minutes ago, dhe said:

Block;s instead of bytes, I guess that's why no one ever wrote a good hash utility for the TI to make sure files hadn't gotten corrupted...

I have a 16 bit checksum command inside ForceCommand. 

[+jedimatt42]

36 minutes ago, 9640News said:

@jedimatt42

 

I am attaching a tipi.log file.

I used GDM2K with window 1 pointed at folder MDOS740DIS and window 2 pointed at MDOS on the TIPI.  The MDOS directory is the native file directory.

 

The log shows reading both directories, reading the file,  and then the file write is still outputting a DIS/VAR 80 file.  It is trying to copy a 500+ sector file with a 2 sector output file.

 

 

tipi.log 695.06 kB · 1 download

Ok, I tested with a program that I forgot would reset my NATIVE_TEXT_DIRS... so my previous tests were invalid and led me to fix an adjacent issue. I am able to reproduce the same log pattern you provided now... 

 

 

[+jedimatt42]

I appreciate the patients exhibited. 

 

Update 3.16 - May 6th 2023

 

- Really only direct-output to a native text file if the FDR being written is for a DV80 file

- less logging when manipulating native text files ( was showing all records of the file in the tipi.log )

where BAS. is the value of NATIVE_TEXT_DIRS configuration.

 

- tested copying a 5 sector DV80 to my TIPI.BAS. dir, verified checksums, verified reading lines, verified equivalent from linux

- tested copying TIPICFG PROGRAM image into TIPI.BAS. and verified checksums, verified identical from linux (TIFILES blobs)

- tested copying the DV80 back to TIPI. with different name to verify native text dirs was not in play, verified checksums, verified equivalent from linux ( TIFILES blobs, names different in header )

- tested copying PROGRAM image from native text dir enabled location to non-native-text-dir location. verified checksum, verified identical from linux ( TIFILES blob, same name )

 

@9640News Maybe this'll work for you. 

 

Note to others: I haven't seen any indication that this ever caused trouble unless the NATIVE_TEXT_DIRS was in play. 

 

 

[+9640News]

 

16 hours ago, jedimatt42 said:

@9640News Maybe this'll work for you. 

 

Note to others: I haven't seen any indication that this ever caused trouble unless the NATIVE_TEXT_DIRS was in play. 

 

 

Everything looks good.  I have not been able to break anything! 😀

[Atari2600PAL]

Hi. I've fitted my TIPIPeb today, all seems to have gone ok

 

I'm new to TIPI and RaspberryPi (not used a unix/linux based system since I worked at Nixdorf, later Siemens Nixdorf, many years ago)

 

In the TIPI utility there's an option to map a folder as a drive

 

Would DSK1 and DSK2 clash with my floppy drives please? or are DSK1/2 on the TIPI referenced in a different way?

 

Sorry if it's a stupid question, but as I say am just getting started and not had time to really sit down and learn what TIPI can do

 

Thanks

 

 

 

 

 

[+Vorticon]

If your disk drives are mapped to TIPI folders, then any reference to DSKx will access these folders and not the physical drives. In order to access the latter, you need to precede them with the disk controller's CRU address, typically 1100. For example, to get a directory of your physical DSK1, you would type in Force Command DIR 1100.DSK1

[Atari2600PAL]

23 minutes ago, Vorticon said:

If your disk drives are mapped to TIPI folders, then any reference to DSKx will access these folders and not the physical drives. In order to access the latter, you need to precede them with the disk controller's CRU address, typically 1100. For example, to get a directory of your physical DSK1, you would type in Force Command DIR 1100.DSK1

Thanks. So if I leave DSK1/2 unmapped and just map 3/4, my floppies DISK1/2 will work as normal without having to specify 1100?

 

EDIT: Just tested and found my assumption is correct

[Atari2600PAL]

I don't have a DIR command, is this part of XB or MDOS or something please?

 

Thanks

[dgrissom]

2 minutes ago, Atari2600PAL said:

I don't have a DIR command, is this part of XB or MDOS or something please?

 

Thanks

Refers to @jedimatt42 's Force Command program/OS/shell.  Don't forget DSK0 is always mapped to the TIPI.

[Atari2600PAL]

6 minutes ago, dgrissom said:

Refers to @jedimatt42 's Force Command program/OS/shell.  Don't forget DSK0 is always mapped to the TIPI.

Many thanks

[+arcadeshopper]

4 hours ago, Atari2600PAL said:

Hi. I've fitted my TIPIPeb today, all seems to have gone ok

 

I'm new to TIPI and RaspberryPi (not used a unix/linux based system since I worked at Nixdorf, later Siemens Nixdorf, many years ago)

 

In the TIPI utility there's an option to map a folder as a drive

 

Would DSK1 and DSK2 clash with my floppy drives please? or are DSK1/2 on the TIPI referenced in a different way?

 

Sorry if it's a stupid question, but as I say am just getting started and not had time to really sit down and learn what TIPI can do

 

Thanks

 

 

 

 

 

i wrote tipimap in xb that's in my folder at ftp.whtech.com.. OLD PI.HTTP:ftp.whtech.com/Users/Gregory%20McGill/TIPIMAP/TIPIMAP

[+arcadeshopper]

2 hours ago, Atari2600PAL said:

Many thanks

Force command is a 128k ROM cart that gives you basically DOS on your 4/a.. it's a pretty amazing achievement you can run it from a ROM board with 74ls378  or a ubergrom board or a finalgrom99 sd card cart 

[Atari2600PAL]

23 minutes ago, arcadeshopper said:

Force command is a 128k ROM cart that gives you basically DOS on your 4/a.. it's a pretty amazing achievement you can run it from a ROM board with 74ls378  or a ubergrom board or a finalgrom99 sd card cart 

Thanks. Just been trying it with my FG99 and I'd have to concur!

 

The DIR command worked fine with my TIPI drives, but it couldn't see my physical floppy drive. Not sure if it's meant to though.

[+arcadeshopper]

2 hours ago, Atari2600PAL said:

Thanks. Just been trying it with my FG99 and I'd have to concur!

 

The DIR command worked fine with my TIPI drives, but it couldn't see my physical floppy drive. Not sure if it's meant to though.

 

cd 1100.DSK1 

should get you DSK1. on the disk controller regardless as to what you have on the TIPI mapped to DSK1. 

[Atari2600PAL]

17 minutes ago, arcadeshopper said:

 

cd 1100.DSK1 

should get you DSK1. on the disk controller regardless as to what you have on the TIPI mapped to DSK1. 

Thanks, just tried it and I get it now

[+9640News]

On 5/7/2023 at 3:24 PM, 9640News said:

 

Everything looks good.  I have not been able to break anything! 😀

@jedimatt42

 

Matt,

 

I haven't broken anything, but I do see something that could be improved.

 

I previously recall files saved as text files, I think with the .txt extension, would show up as a DIS/FIX 128 file.

 

I copied files from a SCSx path to a Native Files directory.  The DIS/VAR 80 files copied over show up as DIS/VAR 80.  That's fine as I am ok (and prefer it) with that versus DIS/FIX 128.  However, the Size (sectors) are showing up "off".  An example, I have a file showing up as 146 sectors on SCSx showing up as 1447 sectors in the Native Files directory.  All the file sizes on the Native Directory are showing anywhere from 3X to 10X difference in sector sizes.  FYI, I get a the same response at the MDOS prompt with respect to file sector size.

 

If I use GDM2K to "T" (Type) the file to screen, then GDM2K does show up the with a block count that matches +/-1 block versus the file on the SCSx device.  I think the +/- 1 block is dealing with  AU's on the device.

 

Anyways, this is more of a cosmetic issue I thought I would report.

 

Beery

[+jedimatt42]

@9640News, this was a conscious decision I made, as a native text file represented as a variable length records would have to be packed into sectors to know how many sectors it takes. This would slow down cataloging for a cosmetic reason.

 

Instead, I believe I stated this somewhere... Maybe just the wiki... But for native_text_dirs, the line count (or record count from a TI perspective) is used instead of the sector count when cataloging.

 

So, it isn't arbitrary, and you are right it could be improved. 

[+9640News]

44 minutes ago, jedimatt42 said:

@9640News, this was a conscious decision I made, as a native text file represented as a variable length records would have to be packed into sectors to know how many sectors it takes. This would slow down cataloging for a cosmetic reason.

 

Instead, I believe I stated this somewhere... Maybe just the wiki... But for native_text_dirs, the line count (or record count from a TI perspective) is used instead of the sector count when cataloging.

 

So, it isn't arbitrary, and you are right it could be improved. 

OK, I am fine with the record count.  I thought it may have been some arbitrary number.

[+jedimatt42]

Update 3.17

 

Squash Unicode characters when sending strings back to the 4A using the JSON query file support ?J flag. 

 

Processes the string data with this library: https://pypi.org/project/Unidecode/ 

 

If this ever proves to be not desired (I don't care about theoretical issues, but practical issues because a piece of software being written needs it), let me know, and I'll make the squashing able to be disabled  

[+9640News]

What is the command to force the PI to manually update?  Could not find it on the wiki, and there are 94 pages in this topic....

[+jedimatt42]

18 minutes ago, 9640News said:

What is the command to force the PI to manually update?  Could not find it on the wiki, and there are 94 pages in this topic....

For what possible reason would you need that?

[+jedimatt42]

22 minutes ago, 9640News said:

What is the command to force the PI to manually update?  Could not find it on the wiki, and there are 94 pages in this topic....

You can do the equivalent of pressing FCTN-U in the TIPICFG tool by using PI.UPGRADE : https://github.com/jedimatt42/tipi/wiki/PI.UPGRADE

When TIPICFG perceives a new version and you press the offered 'U' option, the above is what happens. 

 

However, you may just upgrade to the version you currently have if your network location or PI doesn't see the changes on github.com. So if TIPICFG isn't offering an update, you probably have other problems. Or I failed to push to github again... github looks up to date: https://github.com/jedimatt42/tipi/blob/bullseye_release/version.txt

 

[+9640News]

26 minutes ago, jedimatt42 said:

For what possible reason would you need that?

I upgraded a PI 4 to use Bullseye with MAME and, using the new MDOS release.  Something isn't playing well in the powerup routine and things are in a loop.  Next step is to see about upgrading MAME.

 

@mizapf  Have you got MAME booting MDOS from the latest update to the TIPI?