Jump to content
InsaneMultitasker

Horizon RAMdisk ROS and CFG

Recommended Posts

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
  • Like 1

Share this post


Link to post
Share on other sites

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

 

DSR problem identified in this thread:

 

http://atariage.com/forums/topic/256351-hrd-setup-questions-mame-specificmaybe/page-2?do=findComment&comment=3583501

 

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
  • Like 2

Share this post


Link to post
Share on other sites

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
  • Like 5

Share this post


Link to post
Share on other sites

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.

  • Like 4

Share this post


Link to post
Share on other sites

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.

 

 

 

* CREATE DATA CLUSTERS
*
CRE BL @ADDRF Bring up the FDB sector
AI R6,28 Point to the first cluster
MOV R6,R10 Save the current cluster addr.
CLR R8 Flag = Looking for a Starting Sector
LI R1,2 Start the search at the first sector
CLR R2 No offset at the moment
CREATE MOV R1,R0 Setup the UPDATE with sector number
BL @UPDATE Calc position in the BIT MAP
MOVB *R6,R0 Get the BIT MAP byte for the compar
CZC R7,R0 Is this sector free
JEQ CRE0 Yep, so count it
MOV R8,R8 Nope, so check if looking for SS
JEQ CRE4 Yep, so skip over cluster maker
CLFIN BL @ADDRF Bring up the FDB sector
A R1,R2 Add current sector # to current offset
S R8,R2 Sub starting sector # from current offset
MOV R2,R3 Save current offset into R3
MOV R9,R9 Check if TOTAL AU left is ZERO
JEQ CNXT Yep, so skip over the DEC R3
DEC R3 Nope, so sub 1 from current offset
CNXT BL @BDCLST Build a cluster up in the FDB sector
CLR R8 Start looking for a new SS
MOV R9,R9 Check if TOTAL AU left is ZERO
JEQ CRE4A Yep, then stop building the clusters
S R6,R10 Make R10 cluster offset into the sector
CI R10,255 Check if out of room for another cluster
JGT CRE4B Yep, so exit to diskette full ERROR
A R6,R10 Add starting address into 2K RAM page
CRE4 INC R1 Point to the next sector on the diskette
C R1,@FORSEC Check if at the end of the diskette
JHE CRE4B Yep, so exit to diskette full ERROR [5.7.2017 first cluster is never written if disk fills up]
JMP CREATE Jump back up and check this sector
CRE0 MOV R8,R8 Sector is FREE, check if looking for SS
JNE CRE3 Nope, so don't change R8
MOV R1,R8 Yep, so make R8 the new SS sector number
CRE3 DEC R9 Check if finished building the clusters
JEQ CLFIN Yep, so write the last cluster
JMP CRE4 Nope, so look for another free sector

 

 

 

Edited by InsaneMultitasker
  • Like 2

Share this post


Link to post
Share on other sites

Reviewed ROS DSR with respect to recent tipi discussions concerning duplicate device names/subprograms. No concerns identified. Two reminders:

 

1. Figure out if one or both of the prior two allocation bugs were fixed properly so that I can release the next ROS/CFG version

  • [Edit 8/26: unreleased ROS v8.38 contains the fix for post #203]
  • [Edit 8/26: fix for post #205 does not yet exist]

2. Now that the PEB TIPI cards are escaping ;) from the PNW, test/confirm CFG tipi detection is working as expected.

3. Validate ROS CRC per earlier post related to TI controller bug / 8188 vs. 8192 bytes.

Edited by InsaneMultitasker
  • Like 3

Share this post


Link to post
Share on other sites

I still haven't figured out the proper solution to deal with a full disk and the cluster creation that ultimately corrupts the VIB. I need to map out the entire routine when I have a larger chunk of free time. My initial attempts at a fix had unintended 'consequences' for successfully created files. There is also a bitmap wrap-around process for when the end of the bitmap is reached; I am not sure how to ensure the fix doesn't stomp all over this routine.

 

I did come across an explanation for some of the garbage catalogs we all see when accessing an undefined drive. You may recall from past TIPI discussions that if a call to the DSR results in a device not being found, the DSR should gracefully return so that the DSRLNK can continue scanning other peripherals. Fortunately, ROS follows this convention as best I can tell.

 

However, when I inspected a few programs using sector-based catalog routines, I noticed that instead of testing for the condition status (EQ) bit after the DSRLNK routine is called, they only inspect 0x8350 for an error byte. If a level 2 unit/device number is undefined within the DSRs and 0x8350 is set to 0x0000, there is a good chance the program will think a device was found. Address 0x8350 serves a dual purpose for direct sector IO namely, it contains the sector to read (or write). When the program tries to read sector 0 to capture the VIB then fails to check the EQ status bit, it fools itself into thinking there was a valid sector 0. Now, whatever is in memory at the time will be used for the subsequent attempts to find the FDRs for the files and the catalog routine will fail miserably. I don't think there is any way around this specific problem from a DSR perspective.

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...