Geneve OS development discussion

[+InsaneMultitasker]

For test purposes,  @9640News compiled a version of GeneveOS/MDOS that does not rely upon the fast ram expansion.  I am happy to report that using a slow page of RAM for the SCSI/IDE/RamHD buffers works and the speed difference seems negligible for normal operations.  Neither Genmod Geneves without the Memex nor stock Geneves without the extra 32K SRAM can load and run the latest MDOS iteration, so this option has so far allowed me to troubleshoot cards without resorting to MDOS 2.21.  We'll investigate this further as a potential, future option.

[+9640News]

For curiosity, and I know there are some folks out there, who is stuck on MDOS 2.21 because they do not have the memory expansion to run the newer MDOS versions like 6.50 and 7.30?

 

Beery

[+Ksarul]

One of my machines fits that description. The other one has the 32K and video RAM upgrades.

[+dhe]

 

@9640News according to 9640news.com, MDOS730 was released on April 5, 2021.

   I was wondering when the source code was going to be released, or do you plan on keeping this release closed source?

[+9640News]

It will be released with the next update as there is some cleanup needed.  It will not be closed source.  @InsaneMultitasker and myself are working on several things with the source at the moment.

 

The XOP for the TIPI calls will be fully documented.  In fact, that document for the "GenPROG" package is already written and complete, however it is not good for 7.30, rather for the next release as the updated TIPI XOP calls will allow multiple simultaneous connections that 7.30 did not.  As nobody has inquired about actually using those calls at the present, it has not been a big issue.

 

Beery

[+dhe]

  Two other items:

   1) Is the GenAsm manual PDF'ed some where?

             If not, I can do that thing, if it wouldn't cause problems, and assuming the XOP documentation hasn't changed?

   2) Is Video Fast / Video Slow still a thing?

        I have it marked in my notes as deprecated since V1.5

      

[+9640News]

2 minutes ago, dhe said:

  Two other items:

   1) Is the GenAsm manual PDF'ed some where?

             If not, I can do that thing, if it wouldn't cause problems, and assuming the XOP documentation hasn't changed?

   2) Is Video Fast / Video Slow still a thing?

        I have it marked in my notes as deprecated since V1.5

      

9640news.com under manuals, already in PDF.

 

I think it is there, test it.

 

[+dhe]

Thoughts on filename {X} Extension Separators?

 

TI really didn't have a recommendation on file extensions.

On the Geneve / and . are used almost interchangeable, with . being the predominate filename extension separator in MSDOS.

 

One standard I've seen a lot of on the TI was use of ; - as in cprog;c or cprog;s.  - Unfortunately ; isn't really liked (though it works with "") in MSDOS filenames.

 

The other option that seems popular on the Geneve is: _ as in cprog_c.

 

Unfortunately with _ the version of Peter Muy's editor I use doesn't properly display _ - but that can be worked around.

 

So... What's 9640 news preference as a separator?

 

-----

 

Bug?

 

>DIR    <- Works

>{space}DIR   <- No Work

 

Can an ltrim be added?

 

 

 

 

[+TheBF]

I started using a comma as the next best thing to the '.'

Like ';' it works but still looks a little odd.  

[+mizapf]

I think the safest way for extension separation is the underscore, and I'm using it wherever possible.

[+9640News]

1 hour ago, dhe said:

Thoughts on filename {X} Extension Separators?

 

TI really didn't have a recommendation on file extensions.

On the Geneve / and . are used almost interchangeable, with . being the predominate filename extension separator in MSDOS.

 

One standard I've seen a lot of on the TI was use of ; - as in cprog;c or cprog;s.  - Unfortunately ; isn't really liked (though it works with "") in MSDOS filenames.

 

The other option that seems popular on the Geneve is: _ as in cprog_c.

 

Unfortunately with _ the version of Peter Muy's editor I use doesn't properly display _ - but that can be worked around.

 

So... What's 9640 news preference as a separator?

 

I use whatever is comfortable at the moment depending upon the task.  Sometimes just tailing the source code for the program with an S if I have not already hit the 10 character limit.  Myself, I do not use the semicolon.

 

[+InsaneMultitasker]

