Geneve OS development discussion

[+9640News]

4 hours ago, Schmitzi said:

Hi,

 

maybe just a small thing that I saw:

 

Imagine you have a given install (files) in E:\GDM2K\

and your  PATH  is  E:\MDOS\;E:\BATCH\;E:\GDM2K\;

 

and now you enter the command to start GDM2K with an explicit path to a subdir that does NOT exist

(or within an existing path to a subdir but where the wanted targetfile does NOT exist), like:

E:\> E:\WRONGDIR\GDM2K

 

Against my expections, the target IS found and the (newer!) prog is started. Via the MDOS´ PATH, of course.

But shouldn´t pointing to an empty or not existing folder OR a not existing file end up in an error message,

rather than using the systems MDOS´ PATH then  ? (And this without any hint)

 

What happened to me that I recognized this, what was the problem ?

My actual GDM2K-v3.2 is regulary inside the range of my PATH (as shown above), as I often use it.

But because of some issues, for testing purposes I copied the older GDM2K V3.0 to E:\GDM2K-OLD\

 

Then I wanted to start the old version, just to check something there, and I mistakenly entered

E:> E:\GDM2K-V30\GDM2K

to start it. Of course I expected to see the older version now and checked what I wanted to check,

NOT knowing that I am in the actual version V3.2

 

Is it a bug, or is it a feature ?

 

thx

ACK ACK ACK

Oh, this is a FEATURE <grin>.

 

The first set of characters up to the first space is first tested to see if it is a MDOS command.  if so, it processes the command.

 

If not, then it takes your current filepath you are "in" and the flename, and converts it to a device path/filename.  In other words, E:\MDOS1\GDM2K may be converted to HDS1.MDOS1.GDM2K .

 

If the file exists, it loads.  If not, it starts testing the paths for the filename until it ends.  If a test for a device path  (no filename) were conducted prior to attempting to access the file at each potential PATH location, it will for sure slow file access down with floppy access taking a bigger noticeable hit as it will hit the FDR records twice.  I'm not sure we want to do that.

 

Beery

 

 

 

[+Schmitzi]

2 hours ago, 9640News said:

Oh, this is a FEATURE <grin>.

 

The first set of characters up to the first space is first tested to see if it is a MDOS command.  if so, it processes the command.

 

If not, then it takes your current filepath you are "in" and the flename, and converts it to a device path/filename.  In other words, E:\MDOS1\GDM2K may be converted to HDS1.MDOS1.GDM2K .

 

If the file exists, it loads.  If not, it starts testing the paths for the filename until it ends.  If a test for a device path  (no filename) were conducted prior to attempting to access the file at each potential PATH location, it will for sure slow file access down with floppy access taking a bigger noticeable hit as it will hit the FDR records twice.  I'm not sure we want to do that.

 

Beery

 

 

 

 

Ah OK, but I thought that if it comes to speed, the fastest way is to look wether the explicit target is given, and if not, ==> ERROR. Searching the whole MDOS-PATH for my file, if the filename only was entered at the prompt, then has to be done of course, time unregarded. And then each subdir in the MDOS-PATH must be attempted to "access" the file (=finding the file in the File Allocation Table I think), because if not done, how can it know that it is there or not there, and jump to the next subdir in the path ? (and not looking there too ?)

 

But is it given to search somewhere around if a target is explicit addressed, but not found there? That is what I meant.

And so I see no reason for further searching whereever as my rule is to obey (MY file is to load): THIS file. (=NO other)

 

And the expection,

let´s say if I for instance send a mailed invitation to USA:\NewYork\SoHo\BroomeStreet\No4711\MrMiller

to come to my party, and the Postman does not find this address, I will really wonder if suddenly, inmid of my party,

a complete stranger to me USA:\Oregon\Salem\MainStreet\No9640\MrMiller rings my bell

 

 

[+9640News]

12 minutes ago, Schmitzi said:

 

