Geneve OS development discussion

[+dhe]

I also managed to create an interesting result.

 

F:\something\something

 

ASSIGN F=TIP1 (NO ":)

 

Unless there is a desire to go over three character root device names with a number - I think we should check that the 5 character is a : and if it's not report and error and return before sending the request on down to the assign code.

[+InsaneMultitasker]

1 hour ago, dhe said:

ps... I read the MDOS730 documentation - it seemed to indicate you can assign drive letters up to the letter P:

Yes. Use LASTDRIVE = P to set the maximum.  The variables, path, assigns, etc are all stored in a linked list of limited space within the OS.  The maximum drive is set to a lower value by default.  The use of equals sign "=" is inconsistent in one or two commands, and may require spaces where others require no spaces.  I think LASTDRIVE requires the space before and after the equal sign; it is one of a few minor irritants IMHO that might be more easily changed.

[+dhe]

DM bug report:

 Under certain conditions you can back space over the Path: prompt.

 

[+dhe]

Any chance of moving some of GeneveOS in to C?

[+9640News]

On 6/16/2022 at 4:19 PM, dhe said:

ps... I read the MDOS730 documentation - it seemed to indicate you can assign drive letters up to the letter P:

 

I have in my AUTOEXEC file:

 

LASTDRIVE = P

 

(space before and after the equals sign).

 

If there is not a space as above the way you typed it, it interprets it as an 11 character filename that can not exist.

 

 

[+InsaneMultitasker]

The SCSI card powerup routine has been isolated and tied into the OS powerup routine via XOP 8 (DSR).  It only took 28 years but who's counting.  The hard-coded CRU references are now dynamic, meaning that in theory, the SCSI card can now reside at any CRU. 

 

To recap recent powerup and device modifications:

1) TIPI can now reside at any CRU and if it is located at >1100, the floppy drive remaps for DSK1-4 are adjusted to use the TIPI disk 'emulation'.  /4A mode (GPL) 0x8370 usage needs to be verified. 

2) IDE can now reside at any CRU.

3) SCSI can now reside at any CRU.  Its powerup must happen before the HFDC, since both cards contain the same "WDSx" device names and subprogram linkage. 

4) The /9640 mode SCSI interrupt handler is hard-coded to >1200.  This still needs some special linking for a dynamic CRU and when space permits, a /4A mode handler is needed.

5) DSK1 emulation is still restricted to the HFDC.  The code is intertwined and in its current state, I see no way to tie the SCSI/IDE/RamHD into this emulation.

6) Conditional debug flags have been added to TIPI and SCSI low level routines, so that the rs232debug output can be excluded from the release version. 

7) Error trap for non-existent floppy device at >1100 is partially implemented.  Error traps for TIPI/SCSI/HFDC need to be validated.

SCSI low level code cleanup and cleanup is progressing.  I am 99% convinced a change is required in the write cache routine to resolve what looks like a possibility of corruption if two file writes are interleaved on the same device. I'm not all that keen on testing this one until other work is complete. Most of the other needed changes are implemented, some have been documented in earlier posts.

9 ) The IDE device driver has been updated to fix a few lingering concerns.  Testing is necessary before it is considered finished.

10) The SCSMAP command now invalidates the drive parameters so that the old device parameters are not applied to a newly mapped device.  There is a second set of parameters that identifies whether or not the SCSI drive has been 'started'; this needs to also be invalidated, though I haven't decided on the best way to do this.  I am thinking that if the drive parameters are unknown, the SCSI driver should invalidate the drive start flags at that time. This would keep the code self-contained in the driver and minimize interference to the IDE and RamHD parameters.

11) @mizapf and I have been discussing the MFM hard drive RESTORE command usage. Those of you who use (or used) an HFDC would recognize this by the sometimes-long seek operation that occurs during an OS warm or cold reset, or entering/exiting GPL and EXEC.  The RESTORE command moves the heads from their current position to TRK000 (cylinder 0).  As best we can tell, this is not needed once the system is turned on, meaning the delay that sometimes comes with this seek can be eliminated.  The RESTORE step rate and drive step rate are separately encoded in MDOS.  The CYA parameter for hard drive head step rate setting would be deprecated if the restore is removed.  For reference, when an MFM hard drive is formatted, its step rate is stored in sector 0 (VIB) at byte 14.  MDM5 asks the user for this step rate during the format operation.  Alas, the head step values are not well documented (0=FAST, buffered mode;  1-7 are pulsed step rates of increasing delays) which could mean that people are setting their step rates too slow/too fast.  

 

