Jump to content
InsaneMultitasker

Geneve OS development discussion

Recommended Posts

Genmod question:  The SCSI low level routine checks for the Genmod and if present, forces the SCSI IO transfers to use byte moves (MOVB).   Is this limitation imposed by the Genmod or the SCSI card?   I am now wondering if changing the Horizon ramdisk IO from byte to word transfers will be a problem for Genmod Geneves?

 

TIPI Update:  Level 2 redirection of TIPI mapped drives 1-4 has been implemented and early testing has been successful.  Archiver is able to protect/unprotect files and copy to/from TIPI mapped drives.  I'm not sure how useful level 2 will be with many (most?) level 2 enabled programs requiring direct sector IO, and the OS supporting all opcodes natively.    The PFM/Horizon/internal ramdisk code and HFDC floppy code optimization was needed sooner than I had planned because there were only 8 bytes available in this segment.  :(   

 

 

  • Like 2

Share this post


Link to post
Share on other sites

I like, uh..full.. especially in a tank of gas, or finishing that rare steak.

but when it comes to news on geneve and TIpi and it's, SUCCESS...FULL tests,  man I'm overwhelmedFULL...

Share this post


Link to post
Share on other sites

I have had to take a step backwards on the booting from a TIPI version of the boot eprom.  It was working on my hardware, but not on a beta tester.  When I started stripping hardware from my test system, I discovered it would not then boot.

 

Now, I have bracketed the non-working code, and I believe it is tied up in a DSRLNK call.  Just need to understand what I need to do differently.

  • Like 5

Share this post


Link to post
Share on other sites

2/8 weekend update:

1. @BeeryMiller (re)integrated his TIPI XOP routines into the TIPI DSR.  MyTerm TIPI functions properly.  XOP powerup not yet implemented.

2. TIPI DSK0,1,2,3,4 level2 and level3 redirection is implemented and for all intents and purposes is ready for more stringent testing.   TIPI DSK0. is available from Geneve and /4A modes.  Setpath is disabled pending review.  The very complex COPY command requires some rework to enable mapped drive copy.  

3. Added code to reset TIPI powerup flag from Geneve and /4a modes.  When cleared, the TIPI DSR is primed for a powerup upon the next access.  The powerup is disabled pending review of the XOP powerup.

4. HARD command changed to HFDC to remove command ambiguity.

5. Completed TIPI DSR file cleanup and removed hard-coded addressing between master DSR and TIPI DSR code. 

6. Identified reason for some commands echoing results when ECHO OFF is set:  two different flags, only a handful of commands are truly silent.

7. Spent too long tracking random corruption while working in the new OS.  Finally reproduced the steps needed to generate the errors and lockups; it all seems to have been caused by executing an MDOS COPY command from within the Genprog LINK program.  MDOS 2.21 and MDOS 6.50 exhibit the same problem with the LINK program.  Test results sent to Beery for confirmation; crossing fingers in the meantime.

8. Requests documented for consideration: Remove version CLS;  Change Directory validation.  

 

With the exception of #7, the OS feels relatively stable.  A few more updates and some support utility tweaking are needed before the first test version is released.

 

and... a bit of positive hardware-related trivia:

Both Beery and I have been developing, assembling, linking, and testing the Geneve OS and related programs using our Horizon RAMdisks as the workhorses.   The cards have been very stable.  Many thanks to @Ksarul and @FALCOR4 for their efforts last year to make this a reality!  Having nearly 24,000 sectors of RAM-based "hard drive" space is very nice indeed.

 

  • Like 11

Share this post


Link to post
Share on other sites
8 hours ago, InsaneMultitasker said:

2/8 weekend update:

7. Spent too long tracking random corruption while working in the new OS.  Finally reproduced the steps needed to generate the errors and lockups; it all seems to have been caused by executing an MDOS COPY command from within the Genprog LINK program.  MDOS 2.21 and MDOS 6.50 exhibit the same problem with the LINK program.  Test results sent to Beery for confirmation; crossing fingers in the meantime.

 

