TIPI - TI-99/4A to Raspberry PI interface development

[+jedimatt42]

@BeeryMiller Ok, that was easier than I thought.  So, update 2.15 is available.

 

I changed the PI.CONFIG key to DIR_SORT instead of just DIRSORT, to fit my own coding pattern.  Defaults to FIRST... But if you need to change it...

 

10 OPEN #1:"PI.CONFIG",APPEND
20 PRINT #1:"DIR_SORT=MIXED"
30 CLOSE #1

or something... 

 

Note: this does not fix the safepoint issue... I'll have to re-study that  appropriately, that one gets issue #144 - https://github.com/jedimatt42/tipi/issues/144

Edited December 25, 2020 by jedimatt42

[+9640News]

Matt,

 

Not sure if you want to consider this an issue or not.  Letting you know about it, as there are already work around tools for it.

 

I came across the issue, and after working with Tim, we isolated what is happening as it was not immediately obvious.

 

If there is a native file on a TIPI folder because it was dropped their natively, then it does not have a TIFILES header.  I had some GIF and VOC (sound files) from back in the 90's that were playable on the TI that were downloadable from a MS-DOS PC BBS program back in the day.  When those files were downloaded, the TI would save them as a DIS/FIX 128 file.  However, these files were not downloaded to a TI and never got the TIFILES header as I had them in their original PC format when they made their way to the TIPI.  These files were still useable by our programs; they just could not be copied.

 

With DM2K, and the other catalog programs, these programs present as a DIS/FIX 128.  However, when you try to copy them to another path, you get an error that TIPI logs report as a Level 2 Error, not TIFILES.  I know you indicate these files are readable only as a native file and can not be written.  There is no intention on my part to writing back out to the file itself.  Not sure how, or if you would allow copying the file to another path.

 

Now, a user using DM2K may not realize these are native files since they present as a DIS/FIX 128 file and may struggle a bit to understand why they can not copy the file.  I'm guessing this could include .TXT files as well.  Your WebUI and programs like TIDIR solve the issue by converting and adding the TIFILES header, but only if the user realizes the situation.  I don't use Force Command, so I don't know how you may (or may not) handle it.

 

Again, just pointing out the observation.

 

From the logs, opening the FILEID of the file, the following error occurred.  The lines in Yellow are in the case of the Geneve debug code passing information back out to a terminal with the Pab going in and the Pab that is passed back out for your information.

 

Pab In : 0A00 0001 2000 0000 0000 0000 0000 0013 TIPI.DL1.04DEAD-VOC
Pab Out: 0A00 A001 2000 0000 0000 0000 0001 0013     TIPERR: C000

 

Inspecting the TIPI log shows the following: 

 

2020-12-26 11:46:30,625 LevelTwo    : INFO     unit: 0, blocks: 0, filename: 04DEAD-VOC, startblock 0
2020-12-26 11:46:30,626 tinames.tinames: INFO     TIPI.DL1.04DEAD-VOC -> /home/tipi/tipi_disk/DL1/04DEAD-VOC
2020-12-26 11:46:30,627 LevelTwo    : ERROR    not TIFILES

 

Anyways, just wanted to alert you to the observation.  After I saw what was happening, I converted the files to DIS/FIX 128 TIFILES format and all was well.

 

Beery

 

 

[+jedimatt42]

3 hours ago, BeeryMiller said:

Matt,

 

Not sure if you want to consider this an issue or not.  Letting you know about it, as there are already work around tools for it.

 

I came across the issue, and after working with Tim, we isolated what is happening as it was not immediately obvious.

 

If there is a native file on a TIPI folder because it was dropped their natively, then it does not have a TIFILES header.  I had some GIF and VOC (sound files) from back in the 90's that were playable on the TI that were downloadable from a MS-DOS PC BBS program back in the day.  When those files were downloaded, the TI would save them as a DIS/FIX 128 file.  However, these files were not downloaded to a TI and never got the TIFILES header as I had them in their original PC format when they made their way to the TIPI.  These files were still useable by our programs; they just could not be copied.

 