[+InsaneMultitasker]

On 6/16/2022 at 3:46 PM, dhe said:

ASSIGN F=TIP1 (NO ":)

 

Unless there is a desire to go over three character root device names with a number - I think we should check that the 5 character is a : and if it's not report and error and return before sending the request on down to the assign code.

The assign command is not limited to a device.  For example, you can "ASSIGN F=TIP1.DOS" to access the DOS subfolder with "F:".  The trailing semicolon is not used in the assign in this case.  Add the semicolon for simple devices and it should work as expected.   If you try to enter a relative path without a semicolon, the parser may give you an assignment that you don't expect. 

[+InsaneMultitasker]

"Finished" reworking the SCSI device code to concurrently invalidate a device's parameters /and/ startup sequence whenever SCSMAP is used, no warm restart is required.  

 

Here's a snapshot showing the powerup sequence and detection debug output for SCSI, IDE, and TIPI in /9640 mode.  /4A mode powerups are a bit squirrely and inconsistent with /9640 mode (translation, I strongly dislike having to deal with two environments).  The floppy detection disable code (for when there is no controller present) isn't working but as soon as it is, I'll pull the disk controller and set TIPI to >1100.  I'm curious to see how well a diskless system functions.  That's all for my long weekend... 

[+InsaneMultitasker]

Last night, I removed my Myarc FDC and ramdisks from the PEB, and changed the TIPI from cru >1800 to >1100.   Whenever I accessed the TIPI, the card's LED turned on but nothing seemed to happen.   After much fretting, it turns out that the RS232 was being reset by the DSR powerup (I had changed the powerup order from DSR->TIPI to TIPI->DSR).  The TIPI access was working but the debug output at 300 baud was so slow that I thought the system locked up. A "MODE RS232/1:38400" brought things back to normal.  The TIPI mappings worked as expected and I was able to catalog TIPI's emulated DSK1. as A: without any remap command. 

 

There are still a few quirks with the detection routines that I will work through this weekend. 

[+9640News]

OK, going to post this out there for review/comments regarding the TIPI XOP support for the next version of MDOS.  Please note this document does NOT apply to MDOS V7.30.

 

If there are programmers that may make use of the TIPI XOP opcode calls, please review and see if I have overlooked something, or if there is other potential you may like to see.

 

Beery

GenREF-TIPI.pdf

[+InsaneMultitasker]

1 hour ago, 9640News said:

OK, going to post this out there for review/comments regarding the TIPI XOP support for the next version of MDOS.  Please note this document does NOT apply to MDOS V7.30.

Nice work, Beery.  The document lays out quite a lot of info.  I had two comments after reading:

 

1) Can you elaborate on the second assumption?  I did not follow what this means.

In the preceding example, two hidden assumptions were made. First it is assumed that Hostname or IP address is located on a page which is currently mapped into a memory page which has the same 16-bit address page number as its Virtual address page number (read the section on Memory Management). The second assumption is that TIPI is actually at the virtual address TIPI, not in some overlay segment with a different virtual address.

 

2) For opcode >11, mouse, do existing programs with mouse support work natively or would they have to be modified?  I'm guessing the two libraries don't tie together and if this is true, I wonder if there is a way to install the TIPI mouse driver as an XOP with the same opcode/library as the bus mouse driver.

[+9640News]

30 minutes ago, InsaneMultitasker said:

Nice work, Beery.  The document lays out quite a lot of info.  I had two comments after reading:

 

1) Can you elaborate on the second assumption?  I did not follow what this means.

In the preceding example, two hidden assumptions were made. First it is assumed that Hostname or IP address is located on a page which is currently mapped into a memory page which has the same 16-bit address page number as its Virtual address page number (read the section on Memory Management). The second assumption is that TIPI is actually at the virtual address TIPI, not in some overlay segment with a different virtual address.

 

