MDOS V7.30

[+InsaneMultitasker]

13 hours ago, mvancopp said:

 It does have AUTOEXE1 linked to HDS1.

Can you point us to the post where this disk image is attached?

 

I am interested to know what CRCOS7 reports if you run it against the system-sys file on the "HDS1" disk.

[+InsaneMultitasker]

On 1/12/2022 at 3:19 AM, dhe said:

ok... I need PFM BIO's 8.02. Mine says 8.01 

PFMUPDATE2.zip

 

The attached ZIP contains release 2 of the PFM program suite.  The Boot BIOS startup screen will indicate April 17, 2021 when properly updated.  The core has been modified to turn off all peripheral cards before executing the DSR powerup routine.   No other significant changes have been implemented.

[mvancopp]

10 hours ago, InsaneMultitasker said:

Can you point us to the post where this disk image is attached?

 

I am interested to know what CRCOS7 reports if you run it against the system-sys file on the "HDS1" disk.

On 10/9/2021 at 12:05 PM, 9640News said:

Here you go.

BootDisk730.dsk 180 kB · 39 downloads

@InsaneMultitasker, above is the original post with file link.

 

[+InsaneMultitasker]

12 hours ago, mvancopp said:

@InsaneMultitasker, above is the original post with file link.

 

@9640Newsare you able to remove or correct the file in the post referenced above?

[+9640News]

2 hours ago, InsaneMultitasker said:

@9640Newsare you able to remove or correct the file in the post referenced above?

 

Nope.  File should be removed so that others do use the file/version inadvertently thinking it is a good copy.  Greg, can you help us out?

[+dhe]

Just for completeness sake, here is a copy of the V1 EPROM that was set to boot off SCS6, and the custom load/sys.

 

Checksum: 0012 E69A

 

 

GBV106_CUSTOM.HEX SCS6.SYS SCSI.SYS

[+9640News]

Thanks Dan.  That is indeed a one-off version I was not aware. 

 

 

[+9640News]

Just so that folks know, there will be another MDOS update with a few tweaks.  Don't know when, but work is proceeding.  Tim has fixed a MDOS shared memory issue I found which to date, I think I have been the only person that has tried to use that feature for intertask communication. 

 

I have tested code with a "server manager" that can launch multiple programs for inbound TIPI TCP connections.  Capabilities include a multiline BBS, or potential for multiplayer games.  Haven't exactly decided in what direction I may want to take this at the moment, if anywhere.  If there is anyone serious about writing any MDOS programs for TIPI TCP I/O, let me know.

 

The "server manager" code was written to confirm all the TIPI XOP code was working as implemented with a multi-handle capability for both client and server side capability.  I have written a GenREF document specifically for the TIPI XOP that lays out everything for TCP extension usage with example code as well as code for the TIPI mouse that returns everything in the same format as the Geneve Bus mouse.  Back in the 90's, Bruce Hellstrom wrote a mouse driver for the Bus mouse as well as a mouse driver for a RS232 mouse.  I have a separate mouse driver now for the TIPI responding identical to the Bus mouse driver.

 

Along with the next MDOS release, will be an ANSI driver for anyone desiring ANSI graphics in either text or graphics mode. It is based off of @InsaneMultitasker's ANSI code.

 

There are also some other items updated, but those are the things on my side I have been doing.

 

[+InsaneMultitasker]

12 minutes ago, 9640News said:

Just so that folks know, there will be another MDOS update with a few tweaks.  Don't know when, but work is proceeding.

Most of my OS-specific work last year following the 7.30 release was a deeper dive into the DSR XOP routines.  A few annoyances and bugs were fixed, and the source code cleanup is still under way (in part) to free up space needed for a few additional changes for the upcoming release.  The DSR work takes more time to complete because I don't like to stop-and-start the development every other week, as there is too much risk of creating new problems.  The shared memory issue bug fix helped us to also understand a long-standing memory node leak, which now has a potential fix, but one that requires tweaking the memory XOPs, task loader, and task fork routines. Fortunately, the problem only manifests if you run/re-run programs 200+ times without a warm restart; most of us never work in MDOS this long without some kind of restart.

[+9640News]

4 minutes ago, InsaneMultitasker said:

 Fortunately, the problem only manifests if you run/re-run programs 200+ times without a warm restart; most of us never work in MDOS this long without some kind of restart.

There may only be two of us that do <grin>.

[+mizapf]

Not 200+, but I remember I already had issues during development (in earlier releases of GeneveOS), running QDE, TASM, LDR repeatedly.

[+InsaneMultitasker]

17 minutes ago, mizapf said:

Not 200+, but I remember I already had issues during development (in earlier releases of GeneveOS), running QDE, TASM, LDR repeatedly.