With DM2K, and the other catalog programs, these programs present as a DIS/FIX 128.  However, when you try to copy them to another path, you get an error that TIPI logs report as a Level 2 Error, not TIFILES.  I know you indicate these files are readable only as a native file and can not be written.  There is no intention on my part to writing back out to the file itself.  Not sure how, or if you would allow copying the file to another path.

 

Now, a user using DM2K may not realize these are native files since they present as a DIS/FIX 128 file and may struggle a bit to understand why they can not copy the file.  I'm guessing this could include .TXT files as well.  Your WebUI and programs like TIDIR solve the issue by converting and adding the TIFILES header, but only if the user realizes the situation.  I don't use Force Command, so I don't know how you may (or may not) handle it.

 

Again, just pointing out the observation.

 

From the logs, opening the FILEID of the file, the following error occurred.  The lines in Yellow are in the case of the Geneve debug code passing information back out to a terminal with the Pab going in and the Pab that is passed back out for your information.

 

Pab In : 0A00 0001 2000 0000 0000 0000 0000 0013 TIPI.DL1.04DEAD-VOC
Pab Out: 0A00 A001 2000 0000 0000 0000 0001 0013     TIPERR: C000

 

Inspecting the TIPI log shows the following: 

 

2020-12-26 11:46:30,625 LevelTwo    : INFO     unit: 0, blocks: 0, filename: 04DEAD-VOC, startblock 0
2020-12-26 11:46:30,626 tinames.tinames: INFO     TIPI.DL1.04DEAD-VOC -> /home/tipi/tipi_disk/DL1/04DEAD-VOC
2020-12-26 11:46:30,627 LevelTwo    : ERROR    not TIFILES

 

Anyways, just wanted to alert you to the observation.  After I saw what was happening, I converted the files to DIS/FIX 128 TIFILES format and all was well.

 

Beery

 

 

 

That is as designed. non-TIFILES files are not supported for LVL2 operations. They are treated in a polymorphic manner depending on how you interact with them at LVL3 IO...  For instance, if you LOAD a text file ending in .TB it will be processed by TidBit, and xbas99.py to become a PROGRAM image file for BASIC before being sent to the TI. The treatment of them as at-all usable by the 4A, is to provide cross-development convenience. 

 

Really, you are supposed to use the file share and browser interface, and just manage your files on the modern computer. 

 

I supposed this could be supported, but I've always seen that issue as a problem for the 1%'ers. I'll log it.   I really just have to make up some rules about how it would work... Do I turn things with BASIC extension into BASIC first, and present the PROGRAM image to the DIRECT IO routines? Similar question about txt files... or do I force, even the the stuff that shows up as a DV80 but aren't TI FILES to be file-managed as foreign format, so they end up DIS/FIX 128s if copied from TIPI to TI mediums, even though that's not how they are used? 

 

It's complicated, and depends on perspective... so I probably won't do anything.

 

[+InsaneMultitasker]

Here is another weird one for review.  Short story as best I can tell: 

 

If the level 2 path (set path) is pointing to a folder that is subsequently deleted, the Set Path opcode >17 will no longer process a request to change to another path until the system is restarted or the deleted folder is re-created.  Level 2 is locked into the deleted path.

 

I reset my system & RPI and walked through the steps as documented in the spoiler tags.  TIPI is v2.15.

 

 

 

 

RESTARTED TIPI/RPi

 

Existing folder MW contains 7 files for the MyWord program.

Created folder TIPI\TEST
Created TEST3 file within TIPI\TEST\   (TIPI.TEST.TEST3)


Copied TIPI\MW\EDITOR  to local device.  Successful set path and copy:

2020-12-26 20:46:09,837 LevelTwo    : INFO     set path request
2020-12-26 20:46:09,839 LevelTwo    : INFO     unit: 0, path: TIPI.MW.
2020-12-26 20:46:09,840 tinames.tinames: INFO     TIPI.TEST. -> /home/tipi/tipi_disk/TEST
2020-12-26 20:46:09,841 tinames.tinames: INFO     TIPI.MW. -> /home/tipi/tipi_disk/MW
2020-12-26 20:46:09,842 LevelTwo    : INFO     set unit 0 path to TIPI.MW.
2020-12-26 20:46:09,844 LevelTwo    : INFO     direct input
2020-12-26 20:46:09,847 LevelTwo    : INFO     unit: 0, blocks: 0, filename: EDITOR, startblock 0
2020-12-26 20:46:09,848 tinames.tinames: INFO     TIPI.MW.EDITOR -> /home/tipi/tipi_disk/MW/EDITOR

 

