Jump to content


Horizon RAMdisk ROS and CFG


204 replies to this topic

#201 InsaneMultitasker OFFLINE  



  • Topic Starter
  • 1,909 posts

Posted Mon Aug 29, 2016 2:25 PM

FYI, I've had one report of CFG834 "squealing" during the peripheral test.  As I don't recall any major changes between 8.34 and what was posted here, I'll wait for more feedback before a code review.  (resolved:  bad file transfer to the TI hardware).


Update: I used DSKU to compare CFG832e (July 31 2015) with CFG834.  The only differences are the version text and "Axiom" vs. Axion". 


Update: Added task to add a CRC self-test to CFG, to help protect against corruption.

Edited by InsaneMultitasker, Mon Aug 29, 2016 9:39 PM.

#202 InsaneMultitasker OFFLINE  



  • Topic Starter
  • 1,909 posts

Posted Tue Aug 30, 2016 7:30 PM

Post #200 edited to reflect modified ROS834 (padded file from 8188 to 8192 bytes).


DSR problem identified in this thread:




Edit: noticed ROS CRC detection did not fail when file was padded to 8192 bytes.  Routine is presently hard-coded to 8188 bytes based on the source code. Will review change to routine to account for final 4 bytes or dynamic file size.


File CFG-S1

       CI   R0,>1000+8188     end of ROS?
       JNE  CRC11             no, read next byte and calculate

Edited by InsaneMultitasker, Thu Sep 1, 2016 12:57 PM.

#203 InsaneMultitasker OFFLINE  



  • Topic Starter
  • 1,909 posts

Posted Sun Mar 19, 2017 4:25 PM

Came across this bug today.  Both Atrax and I have confirmed that in some cases, you can write beyond the currently allocated sectors, corrupting other drives in the process.


When ROS looks for free sectors to write to a file, it does so based on the bitmap in sector 0. When it scans the bitmap, it compares the scanned (current) allocation unit number with the total sectors of the disk.  With a 3200 sector disk, the total sectors must be divided by 2, to ensure each allocation unit represents two sectors.  In the current code the division never takes place, so ROS thinks there are up to 6400 sectors to scan. 


The offending routine is listed below. I'll fix this as time permits.

* FIND FIRST FREE SECTOR      OUT: R1= Sector number (ZERO if none)
FNDSEC LI   R6,>5838          Point to the start of the BITMAP
       MOV  @OFSET,R7         Page # of the first page
       CB   @MASK+1,@LINK+1   8 bit or 16 bit BUS
       JNE  FNDSED            Jump if 16 bit
       SWPB R7                8 bit, so swap it
FNDSED LDCR R7,0              Write the page # to the card
       CLR  R1                Start searching at sector 0
       JMP  NXWRD             Jump and get the first WORD
NXCHK  DEC  R2                Finished with this WORD
       JNE  NXSEC             Nope, so shift some more
NXWRD  MOV  *R6+,R0           Get another WORD of the BITMAP
       SWPB R0                Put it in the right order
       LI   R2,16             16 sectors per WORD
NXSEC  SRL  R0,1              Shift 1 sector out
       JNC  FDSEC             If no carry, then it's free
       INC  R1                Not free, so check next sector
       C    R1,@FORSEC        Are we at the end of the drive (BUG! Must /2  IFF disk total allocation is greater than 1600 sectors, i.e., 2 AUs/sector)
       JLT  NXCHK             Nope, so check next sector
       CLR  R1                Yep, so send >0000 back
***2-19-2012tt    FDSEC  RT               RETURN TO THE CALLING PROGRAM
* Test for >1600 and return proper sector#
FDSEC  C    @FORSEC,@D1600    2-19, disk size>1600?
       JLE  FDRT11            no
       SLA  R1,1              yes, adjust x2

#204 InsaneMultitasker OFFLINE  



  • Topic Starter
  • 1,909 posts

Posted Sun May 7, 2017 2:19 PM

I modified the ROS bitmap allocation routine and added the TIPI device to CFG's detection routine.   


The updates have been shared with Atrax for testing, and I will post the updated files when we are satisfied the changes are working as expected.

#205 InsaneMultitasker OFFLINE  



  • Topic Starter
  • 1,909 posts

Posted Sun May 7, 2017 6:03 PM

While testing the allocation bug fix I ran into another odd scenario. 


When writing to a physical floppy disk on a Myarc FDC using level 2 IO, if there is insufficient space for the file, a remnant is left behind that consumes the remaining space. The same things happens when saving a program to disk using XB and the level 3 SAVE opcode.  I haven't tested the same processes with a TI or CorComp disk controller, but I assume the file stub is written or the remnant is deleted.


When writing to a Horizon RAMdisk, the filename and its pointer are written as expected.  The filename shows up in a disk catalog.  However, the DSR does not write an FDR  cluster (chains of 3 bytes which point to the used sectors) for the first group of allocated sectors, leaving the cluster value as >00,>00,>00. This has the unfortunate side effect of redirecting the file to the disk's VIB, sector 0.  As many of us well know, a destroyed sector 0 means the disk contents will not be accessible.


I need to complete some additional testing and compare controller responses before I (try to?) fix this issue.  As far as I can tell, the bug has been lurking in the ROS since the 90s so a while longer won't matter too much.  ;)  The offending code snip can be found below.



Edited by InsaneMultitasker, Sun May 7, 2017 6:04 PM.

Also tagged with one or more of these keywords: ROS, CFG, RAMDISK

0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users