Just a FYI, the issue Tim identified is not specific to GenPROG Link as I have been able to observe the same behavior in another program and requires a specific set of circumstances to duplicate.

 

  • Thanks 1

Share this post


Link to post
Share on other sites
5 hours ago, BeeryMiller said:

Just a FYI, the issue Tim identified is not specific to GenPROG Link as I have been able to observe the same behavior in another program and requires a specific set of circumstances to duplicate.

 

I believe I found a solution and just sent Tim what believe is the fix.  Very obscure bug accessing routines in the CLI from another program, which very few people use.

  • Like 5

Share this post


Link to post
Share on other sites
6 hours ago, BeeryMiller said:

I believe I found a solution and just sent Tim what believe is the fix.  Very obscure bug accessing routines in the CLI from another program, which very few people use.

Confirmed, so far all is working well.

 

This spurred me to look into why GENASM would not assemble and link on the TIPI drive.  I sent you an updated source file that so far (for me) has fixed the problem.  When the /9640 DSR detects an invalid device, it traps the error however, sometime long ago, maybe even before the MDOS buyout, the wrong label was used.  The 9640 mode routine was being directed into a /4A mode floppy drive error trap, where it then tried to flush the nonexistent file and report an error via level2 0x8350 in "PAD" ram.  It isn't clear to me why we rarely see any ill effects or why TIPI was adversely affected, though the answer may lie in how Genasm unconditionally closes files whether they were opened or not, calling sector IO routines the TIPI does not implement.  

  • Like 3

Share this post


Link to post
Share on other sites

I certainly don't intend to document the entire OS in this manner, however, I thought it would be nice to create a few visuals along the way. 

 