Copied TIPI\TEST\TEST3 to local device.  Successful set path and copy: 

2020-12-26 20:48:07,143 LevelTwo    : INFO     set path request
2020-12-26 20:48:07,145 LevelTwo    : INFO     unit: 0, path: TIPI.TEST.
2020-12-26 20:48:07,146 tinames.tinames: INFO     TIPI.MW. -> /home/tipi/tipi_disk/MW
2020-12-26 20:48:07,146 tinames.tinames: INFO     TIPI.TEST. -> /home/tipi/tipi_disk/TEST
2020-12-26 20:48:07,147 LevelTwo    : INFO     set unit 0 path to TIPI.TEST.
2020-12-26 20:48:07,148 LevelTwo    : INFO     direct input
2020-12-26 20:48:07,152 LevelTwo    : INFO     unit: 0, blocks: 0, filename: TEST3, startblock 0
2020-12-26 20:48:07,152 tinames.tinames: INFO     TIPI.TEST.TEST3 -> /home/tipi/tipi_disk/TEST/TEST3

 

Deleted TEST folder using PC / TIPI Share. 

Attempted to copy a second file from TIPI\MW\  ; however, level 2 set path routine >17 will not process the new path.

2020-12-26 20:50:04,770 LevelTwo    : INFO     set path request
2020-12-26 20:50:04,773 LevelTwo    : INFO     unit: 0, path: TIPI.MW.
2020-12-26 20:50:04,773 tinames.tinames: INFO     TIPI.TEST. -> /home/tipi/tipi_disk/TEST
2020-12-26 20:50:04,774 LevelTwo    : INFO     device not mapped

 

Level 3 requests are still processed e.g., I can catalog TIPI.MW. and view test files in TIPI. 

If I re-create TIPI\TEST,  the opcode is once again able to set the path as expected.  In this case, to TIPI.MW.

2020-12-26 21:01:44,375 LevelTwo    : INFO     set path request
2020-12-26 21:01:44,378 LevelTwo    : INFO     unit: 0, path: TIPI.MW.
2020-12-26 21:01:44,379 tinames.tinames: INFO     TIPI.TEST. -> /home/tipi/tipi_disk/TEST
2020-12-26 21:01:44,380 tinames.tinames: INFO     TIPI.MW. -> /home/tipi/tipi_disk/MW
2020-12-26 21:01:44,382 LevelTwo    : INFO     set unit 0 path to TIPI.MW.
 
 

 

[+jedimatt42]

@InsaneMultitasker, lots of issues there. 

 

Unit 0 is being sent down the same code path as DSK1-4, deciding if the drive is mapped at all. But instead it is using the current subdir mapping instead of the lower level device mapping. 

 

Ick. 

 

Edited December 27, 2020 by jedimatt42

[+InsaneMultitasker]

20 hours ago, jedimatt42 said:

@InsaneMultitasker, lots of issues there. 

 

Unit 0 is being sent down the same code path as DSK1-4, deciding if the drive is mapped at all. But instead it is using the current subdir mapping instead of the lower level device mapping. 

 

Ick. 

 

The fix you posted seems to be working nicely, well done and thank you.

 

There is one more item I came across this evening.  It has to do with protected files and the DELETE opcode >07 seemingly ignoring protection.  I didn't  see anything in the wiki that suggests this is expected. 

 

2020-12-27 19:38:21,746 LevelTwo    : INFO     set path request
2020-12-27 19:38:21,748 LevelTwo    : INFO     unit: 0, path: TIPI.
2020-12-27 19:38:21,748 tinames.tinames: INFO     TIPI. -> /home/tipi/tipi_disk
2020-12-27 19:38:21,749 LevelTwo    : INFO     set unit 0 path to TIPI.
2020-12-27 19:38:21,750 LevelTwo    : INFO     protect request
2020-12-27 19:38:21,753 LevelTwo    : INFO     unit: 0, filename: PISTAT, prot: 255
2020-12-27 19:38:21,753 tinames.tinames: INFO     TIPI.PISTAT -> /home/tipi/tipi_disk/PISTAT

 