What you experienced is likely the same issue.  When the OS releases a task's page 0, it moves the physical page number into a free node. However, the node that was originally used for the physical page is cleared and never returned to the pool.  You can observe the behavior with a simple batch file that executes a program over and over.  Eventually, the free node list will be consumed.  Once this happens, the free physical page nodes will be consumed one by one, until there are none available. 

[+9640News]

CYA V7.30 is ready for release in the attached file.  CYA V7.30 works only with MDOS V7.30.

 

@InsaneMultitasker has a great program and I was blessed to have been able to offer some assistance to identify the patch tables for MDOS V7.30.

 

Enjoy

CYA730.zip

[+InsaneMultitasker]

Thank you, @9640News   I snagged a picture of it running on real hardware. 

 

[+dhe]

Peter Muys Editor:

 

 I am running V1.31A (10/1990).

 

 A couple of quirks I've run into ..

 

I can't seem to start the editor and load a file, I have to start the editor and then load the file from the editor.

 

Also quirky... You have to be in edit mode to hit F9 for help - that pulls up a nice little menu.

One of the options is ^A.

 

If I hit that it displays the character set - from here you can see it has no underline character.

 

That's normally the job of 95 - but it too is a dash same as 45.

 

Inside the ascii menu - if you hit ^A again I think there is programmer help on memory management.

 

So.. Is it possible to start the editor and have it load a file from the command line?

 

 

[+dhe]

I have the following autoexec, which gives the following output, I'm not sure why MDOS wants to tell me the time and date?

 

 

 

 

 

 

[+InsaneMultitasker]

Default prompt includes time/date. 

45 minutes ago, dhe said:

Peter Muys Editor:

 

 I am running V1.31A (10/1990).

 

 A couple of quirks I've run into ..

 

I can't seem to start the editor and load a file, I have to start the editor and then load the file from the editor.

 

Also quirky... You have to be in edit mode to hit F9 for help - that pulls up a nice little menu.

One of the options is ^A.

 

If I hit that it displays the character set - from here you can see it has no underline character.

 

That's normally the job of 95 - but it too is a dash same as 45.

 

Inside the ascii menu - if you hit ^A again I think there is programmer help on memory management.

 

So.. Is it possible to start the editor and have it load a file from the command line?

 

 

Yes, I type "EDIT filename" all the time.  You must use the version I patched long ago, with a routine to pre-fill the load file buffer via the command line arguments.  Maybe that archive got lost to the sands of time.  anyway, here are the three files together sans release notes, see if that works better.  You must still type "LL" to load the file and "SL" to save the file, uncompressed!   I made another version that cuts the file load time in half that I'll release some day.  I removed the SF/LF options and made a few other changes.  As I said earlier, I use EDIT pretty much exclusively for all source editing, except when I need MyWord to do some heavy-lifting like merging multiple files or editing a file that is too large for EDIT.  (EDIT also has a quirk or two with respect to copying into existing lines and it might crash if the file contains characters above ASCII 127 due to the compression algorithm using the MSBit as a flag).

 

EDIUEDIT

EDIV

 

 

 

 

[+9640News]

2 hours ago, dhe said:

I have the following autoexec, which gives the following output, I'm not sure why MDOS wants to tell me the time and date?

 

 

 

 

 

 

I have ECHO off in my AUTOEXEC file.  Just ran your test.  Put the PROMPT statement as your first line as it is initially using the default prompt until you change it.

[+dhe]

Sector Count Errors, do some hard drive (MAME/HFDC/HD) reorg and pulled the following error:

 

 

All of the files being complained about are I 128

 

1) are we concerned with the cause of the problem? MDOS / DM / MAME?

2) Is there an easy way to fix?

 

 

 

[+9640News]

15 minutes ago, dhe said:

Sector Count Errors, do some hard drive (MAME/HFDC/HD) reorg and pulled the following error:

 

 

All of the files being complained about are I 128

 

1) are we concerned with the cause of the problem? MDOS / DM / MAME?

2) Is there an easy way to fix?

 

The Directory Manager documentation has a note that indicated what the cause for that prompt to be.  I do not recall what precisely was the issue, but as I recall, it wasn't a MDOS, MAME, or DM issue.  Take a look at the documentation and it should lead you to the clue to the issue.  Obviously, I would not "fix" the file.  I think by just copying the file and not updating it, the issue resolves itself for the destination file.

 

Beery

 

[+dhe]

As a data point.  I redid this copy with gdm2k - and it copied the I 128 files with no complaints.

[+InsaneMultitasker]

On 4/12/2022 at 3:06 PM, dhe said:

Sector Count Errors, do some hard drive (MAME/HFDC/HD) reorg and pulled the following error:

All of the files being complained about are I 128

 