This diagram depicts the Geneve reset sequence at a high level.   (Sorry, poor ol' Visio 2003 has its limitations - I may need to update if I make any more diagrams.)

 

image.thumb.png.32759979a53d19d9717e7fb18a47ed1b.png

  • Like 7

Share this post


Link to post
Share on other sites
17 hours ago, InsaneMultitasker said:

I certainly don't intend to document the entire OS in this manner, however, I thought it would be nice to create a few visuals along the way. 

 

This diagram depicts the Geneve reset sequence at a high level.   (Sorry, poor ol' Visio 2003 has its limitations - I may need to update if I make any more diagrams.)

 

image.thumb.png.32759979a53d19d9717e7fb18a47ed1b.png

Thanks for making this! 

 

What takes it to the third row?

 

Share this post


Link to post
Share on other sites
27 minutes ago, FarmerPotato said:

Thanks for making this! 

 

What takes it to the third row?

 

The process box of the same color on the second row calls each XOP powerup  -- key, video, memory, io, and other xops.  I couldn't figure out how to duplicate the tab so for now, only the IO xop powerup is documented.  Edit: ah, the small circle on the left, in the third lane, should read DSR XOP -  I must have fat-fingered that when I edited the text. 

Share this post


Link to post
Share on other sites

You can't do it with fat fingers and colors make a difference.lol

 

 

 

 

 

 

 

FB_IMG_1613354044893.jpg

Edited by GDMike
  • Like 3
  • Haha 1

Share this post


Link to post
Share on other sites

Weekend update 2/14:

1. Beery released Advanced BASIC v4.05 files, source, manual.  Memory boundary issue identified during DSR testing; resolved for v4.06. 

2. Updated floppy format routine [format-p3] to account for changes to the disk device mappings and for TIPI devices.  Updated error trap to report an error for all devices except TI, CC, Myarc FDC and HFDC floppies.  Format table extended to device 27.

3. Updated remap routine to allow for setting persistence as follows [dsrpass-s, sect2-p]:

-- Drives 1-4 remap at system powerup and and warm restarts based on the identified controller at >1100

-- Drives 5-9 will default to the OS settings at powerup. Once remapped, the settings are now persistent across Geneve and /4a modes until a full system restart (ie, poweroff or SHIFT-SHIFT-CTRL).  The same persistence may be applied to drives 1-4 in the future.  

-- All drive mappings may still be over-ridden by CYA settings. The out-of-the-box setting is to defer to the OS's internal mappings.  

--Edit: DEFMAP has been deprecated in favor of DRVMAP for persistence.

--Caveat: the system remap routine is only called when there is an hfdc in the system. This helps to explain past problems people reported with their remaps. Fix is under review.

4. Traced DSR powerup routines to better understand how the OS,  TIMODE/GPL, and EXEC use the various entry points. 

5. Traced HFDC Emulate file initialization. Identified what looks like an old remap flag. Further research is needed to understand a poorly documented parameter block table. This table is not referenced consistently within the OS.

6. (Re-)learned another ugly lesson about Geneve OS ; the DSR routines jump between source files and routines like a rabbit on steroids. Very easy to break a routine in one file if you are not aware of dependent BRANCHes from another file.  Documenting these instances as they are found.  

7. Primary DSR code segment at >2000 is littered with AORG's.  There is no warning if code overlaps.  Halted further development in this 8k segment to investigate

8. Add: Changed L8. filenames for the RS232 routines;  all files are now groups with prefix "RS".  Further filename cleanup will occur in the future to re-align source and object code, remove some of the old "play" suffixes, and bring some consistency to source file naming. 

9. Add: See post #33, fixed incorrect return "the 9640 mode routine was being directed into a /4A mode floppy drive error trap"

  • Like 5
  • Thanks 2

Share this post


Link to post
Share on other sites

 

Hi, I am just a beginner, but I think problems like

- ghost subfolders (where you can enter with CD but they are not existent) and

- "ghost" files (not really ghost, but if I have a dumb typo at a MDOS-command there suddenly is a file....)

are well known ?

 

---------------------

 

Is it possible/does it make sense to make "CD.." working, too ? (Without the space in between = "CD .."  ). 

Same then for "CD\" next to the "CD \"  command

This is like it works in MS-DOS, it handles both commands/syntax´, but I think MDOS cannot do that

as it sees "CD.." as 1 command that cannot be parsed...

 

---------------------

 

I have not checked in MDOS yet, but just another thought here:

In MS-DOS you can do a "parallel folder jump" - i.e. "CD ..\folder2"  while you are at folder1:

 

C:\FolderXY\--folder1

 "        "      \--folder2

 

OK, just checked it, this works on the Geneve 🤩

 

---------------------

 

Are there environment variables available or any "trick"  maybe ?

I would like to do a "SET DIRCMD= /P"  (or better "SET DIRCMD= /P /O:GEN👀  )

to have the DIR command stopping 🔚 the screen at output everytime

 

---------------------

 

I saw the command "CAPS ON" somewhere around in a batch file, where can I find this nice tool ?

All the harddisks that I have unpacked do not seem to have it.

 

Maybe it can easily be done in the OS ? Just set to "ON" would be OK (for me :grin: )

I cannot see a reason 😎  not to press Alpha-Lock when booting the OS, so maybe some userclicks can be saved :)

 

---------------------

 

Not important, just saying.

 

thanks

 

 

 

  • Like 1

Share this post


Link to post
Share on other sites

Tim,

  I think your Weekend update 2/14 and diagrams are very helpful.

  While most of us will never reach the guru status, there is the hope, some could serve the same purpose as the Linux janitors, and help document and clean up code. Putting the file names after the updates, very helpful.

   Beery, any chance you could republish your MDOS programming notes or are they out there and I just don't know where?

  • Like 2

Share this post


Link to post
Share on other sites

 

1 hour ago, dhe said:

Tim,

  I think your Weekend update 2/14 and diagrams are very helpful.

  While most of us will never reach the guru status, there is the hope, some could serve the same purpose as the Linux janitors, and help document and clean up code. Putting the file names after the updates, very helpful.

   Beery, any chance you could republish your MDOS programming notes or are they out there and I just don't know where?

All of the programming notes are captured in the GenPROG documentation for all the XOP's.  The best reference, and what I use, is at: Index of /Geneve.new/Documents/GenASM (whtech.com)

 

If there is something else you need, let me know.


Beery

  • Like 2

Share this post


Link to post
Share on other sites
1 hour ago, dhe said:

While most of us will never reach the guru status, there is the hope, some could serve the same purpose as the Linux janitors, and help document and clean up code. Putting the file names after the updates, very helpful.

Some of the filenames will change to more logically group files together by function or segment, while others will simply have their old suffixes updated to remove the 'play' designation.  I recently changed the RS232 filenames to group them together - their original names were "A1", "B2" etc.  The updates help me/us to revisit what was completed.  My spiral notebook is hard to decrypt after a few weeks ;)

 

  • Like 1

Share this post


Link to post
Share on other sites

>If there is something else you need, let me know.

 

I'll look this coming weekend, and see if I have the notes you passed out when you taught intro to MDOS programming at the fairs.

  • Like 2

Share this post


Link to post
Share on other sites
14 hours ago, Schmitzi said:

Hi, I am just a beginner,

Will review these at a later date once the DSR updates and review are complete.  The OS command line isn't overly sophisticated, so some things may just require the user to know the difference between correct and incorrect syntax.  :) Also, the routine to -parse- the command line commands and path.filename is intricate so even minor changes can break other programs.   This has to do in part with supporting the 'DOS' style devices\directories like  C:\DOS\FILE as well as the TI style  DSK1.FILE convention.

  • Thanks 1

Share this post


Link to post
Share on other sites
26 minutes ago, dhe said:

>If there is something else you need, let me know.

 

I'll look this coming weekend, and see if I have the notes you passed out when you taught intro to MDOS programming at the fairs.

I think I had the programming class one time at either the Lima or Chicago shows.  Whatever notes I provided at that time are long gone, and are now more encompassed by the GenPROG docs.


Beery

  • Thanks 1

Share this post


Link to post
Share on other sites

Beery alluded to some ABASIC testing a few days ago.  The Geneve OS allows for 10 open disk-based files.  GPL resets this maximum to 3 but doesn't restore the max to 10 upon return to the OS (which is a different issue to resolve) and so this old, elusive bug was encountered by coincidence. 

 

Basically, the DSR routine tests for available buffer slots whenever a file is opened.  If the file is found or an open slot is found, the routine continues processing.  However, if no buffer is available, the routine returns 0x0000 in R3. The open opcode tests R3 and if==0, branches to an error handler.  Unfortunately, the error handler clears *R3 which in this case means the OS reset vector or task vector is cleared. The system locks up when a soft reset is executed.  The fix was to branch one instruction later, bypassing the CLR *R3.  I copied some trace notes for the curious.  ;)   

 

 

