• Please review our updated Terms and Rules here

FreHD on a Model II?

dano

Experienced Member
Joined
Mar 1, 2007
Messages
114
Location
Metzger, Oregon
I hope someone here might have some insight on this. From what I understand, the hard drive system (with the exception of some of the early ones) is the same one use for the Model II/12 and the Model III/4. If that's the case, I see no reason why a FreHD wouldn't work on a Model II, 12, 16, or 6000; yet I have seen no mention of this so far. I have a Model II that is missing it's boot disk, it would be really cool if I could download a LS-DOS image to an SD card and boot directly that way. Anybody know?
 
There's no mention of FreHD working with the II/12/16/6000 because none of us who are part of the FreHD team owns one of those machines, with the appropriate HDC in it... so the jury is still out on whether it will work with the 8" TRS-80s. ON PAPER, it should work. But since none of us has connected it to a correctly configured 8" TRS-80 we don't know. A gentleman bought a FreHD with the intention to set it up on his Model 12, but is currently trying to source the correct HDC before he can move forward with the project. As you can imagine I will be keen to hear his results.

Cheers,

Ian.
 
Of course I have the same issue - no HDC - so I wouldn't even be able to test it at this point. I'm glad to hear that it's at least still an option on paper. I do know someone who's offered me one of his 3 6000s which I believe have the correct HDC so if I'm able to get one, I would be able to test this out. I, too, would love to hear the results of the Model 12 test as that will likely happen a long time before I'm able to try things out. Does anyone know if the Model II is able to boot directly from a HDD or not? I haven't been able to find any specific information about that. If it is, then that would be a *much* easier way to revive one of these machines with no system disk.
 
It won't work as-is on the model II, unfortunately. The reason is that I use several I/O addresses (in the C0-CFh range) for the "extra" provided by FreHD (RTC, access the FAT, auto-boot, etc...). On model I, III and IV, these addresses are free, but they are NOT on the model 2.

That said, the FreHD should be compatible from a hardware perspective, so all it needs is a different PIC firmware, which rips the extra functionality. And maybe add support for 512-bytes sectors (should be easy to do).

But as Ian said, I don't have a model II, so it will be hard to debug the new code. And there is also no model II emulator around...

If a model II owner can come with his machine to Belgium or Luxembourg, I'd be happy to write the code and get it debugged with a real machine :)

-Fred
 
If a model II owner can come with his machine to Belgium or Luxembourg, I'd be happy to write the code and get it debugged with a real machine :)
-Fred
That would be quite a lot of luggage :)

I would be interested in moving this along if anyone wants hardware to play with in the NJ area.
Kelly
 
Fred, thank you for clarifing about the additional I/O addresses. I would love it if you could point me to a document or web site that lists the Model II's I/O mapping. I have some documentation of hardware in the E0-FF range but that's all I was able to find. I hate to ask (because you've already put in a lot of time on the project) but instead of making a custom PIC with the extra features ripped, would it be possible to have a future version of firmware that looks for a switch or jumper or some other external input that can be used to disable the extra features?
 
Dano,

There is a spare pin which could be used for a jumper, or a setting in the eeprom could be done too. On the firmware side, suppressing features is trivial to do (the dispatching is done by a jump table, we should simply have another one for the model II).

Regarding the register mapping, it's basically the same as the model III, but the model II has the CTC I/O map there too. These addresses are not used on the model III/IV, so I used them to provide the extra functionality (RTC, access FAT files, etc..)

-Fred

Here is an extract from Frank Durda which gives more details :


It has certainly been a while since I looked at the code, but port offsets
are exactly the same, eg x0 x1 x8 x9 xA xB xC xD xE xF ports do exactly
the same things on the Model II/12/16/6000 family as they do on the
Model III/4/4D/4P family. The Model I is the odd man, and required the
Model I Hard Disk Adapter in order to function.

You will notice that the CTC present on the Hard Disk Interface registers fill
in the gap between X2 and X7 in the port map. Mode on the CTC ports in a
moment.

The starting offset for the hard disk ports on the Model II/12/16/6000 hard
disk interface port could be several different address ranges, but for almost
every OS I can think of, it was kept in the 0xc0 - 0xcf range, the same as
was used on the Model III/4/4D/4P systems.

Be aware that the 8Meg Hard Disk Systems were hard-coded to run with 512
byte sectors only. Marketing materials claimed that the five meg drives
supposedly only worked in 256 byte mode and the 12-Meg drives only worked
on 512 byte mode, but I know this not true for the drives I had access to.
Perhaps early production runs had such a limitation, but I suspect it was
an artificial limit, so that TRSDOS-II/TRSDOS-16 didn't have to support
5 Meg drives.

Early releases of TRSDOS-II/TRSDOS-16 had to have the exact drive geometry
coded internally, so you actually had to distribute a new release to sell a
new drive size or one with a different number of heads/cylinders. LDOS didn't
have this problem, but the Model III/4 of that period did have a somewhat
paranoid product buyer who didn't want to risk 12 Meg drives being available
leaving him with 5 Meg drives in his stores that no one would buy so there was
a long time when the official word was that 12 Meg drives would not work on
the Model III/4, when in fact they would work. That sort of thing happened a
lot.

The biggest coding difference between the Model II/12/16/6000 and III/4/4D/4P
families was in interrupt control. The Model III/4/4D/4P drivers typically
did not use interrupts at all for hard disk operation. They just waited in a
loop until the given command completed.

On the Model II/12/16/6000, interrupt mode 2 interrupts were available, and
were used by some operating systems, while IM1 were used by a few other
operating systems, and the most primitive drivers didn't use interrupts at all,
again relying on polling loops to determine when the given command had
completed.

DMA was available on the Model II/12/16/6000 for hard disk operations, but was
not required, and with the exception of XENIX 3.2, hard disk DMA was typically
not used. It's use in XENIX 3.2 was something of an experiment. It improved
speeds for certain benchmarks, but generally was neutral or slightly lowered
overall performance. This had to do with a Tandy-custom DMA transfer option
that would halt the 68000 processor while DMA operations to 68000 memory were
occurring, rather than dithering Z80 DMA cycles between 68000 CPU cycles,
which was the default.

So apart from interrupt handling (if it was used) and DMA (if that was used),
drivers for one family could work largely unchanged on the other, with the
biggest difference typically being the sector size, as Model II/12/16/6000 systems
(notably TRSDOS-II and XENIX) using 512 byte sectors and most of the Model
III/4/4D/4P OSes (basically all from Logical Systems) using 256 byte sectors.
 
Fred,

I have a spare model II, what is your address and I can see what it would cost to ship. I could also part out the unit and you could easily just add a video display. Less cost to ship.

Brad
 
Back
Top