2) For opcode >11, mouse, do existing programs with mouse support work natively or would they have to be modified?  I'm guessing the two libraries don't tie together and if this is true, I wonder if there is a way to install the TIPI mouse driver as an XOP with the same opcode/library as the bus mouse driver.

 

For some background information for others, in V7.30, I did not specify the server or client bytes as part of the opcode definition.  I set a default server/client byte and realized afterwards, this should be further expanded in the event users wanted to open multiple connections which have been tested and work. This next release opens that capability.  This advanced testing resulted in an observation of shared memory issues (memory management issues dating back since the earliest MDOS release) that @InsaneMultitasker then fixed.  I believe I have tested something like 8 simultaneous TCP connections through the multitasking features of MDOS.  I will say realistically, no more than 4 should be open.

 

 

Regarding #2:

 

I have both a TIPI mouse driver and the Bus mouse driver working.  The TIPI mouse driver accesses the TIPI XOP for position/movement while the Bus mouse driver accesses the bus mouse routines.  Both drivers then use the Video XOP's to drive a sprite based mouse around the screen, or the "+" symbol around the screen in text mode.  Bruce Hellstrom wrote the first bus mouse driver, then I modified his code to use the TIPI XOP.

 

Regarding #1:

 

I had to find the section to read it, and it needs more clarification and some text revision highlighted in red.  I have added the complete text of that page below so that it makes more sense to those following here.  Let me know if this clears up the confusion.

 

===========

 

The MDOS TIPI Library must be called from within a machine code program running as a task under MDOS. You pass arguments to the TIPI Library via the calling registers.

 

The MDOS TIPI Library is invoked from a machine code program when software trap number zero (XOP 0) is called with a library number of 12. The calling program's R0 must contain the 16-bit subprogram at the time of the XOP.  The following code fragment will open a TCP connection to a hostname or IP address.

 

                                    LI          R0,>0002       Open hostname

                                    LI          R1,HOST       Hostname to open with port number

                                    LI          R2,22             Length of Hostname String

                                    LI          R3,>0100       TCP Socket Handle Byte (MSB)

                                    XOP     @TIPI,0          Access subprogram

                                   

                        TIPI       DATA   12

                        HOST   TEXT    “Heatwave.ddns.net:9640”          HOST to open

                                    EVEN

        

 

In the preceding example, two hidden assumptions were made.  First it is assumed that Hostname or IP address is located on a page which is currently mapped into a memory page which has the same 16-bit address page number as its Virtual address page number (read the section on Memory Management). The second assumption is the TIPI label is currently mapped into a memory page which has the same 16-bit address page number as its Virtual address page number.

=================================== 

[+dhe]

 

The MAME lockup Odyssey

 

I went to create a simple tool chain on the Geneve, to create assembler programs on the Geneve, targeting the 99/4a.  I did this because of the ability to script and a larger memory space.

 

    The tool chain looks like this: 

   QDE:     Edit assembly source code.

   GENASM:    Assemble source code.

   GENLINK:    Even with good libraries - I couldn’t get GENLINK to accept them. 

 

   Commands are ran with:

   Qde              <source>

   AS:        assembles program

   LK:         Link and create a 99/4a program image.

   EXEC          <99/4a Program Image file>

 

This makes a relatively comfortable, complete and fast development environment.

 

But of course there was trouble in paradise. I thought there was a bug in my assembly code, because the Geneve kept locking up when I ran the code. Most of the time, you can get back or reboot with CTRL-SHIFT-SHIFT. In this case MAME was locking up hard.  MAJOR BUMMER!

 

I reached out to @InsaneMultitasker to see if he had any suggestions, he asked me to send him my program image. I did and he immediately said look at the first six bytes of your program. Having never built a program image I wasn’t sure what he was getting at, so I pulled out my Disk-Assembler Manual from Miller's Graphics. 

 

What @InsaneMultitasker had found first, was that the program was trying to load into DSR space, apparently MAME was grooving on the action.

 

 

My email back to @InsaneMultitasker :

In my usual slow plodding methodical way. I researched what we were talking about.

