Jump to content

Recommended Posts

The MFM throughput is determined by the MFM drive and is typically limited to 5 MBit/s (for a 3600 rpm drive)*. The IDE drive boots much faster on the MAME Geneve emulation, so you see that the drive is the actual bottleneck.

 

*MFM controllers like the HDC9234 on the HFDC are clocked at 10 MHz, so the world cannot be faster for them than 10000000 events per second, which are MFM cells on the platter, and you need 2 cells per bit. 

  • Like 1

Share this post


Link to post
Share on other sites
4 hours ago, mizapf said:

The MFM throughput is determined by the MFM drive and is typically limited to 5 MBit/s (for a 3600 rpm drive)*. The IDE drive boots much faster on the MAME Geneve emulation, so you see that the drive is the actual bottleneck.

 

*MFM controllers like the HDC9234 on the HFDC are clocked at 10 MHz, so the world cannot be faster for them than 10000000 events per second, which are MFM cells on the platter, and you need 2 cells per bit. 

At 5Mbit/s maximum, what would you consider as the typical maximum theoretical controller throughput?   Obviously, throughput is not anywhere near 5 Mbit/s as that would allow us to load Geneve OS in under one second, if I am thinking about this correctly.

  • Like 1

Share this post


Link to post
Share on other sites

5 MBit/s unformatted. We have 32 sectors per track, i.e. 8192 byte or 64 KBit, with a transfer time of 1/60 sec (whole track), so this is 3.9 Mbit/s formatted. However, we have an interleave of 4, so you need 4 revolutions, i.e. the rate is 1/4 or 983 kBit/s. Add some time for head positioning. Finally, the contents must be copied from the buffer SRAM on the HFDC into main memory.

 

I mentioned the loading time in MAME because I adjusted the MFM hard disks to exactly deliver bytes at the raw rate of 5 MBit/s (with all head positioning timings etc), and you really notice how much longer it takes to load GeneveOS. That is, if we put some effort in it, we may have a chance to find out where most of the time is spent.

 

On the other hand, I did not add any timing to the IDE drive, so it shows the speed of a ramdisk.

  • Like 1

Share this post


Link to post
Share on other sites

mizapf,

  Any chance of adding pfm support to the geneve emulation? I assume since it's 'just' memory it's as 'simple' as just adding the correct addresses and then over laying them with access rules? I'm really not asking of you to embark on a great deal of work, more in just learning how emulation is done.

thanks,

Share this post


Link to post
Share on other sites
1 hour ago, mizapf said:

5 MBit/s unformatted. We have 32 sectors per track, i.e. 8192 byte or 64 KBit, with a transfer time of 1/60 sec (whole track), so this is 3.9 Mbit/s formatted. However, we have an interleave of 4, so you need 4 revolutions, i.e. the rate is 1/4 or 983 kBit/s. Add some time for head positioning. Finally, the contents must be copied from the buffer SRAM on the HFDC into main memory

Thank you, Michael.  When I repaired Beery's HFDC some time ago, he sent his DREM unit along so that I could verify that the card and DREM worked together after the repair.  What caught my attention was that the device's throughput was the same speed or slightly slower (at the time) than my 20MB MFM 1/2 height hard drive.  I did not research the DREM to understand why this might be the case.

 

Within the Geneve OS, the SCSI, IDE, and RamHD devices all use the same, common buffering routines - the SCSI even uses one additional, intermediate buffer - so we know that portion of the OS code is not an MFM bottleneck. 

 

That reminds me, I have a few HFDC-specific dumps that you created for me. I'll have to revisit that information as I have since forgotten what we were trying to determine...

 

  • Like 1

Share this post


Link to post
Share on other sites

@dheGood news: Enter the OSD menu, machine configuration, step through the options "Boot from".

 

  • Like 3

Share this post


Link to post
Share on other sites
13 hours ago, mizapf said:

5 MBit/s unformatted. We have 32 sectors per track, i.e. 8192 byte or 64 KBit, with a transfer time of 1/60 sec (whole track), so this is 3.9 Mbit/s formatted. However, we have an interleave of 4, so you need 4 revolutions, i.e. the rate is 1/4 or 983 kBit/s. Add some time for head positioning. Finally, the contents must be copied from the buffer SRAM on the HFDC into main memory.

 

I mentioned the loading time in MAME because I adjusted the MFM hard disks to exactly deliver bytes at the raw rate of 5 MBit/s (with all head positioning timings etc), and you really notice how much longer it takes to load GeneveOS. That is, if we put some effort in it, we may have a chance to find out where most of the time is spent.

 

On the other hand, I did not add any timing to the IDE drive, so it shows the speed of a ramdisk.

Update: 

I spent some time reading and commenting HD.SECTORIOW.  The low level routine flow diagram would be quite difficult to create with all of the code jumps and flag gymnastics.  I suppose speed increases might be possible by changing the physical sector interleave and reading more than one sector (256 bytes) at a time, though the latter is beyond the current OS's capabilities.  And I don't see how interleave would affect DREM access times, even if it affected the electro-mechanical drives.

 

Also, I don't yet see a reason why there was a "need" to update the HFDC memory from 8K to 32K to use CFORM and High Density disks.  The OS doesn't read/write tracks (maximum size 256*34 sectors=8.5Kib) operations and DMA read/write operations are completed one sector at a time.  Is the controller using DMA memory to build the entire track?  I don't think so, the manual suggests otherwise and there is no indication that the OS saves/restores the 8k chip to format a track.  (I'll dig up the MDM5 or CFORM code to look for a few clues) 

  • Like 5

