Geneve OS development discussion

[+9640News]

@dhe and @InsaneMultitasker

 

Right now, I do not know how many people are making use of the native files feature.  I wrote @jedimatt42 a note in the tipi development thread.

 

The original aim when I proposed to Matt the native files option, was to make moving back and forth source files from github much easier.  We have a few options depending upon how versatile Matt desires to leave the same or expand upon this feature.  Right now, I think it keeps PROGRAM image files as PROGRAM image files, but it looks like it treats everything else as DIS/VAR 80.

 

I had after the source code to MDOS 7.40 was released, revised the !MAKEFILE and the HDOS\HDOSL file for the assembly and linking process so that OBJ files would be dropped into its own separate destination folder which can be outside the native folder path.  I did this as I maintain the source files on my HRD for the quickest process for assembling and linking.

 

The second option that could be done, is to copy the contents of the native files folder to another path on the TIPI.  Then, you can assemble everything on the TIPI without an issue if users want to assemble on the TIPI.

 

Beery

 

 

[+9640News]

1 hour ago, InsaneMultitasker said:

@9640News Unrelated to the native_text issue...

I can confirm that ASM is at fault for incorrectly opening the catalog file.  If the list filename parameter is empty, ASM parses the current directory and attempts to open it as OUTPUT, D/V 80.  As we all know, the catalog file can't be opened in OUTPUT mode so the Geneve DSR returns an error and ASM continues on its way.  It is only thanks to the excellent logging in the TIPI that we see this oddity.  ASM is protected by CRC traps and pitfalls so for now, this is noted for awareness.  We can only guess as to whether this was an oversight or intentionally ignored. 

 

I wonder if this was an attempt to verify a valid file path?  or maybe it may have been something needed for the old Myarc Personality card in the earlier stages of MDOS development????

 

 

[+InsaneMultitasker]

I like the approach where the file types besides DV work with TIFILES, if possible. It already seems to work this way, otherwise the file copies would have resulted in all of the object files being converted to native files. Even if the decision is to limit the file type, the native folder is really slick for source code….

[+jedimatt42]

The posted update should fix your TIPI issue.

 

 

 

[+dhe]

Given what I have learned in the last week about TIPI and native_dirs, I decided to re-work things a bit.

 

TIPI will now have a directory called GIT - it's will have native_dirs, I won't "work" in it, it will only be used for git cloning.

 

The new cycle will be:

   cd GIT

   git clone https://github.com/BeeryMiller/MDOS

 

   copy contents to root of tipi and do things.

 

GeneveOS build Question:

   In MDOS there used to be a command testh - it was a program that loaded a newly built HDOS.

   It was in the root of the build directory.

   Now, the only testh, is in the hdos, and it's a dv80.

 

 

 

[+InsaneMultitasker]

@dhe it is possible that the git repo doesn't have the program. @9640News will need to confirm. The folder in your screenshot is for the source to TESTH, TESTM, etc, (which are used to set the correct boot device flag during testing) although it seems the program and DF80 object files should be in the folder. I don't think they are part of the MAKE process.

[+InsaneMultitasker]

In @9640News repo, it seems the "program" files are 2 bytes, so maybe they didn't come across as expected.  In my dev folder, I keep the test program and a test batch file in the MDOS root, so I can just type "test" to load the newly-assembled OS.

[+dhe]

As an aside,

  When cloning a repo, it's probably best as soon as you do the git clone to remove the .git directory.

 

 

[+InsaneMultitasker]

@dhe I kicked off a full assembly of the OS, using the TIPI native_text folder.  About 30 seconds into the process, $MAKE tossed its cookies with an error message, "Don't know how to make "ZXZXZXZXZXZZXZXZXZXZXZZXZXZXZXZXZZXZXZXZXZXZZXZXZXZXZXZZXZXZXZXZXZZXZXZXZXZXZZXZXZXZXZXZZXZXZXZXZXZ" (the X was some graphics character). So there is still something it doesn't care for with one or more files, or a difference in how the data is consumed by $MAKE.  Not to be dissuaded, I kicked off the batch file that assembles everything; MDOS is so-far successfully grinding through the source files now. I'll report back in this same post whether the resulting OS starts up properly.   

The $MAKE issue was due to incorrectly (inadvertently) using MDOS 7.30 instead of MDOS 7.40. 

 

[+dhe]