I append an S for source, O for object, and have a batch file that does the rest of the work.  I have followed the same convention for decades now.

For example, I have a bat called "AS" that contains this line:  ASM %1S,%1O,,RCO

To assemble a file, I type "AS FILE" which turns to "ASM FILES,FILEO,,RCO"

I rid myself of all the slashes, underscores, etc long ago. And, it means my source filenames can have up to 9 characters. 

 

@dhe are you using SL and LL to save and load files in Peter's editor?  If not, that is the problem.  SF and LF compress the document with RLE encoding of a sort.  I use Peter's editor for all of my development.

[+InsaneMultitasker]

18 hours ago, 9640News said:

It will be released with the next update as there is some cleanup needed.  It will not be closed source.  @InsaneMultitasker and myself are working on several things with the source at the moment.

Agreed. It won't take 20 years but it won't be tomorrow.

[+FarmerPotato]

Are there conventions for where native GeneveOS programs can look for things? Like graphics, CHARA1 fonts? 

For starters, how does a program find out the boot volume? 
 

When loaded from a directory in PATH, how does a program find itself? Suppose it needs to access some files in its folder like a CHARA1. 

If there is a preferred CHARA1 file, could a program assume it’s on the boot volume next to SYSTEM/SYS? Or when it’s trying to get proper text chardefs, should it just make the VIDEO xop for that? 
 

 

 

 

Finally, what would be a logical place to put TI Artist fonts that could be shared? Just invent a FONTS directory on the boot volume? Searching PATH seems inefficient. 
 

I’ve converted the TIGA fonts (TI graphics standard on PC)  to BMP format— to show that it can be done. Other formats when I figure them out.  I guess if I wanted two programs to share them, I would just start a convention like

 

\TIGA\FONTS\09\AUSTIN
\TIGA\FONTS\09\CORPUSCHR
\TIGA\FONTS\09\HELVETICA
\TIGA\FONTS\12\AUSTIN
\TIGA\FONTS\12\CORPUSCHR
\TIGA\FONTS\12\HELVETICA
\TIGA\FONTS\12\MATH

 

on the boot volume.

 

Like 9640News I’m disliking file extensions. But the TI-Artist extensions, _C and the like, I’m used to. Similarly cartridge files. 

Note: there’s only one font at   7 pixels high, Luckenbach 5 pt, suitable for Text mode.   The 9 point fonts have descenders that go outside a 8x8 cell. 12 pts go 14-16 pixels with true descenders. TI’s default font was Corpus Christi 12. These are all bitmaps. 

 

 

 

 

 

[+9640News]

Right now, CYA which was just released, is the one way to change character fonts in the newest MDOS 7.30. I believe there is a video XOP where you can redefine character definitions so that is another part.

 

FYI, CYA has presently been manually edited for sector/byte offset in the SYSTEM-SYS file to know locations where to patch things.  I actually have an idea I floated by @InsaneMultitasker this past week about an embedded table for a new CYA version that would in the future be version independent.  I have laid that part out on the table, however it does have some challenges as MDOS uses more 8K pages than the original SYSTEM-SYS is.  There is some data segments moved into other parts of the file that are unpacked upon loading.  I will have to get creative with some math and managing some data segments to make it all work.  I haven't started placing the labels in the other source files to use as a number of the labels are in some source files @InsaneMultitasker is presently editing and I need to wait on those changes.

 

MDOS itself when it first boots does not know from what device it booted from on its own.  It thinks it booted from DSK1.AUTOEXEC, unless it sees a specific two byte flag in the onboard 9995 ram that is placed there by the booting LOAD-xxx file.  If it matches the two bytes, then it will look for the HDS1, IDE, SCS, TIP device 1.AUTOEXEC file.

 

MDOS does not know anything about locations to CHARA files.  it is up to the running program to have the ability to either prompt for the location/name of the file or to be hard coded to a path/filename.  When you type something at the CLI, it first searches the CLI routines (TYPE, DIR, PATH, FORMAT, COPY, TELNET, etc).  If it finds it, then it uses that program code.  The listing of those calls are at the end of CLI\HCLIS  source file.  If the text typed is not one of those calls, then it searches the current path using the UTIL XOP Parse filename to use the current path and looks for the filename at that path.  If it is not there, then it starts searching with the PATHS (if any) that are defined by the PATHS command.  This is done within the CLI\HCLIS "Command Line Interpreter", aka the Prompt for MDOS.

 

