• Please review our updated Terms and Rules here

North Star / Disk Data Format / Horizon vs. Advantage

haglebu

haglebu

Experienced Member
Joined
Nov 22, 2018
Messages
153
Location
Germany, Lower-Saxony, Hildesheim
Both computers basically use hard-sectored floppy disks with 10 sectors in 5.25" format. Both FM and MFM, single-sided and double-sided are possible.
To the Horizon format I have read (I do not know however where) that here NO track and/or sector ID is used. In the Horizon manual is only talk about 96 microseconds between sector hole and start of DATA. Therefore the drives must be really optimal set for 300 RPM.

In the Advantage manual, however, I found information about the sector and track ID between SYNC BYTE and DATA.

Does anyone have further or more in-depth information on this?

data-format_hrz.png

data-format_adv.png
 
Last edited:
Here are my notes on N* format.

Northstar DD floppy format

10-sectors per track x 35 tracks per side
MFM encoding

Single and double-sided formats are supported

---

Data Layout

[Leading (falling) edge of sector index]
[96 us delay]
[Preamble = 33 Bytes of 0]
[Sync 0xFB 1-byte]
[Track-Sector 1-byte (see below)]
[Data 512-bytes]
[Checksum 1-byte (see below)]

There is no formal padding at the end of the sector. In a hard-sector
format the diskette controller is expected to re-sync on the next
index hole.

---

Track-Sector Byte Detail

Bits 0-3 = Sector (0..9)

Physical Order from rotational index: 0 2 4 6 8 1 3 5 7 9

Bits 4-7 are related to the track.

On side 0 of a diskette, the value in bits 4-7 cycles through the
sequence: 0x0 0x4 0x8 0xC as track advances. In other words,
tracks 0, 4, 8, 12, 16, 20, 24, 28, 32 have a value of '0x0' in the
upper four bits. Tracks 1, 5, 9, 13, 17, 21, 25, 29, 33 have a value
of 0x4 in the upper bits, etc.

On side 1 of a double-sided diskette, the value in bits 4-7 cycles
through the sequence: 0x1, 0x5, 0x9, 0xD as we advance inward from the
outermost track. This amounts to the same pattern shown above, but
with bit 4 set to denote the second side of the diskette.

---

Checksum Byte Detail

The checksum algorithm works as follows:

// Sector data
unsigned char data[512];

unsigned char csum = 0;
for (int i=0; i<512; i++) {
csum = csum ^ data;
csum = (csum << 1)|(csum >> 7);
}

// Resulting value is written to diskette as the checksum byte.

---

Logical data organization on double-sided diskette

Data is written in a serpentine order:

Side 0: Track 0..34
Side 1: Track 34..0

---

NOTE:

The Northstar technical documentation has a discrepancy between
figures and text. Figures 3-4 and 3-5 show the layout for DD MFM
diskettes with 512-byte sectors. The text references an older SD FM
format with 256-byte sectors.

The document you are reading now is intended to cover the DD MFM
512-byte format.
Click to expand...
 
It doesn’t appear that much of the Advantage software uses or validates the track/sector ID byte. For example, you can write an Advantage CP/M disk using the S-100 North Star DD controller, which writes two sync bytes instead of sync and track/sector ID, and the resulting disk will work in the Advantage. See the ReadMe file here: https://deramp.com/downloads/north_star/advantage/Software/

Mike
 
The hard sectored N* is more fussy about the sectors than the Heathkit H17 was. That is why, without more memory, the gotek would be quite difficult to use with the N*. As it is, the gotek has only been used as a read only drive on the H17. Getting it working on a N* would be a work of art. The controller on the N* keeps track of the sectors by a counter. It isn't quite as fussy about 300 rpm as you might think. It does expect the drive to be up to speed in only a few sectors after enabling the drive. It has a limit on the amount of time between sectors before the controller will error out. I forget what it was but it is controlled by a crystal divider, as a counter.
I got a N* a while back and most of the problems we related to rail voltages. Both regulators for 12V were bad. One did nothing and the other couldn't even support one drive, without sagging in voltage. Of course it had the usual number of tantalum capacitors that had failed. Even one of the axial ones on one drive were bad.
The other source of issues was the crimped connectors used on the bridge rectifiers. I know people say that the crimps are more reliable than solder but my experience says otherwise. I was seeing quite a bit of power supply sag. A quick look on the scope showed that the ripple was 60 Hz instead of 120 Hz. A missing phase from the supply was causing a lot of difficulty.
Dwight
 