@InsaneMultitasker received the same error.

 

started with MAKE HDOS,F - It starts, I can see it reading TIPI  and then it just stops.

 

 That's after upgrade to 3.19 on tipi.

 native_dirs = GIT.

 clone MDOS

 delete .git from tip1.git.mdos

 using the latest GDM2K to copy to TIP1.MDOS.

 MAKE HDOS,F

 

 {Head Scratch}

 

  I noticed, the assembler was saying #0101 John Birdwell.

 

  I modified my path to just be I: (no other directories).

  I restarted with MAKE HDOS,F

 

  This time, I received, don't know how to make ZZZZZZZZZZZZ.

  But, it didn't lock up, and I'm being told assembler is #2000 MDOS Developer.

 

  It did complete this time, but no HDOS was created?

 

 

 

 

[+InsaneMultitasker]

2 hours ago, dhe said:

It did complete this time, but no HDOS was created?

It looks like yours stops in the same place as mine. If you inspect !DOIT, you'll see it stops in the L8\ range of files.  The remaining assembly and link statements are missing.

 

The TIPI log shows something weird with the direct input file IO in the native_text file folder.  The start block is incrementing by one or more, for each subsequent file, until it reaches DSRPASS-S and then $MAKE locks.  I can CTRL-C the $MAKE program, so this isn't a TIPI DSR lockup but it may be induced by TIPI (or MDOS DSR) IO.  Edit: I am going to assume this is related to MAKE crashing as I cannot yet reproduce it.

 

I created a non-native folder and was able to assemble MDOS properly, from the TIPI, with all TIFILES headered files.  I don't have any more time this morning to dig into this, but I'll circle back in the evening.   Edit: The OS file was not created. this may be related to a /4a PAB limitation, since the OS program file is 136K.  I  have some work to do, I'll test more later.

Edited July 15, 2023 by InsaneMultitasker
Further updates

[+InsaneMultitasker]

Lest I forget the lesson I learned today: if you are using TIPI and have not updated your Geneve OS to 7.40, your first order of business should be to update your system. If you aren't sure what OS version you are running, type "VER" at the command line and update accordingly.  If your autoexec clears the screen, consider adding a VER statement near the end of the file.  

 

Earlier today, I discovered that the PFM in my development Geneve is still loaded with MDOS v7.30. As best I can recall, I updated my test Geneve, got distracted by 'life', and forgot to follow through to update the more important Geneve.    Some (though not all) of what I and others have recently experienced can be traced back to the bug that affected the COPY command in v7.30. 

[+9640News]

3 hours ago, InsaneMultitasker said:

@dhe I kicked off a full assembly of the OS, using the TIPI native_text folder.  About 30 seconds into the process, $MAKE tossed its cookies with an error message, "Don't know how to make "ZXZXZXZXZXZZXZXZXZXZXZZXZXZXZXZXZZXZXZXZXZXZZXZXZXZXZXZZXZXZXZXZXZZXZXZXZXZXZZXZXZXZXZXZZXZXZXZXZXZ" (the X was some graphics character). So there is still something it doesn't care for with one or more files, or a difference in how the data is consumed by $MAKE.  Not to be dissuaded, I kicked off the batch file that assembles everything; MDOS is so-far successfully grinding through the source files now. I'll report back in this same post whether the resulting OS starts up properly. 

I got a message from Tim where I think this message is related to using MDOS 7.30 instead of 7.40.

I just did a full MAKE from the TIPI, with only one issue.  In file HDOS\HDOSL, the PSAVE command that saves the HDOS file containing the assembled MDOS version, must have a path set to something other than the TIPI.  This is due to a 4A limitation on the PAB of 64K with the opcode being used as MDOS is > 64K.

 

On one other note, if you do find you do get that error, do a MEM immediately after to see how much memory is still free.

[+dhe]

Hi,

 I've not really kept up with the development of MDOS support for the TIPI - just mainly using it as a mass storage device with network connectivity.

 

  But, what is this 4A limitation you speak of:

    >"This is due to a 4A limitation on the PAB of 64K with the opcode being used as MDOS is > 64K."

 

  Since the only mass storage I have sitting with the Geneve is the TIPI, can you ID what I would need to change, in order to build to a floppy drive?

[+9640News]

27 minutes ago, dhe said:

Hi,

 I've not really kept up with the development of MDOS support for the TIPI - just mainly using it as a mass storage device with network connectivity.

 

  But, what is this 4A limitation you speak of:

    >"This is due to a 4A limitation on the PAB of 64K with the opcode being used as MDOS is > 64K."

 

  Since the only mass storage I have sitting with the Geneve is the TIPI, can you ID what I would need to change, in order to build to a floppy drive?

I hope I can get this explanation right.  @InsaneMultitasker can correct me if I get something wrong.

 

All file I/O on the 4A with the TIPI has a PAB that with two bytes of that PAB for filesize.  On the Geneve, DSR PAB's for the XOP use three bytes for filesize.  So, to save a program image file > 64K requires 3 bytes to pass that information.  Unfortunately, the TIPI to PI interface does not allow this.  Insanemultitasker was able to work around most of the differences between 4A and Geneve PABS, but I think this was one issue that could not be overcome.

 

As far as building on the TIPI and changing to a floppy drive, edit the file HDOS\HDOSL

 

Right near the end, after all the COPY directives but before the EVAL directives, there is a PSAVE command.

 

It present is something like:

 

PSAVE HDOS\HDOS,14,0,P_LAST+4*>2000

 

Change HDOS\HDOS to DSK1.HDOS

 

Now, the file HDOS will be saved to DSK1. and will be the newly created image.

 

 

[+InsaneMultitasker]

1 hour ago, 9640News said:

I hope I can get this explanation right

Makes sense to me. What is peculiar to me is that the TIPI log has no record of the attempted operation and no OS error is generated. The file's byte size is >22000, so masking the high byte should yield a >2000 byte file. The MDOS DSR's error trap looks for a zero byte file and jumps to an error routine, but the error code is not set.  Some follow-up is needed on these MDOS opcodes.  It's rare that anyone wants to save or load a 0-byte file.  

 

I suppose there is a way around the /4a PAB limitation but I'm not sure that I want to go down the path. The MDOS version of the TIPI load/save opcodes could be re-written as 2-part BREAD and BWRITE operations. The first to read/write the file attributes and the second to read/write the file.  

Edited July 15, 2023 by InsaneMultitasker
clarifications

[+jedimatt42]

4A PABs don't talk much about actual file size in bytes... except for PROGRAM LOAD / SAVE. But here, you must have already changed the TIPI DSR for LOAD and SAVE as my implementation only works off of buffers in VDP. Implementing this in terms of whatever front you have for Direct-Input and Direct-Output 

 

But if you want to keep to the LOAD and SAVE opcodes.. I could fix the TIPI python side to understand a 3rd byte... If I where to guess, you probably send the high byte in byte 5 of the PAB just before bytes 6/7, the normal number of bytes to save/load... ( edit: Oh, but the single message size limit for TIPI is also 64k )

 

The only issue I'd have, is if 4A software has any history of dirty PABs that have junk left in byte 5 ( or whichever one you expect it to be... )... Is there any other bit set that indicates the extended mode for the PAB? 

 

---

My direct-write can only write 64k at a time, but it can have a starting block address anywhere in a 16Meg file. So you could delegate to that as is, in 3 TIPI operations. 

 

 

[+InsaneMultitasker]

Thank you for sharing that 3rd byte idea.  That would certainly make it simple.  though my concern echos yours: modifying the /4A-style Pab could open up some unintended consequences for LOAD/SAVE; even the Geneve does not extend these opcodes while emulating the /4A.

 

For the limited use case that is the Geneve native DSR mode, my initial thinking was to leverage the direct read/write routines in a different way, thus mimicking the SAVE/LOAD opcodes.  An alternative might be two new Python opcodes that mirror load/save, but allow for the third byte in some currently-undefined location. 

 

All Geneve-based TIPI operations occur in 256-byte increments due to how the DSR is structured, incuding load/save/direct read/direct write.  Direct read/write  iterate over the number of 256-byte blocks presented, which is why we can copy and perform other operations, and only now realized the limitation with save/load because the OS presents three bytes, whereas the /4a PAB only affords us two. 

[+InsaneMultitasker]

On 7/3/2023 at 7:43 AM, mizapf said:

Yes, you could save on "Ignored". Like in the Unix world, no news is good news, so any kind of message is a warning or an error.

 

But this is a great and long-awaited enhancement. Can't tell you how many times I misspelled the directory name when using CD.

 

