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.