I never really coded in assembly. I went to E/A Manual and couldn't quickly find what I was looking for, so I pulled out DiskAssembler by Tom Freeman, and found exactly what I needed. My assembler master piece was opening a file with student names and grades, and calculating an average for each student.

From: MG Disk Assembler - Manual.

Standard also indicates that the first 3 words of a PROGRAM   file contains:

 1. A flag indicating whether another file follows, >0000 or >FFFF

    (this word tells DISkASSEMBLER the file is Standard).

    Note: If it is Custom and this word is >0000 or >FFFF you will get

        some strange values for "Length" and "Loads At".

 2. The total number of bytes in the file (if it is Standard

     DISkASSEMBLER uses this for "Length").

3. The address to start loading the fourth word at (if it is Standard

     DISkASSEMBLER uses this for "Loads At").

  

Using DM - First six bytes are displayed in HEX - Yea! ?

00 00 02 72 43 BD

>0000 = No Additional Files.

>0272 = Total Number of Bytes in file.

>43BD = Where to start loading.

         BAD NEWS - >4000 .. >5FFF = DSR ROM Space

 Thank you for the help, I really appreciate it.

 I now have a much more clear understanding of an area I was fuzzy on.

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

 

Then @InsaneMultitasker sent a new linker control file, which worked for him, but still gave me the same issue with loading into DSR space. 

--- 

Thinking along the lines of maybe, like my lib_4a file being corrupt, maybe the version of genprog had a problem. I own an official copy of genasm, but I never ported it from a TI floppy to the digital PC age. There was a warning by Paul that ‘pirated’ copies would have problems…. 

 

The version I was using came out of a directory called master, it displayed:

 

So I tried a version that came with MDOS 3.00.

 

 

And lo and behold:

 

 

 

 

LCF:

 

 

 

Since I wasn’t able to use lib_4a, I’m building up E/A Utilities around the library released by Steve J. Royce of the Western New York 99ers User Group and wrote: “Assembly Language Tutorials”.

[HOME AUTOMATION]

These?

 

Assembly Utilities-Tutorials/

 

[+mizapf]

@dheI am not quite sure ... now is there a problem in MAME or not? And if you say that MAME locks up, it seems to me that the emulated Geneve / GeneveOS locks up.

 

If MAME locked up or somewhat behaved unexpectedly, this would mean I'd have to search for an error.

[+9640News]

Dan,

 

If your code is loading into the DSR space in the >4000 to >5FFF range, then I suspect you are overwriting part of the Geneve's master DSR.

 

I would have the first instruction in your source file as a B  @START, then your BLOCK >A000,>FFD8.

 

After you have loaded your object file, then do a PSAVE for the for the filetype in 8K blocks minus 6 bytes, i.e.

 

PSAVE FILE1,4,>A000,>BFF8

PSAVE FILE2,5,>BFF8,>DFF0

 

PSAVE gives more flexibility to control the segments and how the image files are saved.

 

As a reference, you look up my AFTERHOURS source file on here in one of the zip's that I did for the TI-99/4A and look for filenames ASS and I think LINK1 on what I did.

 

I use memory from >A000,>FFFD8 and >6000 to >7FFF for the code storage.

[+InsaneMultitasker]

I think what Dan is trying to say is that the modified/corrupt LINK program was doing exactly what Paul intended:  corrupting the resulting program image file to confound the programmer. 

[+dhe]

True dat @InsaneMultitasker  !!!

With a side of what I learned and a side of here is my dev environment!

[+9640News]

12 hours ago, InsaneMultitasker said:

I think what Dan is trying to say is that the modified/corrupt LINK program was doing exactly what Paul intended:  corrupting the resulting program image file to confound the programmer. 

OK, missed that.  Too many long days out of town fixing problems at another lab.

[+InsaneMultitasker]

The OS command line FORMAT command has been updated so that if the selected DSKx device is not a true floppy controller device, an error is reported and the code to perform format/sector IO is not called. The GPL-based format DSR opcode is similarly restricted.

 

Are there other commands that should be restricted to specific devices?   I would prefer to target commands (or opcodes) that are potentially destructive or could create an improper operating condition.  

 