Jeff (HxC) tried mightily to get N* read support working on a Gotek. No joy. The only device that can do it reliably is a DREM.
 
I was really lucky with my new (old) N* Horizon. I only had to change one 5V regulator on the ZPB-A2 CPU board. The power supply works fine. I am currently using two TEAC FD-55 or a COPAL M2551A. But without the DREM I would not have been able to get the N* to run.

North Star Horizon / Restoration / Part 1 // retrocmp / retro computing

North Star Horizon
www.retrocmp.de
 
Last edited:
haglebu said:
I was really lucky with my new (old) N* Horizon. I only had to change one 5V regulator on the ZPB-A2 CPU board. The power supply works fine. I am currently using two TEAC FD-55 or a COPAL M2551A. But without the DREM I would not have been able to get the N* to run.

North Star Horizon / Restoration / Part 1 // retrocmp / retro computing

North Star Horizon
www.retrocmp.de
Click to expand...
So, if I understood, you initially used the DREM and now use the TEAC or COPAL? What controller do you use with the TEAC and do you use a virtual sector generator?
 
Hello @jon1967us,

correct. I started with the DREM because I did not have any working HS10 boot disk. After the DREM ran fine with the N* I first connected a Tandon TM100-2 as drive B and was able to make a real boot disk; I have a lot HS10 floppies. Later I connected two TEAC FD-55B; these are perfectly matched. I have only tested the COPAL. I use the MDS-AD3 Micro Disk Controller. The VSG is just ordered from Mike; it is on the journey.

The next job is making the PROM mod (with 2732 or 2716) by Mike Douglas.

Maybe I was actually lucky with my Horizon because it ran again so quickly. I had not expected that. Basically, the Horizon is ingenious. Masses of documentation and software. And Mike Douglas (@deramp5113) was/is a real help to me.
 
Last edited:
I have an MDS-AD2. I wonder if it would work with the Teac. I think Mike Douglas mentioned these less expensive, more reliable drives in one of his videos.
I have 2 Horizons, btw, both with the ROM mods and VSGs in them. One is an early 80's DS+HD the other is a 70's single SS drive. The latter has developed problems with the drive, so hence the question.
 
In 2021 I added hard-sector support to FlashFloppy Gotek firmware to use with the Vector 4. After a lot of bug fixing, the Advantage was happily reading and writing was stabilizing. It's not been tested with the Advantage since my last bug fix. The issues were simply bugs, not Gotek limitations. You'd want to use a good USB disk, though.
 
ejona said:
In 2021 I added hard-sector support to FlashFloppy Gotek firmware to use with the Vector 4. After a lot of bug fixing, the Advantage was happily reading and writing was stabilizing. It's not been tested with the Advantage since my last bug fix. The issues were simply bugs, not Gotek limitations. You'd want to use a good USB disk, though.
Click to expand...
I'm excited to try this, I have a number of gotek and openflops devices that I can use too try this and I've got a couple advantages I want to get going again without risking my limited hard sectored media
 
ejona said:
In 2021 I added hard-sector support to FlashFloppy Gotek firmware to use with the Vector 4. After a lot of bug fixing, the Advantage was happily reading and writing was stabilizing. It's not been tested with the Advantage since my last bug fix. The issues were simply bugs, not Gotek limitations. You'd want to use a good USB disk, though.
Click to expand...
That's good news. After reading some of the GitHub issues threads I had the impression this was an incomplete and abandoned effort! Is this code in the main branch?
 
ejona said:
In 2021 I added hard-sector support to FlashFloppy Gotek firmware to use with the Vector 4. After a lot of bug fixing, the Advantage was happily reading and writing was stabilizing. It's not been tested with the Advantage since my last bug fix. The issues were simply bugs, not Gotek limitations. You'd want to use a good USB disk, though.
Click to expand...
Do you have any details about the configuration required? I'm working to get it working right now and I can get the green LED to flash, but it doesn't seem to want to read my HFE images
 
@shirsch's notes seem to be for the Advantage (especially with the note of inconsistent docs). I was digging into the formats for the Northstar single-density controller on the FlashFloppy thread.