Ah OK, but I thought that if it comes to speed, the fastest way is to look wether the explicit target is given, and if not, ==> ERROR. Searching the whole MDOS-PATH for my file, if the filename only was entered at the prompt, then has to be done of course, time unregarded. And then each subdir in the MDOS-PATH must be attempted to "access" the file (=finding the file in the File Allocation Table I think), because if not done, how can it know that it is there or not there, and jump to the next subdir in the path ? (and not looking there too ?)

Put the request in.  No guarantees one way or the other.  When you do, make sure you specify when a file specified by "explicit path", that the file searching does not continue looking at other path's specified by the PATH command.  I will need to look at the code to see if there is an opportunity within the current code to handle an explicit path.

 

If you would, do a test to see if entering HDS1.<BADDIR>.GDM2K loads GDM2K from a PATH, or if it gives you an error and says the file can not be found.  Use the actual device name versus drive letter to see if there is a difference.

 

 

[+9640News]

I want to put this out there.  Between @InsaneMultitasker and myself, summer is approaching and I know we both have various things that will distract our time from programming unlike the winter months.  I know we will both try to address any serious issues or concerns should they arise, but the "extras" will be on limited basis.  I really don't anticipate any serious issues as Insanemultitasker and myself have put a lot of time in testing the new code.  I know I will be doing some traveling for work, plus other "fun" traveling this summer and fall so I know time is going to be reduced on my end.

 

Anyways, that is why I have the "list" of things on 9640news.com so we can track them so they are not forgotten. 

 

The focus right now is to resolve any Geneve boot eprom issues for the new devices added and identify those fixes and barring any other significant issues, take a breather.

 

I hope everyone understands!

[+InsaneMultitasker]

4 hours ago, Schmitzi said:

oh yes here, from the manual, it looks like with and without space should be standard ?

(and the 2nd CD is wrong there, it must be CHDIR)

 

 

The manual contains errors and differences, many are not recent changes.   A space is required.

[+Schmitzi]

44 minutes ago, 9640News said:

Put the request in.  No guarantees one way or the other.  When you do, make sure you specify when a file specified by "explicit path", that the file searching does not continue looking at other path's specified by the PATH command.  I will need to look at the code to see if there is an opportunity within the current code to handle an explicit path.

 

If you would, do a test to see if entering HDS1.<BADDIR>.GDM2K loads GDM2K from a PATH, or if it gives you an error and says the file can not be found.  Use the actual device name versus drive letter to see if there is a difference.

 

 

 

Yes I entered it in a short form as the field there is to small for my input text
I added a link to this thread here.

 

And I tested what you asked:

 

(E:\WRONGDIR\GDM2K starts the not there given program, as we know)

 

G:\WRONGDIR\GDM2k also starts it

HDS1.WRONGDIR-GDM2k also starts the not-at-this-place-present program

HDS1.\\\WRONG\.GDM2K also starts it

and now it comes:

HDS12.WRONG.GDM2K also starts it (HDStwelve.)

HDSWRONG.WRONG.GDM2K starts

and

HDS3.WRONG.GDM2K (a not given disk) starts it

FANTASY:\WRONG\GDM2K starts it

 

 

 

 

 

[+jedimatt42]

When using a TIPI only system on GenMod Geneve... The first time I try to run any executable from MDOS, it fails with results like this:

 

2021-04-15 22:06:17,015 TipiDisk    : INFO     Opcode 5 LOAD - TIPI.GPL730.GPL
2021-04-15 22:06:17,016 Pab         : INFO     opcode: Load, fileType: Sequential, mode: Update, dataType: Display, recordType: Fixed, recordLength: 0, recordNumber: 16256
2021-04-15 22:06:17,017 tinames.tinames: INFO     TIPI.GPL730.GPL -> /home/tipi/tipi_disk/GPL730/GPL
2021-04-15 22:06:17,020 TipiDisk    : INFO     LOAD image size 7168
2021-04-15 22:06:18,347 TipiService : INFO     Request completed.
2021-04-15 22:06:18,359 TipiDisk    : INFO     Opcode 0 Open - TIPI.GPL730.GPL
2021-04-15 22:06:18,359 Pab         : INFO     opcode: Open, fileType: Sequential, mode: Input, dataType: Display, recordType: Variable, recordLength: 80, recordNumber: 0
2021-04-15 22:06:18,360 tinames.tinames: INFO     TIPI.GPL730.GPL -> /home/tipi/tipi_disk/GPL730/GPL
2021-04-15 22:06:18,361 ti_files.VariableRecordFile: ERROR    not a valid Variable Record TIFILE /home/tipi/tipi_disk/GPL730/GPL
Traceback (most recent call last):
  File "/home/tipi/tipi/services/ti_files/VariableRecordFile.py", line 60, in load
    raise Exception("file is FIXED, must be VARIABLE")