[+TheBF]

On 6/17/2022 at 5:36 PM, dhe said:

Any chance of moving some of GeneveOS in to C?

I guess based on the responses to your question you will have to be the first one to try something.

[+InsaneMultitasker]

On 6/19/2022 at 8:40 PM, InsaneMultitasker said:

4) The /9640 mode SCSI interrupt handler is hard-coded to >1200.  This still needs some special linking for a dynamic CRU and when space permits, a /4A mode handler is needed.  SCSI Interrupt handler now works from any address.  /4a mode SCSI interrupt handler has been added.  Interrupt routine has been moved from the high level DSR to the SCSI low level driver.  
10) The SCSMAP command now invalidates the drive parameters so that the old device parameters are not applied to a newly mapped device.  There is a second set of parameters that identifies whether or not the SCSI drive has been 'started'; this needs to also be invalidated, though I haven't decided on the best way to do this.  I am thinking that if the drive parameters are unknown, the SCSI driver should invalidate the drive start flags at that time. This would keep the code self-contained in the driver and minimize interference to the IDE and RamHD parameters.  The second set of flags has been removed. Drive parameters are now invalidated and self-contained within the SCSI low level routines.  Memory overflow into the common file buffer locatd at >9000 has been corrected.

12)  An IDE card interrupt handler has been implemented for both /4A and /9640 modes, with exception of calling the on-EPROM interrupt routine.  Since the IDE IO leverages the EPROM DSR, a simulated /4A environment also needs to be in place before the interrupt handler is executed.  Early research suggests the lower 1K of the SCSI/IDE/RamHD 8k code page can be used to simulate PAD RAM.

 

13) ASCSI card detection has been added to the SCSI Powerup routine.  Thanks to @mizapf for the routine.  PDMA will be set to ON when the card is detected; previously, the card was incorrectly detected as a v1.5 DSR with PDMA OFF, resulting in lockups and a need to manually configure the PDMA setting. 

 

A few more updates to round out the weekend...

[+InsaneMultitasker]

2 hours ago, TheBF said:

I guess based on the responses to your question you will have to be the first one to try something.

I was fairly certain this question had been addressed but maybe it was a similar question in this thread or another thread.

2 hours ago, TheBF said:

  On 6/17/2022 at 4:36 PM, dhe said:

Any chance of moving some of GeneveOS in to C?

The only C code in the OS was within the SCSI DSR.  I have spent a lot of time unwinding that convoluted, compiled code starting with version 6.70RC1, which resulted in doubling the overall performance.  It also gave me a headache and a cache bug error that renders versions after 6.50 and before 7.30 as problematic, to say the least.   

 

Given the maturity level of the OS and the intertwined nature of the code, I don't see moving any OS code to C.  That doesn't mean you cannot write drivers and hooks, utilities, etc in C to augment the OS, but the core itself will remain assembly.

 

 

[Willsy]

11 hours ago, InsaneMultitasker said:

Given the maturity level of the OS and the intertwined nature of the code, I don't see moving any OS code to C.  That doesn't mean you cannot write drivers and hooks, utilities, etc in C to augment the OS, but the core itself will remain assembly.

It's none of my business but I'm inclined to agree. If it ain't broke don't fix it! If you were starting out from scratch there might be an argument for using C, assuming the current crop of C compilers targeting the 9900 are good enough. From what I've read here on Atariage, I think there's sufficient grounds to argue they are too buggy at the moment.

[+InsaneMultitasker]

5 hours ago, Willsy said:

If you were starting out from scratch there might be an argument for using C, assuming the current crop of C compilers targeting the 9900 are good enough. From what I've read here on Atariage, I think there's sufficient grounds to argue they are too buggy at the moment.

Isn't @FarmerPotato working on a Forth version of the Geneve OS?    

 

The C code in MDOS wasn't buggy, per se, but it wasn't efficient. It passed addresses and variables to local processes like a good function should, but then used those function variables for other purposes.   Now to be fair, many C routines were written around 1994 prior to implementing the device support within the OS. So without the C work, I doubt the SCSI support would have ever made it into the OS, nor the other devices that have since followed.