I removed 'Ignored' from the warning and shared the source file with 9640News, for testing purposes.  We haven't talked much about how to leverage Github or how to address changes like this that could be released for testing, in advance of a formal release.

 

My PFM device is loaded with v7.40 and after using the modified CD routine for a few days, I realize that I now miss the feature for the reason you cited. 

[+InsaneMultitasker]

Maintenance update for EXEC based on my recent activity with the 'FinalGROM simulation' loader.

 

Both EXEC28 and EXEC28DOC are TIFILES format.  I included a copy of the notes as a text file, see change log excerpt: 

 

- Keyscan table is no longer passed back to the OS, with exception of the
  CAPS and NUMLOCK status.  This resolves 'phanton' keypresses upon re-entry
  and with certain scan modes. (The keyboard state table was incorrectly
  being preserved for all depressed keys).  For example, After loading EXEC
  once, the second or third time could result in an unexpected reboot at the
  command line.  
- Holding SHIFT-SHIFT-CONTROL (or ctrl-alt-del) too long on exit will no longer restart system. 

 

EXEC V28 released 13August2023.zip

[+InsaneMultitasker]

Source code for the most recent release of GENCFG has been uploaded to the Horizon Ramdisk github repository.  These are text files without an extension, copied directly from my TIPI 'native text' folder, so they are immediately viewable and searchable via github. 

 

Horizon-Ramdisk-ti994a/GENCFG at master · horizonramdisk/Horizon-Ramdisk-ti994a (github.com)

 

[+Schmitzi]

8 hours ago, InsaneMultitasker said:

Source code for the most recent release of GENCFG has been uploaded to the Horizon Ramdisk github repository.  These are text files without an extension, copied directly from my TIPI 'native text' folder, so they are immediately viewable and searchable via github. 

 

Horizon-Ramdisk-ti994a/GENCFG at master · horizonramdisk/Horizon-Ramdisk-ti994a (github.com)

 

 

Hi,

as I am losing the overview a little bit and am never sure if I found the correct file on GutsHub  ,

will there be a complete distribution with a future v7.4x with all the recently updated files like:

ABasic, GPL, TSTAT, EXEC, GenCFG, Editors, PFMup, Cya, MemTest, CRCOS7, 

and whatever has been changed ? (Did I forget one ?)

Maybe divided into 2 .DSKs, 1 Boot and 1 Util or so ? (Can I help with that?)

 

SubQuestion: Is there a running version of this new GENCFG v1.5 (or just the source code) ?

If so, how can I download it ? (there is a mass of files on Github and I only land on the sourcecode in the end)

 

thanks

xXx

 

[+9640News]

40 minutes ago, Schmitzi said:

 

Hi,

as I am losing the overview a little bit and am never sure if I found the correct file on GutsHub  ,

will there be a complete distribution with a future v7.4x with all the recently updated files like:

ABasic, GPL, TSTAT, EXEC, GenCFG, Editors, PFMup, Cya, MemTest, CRCOS7, 

and whatever has been changed ? (Did I forget one ?)

Maybe divided into 2 .DSKs, 1 Boot and 1 Util or so ? (Can I help with that?)

 

SubQuestion: Is there a running version of this new GENCFG v1.5 (or just the source code) ?

If so, how can I download it ? (there is a mass of files on Github and I only land on the sourcecode in the end)

 

thanks

xXx

 

I believe everything you mentioned is in the 7.4 distribution as a zip file. As things are being distributed here and on 9640news.com and not on a bbs where would Xmodem download, everything pretty much has to go through a web browser for download. The zip format makes the most sense for distribution so that users can use the various utilities they use to move the files over to their devices. I do not have plans to make Dsk images as then you get into the issue of 90k, 180k, 360k, or maybe even 720k and 1.44mb formats. It can easily get out of control with such a large distribution of files. 

[+InsaneMultitasker]

Th first post of this topic has links to the release posts.

[RickyDean]

Oh @InsaneMultitasker, going into your Github above, as I move to your wiki at https://github.com/horizonramdisk/Horizon-Ramdisk-ti994a/wiki, I find an issue. When I click on the hotlink 

• GenCFG - Geneve configuration/formatter with disk and 'ramHD' partition support; see MDOS 7.30 release (https://www.9640news.com/mdos/mdos-7-30-released/)

I get a page not found report. FYI.

  Thanks for your contributions to our hobby.