Exception: file is FIXED, must be VARIABLE
2021-04-15 22:06:18,363 TipiDisk    : ERROR    responding with error: 2
NoneType: None
2021-04-15 22:06:18,365 TipiService : INFO     Request completed.

All subsequent attempts work correctly.  And the subsequent attempt can be for a different file... such as MYGPL.  This happens after every fresh boot. The initial LOAD command appears to succeed, but then MDOS doesn't like something.. and tries to open as a script.. and then reports file not found.

 

The subsequent successful load transcript is below... Nothing stands out to me.

2021-04-15 22:11:08,184 TipiDisk    : INFO     Opcode 5 LOAD - TIPI.GPL730.GPL
2021-04-15 22:11:08,185 Pab         : INFO     opcode: Load, fileType: Sequential, mode: Update, dataType: Display, recordType: Fixed, recordLength: 0, recordNumber: 16256
2021-04-15 22:11:08,186 tinames.tinames: INFO     TIPI.GPL730.GPL -> /home/tipi/tipi_disk/GPL730/GPL
2021-04-15 22:11:08,188 TipiDisk    : INFO     LOAD image size 7168
2021-04-15 22:11:09,513 TipiService : INFO     Request completed.
2021-04-15 22:11:09,725 TipiDisk    : INFO     Opcode 5 LOAD - TIPI.GPL730.GPM
2021-04-15 22:11:09,726 Pab         : INFO     opcode: Load, fileType: Sequential, mode: Update, dataType: Display, recordType: Fixed, recordLength: 0, recordNumber: 16256
2021-04-15 22:11:09,726 tinames.tinames: INFO     TIPI.GPL730.GPM -> /home/tipi/tipi_disk/GPL730/GPM
2021-04-15 22:11:09,728 TipiDisk    : INFO     LOAD image size 8448
2021-04-15 22:11:11,281 TipiService : INFO     Request completed.
2021-04-15 22:11:11,444 TipiDisk    : INFO     Opcode 5 LOAD - TIPI.GPL730.GPN
2021-04-15 22:11:11,444 Pab         : INFO     opcode: Load, fileType: Sequential, mode: Update, dataType: Display, recordType: Fixed, recordLength: 0, recordNumber: 16256
2021-04-15 22:11:11,445 tinames.tinames: INFO     TIPI.GPL730.GPN -> /home/tipi/tipi_disk/GPL730/GPN
2021-04-15 22:11:11,447 TipiDisk    : INFO     LOAD image size 6400
2021-04-15 22:11:12,602 TipiService : INFO     Request completed.
2021-04-15 22:11:12,727 TipiDisk    : INFO     Opcode 5 LOAD - TIPI.GPL730.GPO
2021-04-15 22:11:12,728 Pab         : INFO     opcode: Load, fileType: Sequential, mode: Update, dataType: Display, recordType: Fixed, recordLength: 0, recordNumber: 16256
2021-04-15 22:11:12,728 tinames.tinames: INFO     TIPI.GPL730.GPO -> /home/tipi/tipi_disk/GPL730/GPO
2021-04-15 22:11:12,730 TipiDisk    : INFO     LOAD image size 6144
2021-04-15 22:11:13,851 TipiService : INFO     Request completed.
2021-04-15 22:11:13,974 TipiDisk    : INFO     Opcode 5 LOAD - TIPI.GPL730.GPP
2021-04-15 22:11:13,975 Pab         : INFO     opcode: Load, fileType: Sequential, mode: Update, dataType: Display, recordType: Fixed, recordLength: 0, recordNumber: 16256
2021-04-15 22:11:13,975 tinames.tinames: INFO     TIPI.GPL730.GPP -> /home/tipi/tipi_disk/GPL730/GPP
2021-04-15 22:11:13,977 TipiDisk    : INFO     LOAD image size 2816
2021-04-15 22:11:14,467 TipiService : INFO     Request completed.

 