Share this post


Link to post
Share on other sites
13 hours ago, InsaneMultitasker said:

Update: 

I spent some time reading and commenting HD.SECTORIOW.  The low level routine flow diagram would be quite difficult to create with all of the code jumps and flag gymnastics.  I suppose speed increases might be possible by changing the physical sector interleave and reading more than one sector (256 bytes) at a time, though the latter is beyond the current OS's capabilities.  And I don't see how interleave would affect DREM access times, even if it affected the electro-mechanical drives.

 

Also, I don't yet see a reason why there was a "need" to update the HFDC memory from 8K to 32K to use CFORM and High Density disks.  The OS doesn't read/write tracks (maximum size 256*34 sectors=8.5Kib) operations and DMA read/write operations are completed one sector at a time.  Is the controller using DMA memory to build the entire track?  I don't think so, the manual suggests otherwise and there is no indication that the OS saves/restores the 8k chip to format a track.  (I'll dig up the MDM5 or CFORM code to look for a few clues) 

It's been a long time, but I thought the format command in MDM5 may have needed the 32K chip to format a 1.44 MB floppy.

  • Like 2

Share this post


Link to post
Share on other sites
18 hours ago, 9640News said:

It's been a long time, but I thought the format command in MDM5 may have needed the 32K chip to format a 1.44 MB floppy.

 

I dug into this a bit more.

 

The 9234 format track command requires 4-5 bytes of external RAM.  There is nothing that I can find in the 9234 manual that suggests more RAM is needed to format the drive.  And if I understand the process correctly, the controller's format command lays down the cylinders and interleaves them as requested;  once the cylinders are written, the data can be written/read (initialized) to determine if any sector errors are present.

 

The MDM5 hard drive format routine formats the cylinder (track) first, then it initiates a 'multiple sector write' command and a 'multiple sector read' command to write 32 sectors the drive then verify them. If CFORM followed this example, it would account for the need for the extra ram when writing >32 sectors/cylinder.  However, there is nothing preventing a format program from reading only one half of the cylinder (16-18 sectors) per iteration at the minor expense of speed. In fact, I wonder if the data write is even necessary; in theory, we should be able to validate the sectors after the format. Is writing/reading each cylinder after the format is a best practice?  

 

To format a floppy, the Geneve OS and 9234 use 5 bytes per track  (5 ID bytes *80 [tracks] * 2 [sides]) for a maximum RAM requirement of 800 bytes.  Unlike the MDM5 hard drive format routine, the Geneve OS does not write data to each track; verification is done by reading one sector at a time (slow!).  I have not (yet) found any evidence to support the need for extra RAM for the HFDC floppy IO.

 

CFORM can format hard drives at 33 and 34 sectors per cylinder, though in practice squeezing more than 32 sectors/cylinder seemed to push the data integrity limits of the drives and/or controller. (Edit: based on customer-reported issues/observations)   Track copiers always try to eek out the most speed and I'm sure tape drive support would have benefited from more DMA RAM, though neither materialized for the HFDC.

 

Share this post


Link to post
Share on other sites

As for the additional sectors being squeezed into the track, this is a common thought but it is not really substantial, as I learned. It is a matter of gap length. The controller does not care what is inside the gaps, and it does not care how long the gaps are, except for the sync gaps which must be 12 or 13 bytes long.

 

The cell width is fixed; that is, you always have the same number of cells on the track, and two cells are one bit, so there is an unformatted capacity that we can talk about. For the usual ST-225 and similar ones, you have 3600 rpm and a cell width of 0.1µs, so you get 166666 cells on the track. This is an unformatted capacity of 10416 byte.

 

Per sector, you have two sync gaps (13 bytes each), IDAM, DAM (1 byte each), sector header (4 bytes), 2 CRCs (2 bytes each), which is 36 bytes. Then you have some inter-sector gap which you can define (say, at least 8 bytes). This means 300 bytes per sector. Thus you can safely put 34 sectors in the track. 35 would be possible with a minimum gap, and 36 would definitely not fit ((256+36)*36 = 10512).

 

There was a similar discussion about the reasons why TI designed its double density format to be 16 sectors/track instead of 18, and I am almost sure that this is a purely mathematical issue, not related to data safety.

  • Like 2

Share this post


Link to post
Share on other sites

Mizapf,

  Let me try my question again, know that we know PFM has already been implemented.

  What were the steps you needed to take to add PFM in particular, and what do you do to add a piece of hardware in general?

 

Share this post


Link to post
Share on other sites
2 hours ago, mizapf said:

There was a similar discussion about the reasons why TI designed its double density format to be 16 sectors/track instead of 18, and I am almost sure that this is a purely mathematical issue, not related to data safety.

Good point.   My 'data integrity' comment was based on customer-reported issues/loss of data after they formatted their drive at 33/34 sectors per track, and subsequent return to normal operation upon reformatting at 32 sectors/track. The simplest, cost-effective customer fix was to say, "don't format to 33 or 34 sectors/track"; I don't recall if the root cause was ever determined.  

  • Like 1

Share this post


Link to post
Share on other sites
On 5/31/2021 at 2:06 PM, dhe said:

Let me try my question again, know that we know PFM has already been implemented.

What were the steps you needed to take to add PFM in particular, and what do you do to add a piece of hardware in general?

The answer would require me to elaborate on the MAME development process. If you are interested in contributing, please send me a private message.

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...