Now, MDOS itself does sorta knows at what drive letter/directory it is currently sitting.  So, if one is loading a MDOS program (not TI-99/4A program), the author of the program can use the UTIL XOP for Parse Filename to add the prefix with path/directory of where one is currently sitting to load additional files.  Otherwise, the program and user would need to be prompted for the device/path/filename to load, etc.

 

Hopefully, this makes sense.

 

Beery

 

 

 

 

 

 

 

[+dhe]

Need to check for a scsi dsr, if not found, issue a device error message when ever a scsi device is accessed.

 

"  Long ago, a DSR EPROM was not required to use the SCSI card with a Geneve.  I think we've moved beyond that and if validation hasn't already been added to 7.3x as part of the in-process cleanup, the code should be added before a next release.  Can someone please add this issue to the Geneve OS development thread if it is not a MAME issue? "

[+mizapf]

Ehm, I seem to remember we once planned to have something like a repository for GeneveOS on Github or so, including an issue tracker system ...

[+InsaneMultitasker]

@9640News has an enhancement tracker on his web site.  The github repository is not yet public and this thread will still serve as a catch-all for issue discussion.

[+9640News]

I have created a github repository for MDOS 730 issues.

 

BeeryMiller/MDOS730-Issues (github.com)

 

Click on the issues button to add items.

[+dhe]

Does @9640news still offer a $100 bug bounty for each bug found? ?

 

 

[+InsaneMultitasker]

On 4/27/2022 at 5:49 PM, dhe said:

Need to check for a scsi dsr, if not found, issue a device error message when ever a scsi device is accessed.

 

"  Long ago, a DSR EPROM was not required to use the SCSI card with a Geneve.  I think we've moved beyond that and if validation hasn't already been added to 7.3x as part of the in-process cleanup, the code should be added before a next release.  Can someone please add this issue to the Geneve OS development thread if it is not a MAME issue? "

 

OK, I reviewed a backup of my Geneve OS development files and as of June 2021, much of the new powerup/detection is already in place. 

 

The new routine does not allow the OS-based DSR to access a SCSI device if the card itself is missing a DSR EPROM.  This aligns with the future intent that the IDE, TIPI, and SCSI card may be placed at most any valid CRU address.  It also allows the DSR to use TIPI DSK1-4 in place of a floppy controller, if the TIPI is at CRU >1100.  (See SCSI and TIPI code snips in spoiler)

 

This also means that many of the hard-coded CRU restrictions implemented since MDOS 2.50S will be removed, though a few are necessary due to their function e.g., RamHD devices will remain at >1400 and >1600. 

 

 

 

; File: POWERS, SCSI Powerup and detection routines w/FINDNAME common code
; Date: 26 June 2021
;
; 6.26.2021 Removed genmod/detect from SECTOR_S; updated SCSI_S and MAKEFIL
;           Combined tests for card, version, and genmod
;           Incorporated SCSI ID test from SCSICOM; removed from SECTOR_S
;           (Does not yet perform any buffer/page/setup for OS)
;
SCSCRU   DATA 0            ;detected CRU for SCSI card
SCS1NAME    BYTE 4
            TEXT 'SCS1'
            BYTE 0
;-----------------

; SCSI Powerup Routine
;      Does NOT execute a card powerup at this time
;
; *** must reset GENSET or integrate into powerup ***
;
SCSPWL DATA SPWS,$+2     ;blwp?
       LIMI 0
       ABS  @GENSET      already called?
       JEQ  SCSPW2       no, do it
       RTWP              yes, exit (fix when we integrate powerup to OS)


SCSPW2 BLWP @INITRS      ;debug via rs232
       BLWP @XMTEXT
       DATA PWRINIT

       SETO @CACHE#HIGH  invalidate read cache
       SETO @P#S#HIGH    "    "     write 'cache'

       MOV  R12,@SR12
       MOVB @>F112,@HBA+1
       MOVB @HBA,@>F112