The AUTOEXEC only has the 'TIMODE' statement in it... ... then I manually type:

 

assign A=TIP1:

cd GPL730

GPL

 

and it fails...

 

GPL

 

succeeds. back to mdos, GPL, succeeds... reboot, fails again.

 

EDIT: User error... the MEMEX card was not set correctly to block MEMEX RAM pages used by the TIPI.

 

Edited April 16, 2021 by jedimatt42

[+InsaneMultitasker]

The OS task loader is failing after the first file in the sequence (GPL) and is falling into the routine to open it as a batch file.  This should only happen if the DSR reports an error or the task loader runs out of memory.  Your logs do not indicate an error has occurred with the DSR and I assume you have ample memory available as the subsequent load succeeds.  I will attempt to reproduce the problem this evening with a standard Geneve + TIPI.   I was unable to reproduce the error with my 'loaded' PEB Geneve system. 

 

[+jedimatt42]

5 hours ago, InsaneMultitasker said:

The OS task loader is failing after the first file in the sequence (GPL) and is falling into the routine to open it as a batch file.  This should only happen if the DSR reports an error or the task loader runs out of memory.  Your logs do not indicate an error has occurred with the DSR and I assume you have ample memory available as the subsequent load succeeds.  I will attempt to reproduce the problem this evening with a standard Geneve + TIPI.   I was unable to reproduce the error with my 'loaded' PEB Geneve system. 

 

 

Ok, my issue was a user-error situation. I didn't have the dip switches on the MEMEX card set correctly to block the series of pages that conflict with TIPI memory mapped ports and DSR. 

 

Sorry about that.

[+Schmitzi]

 

Request #11 Allow empty lines in AUTOEXEC

For a better orientation in and much easier formatting the AUTOEXEC here the request that empty lines should NOT be handled as errors, and should NOT output errors on running the batch. Separating program sections just with some empty lines massively can help while reading through and programming any source code.

 

Thanks

 

[+9640News]

1 hour ago, Schmitzi said:

 

Request #11 Allow empty lines in AUTOEXEC

For a better orientation in and much easier formatting the AUTOEXEC here the request that empty lines should NOT be handled as errors, and should NOT output errors on running the batch. Separating program sections just with some empty lines massively can help while reading through and programming any source code.

 

Thanks

 

Try using an ECHO statement between sections, but nothing after the ECHO and see if that solves the issue.

[+Schmitzi]

10 minutes ago, 9640News said:

Try using an ECHO statement between sections, but nothing after the ECHO and see if that solves the issue.

 

yes that´s what I´m doing instead of the empty line, using REM

but that´s not so clear separated with text, instead of one or more empty lines

Especially if you scroll through some text/code

 

I thought maybe it´s not a big problem to solve that, as it is just an empty line. I hope so

 

 

 

[+InsaneMultitasker]

35 minutes ago, 9640News said:

Try using an ECHO statement between sections, but nothing after the ECHO and see if that solves the issue

I have a note in the old 6.50 source file to consider adding the following test to hclis after label vari99.  Never tested, maybe add this info to item #11 comments for future consideration when we are looking at the parser holistically.

*
* is it a label?
*
       CB   @CBUF,@COLON      yes, ignore it (no echo, either)
       JEQ  COMMAN

       CB @cbuf,@H00    null line?  (see start of parse/read code)
       JEQ  COMMAN       skip

[+Schmitzi]

 

great

 

