Geneve OS development discussion

[+retroclouds]

1 hour ago, InsaneMultitasker said:

I was driving the other day and we were behind this white Chevy.  The plate caught my attention; I chuckled at the thought (albeit unlikely) that I might be following the author of our Geneve's Infocom interpreter.  

 

 

Sorry, don’t want to derail. Just couldn’t resist. Berlin band Modeselektor

 

 

And now back to your usual MDOS development… 😁

[+InsaneMultitasker]

18 hours ago, retroclouds said:

Sorry, don’t want to derail. Just couldn’t resist. Berlin band Modeselektor

The song reminds me of an old school demo program. As for the video content, well, I don't think I'll get that 4 minutes back...  

 

[+Ksarul]

On 4/28/2023 at 6:33 PM, InsaneMultitasker said:

The song reminds me of an old school demo program. As for the video content, well, I don't think I'll get that 4 minutes back...  

 

And now I have yet another Berlin group making music to hunt down. . .I like it.

[+InsaneMultitasker]

MDOS initializes the RS232 ports during a reset.  A table manages the settings for the serial and parallel ports.  While documenting the source, I realized that the powerup routine is not using the correct table entries. 

 

In the code snip below, >0300 is loaded into the RS232 control register. I believe this means 8 bits, no parity, and 1.5 stop bits.  I think MDOS should be changed to initialize the control register to >8300 for 8N1.  And I see no option in the OS to set 1.5 stop bits; only 1 or 2 stop bits are allowed by the MODE and OPEN routines. 

 

 

 

* port status flags . . each port gets 12 words . .
*  first 12 words are last status stuck in buffer
*  2nd words are current port characteristics
*
STATAB DATA STAR1,STAR2,STAP1,STAR3,STAR4,STAP2
STAR1  DATA >0300,>01A1,0,0,0,0
       DATA >0300,>01A1,0,0,0,0
STAR2  DATA >0300,>01A1,0,0,0,0
       DATA >0300,>0034,0,0,0,0              9600 baud default

[+mizapf]

I seem to remember this 1.5 setting when I used the "serial bridge" to communicate with the emulated Geneve via the PC serial port. ...

 

wait ...

 

remembered correctly. Only appears after pressing Ctrl-Alt-Del, not after initial booting.

[+dhe]

Nice catch @InsaneMultitasker - from modem days I remember 8n1, 7e2 - but never did I ever see 1.5!

[+FarmerPotato]

28 minutes ago, dhe said:

Nice catch @InsaneMultitasker - from modem days I remember 8n1, 7e2 - but never did I ever see 1.5!

I think 1.5 and 2 stop bits were a teletype thing. Amounts to an extra tiny delay after the character. A Stop bit is HIGH, an idle state, so the extra half won't matter. Unless the receiver insists on its being HIGH for that long. The next start bit must be  LOW and it's that HIGH to LOW transition that resets the receiver sampling. 

 

 

TI 9902 sample code in books has yet another delay at end of line, to accommodate the TI 733 KSR or ASR hard-copy terminal. (300 baud, too.)

 

 

[+InsaneMultitasker]

36 minutes ago, mizapf said:

remembered correctly. Only appears after pressing Ctrl-Alt-Del, not after initial booting

This is a good clue for me.  The reason I started looking at the tables is that my AUTOEXEC no longer contains a MODE RS232/1:38400 statement, yet the OS is initializing the port at 38.4K, contrary to what is seen in the table and contrary to what I recall from earlier releases.  I have not yet determined the reason nor will I delay the 7.40 release for this.  I am a bit perplexed though...

[+mizapf]

Yes, the settings after cold booting (and Ctrl-Shift-Shift) are 38400, 8N1, as I can see in the serial bridge monitor window. Also, the 1200-8N1.5 appear after "&" in the command line.

[+Ksarul]

50 minutes ago, FarmerPotato said:

I think 1.5 and 2 stop bits were a teletype thing. Amounts to an extra tiny delay after the character. A Stop bit is HIGH, an idle state, so the extra half won't matter. Unless the receiver insists on its being HIGH for that long. The next start bit must be  LOW and it's that HIGH to LOW transition that resets the receiver sampling. 

 

 

TI 9902 sample code in books has yet another delay at end of line, to accommodate the TI 733 KSR or ASR hard-copy terminal. (300 baud, too.)

 

 

1.5 stop bits were indeed intended for use with old-school teletypes, but oddly enough, that was only the nearest possible approximation of the teletype's intended number of stop bits: 1.42. That value gave the mechanical parts of the teletype just enough time to come to a readiness standstill (quiescence) for it to be ready to accept the next character. That also allowed it to work just a "touch" faster than it would have if they'd rounded up to 1.5 bits at a time when 45.5 BAUD was a normal line speed. I used to work on those beasties BITD. . .

[+InsaneMultitasker]

1 hour ago, mizapf said:

Yes, the settings after cold booting (and Ctrl-Shift-Shift) are 38400, 8N1, as I can see in the serial bridge monitor window. Also, the 1200-8N1.5 appear after "&" in the command line.

The MODE command appears to make the baud rate persistent until another MODE command is executed or a cold restart of the OS. This is probably intentional. 

 

Walking through the RS232 code reminds me of the opening to Infocom's Sorceror; I feel that I have entered the Geneve OS's "twisted forest"...

[+9640News]

I want to post a caution to any users using PI Version 3.11 with MDOS 7.30!!!!!

 

@jedimatt42 fixed an issue with the release of 3.11 and the method the MDOS COPY command uses to copy files.  It was an obscure issue nobody else has detected as it was so infrequently used by other programs.  Prior versions of the PI software, V3.10 or earlier, MDOS would issue an error when copying files to/from another device using the MDOS COPY command.  Disk Managers like Clint Pulley's Directory Manager or Fred Kaal's GDM2K had no issues with PI Software 3.10 or earlier.  It is only with the MDOS COPY command.

 