1) are we concerned with the cause of the problem? MDOS / DM / MAME?

2) Is there an easy way to fix?

It isn't so much a fix as it is a removal of DM's notification and user choice.  I suspect we could default to simply copying every file and never know the difference, but the error alert tells us there is a discrepancy with the file, as per Clint's DM documentation:

 

Certain  versions  of  MDOS (H versions prior to v1.23) are known to
        have a problem with fixed record  files  on  hard  disks  which  are
        accessed  in  relative  mode.  The  problem results in some relative
        files having an incorrect sector count. On copy/move operations,  DM
        computes  the  sector  count for fixed record files using the record
        count and records/sector data  from  the  file  id  info  block  and
        compares  this  to the recorded sector count. If the recorded sector
        count is less than the computed count the user  is  advised  of  the
        discrepancy  and given the option of updating the file id info block
        on  the  input  device  so  the  copy/move  may  proceed  correctly.
        Unfortunately,  recent testing has shown that some programs (notably
        GenAsm) can generate fixed record files with erroneous file id  info
        blocks which appear to have sector count errors. If the file id info
 
 
  (c) 1994 Clint Pulley              04-07-94                      Page DM-5
.
 
  DM                    Directory Manager Version 2.23                    DM
 
 
        block  is  updated  for  such  files  the input file may be damaged!
        Unfortunately, it is impossible to distinguish files with legitimate
        sector count errors. Unless you know that the file was  produced  on
        an early H version (pre v1.23) of MDOS by a database program such as
        TI-Base  /  First  Base or is a relative access file such as Telco's
        dial directory, do NOT update the file id info block. If  you  reply
        "no"  then you will be asked if you wish to copy the file anyway. In
        99% of cases the copy will be valid and in all cases the input  file
        will be intact.

 

[+InsaneMultitasker]

I researched the Directory Manager warning message that @dhe reported.  The DM documentation is slightly misleading; the "record count" refers to the "highest written record number" value in the FDR.  I came across a file that triggered the warning:

 

File: ROBOT  Type: IF128,  DM reported "Indicated 46 sectors" and "Computed 52 sectors";  MDOS and DM both show file size of 46 sectors in the catalog listing.

 

Inspecting the FDR we see:

Offset/value

10  >0000 extended record length
12  >0202 file id status/records per sector
14  >002e, sectors allocated (46 sectors)
16  >0080, eof/logical record length of >80 (128 byte records)
18 >6a00, highest written record number/allocation - >6a/2 records/sector is >35 
 

For this example, I noticed that the file was the last one copied to the disk, and the disk had 0 sectors free.  The file was copied in 1992, so I no longer remember what program/operation was used or whether it was a Geneve/TI  but I strongly suspect the copy operation failed on the last sector pass and the DSR did not properly adjust the FDR.  Extended BASIC is unable to read beyond record 92, which infers the DSR is using the allocated sector and clusters.  The cluster allocation in the FDR also agree with the sector allocation.  I still have a few disks to copy, so I hope that I might encounter another issue for test purposes.

 

I identified the routine in Directory Manager (DMSF_C) that handles the computation and warning message.  I think we are safe to remove this warning and instead rely wholly on the attributes passed by BREAD/BWRITE.  @9640News or @mizapf do you have any concerns with this approach?   MDOS still copies some files on a record-basis with the native COPY command, so we may need to dig into that routine when we circle back to the tipi copy issue. 

 

Edit: I should mention that when copied with GDM2K and a fixed DM, the FDR highest record number is not recomputed by the Geneve DSR, so we still see >6A00 in the FDR. I'm not quite sure where we can see an effect of this incorrect value.

[+InsaneMultitasker]

I found another instance of the file discrepancy on a disk from 1991. This time, DM reported an indicated size of 186 versus calculated 192. 

 

I copied the file then opened it with the program; the last 6 sectors were trashed. Within the FDR, the "sectors allocated" does not agree with the "highest record written" or the cluster count.  I opened the file on the original floppy, and surprisingly, the last 6 sectors had valid data, meaning offset 14 "sectors allocated" should have been 192.  The program opened the file in update mode and upon exiting, the FDR was updated, so I'll need to do a bit more review. 

 

GRBASE9/BS - 186 versus 192 sectors

12  >0201 file id status/records per sector (1)
14  >00BA, sectors allocated (186 sectors)
16  >00FF, eof/logical record length of >80 (255 byte records)
18 >C100, highest written record number/allocation

Clusters: size 193 // sectors 03bf-047f; so here it is the sectors allocated that's wrong

 

Back then my disk system consisted of a Myarc floppy controller.  The files were time-stamped by the Geneve.  I don't think this error is reason to retain the DM warning though I wish I knew if this situation was an anomaly or if it can still be caused by one or more DSRs.