Jump to content

Photo

Horizon RAMdisk ROS and CFG

ROS CFG RAMDISK

202 replies to this topic

#201 InsaneMultitasker OFFLINE  

InsaneMultitasker

    Stargunner

  • Topic Starter
  • 1,484 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  

InsaneMultitasker

    Stargunner

  • Topic Starter
  • 1,484 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:

 

http://atariage.com/...-2#entry3583501

 

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  

InsaneMultitasker

    Stargunner

  • Topic Starter
  • 1,484 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
FDRT11 RT






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