;----temp hardcode [current OS]
;;     LI   R12,>1200    ;hardcode, for now
;;     MOV  R12,@SCSCRU  ;hardcode
;;     SBO  0            ;turn on
;;     JMP  DETECTSCSIVER
;;
       BL   @FINDNAME    ;R12=CRU of card; 0 if not found
       DATA SCS1NAME     ;if found, card is left on! <<<--important

       MOV  R12,@SCSCRU  ;save cru for device driver
       JNE  DETECTSCSIVER     if <>0, we found the card
       B    @DETEXIT          if ==0, exit

 

=-=-=-=-=-=-=-=-=

L8\DSRPASS

;4.18.2021  REMAP routine updated; TIPI DSK1-4 mapped active if CRU==1100
;           See linkage and REF's to tipi code

 

;4.17.21, TIPI remaps if card at >1100
       LI   R4,HTIPDD         check for tipi first
       C    @TIPCRU,@CR1100   tipi page must be at >6000 to work
       JEQ  REMAP1

       LI   R4,H0102     FDC default
       CI   R12,>1100    hfdc at >1100? see flpprm
       JNE  REMAP1         no
       LI   R4,H0A0B       yes,default to hfdc floppy

REMAP1 MOVB *R4+,*R3+    set dsk1-4 remaps
       MOVB *R4+,*R3+
       MOVB *R4+,*R3+
       MOVB *R4+,*R3+

 

 
 

 

[+InsaneMultitasker]

@mizapfidentified a problem with the SCSI direct sector read/write routine that trimmed a 24-bit sector number to the least significant 16-bits.  Reading/writing sector >10000 resulted in accessing sector >0.  Not cool. 

 

The high order byte of the sector number is stored in PAB byte 14 during direct sector operations.  The label for this byte is "SCNOFF" and the documented DSR operation is "screen offset".  This sounds all well and good, except the Geneve DSR does not use nor require a screen offset.  Furthermore, the status opcode >09 uses this byte to return a file status.   Sometime between MDOS 6.50 and 7.30, I consolidated a few routines and was saving a value into byte 14 for all operations; that was the wrong approach due to incorrect internal documentation.  Fortunately, this error only affected sector read/write programs and not other internal MDOS operations.  I've fixed this issue and identified a few related concerns to follow-up on.

 

@9640News sent me latest updates to code he has been updating and enhancing.  We are starting the process of validating our changes as schedules allow.  There are a few DSR-cleanup activities that need to be completed before we release a test version. 

 

I've mentioned rs232debug output so here are a few examples used during recent validation work: 

 

 

 

Example of a file save operation showing the SCSI driver caching the 512-byte physical sector in order to concatenate each saved 256-byte sector.  Sector 0 is never cached.

 

File Save:

AU:   READ: 0000 1170
AU:   WRITE: 0000 1170  (force read-no skip) (Read before Write)
AU:   WRITE: 0002 1240  (force read-no skip) (Read before Write)
AU:   WRITE: 0002 1241  (cached) (skip read) (L15 entry)
AU:   WRITE: 0002 1242  (force read-no skip) (Read before Write)
AU:   WRITE: 0002 1243  (cached) (skip read) (L15 entry)
AU:   WRITE: 0002 1244  (force read-no skip) (Read before Write)
AU:   WRITE: 0002 1245  (cached) (skip read) (L15 entry)
AU:   WRITE: 0002 1246  (force read-no skip) (Read before Write)
AU:   WRITE: 0002 1247  (cached) (skip read) (L15 entry)
AU:   WRITE: 0002 1248  (force read-no skip) (Read before Write)
AU:   WRITE: 0002 1249  (cached) (skip read) (L15 entry)
AU:   WRITE: 0002 124A  (force read-no skip) (Read before Write)
AU:   WRITE: 0002 124B  (cached) (skip read) (L15 entry)
AU:   WRITE: 0002 124C  (force read-no skip) (Read before Write)
AU:   WRITE: 0002 124D  (cached) (skip read) (L15 entry)
AU:   WRITE: 0000 1170  (force read-no skip) (Read before Write)

 

 