(The TIPI log reports this error for every folder during creation of the catalog. I don't think this is related to the protection but I don't recall seeing error 21 a few days ago, so I've included an excerpt just in case)
2020-12-27 19:38:26,952 TipiDisk    : INFO     Opcode 0 Open - TIPI.
2020-12-27 19:38:26,952 Pab         : INFO     opcode: Open, fileType: Relative, mode: Input, dataType: Internal, recordType: Fixed, recordLength: 0, recordNumber: 0
2020-12-27 19:38:26,953 tinames.tinames: INFO     TIPI. -> /home/tipi/tipi_disk
2020-12-27 19:38:26,953 ti_files.CatalogFileTimestamps: INFO     Creating catalog with timestamps
2020-12-27 19:38:26,957 ti_files.ti_files: ERROR    [Errno 21] Is a directory: '/home/tipi/tipi_disk/MDOSBM'
Traceback (most recent call last):
  File "/home/tipi/tipi/services/ti_files/ti_files.py", line 21, in isTiFile
    fh = open(filename, 'rb')
IsADirectoryError: [Errno 21] Is a directory: '/home/tipi/tipi_disk/MDOSBM'
2020-12-27 19:38:26,960 ti_files.ti_files: ERROR    [Errno 21] Is a directory: '/home/tipi/tipi_disk/TIPI12232020'
Traceback (most recent call last):
  File "/home/tipi/tipi/services/ti_files/ti_files.py", line 21, in isTiFile
    fh = open(filename, 'rb').

(continues for all directories)
 

Using ROMPAGE to check status and attempt a delete:

A directory shows attribute "P" for protected file.  Fred's DM2K reports the file as protected.

I dropped into Extended BASIC and typed DELETE "TIPI.PISTAT".  The protected file was deleted successfully.  Confirmed by looking at the folder via the TIPI Share.

 

2020-12-27 19:39:04,430 TipiDisk    : INFO     Opcode 7 Delete - TIPI.PISTAT
2020-12-27 19:39:04,431 Pab         : INFO     opcode: Delete, fileType: Sequential, mode: Update, dataType: Display, recordType: Fixed, recordLength: 0, recordNumber: 0
2020-12-27 19:39:04,431 tinames.tinames: INFO     TIPI.PISTAT -> /home/tipi/tipi_disk/PISTAT
2020-12-27 19:39:04,435 TipiService : INFO     Request completed.
 

 

 

 

[+jedimatt42]

53 minutes ago, InsaneMultitasker said:

The fix you posted seems to be working nicely, well done and thank you.

 

There is one more item I came across this evening.  It has to do with protected files and the DELETE opcode >07 seemingly ignoring protection.  I didn't  see anything in the wiki that suggests this is expected. 

 

2020-12-27 19:38:21,746 LevelTwo    : INFO     set path request
2020-12-27 19:38:21,748 LevelTwo    : INFO     unit: 0, path: TIPI.
2020-12-27 19:38:21,748 tinames.tinames: INFO     TIPI. -> /home/tipi/tipi_disk
2020-12-27 19:38:21,749 LevelTwo    : INFO     set unit 0 path to TIPI.
2020-12-27 19:38:21,750 LevelTwo    : INFO     protect request
2020-12-27 19:38:21,753 LevelTwo    : INFO     unit: 0, filename: PISTAT, prot: 255
2020-12-27 19:38:21,753 tinames.tinames: INFO     TIPI.PISTAT -> /home/tipi/tipi_disk/PISTAT

 

(The TIPI log reports this error for every folder during creation of the catalog. I don't think this is related to the protection but I don't recall seeing error 21 a few days ago, so I've included an excerpt just in case)
2020-12-27 19:38:26,952 TipiDisk    : INFO     Opcode 0 Open - TIPI.
2020-12-27 19:38:26,952 Pab         : INFO     opcode: Open, fileType: Relative, mode: Input, dataType: Internal, recordType: Fixed, recordLength: 0, recordNumber: 0
2020-12-27 19:38:26,953 tinames.tinames: INFO     TIPI. -> /home/tipi/tipi_disk
2020-12-27 19:38:26,953 ti_files.CatalogFileTimestamps: INFO     Creating catalog with timestamps
2020-12-27 19:38:26,957 ti_files.ti_files: ERROR    [Errno 21] Is a directory: '/home/tipi/tipi_disk/MDOSBM'
Traceback (most recent call last):
  File "/home/tipi/tipi/services/ti_files/ti_files.py", line 21, in isTiFile
    fh = open(filename, 'rb')
IsADirectoryError: [Errno 21] Is a directory: '/home/tipi/tipi_disk/MDOSBM'
2020-12-27 19:38:26,960 ti_files.ti_files: ERROR    [Errno 21] Is a directory: '/home/tipi/tipi_disk/TIPI12232020'
Traceback (most recent call last):
  File "/home/tipi/tipi/services/ti_files/ti_files.py", line 21, in isTiFile
    fh = open(filename, 'rb').

(continues for all directories)
 

Using ROMPAGE to check status and attempt a delete:

A directory shows attribute "P" for protected file.  Fred's DM2K reports the file as protected.

I dropped into Extended BASIC and typed DELETE "TIPI.PISTAT".  The protected file was deleted successfully.  Confirmed by looking at the folder via the TIPI Share.

 

2020-12-27 19:39:04,430 TipiDisk    : INFO     Opcode 7 Delete - TIPI.PISTAT
2020-12-27 19:39:04,431 Pab         : INFO     opcode: Delete, fileType: Sequential, mode: Update, dataType: Display, recordType: Fixed, recordLength: 0, recordNumber: 0
2020-12-27 19:39:04,431 tinames.tinames: INFO     TIPI.PISTAT -> /home/tipi/tipi_disk/PISTAT
2020-12-27 19:39:04,435 TipiService : INFO     Request completed.
 

 

 

 

 

I didn't realize protected meant you shouldn't be able to delete... I just thought it meant you couldn't LIST. 

 

Everything in the world of TI seems to be about "how do I get rid of this PROTECTED thing???" so, no I didn't implement deletion protection. I just carry the bit in the TIFILES if you want to set it or not... Can't stop you from deleting in the TIPI shared folder anyway... 

 

As for the ti_files.py:21 error, I saw that, it is benign.. exception handling that should be ignored instead of logged.

 

[+arcadeshopper]

 
I didn't realize protected meant you shouldn't be able to delete... I just thought it meant you couldn't LIST. 
 
Everything in the world of TI seems to be about "how do I get rid of this PROTECTED thing???" so, no I didn't implement deletion protection. I just carry the bit in the TIFILES if you want to set it or not... Can't stop you from deleting in the TIPI shared folder anyway... 
 
As for the ti_files.py:21 error, I saw that, it is benign.. exception handling that should be ignored instead of logged.
 

Oops no the disk protect is delete protect
There is no way to tell if an xb program has the protection flag saved from a disk catalog level

Sent from my LM-V600 using Tapatalk

[+jedimatt42]

4 minutes ago, arcadeshopper said:

Oops no the disk protect is delete protect
There is no way to tell if an xb program has the protection flag saved from a disk catalog level

Sent from my LM-V600 using Tapatalk
 

 

Oh well, nobody has any use for either  -- filed a github issue...

 

Edited December 28, 2020 by jedimatt42

[+arcadeshopper]

Correction is write protection also

Sent from my LM-V600 using Tapatalk

[+jedimatt42]

2 minutes ago, jedimatt42 said:

 

Oh well, nobody has any use for either  -- filed a github issue...

 

 

One of these days, we'll get to a point where TIPI is almost usable.  LOL.

 

[+jedimatt42]

And sure enough the BASIC reference for 'SAVE' says it's PROTECTED is not the same as Disk Manager's protected.

[+InsaneMultitasker]

Seems (to me) many/most of the recent items are edge case scenarios that few people will encounter.  For example, I'm not particularly concerned about the file protection as I have little use for it myself and it is almost always an inconvenience when encountered, so if you were to say it will be ignored, I couldn't care less    

 

6 minutes ago, jedimatt42 said:

One of these days, we'll get to a point where TIPI is almost usable.  LOL.

I think you say this tongue in cheek yet I still want to say the positive usability point was reached long ago.  Many of us are doing things with TIPI that we couldn't dream of in the near past and integrating it into how we use the TI and emulation, e.g., sharing files between real TI and Classic99 via TIPI.   It is certainly a "necessity" for me these days. 

[+jedimatt42]

In my defense, the documentation for DELETE in TI's "FILE MANAGEMENT SPECIFICATION", doesn't mention protection. 

 

And this is funny, my "Disk Memory Sytstem" printout, is missing page 22 & 23. It is page 22 that should be describing the file manager's option 4 MODIFY FILE PROTECTION function.

 

None of the low level stuff describes its use. It is hard to tell if the controller enforces it or the disk manager software does.

[+jedimatt42]

31 minutes ago, InsaneMultitasker said:

Seems (to me) many/most of the recent items are edge case scenarios that few people will encounter.  For example, I'm not particularly concerned about the file protection as I have little use for it myself and it is almost always an inconvenience when encountered, so if you were to say it will be ignored, I couldn't care less    

 

I think you say this tongue in cheek yet I still want to say the positive usability point was reached long ago.  Many of us are doing things with TIPI that we couldn't dream of in the near past and integrating it into how we use the TI and emulation, e.g., sharing files between real TI and Classic99 via TIPI.   It is certainly a "necessity" for me these days. 

 

Yes, I totally say that tongue-in-cheek. The reality though, is it has never been my intention to make the TIPI software perfect. But faced with a problem that is easier to solve than live with, I'll go for solve every time.  (This is the way)

 

I appreciate the opportunity to shore up the corner cases, along with learning more about the corner cases. Prior to TIPI, I had no experience with hard-drive like substance on a 4A. Just a general awareness of their existence, and the possibilities. The corner case fixes add up. There are dozens of things I've dismissed when brought to my attention, cause I'm judgmental, and quickly go to "why would you want to?" and rarely get a good answer. But then later someone had an adjacent use case, and a good answer, so a lot of the "stupid"  LOL stuff just works now. 

 

(Edit: My boss hates it when I forget to state my point)

 

So, thanks for all the bug reports! They just add up in a way that helps everybody involved!

 

Edited December 28, 2020 by jedimatt42

[+jedimatt42]

35 minutes ago, jedimatt42 said:

In my defense, the documentation for DELETE in TI's "FILE MANAGEMENT SPECIFICATION", doesn't mention protection. 

 

And this is funny, my "Disk Memory Sytstem" printout, is missing page 22 & 23. It is page 22 that should be describing the file manager's option 4 MODIFY FILE PROTECTION function.

 

None of the low level stuff describes its use. It is hard to tell if the controller enforces it or the disk manager software does.

 

REQUEST: Anyone have page 22&23?

 

This obvious file on whtech is my lacking source:  http://ftp.whtech.com/datasheets and manuals/Hardware/Texas Instruments/PHP1240 Disk Controller Card/ti floppy controller card manual.pdf

 

 

[+InsaneMultitasker]

I could not locate a copy of the desired manual (nor its missing pages).  This excerpt from the "GPL Interface Specification for the 99/4 Disk Peripheral" may complement what you seek.

 

 

[wolhess]

8 hours ago, jedimatt42 said:

REQUEST: Anyone have page 22&23?

Here it is:  Disk memory System p22p23.pdf

[Tursi]

I didn't think anything but XB and Disk Manager honored the 'protect' flag... I deliberately don't honor it in Classic99.

 

[+jedimatt42]

A nice way to tie some stuff together, would be for me to implement this protect flag properly and report all the magic native conversion type files as protected, since they are implicitly already, but the error handling is ... made up. 

[+Lee Stewart]

The TI DSR issues an error for the following attempted level-3 file operations when the “write protect” bit is set on a file:

• OPEN a file in any mode except INPUT
• RENAME a file
• DELETE a file
• SAVE a file (I think I got this right—It looks like an existing file must first be DELETEd, which will fail if protected)

Attempts to WRITE a sector (subprogram >10), directly WRITE a file sector (subprogram >15), or FORMAT a disk (subprogram >11), check status bits from the FDC (I think—difficult to follow) for a “write protect” bit (disk-notch check?) and issue an error if it is set.

 

...lee

[RXB]

15 hours ago, wolhess said:

Here it is:  Disk memory System p22p23.pdf

Hmm 

CALL LOAD(-31931,0) ! Unprotected flag

CALL LOAD(-31931,128) ! Protected flag

 

Load a program and CALL LOAD(-31931,0) ! Unprotected flag then save it as unprotected.

 

That flag is almost useless.

[+jedimatt42]

29 minutes ago, RXB said:

Hmm 

CALL LOAD(-31931,0) ! Unprotected flag

CALL LOAD(-31931,128) ! Protected flag

 

Load a program and CALL LOAD(-31931,0) ! Unprotected flag then save it as unprotected.

 

That flag is almost useless.

 

 

Those CALL LOADs are for the BASIC SAVE ____,PROTECTED option. Which has zero to do with file storage and is part of the content of the data.

 

That's what I thought the disk management "protected" attribute was about, but I was wrong. 

 

[Tursi]

Ahhhh, that's what I thought too.

 

[RXB]

RXB SOURCE same as XB:

[0149] 8345          FLAG   EQU  >8345            General 8-bit flag

[0262] 03B9          SAPROT EQU  >03B9             PROTECTION flag in SAVE

[1974] 8C15 86,45    G8C15  CLR  @FLAG             Otherwise clear protection

[2047] 8CBD 86,45    G8CBD  CLR  @FLAG             Otherwise clear protection flag

[2215]               * Has to be PROTECTED option here, crunched as unquoted str
[2216] 8DF4 D7,B0,2C G8DF4  DCEQ >C809,V*PGMPTR    Unquoted string with length 9
       8DF7 C8,09
[2217]               *                              has to be PROTECTED
[2218] 8DF9 41,09           BR   ERRSYN
[2219] 8DFB D7,E0,02        DCEQ >5052,V@2(@PGMPTR) "PR" of PRotected
       8DFE 2C,50,52
[2220] 8E01 41,09           BR   ERRSYN             If not : SYNTAX ERROR
[2221] 8E03 D7,E0,04        DCEQ >4F54,V@4(@PGMPTR) "OT" of prOTected
       8E06 2C,4F,54
[2222] 8E09 41,09           BR   ERRSYN             If not : SYNTAX ERROR
[2223] 8E0B D7,E0,06        DCEQ >4543,V@6(@PGMPTR) "EC" of protECted
       8E0E 2C,45,43
[2224] 8E11 41,09           BR   ERRSYN             If not : SYNTAX ERROR
[2225] 8E13 D7,E0,08        DCEQ >5445,V@8(@PGMPTR) "TE",of protecTEd
       8E16 2C,54,45
[2226] 8E19 41,09           BR   ERRSYN             If not : SYNTAX ERROR
[2227] 8E1B D6,E0,0A        CEQ  >44,V@10(@PGMPTR)  "D" of protecteD
       8E1E 2C,44
[2228] 8E20 41,09           BR   ERRSYN             If not : SYNTAX ERROR
[2229] 8E22 8E,E0,0B        CZ   V@11(@PGMPTR)     Check EOL
       8E25 2C
[2230] 8E26 41,09           BR   ERRSYN
[2231] 8E28 90,A3,B9        INC  V@SAPROT

XB protection flag is at Hex >03B9 or Decimal 953 the flag named is SAPROT also set by flag named oddly FLAG

 

CALL POKEV(953,0) ! Unprotects file and clears SAPROT flag

CALL POKEV(953,1) ! Protects file and sets SAPROT flag

 

XB does not have a CALL POKEV command so you are screwed in XB.