With PI Version 3.11 and MDOS 7.30, copying a file to the TIPI will result in the last sector of the file being either corrupted, or in my testing, all >00 bytes.

 

@InsaneMultitasker resolved the fix in MDOS 7.40 which has not been released, but will be shortly.

 

So, if you are using a TIPI with the Geneve, use Directory Manager or GDM2K to copy files to your TIPI device and do not use the MDOS COPY command until 7.40 MDOS is released.

 

[+InsaneMultitasker]

@9640News, I sent you my remaining "cosmetic" OS updates and comments for the 7.40 release. I will check a few utilities for updates since April 2021 and let you know if I think any should be included.

 

2 hours ago, 9640News said:

 MDOS 7.30, copying a file to the TIPI will result in the last sector of the file being either corrupted, or in my testing, all >00 bytes.

As best I can tell, I was trying to fix two related problems but only 'knew' there was one. I wish I had written a simple separate test program last year.  It was very tempting to redo the COPY command to utilize the FDR like all other programs, except for the record-to-block IO that is intertwined with the routines. That is, the CON, RS232, and PIO devices.  All's well that ends well. 

 

[+InsaneMultitasker]

First post has been updated with a link to the MDOS 7.40 (and 7.30) release topic.  Shared below as a point of reference.  

 

[+dhe]

What's the easiest way to suck the Geneve OS source code from GitHub in to a TIPI and Compile?

[+9640News]

16 minutes ago, dhe said:

What's the easiest way to suck the Geneve OS source code from GitHub in to a TIPI and Compile?

I am not sure what the tool is, but there is a github application I run on my Windows system that will retrieve all the source files in the MDOS folder to a Subdirectory on your PC hard drives.  All the files are ".txt" files without the ".txt" file extension.

 

Drop/copy those files into a TIPI folder. I use the Windows manager with drive mapping to the TIPI.  I do not use the web interface myself. In PI.CONFIG, designate the TIPI folder to be a NATIVE_TEXT_DIRS .  Files in that folder without a TIFILES header will be treated as a DIS/VAR 80 file.  You can then use GenASM/GenLINK to compile and link the files from the TIPI folder.  Or, you can use GDM2K to copy those files to a folder on another device with copying those files back to a standard directory, they will end up with a FDR/TIFILES header as a DIS/VAR 80 file and can be assembled/linked from that device.

 

I am out of town on business for another week or so, and I looked at @jedimatt42's information on the WIKI and it was limited on the details for the format of the NATIVE_TEXT_DIRS line you need  in your PI.CONFIG.  I know Matt detailed it in the development area for the TIPI a week or two before MDOS 7.40 was released if you want to search AtariAge for the informaiton.

 

Beery

 

[+mizapf]

57 minutes ago, dhe said:

What's the easiest way to suck the Geneve OS source code from GitHub in to a TIPI and Compile?

The tipi should already contain the git command. Try this on the tipi:

 

$ cd ~/tipi_disk
$ git clone https://github.com/BeeryMiller/MDOS

 

This creates an MDOS subdirectory that you can read with the Geneve and TIPI support. However, I noticed that all text files are visible as "DIS/FIX128". Is that intended? Or are they lacking a TIFILES header?

[+9640News]

There are no TIFILES header on the files on GitHub for the MDOS source files. 
 

 

[+mizapf]

This is slightly uncomfortable, as they do not show up as DIS/VAR 80 files on the TIPI drive when you access them from the Geneve. I suppose you don't use a header for direct editing on the PC.

[+InsaneMultitasker]

45 minutes ago, mizapf said:

This is slightly uncomfortable, as they do not show up as DIS/VAR 80 files on the TIPI drive when you access them from the Geneve. I suppose you don't use a header for direct editing on the PC.

If I understand correctly, the likely solution is noted a few posts earlier:  leverage the TIPI setting for "NATIVE_TEXT_DIRS".  I would suggest reading the linked thread (below) for some background information.  I have not tried this setting on my system, but I have used the "?W" option on which this is based.

 

[+mizapf]

Ah, OK. Sorry, I did not follow the thread - will try when I return to my system in a few days. Thanks for the pointer.

[+jedimatt42]

https://github.com/jedimatt42/tipi/wiki/PI.CONFIG#native-text-directories

 

I thought the BASIC example for adding a dir to the list provided unambiguous detail.

[+9640News]

9 hours ago, jedimatt42 said:

https://github.com/jedimatt42/tipi/wiki/PI.CONFIG#native-text-directories

 

I thought the BASIC example for adding a dir to the list provided unambiguous detail.

My thought process, and it may be different from others, was that I use an editor to load PI.CONFIG.  From there, I make my changes rather than with a Basic program.  Simpler to visualize......

[+mizapf]

OK, this worked as promised.

 

I edited the tipi.config file by setting "NATIVE_TEXT_DIRS=MDOS.". All text files in the MDOS folder (which was created by git) are now shown as DIS/VAR 80. Using the git command should be the easiest way to pull the GeneveOS sources.

 

The only left issue is that MDOS shows a subdirectory "/git" on DIR which is of course the .git subdirectory on the TIPI. Maybe you could add a feature that allows to hide that subdirectory from the TIPI directory display (if that is not already possible - I'm getting cautious about what I may have missed in the descriptions).

[+InsaneMultitasker]

My Horizon RAMdisk needed a bit of charging so I poked around MDOS for a bit, and updated the Change Directory (CD) command.  It now attempts to validate the existence of the desired folder on any valid device.  A few of you have asked for this and it will be in the next release, barring any issues.