Example of reading the root directory (no files) of SCS3.  Ah, each directory operation must read the entire bitmap to determine the free/used sectors - 32 31 sectors worth. 

 

Read directory:

DSEL: 0003  READ: 0000 0000  Parameter (direct)F800 20E6 0000 7000
AU:   READ: 0000 0040
Direct:   READ: 0000 0001
Direct:   READ: 0000 0002
Direct:   READ: 0000 0003  (cached)
Direct:   READ: 0000 0004
Direct:   READ: 0000 0005  (cached)
Direct:   READ: 0000 0006
Direct:   READ: 0000 0007  (cached)
Direct:   READ: 0000 0008
Direct:   READ: 0000 0009  (cached)
Direct:   READ: 0000 000A
Direct:   READ: 0000 000B  (cached)
Direct:   READ: 0000 000C
Direct:   READ: 0000 000D  (cached)
Direct:   READ: 0000 000E
Direct:   READ: 0000 000F  (cached)
Direct:   READ: 0000 0010
Direct:   READ: 0000 0011  (cached)
Direct:   READ: 0000 0012
Direct:   READ: 0000 0013  (cached)
Direct:   READ: 0000 0014
Direct:   READ: 0000 0015  (cached)
Direct:   READ: 0000 0016
Direct:   READ: 0000 0017  (cached)
Direct:   READ: 0000 0018
Direct:   READ: 0000 0019  (cached)
Direct:   READ: 0000 001A
Direct:   READ: 0000 001B  (cached)
Direct:   READ: 0000 001C
Direct:   READ: 0000 001D  (cached)
Direct:   READ: 0000 001E
Direct:   READ: 0000 001F  (cached)
Direct:   READ: 0000 0000
AU:   READ: 0000 0040  ---   root FDIR (file descriptor index record)

 

Example of reading SCSI ID4 for the first time and then reading a few sectors.  MDOS reads sector 0 each time, so there is no caching.

 

Direct sector IO via XOP:

Direct:
DSEL: 0000  READ: 0000 0000  Parameter (direct)F800 20E6 0000 7000
Direct:   READ: 0000 0000
AU:   READ: 0000 0000
Direct:   READ: 0000 0000
AU:   READ: 0000 0001
Direct:   READ: 0000 0000
AU:   READ: 0000 0002
Direct:   READ: 0000 0000
AU:   READ: 0000 0003
Direct:   READ: 0000 0000
AU:   READ: 0000 0004

 
 

 

[+dhe]

@InsaneMultitasker are you going to leave rs232 debugging code in place? As a conditional compile? Inserted as needed? Maybe a permanent XOP in MDOS?

 

@9640News I don't remember seeing it as asked anywhere, but is the rs232 debugger code still active in V2 of the boot EPROM?

[+9640News]

1 hour ago, dhe said:

@InsaneMultitasker are you going to leave rs232 debugging code in place? As a conditional compile? Inserted as needed? Maybe a permanent XOP in MDOS?

 

@9640News I don't remember seeing it as asked anywhere, but is the rs232 debugger code still active in V2 of the boot EPROM?

The V2 debugger code I do not think is there. I do not think my compile had the code. Tom Freeman’s Debugger was a separate program and more advanced.  There is also Bruce Hellstrom’s BHDMV program which is a good debugging tool as well. 
 

The RS232 debugging code @InsaneMultitasker Mentioned is not XOP code. It is something temporarily added in a specific segment of code and accessed with BLWP’s to reference specific labels, registers, etc. 

[+InsaneMultitasker]

4 hours ago, dhe said:

@InsaneMultitasker are you going to leave rs232 debugging code in place? As a conditional compile? Inserted as needed? Maybe a permanent XOP in MDOS?

 

It is temporary, as mentioned above however, my intention is to retain some of the more helpful output via a conditional compile. @9640News showed me how to do this with GenASM some time ago, I just haven't taken that next step. 

 

(Edit: to clarify, my code is debugger output and is not interactive.  It works well because you can access the RS232 output without "turning on" the card and causing a conflict.  This is the same approach I used to debug the internals of the Horizon ROS from within)