Routine COMPAT checks for an open disk buffer via PG2VEC routine 16  (yea, this needs documenting badly)
COMPAT returns R3=0 if there is no buffer found. 
Another branch made to OPEN opcode. DSR checks for open status. It then checks R3.

L8.OPEN&LS2

ISNOPN MOV  R3,R3             is there a free buffer?
       JNE  BUFOK             yep, we can open the file
       B    @BADOP4
 

No buffer available (we used all available based on NUMFIL count).

 

Now we branch to BADOP4
L8.SYSRTN-P

BADOP4 LI   R10,>8000
       JMP  CNBOP1

 

which jumps to the error trap: 

CNBOP1 CLR  *R3
CNBOP2 MOVB R10,@MYPAD+>50
       JMP  CNBOP
*
Notice - R3 is 0 at this point. So we are clearing address >0000 which is the OS page 0 or CLI page 0 at this point. So when we try to reset, crash.
Same thing happens in GPL though you need to do a hard exit from XB to the GPL title screen.  If you do that after the error, GPL will not let you back into 4A mode nor can you exit to MDOS.
 

 

  • Like 4

Share this post


Link to post
Share on other sites

Maybe also well-known (?) :

 

on MDOS650, i.e. when I make a

DIR AU*

then the result is like AUTOEXEC, AUTOXY, AUTOBLA

PLUS

ALL SubDirs are listed (not just the ones that start with AU)

 

Share this post


Link to post
Share on other sites

 

Another thought:

 

Is there a command to list only the subdirectories ?

 

Like   DIR *.    in MS-DOS ?

 

 

  • Like 1

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...