Interleaved sectors are a pretty big difference with the Advantage, although I don't see that mentioned prominently in a glance through manuals. I see evidence in FluxEngine and HxC that some real-life disks seemed to have sequential sectors. The second sync byte being [2 track bits, 2 head bits, 4 sector bits] agrees with HxCFloppyEmulator's behavior, but is different than what the technical manual that says [4 track bits, 4 sector bits] (p. 3-36). The notes mention the 96 µs wait before the preamble, which is stated in the Advantage tech manual, but it seems that may just be the standard software driver delay. The requirement seems to be 0-200 µs of wait before the preamble.

The reading process in the manual expects the sync byte after 500+150 µs, and the preamble should be 1 ms so there's plenty of slack. HxCFloppyEmulator uses too small a preamble (12.5 bytes; really the index looks to be in the wrong place) and has no wait, so it seems we'd expect HFEv3 images it produces to not work in the Advantage.

I'm going to search around for some low-level images and dig into the manuals to see if I can get a better picture of the interleaving and second sync byte variations. I might also see if I stumble on a listing for the driver, which would probably shed some light. The selection selection process (p. 3-35) makes me think it reads the sector id from the disk, but that raises more questions.
 
https://deramp.com/downloads/north_star/software/h_harte_disks/HD-18.zip has FluxEngine recordings of three disks:
  • Single_Retry_Test_C2_C3_02-05-83. DSDD. 349 µs wait before preamble. track/head/sector sync byte, using physical track number. No interleaving
  • HDOS2_1_SYSTEM_EAT_Copy_TEST_disk_do_NOT_distribute. DSDD. 334-350 µs wait before preamble. 0xFB sync byte
  • HD-18_Final_Test_SN003_06-18-82. SSDD. 378-401 µs wait before preamble. 0xFB sync byte
The 500 µs read delay seems to be to cover long waits before the preamble, even if they claim it should be less than 150 µs when writing and show it as 0-200 µs when reading.

The sector counting is done by the 8035, which has access to the sector pulse but not the floppy data bits. So the need for sector selection to happen at the end of the sector isn't clear, but it also doesn't seem important. Maybe it is an optimization to allow the value to be accurate within one rotation.
 
ejona said:
Interleaved sectors are a pretty big difference with the Advantage, although I don't see that mentioned prominently in a glance through manuals.
Click to expand...

snhirsch mentioned on the HxC forum a long time ago that it was a logical/software interleaving, so it wouldn't show up in sector headers. And I don't think it would have been documented in the manuals I was looking at.
 
I use the MDS-AD3 controller. It has worked perfectly for me, combined with Mike's VSG and the IBM Japanese made YD-580 disk drives & my SOL-20.

One reason I chose these drives is that they are a direct motor drive type and I think that helps with both speed jitter and speed calibration.

I had read a few stories about drives with belts and it worried me. I had worked before, extensively, in the field of belt driven vs direct drive systems in VCR's and various DC motor servo systems and I was very aware of the performance differences in those and figured the same principles probably applied to disk drives.

In practice the only trouble I have had is that some disks out there have degraded magnetic media and don't work well if at all, while others work fine, especially the ones from 3M, of their later manufacturing runs.
 
Dwight Elvey said:
The other source of issues was the crimped connectors used on the bridge rectifiers. I know people say that the crimps are more reliable than solder but my experience says otherwise. I was seeing quite a bit of power supply sag. A quick look on the scope showed that the ripple was 60 Hz instead of 120 Hz. A missing phase from the supply was causing a lot of difficulty.
Dwight
Click to expand...

I had exactly this problem in my SOL-20.

The crimping on the spade connectors on the wires leading to the bridge rectifier were badly done at the factory, one was crimped onto the plastic insulation obviously by a trainee. The copper strands were just touching the metal part of the connector. The main power supply rail would transiently collapse and recover. It corrupted a good number of disks when I was using the N* controller. It took me a while to find it, because the defect was hiding under an insulation sleeve on the spade connector. I only got to the bottom of the problem, because I had fitted a compact LED voltmeter and I saw it flicker when the defect occurred.

In the end I re-did all of the crimped connectors like this and soldered them, rather than crimping. No power supply issues since.

Crimping is good provided:

1) Exactly the right tool and wire size is used for the connector type.
2) The operator knows exactly what they are doing.

If those two basic parameters are not met, bad crimping creates a "disaster in waiting" that could rear its ugly head anytime, from now until eternity.
 
You must log in or register to reply here.
Back
Top