( I think I cannot make changes to #11 on www.@9640News.com, but maybe Beery can this ? )

 

 

[+9640News]

On 4/17/2021 at 1:30 PM, Schmitzi said:

 

Request #11 Allow empty lines in AUTOEXEC

For a better orientation in and much easier formatting the AUTOEXEC here the request that empty lines should NOT be handled as errors, and should NOT output errors on running the batch. Separating program sections just with some empty lines massively can help while reading through and programming any source code.

 

Thanks

 

Next release, an empty line will be skipped over in the processing.  @InsaneMultitasker identified the code with the necessary changes.

[+InsaneMultitasker]

On 4/18/2021 at 2:00 PM, 9640News said:

Next release, an empty line will be skipped over in the processing.  @InsaneMultitasker identified the code with the necessary changes.

For historical reference, the batch file processor reads each line from the file and appends a null (0x00) character to it.  The parser was not testing for a null character (blank line) and instead treated it like a command or file.  The fix was to trap that null and skip any further processing.

[+Schmitzi]

 

thanks a lot !

 

I have another one, just dismiss it if it´s crap

 

#12 The DIR command should show directories first...

       ...and files secondary. Maybe just an optical thing only for a stressed user

 

please discard and forget about #12, I think I booted an old MDOS version ?

On v7.30, it lists like a charm ? so I dismissed it by myself

 

 

[+Schmitzi]

 

I have a question concerning batches.

 

I see that I can use the ">" sign to route screen output into a file.

This is very useful for many things.

But, is there any way to get input from a file, maybe like "<" in MS-DOS ?

I tried it here, but no gain. Or I am doing something wrong.

 

The "<" is very useful for batch programming, but I can imagine that it is very hard

to introduce this to MDOS if not given yet.

 

thanks

 

 

[+mizapf]

I guess this will sooner or later require a redesign of the MDOS shell with internal and external commands, that is, by moving functionality out of the shell into files that need to be loaded at runtime. Maybe one could consider something like a RAM disk cache for more frequently used commands.

[+Schmitzi]

25 minutes ago, mizapf said:

I guess this will sooner or later require a redesign of the MDOS shell with internal and external commands, that is, by moving functionality out of the shell into files that need to be loaded at runtime. Maybe one could consider something like a RAM disk cache for more frequently used commands.

 

Ah OK, yes I don´t want it if it is much work. That´s not worth it. I thought it´s "just routing the input" or so ?

Maybe I can try to do some small programming in ABASIC for that if needed.

 

[+mizapf]

No, it was just a thought I had a while ago already, and your suggestion shows that it could be something worth considering for later releases of GeneveOS and its MDOS shell.

[+9640News]

Just throwing this out there.  There are a lot of could of, would of, should of, etc great ideas out there.  There is nothing stopping someone from writing their own utilities to process and/or redirect input/out commands, or any other feature. 

 

If someone is serious about wanting to work on updating some features or capabilities within MDOS itself, you are more than welcome to join the team!!!! I know I speak for myself, and I think @InsaneMultitasker would concur though I do not speak for him, if someone is serious about updating MDOS, we would encourage more hands on deck!!!

 

I know for myself, I have some personal projects I want to work on.

 

Beery

 

[+mizapf]

Your exclamation key is bouncing.

 

Just to be clear: These are no "do it now!" points, no need to get into distress. I understood that we all are open to post our ideas, and maybe we can/should collect them, pick some of them for the next release, maybe I can help with programming, too. As time allows me.

[+9640News]

12 minutes ago, mizapf said:

Your exclamation key is bouncing.

 

Just to be clear: These are no "do it now!" points, no need to get into distress. I understood that we all are open to post our ideas, and maybe we can/should collect them, pick some of them for the next release, maybe I can help with programming, too. As time allows me.

No, I wasn't in distress.  Just simply pointing out that others are more than welcome to take the plunge and help if they feel like it.

[+FarmerPotato]

On 4/20/2021 at 4:46 AM, mizapf said:

I guess this will sooner or later require a redesign of the MDOS shell with internal and external commands, that is, by moving functionality out of the shell into files that need to be loaded at runtime. Maybe one could consider something like a RAM disk cache for more frequently used commands.

What is the issue with putting external commands in your batch file? I have “external” commands in my AUTOEXEC which fine tune the screen, and batch files that run GenProg. 
 

I suppose it would be hard to disentangle FORMAT to remove it to an external?