Loading ...
Sorry, an error occurred while loading the content.

Re: Grocking the SBC6120 RAM Disk Structure

Expand Messages
  • aa3nm
    With some inputs from Bob and a couple of others I think I have a better sense of the the Ram Disk Addressing. I m pawing through the information provided by
    Message 1 of 11 , Jul 12, 2013
    • 0 Attachment
      With some inputs from Bob and a couple of others I think I have a better sense of the the Ram Disk Addressing.

      I'm pawing through the information provided by Bob on the BTS6120 which discusses the variations between the 3 formats of RAM disk as implemented in the: Add on RAM Disk option to the SBC, The SBC6120RC, and the IOB6120 RAM disk. I'll hopefully have some graphics for each variation shortly... there is a lot there to digest.

      I've made a couple of corrections to the graphics for Fig 4.2-2 SRAM Structure, and to Fig 4.2-1 RAM Disk Bank Structure as suggested by Bob and have reposted the revised graphics in the folder for review.

      BTW these files also depict some of the structure related to addressing and partitioning of the IDE Drive too.

      As always, comments and corrections are encouraged.

      Steve Gemeny



      --- In sparetimegizmos@yahoogroups.com, Steve Gemeny <steve@...> wrote:
      >
      > I guess it is the "magic happens here" part of "packing and unpacking" 2 words into 3 bytes and the associated "complicated" ness that Bob refers to that I'm picking at... It feels like address inflation by a factor of 1.5 that is somehow bothersome to me. I guess it feels like that address inflation rolls into the DAR deeper as the file address inflation increases on large files...
      >
      > Maybe I need to stop scratching at this and trust that magic happens.
      >
      > I'm not so confused about leaving unused bytes in RAM, just the idea of using more and more address space (x 1.5 per) that is getting to me. But I'll put that on the shelf for a bit and trust the magic...
      >
      > Thanks
      >
      > Stave
      >
      >
      > Sent by my large thumbs via tiny soft iKeys...
      >
      > On Jul 3, 2013, at 7:46 PM, "Stephen L" <steve@...> wrote:
      >
      > > > This seems to imply that there is some translation done in BTS6120 for
      > > RAM Disk addressing beyond that stated in the manual - section 3.4:
      > > "address bits 0..11 are supplied by the HD-6120 MA11-0".
      > >
      > > --- Well, there isn't any other translation in the hardware, actually. I
      > > think you're aware that the Disk Address Register (DAR) holds the value
      > > which selects the 4KB bank being addressed. I'm struggling to imagine
      > > why you might think that there is more to the addressing. Is it that
      > > fact that some of the RAM disk locations are not used? Remember that the
      > > way the file data is packed into the Disk-RAM is a software process,
      > > which is independent of the hardware mechanism of the CPU accessing the
      > > Disk-RAM.
      > >
      > > Let's look at how the software might go about ignoring the left-over 0.3
      > > pages per 4KB bank: Suppose we are storing a large data file and the
      > > software has been packing it into the first 4096-byte RAM bank. Pages of
      > > 128, 12-bit words are formed into chunks (that's a technical term :) of
      > > 192-bytes. It could store about 21.3 chunks in the bank but has been
      > > programmed to keep it simple and put only 21-chunks there. After writing
      > > the 21st chunk, it has used 4032-bytes of the bank. It sees that only
      > > 64-bytes are left. Instead of trying to do something fancy to split
      > > chunks (pages) across banks, it just moves on to the next bank by
      > > changing the value in the DAR. The next chunk is loaded into the new
      > > 4096-byte bank.
      > >
      > > Notice that there was no hardware funny-business about how the last
      > > 64-bytes in the first bank were skipped, so there is nothing strange in
      > > the address of the Disk-RAM. The software could have accessed those
      > > bytes but didn't, under program control.
      > >
      > > Steve L.
      > >
      > > PS: I should mention that in addition to the DAR register, two EMA lines
      > > are used to select one of the four Disk-RAM chips. That's really sort of
      > > an extension of the bank select.
      > >
      > > [Non-text portions of this message have been removed]
      > >
      > >
      >
      >
      > [Non-text portions of this message have been removed]
      >
    • krs60555b@att.net
      Steve, Where did these graphics go to? I can t find them under the files area. Thanks, keith
      Message 2 of 11 , Dec 17, 2013
      • 0 Attachment
        Steve,
        Where did these graphics go to?
        I can't find them under the files area.

        Thanks,
        keith
        =========



        --- In sparetimegizmos@yahoogroups.com, "aa3nm" <steve@...> wrote:
        >
        > With some inputs from Bob and a couple of others I think I have a better sense of the the Ram Disk Addressing.
        >
        > I'm pawing through the information provided by Bob on the BTS6120 which discusses the variations between the 3 formats of RAM disk as implemented in the: Add on RAM Disk option to the SBC, The SBC6120RC, and the IOB6120 RAM disk. I'll hopefully have some graphics for each variation shortly... there is a lot there to digest.
        >
        > I've made a couple of corrections to the graphics for Fig 4.2-2 SRAM Structure, and to Fig 4.2-1 RAM Disk Bank Structure as suggested by Bob and have reposted the revised graphics in the folder for review.
        >
        > BTW these files also depict some of the structure related to addressing and partitioning of the IDE Drive too.
        >
        > As always, comments and corrections are encouraged.
        >
        > Steve Gemeny
        >
        >
        >
        > --- In sparetimegizmos@yahoogroups.com, Steve Gemeny <steve@> wrote:
        > >
        > > I guess it is the "magic happens here" part of "packing and unpacking" 2 words into 3 bytes and the associated "complicated" ness that Bob refers to that I'm picking at... It feels like address inflation by a factor of 1.5 that is somehow bothersome to me. I guess it feels like that address inflation rolls into the DAR deeper as the file address inflation increases on large files...
        > >
        > > Maybe I need to stop scratching at this and trust that magic happens.
        > >
        > > I'm not so confused about leaving unused bytes in RAM, just the idea of using more and more address space (x 1.5 per) that is getting to me. But I'll put that on the shelf for a bit and trust the magic...
        > >
        > > Thanks
        > >
        > > Stave
        > >
        > >
        > > Sent by my large thumbs via tiny soft iKeys...
        > >
        > > On Jul 3, 2013, at 7:46 PM, "Stephen L" <steve@> wrote:
        > >
        > > > > This seems to imply that there is some translation done in BTS6120 for
        > > > RAM Disk addressing beyond that stated in the manual - section 3.4:
        > > > "address bits 0..11 are supplied by the HD-6120 MA11-0".
        > > >
        > > > --- Well, there isn't any other translation in the hardware, actually. I
        > > > think you're aware that the Disk Address Register (DAR) holds the value
        > > > which selects the 4KB bank being addressed. I'm struggling to imagine
        > > > why you might think that there is more to the addressing. Is it that
        > > > fact that some of the RAM disk locations are not used? Remember that the
        > > > way the file data is packed into the Disk-RAM is a software process,
        > > > which is independent of the hardware mechanism of the CPU accessing the
        > > > Disk-RAM.
        > > >
        > > > Let's look at how the software might go about ignoring the left-over 0.3
        > > > pages per 4KB bank: Suppose we are storing a large data file and the
        > > > software has been packing it into the first 4096-byte RAM bank. Pages of
        > > > 128, 12-bit words are formed into chunks (that's a technical term :) of
        > > > 192-bytes. It could store about 21.3 chunks in the bank but has been
        > > > programmed to keep it simple and put only 21-chunks there. After writing
        > > > the 21st chunk, it has used 4032-bytes of the bank. It sees that only
        > > > 64-bytes are left. Instead of trying to do something fancy to split
        > > > chunks (pages) across banks, it just moves on to the next bank by
        > > > changing the value in the DAR. The next chunk is loaded into the new
        > > > 4096-byte bank.
        > > >
        > > > Notice that there was no hardware funny-business about how the last
        > > > 64-bytes in the first bank were skipped, so there is nothing strange in
        > > > the address of the Disk-RAM. The software could have accessed those
        > > > bytes but didn't, under program control.
        > > >
        > > > Steve L.
        > > >
        > > > PS: I should mention that in addition to the DAR register, two EMA lines
        > > > are used to select one of the four Disk-RAM chips. That's really sort of
        > > > an extension of the bank select.
        > > >
        > > > [Non-text portions of this message have been removed]
        > > >
        > > >
        > >
        > >
        > > [Non-text portions of this message have been removed]
        > >
        >
      • Steve Gemeny
        Keith, At one point a few months back I was going to do some editing and correcting. I took the graphics down at that time, promptly got distracted and -
        Message 3 of 11 , Dec 17, 2013
        • 0 Attachment
          Keith,



          At one point a few months back I was going to do some editing and
          correcting. I took the graphics down at that time, promptly got distracted
          and - until just now - proceeded to forget about them.



          Let me have a look at where I had left them and I'll see about reposting
          them.



          Sorry for the brain fart and any resulting confusion.



          Steve



          From: sparetimegizmos@yahoogroups.com
          [mailto:sparetimegizmos@yahoogroups.com] On Behalf Of krs60555b@...
          Sent: Tuesday, December 17, 2013 12:34 PM
          To: sparetimegizmos@yahoogroups.com
          Subject: [sparetimegizmos] Re: Grocking the SBC6120 RAM Disk Structure





          Steve,
          Where did these graphics go to?
          I can't find them under the files area.

          Thanks,
          keith
          =========

          --- In sparetimegizmos@yahoogroups.com, "aa3nm" <steve@...> wrote:
          >
          > With some inputs from Bob and a couple of others I think I have a better
          sense of the the Ram Disk Addressing.
          >
          > I'm pawing through the information provided by Bob on the BTS6120 which
          discusses the variations between the 3 formats of RAM disk as implemented in
          the: Add on RAM Disk option to the SBC, The SBC6120RC, and the IOB6120 RAM
          disk. I'll hopefully have some graphics for each variation shortly... there
          is a lot there to digest.
          >
          > I've made a couple of corrections to the graphics for Fig 4.2-2 SRAM
          Structure, and to Fig 4.2-1 RAM Disk Bank Structure as suggested by Bob and
          have reposted the revised graphics in the folder for review.
          >
          > BTW these files also depict some of the structure related to addressing
          and partitioning of the IDE Drive too.
          >
          > As always, comments and corrections are encouraged.
          >
          > Steve Gemeny
          >
          >
          >
          > --- In sparetimegizmos@yahoogroups.com, Steve Gemeny <steve@> wrote:
          > >
          > > I guess it is the "magic happens here" part of "packing and unpacking" 2
          words into 3 bytes and the associated "complicated" ness that Bob refers to
          that I'm picking at... It feels like address inflation by a factor of 1.5
          that is somehow bothersome to me. I guess it feels like that address
          inflation rolls into the DAR deeper as the file address inflation increases
          on large files...
          > >
          > > Maybe I need to stop scratching at this and trust that magic happens.
          > >
          > > I'm not so confused about leaving unused bytes in RAM, just the idea of
          using more and more address space (x 1.5 per) that is getting to me. But
          I'll put that on the shelf for a bit and trust the magic...
          > >
          > > Thanks
          > >
          > > Stave
          > >
          > >
          > > Sent by my large thumbs via tiny soft iKeys...
          > >
          > > On Jul 3, 2013, at 7:46 PM, "Stephen L" <steve@> wrote:
          > >
          > > > > This seems to imply that there is some translation done in BTS6120
          for
          > > > RAM Disk addressing beyond that stated in the manual - section 3.4:
          > > > "address bits 0..11 are supplied by the HD-6120 MA11-0".
          > > >
          > > > --- Well, there isn't any other translation in the hardware, actually.
          I
          > > > think you're aware that the Disk Address Register (DAR) holds the
          value
          > > > which selects the 4KB bank being addressed. I'm struggling to imagine
          > > > why you might think that there is more to the addressing. Is it that
          > > > fact that some of the RAM disk locations are not used? Remember that
          the
          > > > way the file data is packed into the Disk-RAM is a software process,
          > > > which is independent of the hardware mechanism of the CPU accessing
          the
          > > > Disk-RAM.
          > > >
          > > > Let's look at how the software might go about ignoring the left-over
          0.3
          > > > pages per 4KB bank: Suppose we are storing a large data file and the
          > > > software has been packing it into the first 4096-byte RAM bank. Pages
          of
          > > > 128, 12-bit words are formed into chunks (that's a technical term :)
          of
          > > > 192-bytes. It could store about 21.3 chunks in the bank but has been
          > > > programmed to keep it simple and put only 21-chunks there. After
          writing
          > > > the 21st chunk, it has used 4032-bytes of the bank. It sees that only
          > > > 64-bytes are left. Instead of trying to do something fancy to split
          > > > chunks (pages) across banks, it just moves on to the next bank by
          > > > changing the value in the DAR. The next chunk is loaded into the new
          > > > 4096-byte bank.
          > > >
          > > > Notice that there was no hardware funny-business about how the last
          > > > 64-bytes in the first bank were skipped, so there is nothing strange
          in
          > > > the address of the Disk-RAM. The software could have accessed those
          > > > bytes but didn't, under program control.
          > > >
          > > > Steve L.
          > > >
          > > > PS: I should mention that in addition to the DAR register, two EMA
          lines
          > > > are used to select one of the four Disk-RAM chips. That's really sort
          of
          > > > an extension of the bank select.
          > > >
          > > > [Non-text portions of this message have been removed]
          > > >
          > > >
          > >
          > >
          > > [Non-text portions of this message have been removed]
          > >
          >





          [Non-text portions of this message have been removed]
        Your message has been successfully submitted and would be delivered to recipients shortly.