Re: TRS-80 Question

[Charles Dickman via cctalk]

On Tue, Apr 12, 2022 at 3:46 PM Fred Cisin via cctech 
wrote:

> >> There's a 2K hole in the Model I memory map above the ROM
> On Tue, 12 Apr 2022, Yeechang Lee via cctech wrote:
> > Is this the hole that causes stock Model I to not run CP/M?
>
> NO.
> The problem with CP/M on TRS80 is that CP/M expects RAM from location 0 on
> up.


When I was a freshman at Purdue, I lugged my Model III to my dorm room and
connected to the ECN network with a 300 baud modem. I used a local editor
and wrote a Pascal program to upload my Pascal source to the dual processor
VAX-11/780 (Google George Goble), ea or eb, (I don't remember) that was
used by our introductory programming class. The terminal program I had was
something I found in Byte magazine in assembler and I modified it for the
TRS-80. I had BASIC, Assembler and Fortran on the TRS-80 M III, so it was
probably all in assembly.

There was an article in Byte about CP/M for the TRS-80 Model III that
described a hack to swap the ROM for RAM. The idea was to invert bits A15
and A14. That would move the ROM and keyboard from  to C000. There was
a spare bit in some 4 bit register, so all you had to do was cut a couple
traces and insert some XOR gates. I remember doing the modification on a
Saturday while listening to the Purdue football game on the radio. I put it
all back together and it worked. WoHo!

At that point though I had no access to CP/M or where I might get it legal
or otherwise, but I was good to go when I found it.

I still have the computer and I still have the Byte copy. So 37 years later
I should try to complete the project.

-chuck

Re: idea for a universal disk interface

[Chris Zach via cctalk]

Good data, thanks! I kind of like the ESDI disks, they're more solid and 
reliable than the MFM ones, and to be honest the RQDX3 was not a super 
fast disk controller. I wonder if it could do block mode DMA.


I'll keep an eye out for the Sigma, the only thing I wish I had on the 
MTI MQD13 would be some disk cache to speed things up. Granted 11/M+ 
does have disk caching in the OS, I should check to see how much quicker 
that makes things.


Good used ESDI disks come up on Ebay from time to time. A nice 660mb CDC 
is enough for most general pdp usage...


C


On 4/19/2022 1:03 PM, Glen Slick via cctech wrote:

I also have multiple ESDI controllers, more than one these flavors:

Dilog DQ686
http://www.bitsavers.org/pdf/dilog/2120-0137-1_DQ686_Nov89.pdf

Emulex QD21
http://www.bitsavers.org/pdf/emulex/QD2151002-J_QD21_Jun90.pdf

Sigma SCD-RQD11-EC (There seems to be multiple versions from different
vendors of this same basic board).
http://www.bitsavers.org/pdf/sigmaInformationSystems/400740-B_SDC-RQD11-EC_Disk_Ctrl_Man_Jul88.pdf

They all support block mode DMA transfers, and command queuing with
seek optimization. The Dilog DQ686 and Emulex QD21 are dual wide
boards. The Sigma SCD-RQD11-EC is a quad wide board and has 1MB of
cache memory (which takes up about a quarter of the board area). The
examples I have might only be populated with 512KB of cache memory.

I might have had close to a dozen working full height 5.25-inch ESDI
drives at one point. Unfortunately most of them have failed while
sitting idle over the last few years. Without checking now I don't
know if any of them still work. So the dozen or so Q-Bus ESDI
controllers don't have any use for me now. (Fortunately I also have
more Q-Bus SCSI controllers than backplanes to put them in).

I also have a single Andromeda ESDC ESDI controller. Never found a
manual for that one. Did eventually figure out how to get into the
on-board configuration utility.



On Tue, Apr 19, 2022 at 8:56 AM Douglas Taylor via cctech
 wrote:


Once upon a time I used an Emulex QD21, but I sold it because the actual
ESDI disks I had were a pain in the butt.  Always crashing.
I still have a Webster (quad board) SRQD something.
I think I had a Dilog board also.  It's been a while, probably 20 years.
Doug

On 4/18/2022 9:12 PM, Chris Zach via cctech wrote:

Interesting, what kind of ESDI controllers do you have? They got
advanced features like cache, ordered seeks, and burst mode/block mode
DMA?

Re: TRS-80 Question

[Fred Cisin via cctalk]

There's a 2K hole in the Model I memory map above the ROM

Is this the hole that causes stock Model I to not run CP/M?



NO.
The problem with CP/M on TRS80 is that CP/M expects RAM from location 0 on
up.


On Tue, 19 Apr 2022, Charles Dickman wrote:

When I was a freshman at Purdue, I lugged my Model III to my dorm room and
connected to the ECN network with a 300 baud modem. I used a local editor
and wrote a Pascal program to upload my Pascal source to the dual processor
VAX-11/780 (Google George Goble), ea or eb, (I don't remember) that was
used by our introductory programming class. The terminal program I had was
something I found in Byte magazine in assembler and I modified it for the
TRS-80. I had BASIC, Assembler and Fortran on the TRS-80 M III, so it was
probably all in assembly.

There was an article in Byte about CP/M for the TRS-80 Model III that
described a hack to swap the ROM for RAM. The idea was to invert bits A15
and A14. That would move the ROM and keyboard from  to C000. There was
a spare bit in some 4 bit register, so all you had to do was cut a couple
traces and insert some XOR gates. I remember doing the modification on a
Saturday while listening to the Purdue football game on the radio. I put it
all back together and it worked. WoHo!

At that point though I had no access to CP/M or where I might get it legal
or otherwise, but I was good to go when I found it.

I still have the computer and I still have the Byte copy. So 37 years later
I should try to complete the project.

-chuck


There were numerous hacks for TRS80 CP/M.
FMG sold a relocated CP/M for stock TRS80
Mnay programs weren't compatible, but it WAS CP/M, and adequate for 
teaching CP/M basics to my class, such as creating a zero length file for 
program restarting, etc.


Omikrom ("Mapper")
Parasitic Engineering ("Shuffleboard"?  Howard Fullmer's company)
Both of those were one daughterboard in the Model 1 to remap memory, and a 
daughterboard in the Expansion Interface to add 8" capability



There also some for model 3, including
Montezma Micro (Ron Jones?)
Hurrican Labs,
FEC?
Holmes?
Micro Craft?


When Radio Shack came out with the Model 4, which had built-in suitable 
memory map, they sold "CP/M Plus" (3.0?)
That would probably be the best to work with, and likely the easiest 
to find.


--
Grumpy Ol' Fred ci...@xenosoft.com

RE: Fanuc PPR - Paper Tape Punch, Printer and Reader

[Martin Bishop via cctalk]

An update on my fight with the PPR, also one of its cousins.

https://www.cnczone.com/forums/general-cnc-machine-related-electronics/430874-cnc-engineering.html#post2505622
 covers my RFI to the CNC community and provides a few pictures of a 19" rack 
reader integrated with a Zynq; load binary tape, run program on FPGA PDP-11.

That was the cousin, which provided an education on Fanuc PTRs.  The PPR's PTR 
turns out to have had a blown illuminator: the series (active) diode was o/c 
and the PNP which effects the constant current source had the wrong pin out - 
the Fanuc footprint is not industry standard.  The PNP had obviously been 
replaced by hands unknown, the flux had not been cleaned off.  My only, real, 
interest in the pathology is will it happen again.

With that fixed: PPR in remote mode, load tape, send DC1, tape whizzes through, 
octets crawl out (4800 baud).

My unanswered questions are now mostly those associated with the 19" rack 
reader.  Specifically, what input A13 does and the semantics of the front panel 
switch positions.

Martin

Re: idea for a universal disk interface

[Guy Sotomayor via cctalk]

It's not really fast enough and you'll get into all sorts of 
complications once you start to think about trying to keep up with 
simulation rotations.  For example, if someone starts a read at half way 
through a rotation (e.g. after the index pulse) now you have to have 
logic/code that can start/stop the transfer in random places.  The way 
that I have it designed, it's all sequential so no random start / 
lengths and it's all done during a seek which the data isn't being 
clocked out.


The Zynq-7020 (which is my low end design) has 4.9Mb of block RAM (in 
140 36Kb blocks).  In the cylinders I actually use 9-bits per byte as I 
need an escape in order to encode some other data.  ;-) With that it can 
hold the 512KB needed with some to spare.  My high end design will use 
the Zynq-Ultrascale+ (ZU3CG) has 7.6Mb of block RAM (in 216 36Kb 
blocks).  If I go to the next higher version (ZU4CG)the block RAM goes 
down to 4.5Kb (in 128 36Kb blocks) but gains 13.5Mb in "UltraRAM" which 
should allow for any reasonable cylinder buffering.


Of course, I'm just describing my design and design requirements.  First 
and foremost I wanted a simple HW & SW design that could provide 
accurate drive timings (e.g. I could faithfully reproduce the timings of 
any particular drive) so as to maximize the compatibility with any 
controller (and I have some weird ones).


I've been pouring over ANSI specs, controller specs and drive specs for 
SMD/ESDI for a few years now and have thought about a number of 
different ways to do this and what I've described is what I've come up with.


You may have different goals which may drive you to make different 
choices/decisions.


TTFN - Guy

On 4/19/22 11:49, shad via cctalk wrote:

Guy,
I understand that cylinder command has no particular timing requirements, while 
head command must be effective within microseconds. My doubt is, RAM access on 
high performance port could be fast enough to satisfy also the latter.
In case it couldn't or was not assured, I think the best strategy could be to 
preload only a small block of data for each head, for prompt start on head 
command; enough to manage safely RAM access latency.
Each block also would work as buffer for data of subsequent RAM accesses, until 
whole cylinder had been processed.
This strategy would remove the strict requirement of blockram capacity for the 
Zynq, and given that bigger models cost a lot, it would be a significant spare 
for anybody.
Furthermore,  support for any hypotetical disk with bigger cylinder (not SMD) or for tape 
with very large blocks or "infinite" streams could not be feasible with the 
whole cylinder design. I would prefer to avoid any such limitation, in way to possibly 
reuse the same data transfer modules for any media.

Andrea


--
TTFN - Guy

RE: idea for a universal disk interface

[Tom Gardner via cctalk]

Agree that we are talking about two vastly different projects.

Personally I think the universal disk reader is doable and interesting but
expensive.

 

Start with a clean bench having an air bearing variable speed motor and a
universal mount to which various pack/cartridge adapters can be mounted.

Add a laser controlled horizontal positioner with a Z height adjustable
probe head station  (manual Z height at first but maybe automated if volume
dictates)

Add some sort of head load/unload

Pretty straight forward stuff

 

A modern TMR should easily read the much wider track of old iron oxide but
the issue is flying high and head crashes.  So there needs to be some
research here.  Perhaps a surface (or track) mechanical buffering process
would be sufficient or a ridiculously wide by current standards TMR head or
such a head with an adjustable flying height read element or some
combination should be workable.

 

Track following may or may not be a requirement.  If the read element is
small enough maybe just positioning it in the center is enough.  Or maybe
just once around synthetic run out compensation would work given the very
wide track/ very narrow reader.  If you have to go full track following
that's not much of a problem with the few embedded servo old iron but
implies a second head  reading the servo disk coupled to the reader head -
doable but one more head to crash and a whole research project on the
various track following systems and associated hardware.   Probably doable
with DSPs since the transition rate on the servo info is pretty low

 

Finally you get to interpreting the raw data; this might be relatively
straight forward since the data rate of old iron is fairly low so the analog
signal could be highly oversampled, 10x maybe, which makes the decoding
pretty straight forward if you know the format and recording code.

 

I once built a disk pack servo writer, class 100 clean room, slit the
concrete foundation, excavated and filled with sand, put an air bearing dc
motor with a 3330 spindle mount in a granite slab and used a laser
positioning micro stepping actuator to write the servo surface of 3336 class
disk packs.  Feels like a similar project

 

Tom 

 

 

 

 

-Original Message-
From: Paul Koning [mailto:paulkon...@comcast.net] 
Sent: Tuesday, April 19, 2022 5:30 AM
To: Mike Katz; cctalk@classiccmp.org
Subject: Re: idea for a universal disk interface

 

 

 

> On Apr 18, 2022, at 6:44 PM, Mike Katz via cctalk <
 cctalk@classiccmp.org> wrote:

> 

> Which is more generic.

> 

> ESDI, SMD or SCSI.

> 

> In my opinion, SCSI is as close are you are going to get to a universal
interface.

> 

> As for reading raw data from a drive.  The newer the drive, the higher the
bit density and lower the strength of the magnetic fields and hence the
lower the flying height.  You have to deal with linear (or horizontal)
recording, perpendicular recording, Heat assisted magnetic recording,
microwave assisted magnetic recording.  The latest technologies are
approaching 1TB (yes that's TB) per square inch.

> 

> If you spin the platters too slowly you will not be able to distinguish
individual magnetic fluctuations from noise.  What do you propose as your
maximum data density (in BPI) and what is the minimum speed you will need to
accurately decode it.

 

I know about some of the modern drive magic, but I wasn't talking about
those at all.  My comments about recovering raw signals from disk surfaces
is for much earlier disks, especially removable packs.  In more recent disks
you always have the drive if you have the disk since they are the same
thing.  (I'm ignoring "data recovery" services here that deal with
mechanically failed drives; that's a specialized business and as you said
it's increasingly difficult with modern drives.)  

 

If you consider 1960s through 1980s you're likely to run into disk packs for
which the drives may be hard to find.  The mechanical tolerances of those
devices require care but are not crazy difficult, as my RC11/RS64 example
last week was meant to illustrate.  The bit densities are not all that high,
nor the track densities.  Consider for example that the track positions on a
1311 drive are set by mechanical detents, and are low enough that no servo
system is used at all.

 

My mechanical skills and tools are perhaps a bit better than some of the
readers here, undoubtedly worse than others.  I could sketch a "spin table"
that could handle, say, an RK05 pack.  Without a milling machine I can't
build it, but that could be fixed, and I could refine my skills to make it
work.  Do I plan to?  No, but if an interesting enough pack showed up I
could imagine doing it.  The RA60 pack I have would be a bit more of a
stretch -- more platters and higher densities, not to mention lack of
documentation -- but it's still on the edge of possibilities.

 

So I think there are two different possible projects here.  One involves a
generic c

Re: interesting DEC Pro stuff on eBay

[John Foust via cctalk]

At 01:40 PM 4/19/2022, Bjoren Davis via cctalk wrote:
>Looking at the photo I see the name "Dave Iacobone".  I wonder if he is still 
>around and remembers that board.

https://www.linkedin.com/in/dave-iacobone-0a11436/

At DEC from 1993 to 1996, now at iRobot.

- John

Re: RCA COSMAC MS2000 MicroDisk Development System

[Joshua Rice via cctalk]

On with the saga of the COSMAC MS2000…

I powered it up a few days ago. The ROM boots, nothing smoked, the drives whirr.

However, one of the RAM boards (the lower 32k) seems to have failed with a 
stuck bit. it outputs the rather humourous message of BAD RAM P00 (where P00 is 
memory page 00h). poking at various memory locations seem to reveal that they 
are populated with 40h instead of 00h. I tried reseating th card, and swapping 
backplane slots, to no avail.

Now my first assumption was that the tc40h245p bus buffer might have an open 
short driving one of the lines high, but probing it with a multimeter hasn’t 
revealed anything enlightening, with all resistance values being practically 
identical. Sadly, this seems to be the only thing between the RAM chip’s data 
bus and the card edge connector. Continuity seems fine on all pins.

Is it entirely possible that one of the RAM chips has an open short and is 
pulling the line high? How would i go about testing this without desoldering 
every chip off the board? I fear my soldering skills (and tools) aren’t up to 
the skill level required for such an endeavor, and i’m really paranoid about 
killing something that’s practically irreplaceable. One chip is probably fine, 
but a whole board is just asking for trouble.

I hope someone here can shine some light on the matter. I’m really flying from 
the seat of my pants on this one, and thoroughly understand i’m way out of my 
depth! It’s entirely possible there’s something i’ve overlooked.

For reference, this is the offending board: https://i.imgur.com/G2zMw7t.jpeg 
https://i.imgur.com/rrHvl4C.jpeg

The data lines on the card edge connecter start from the 3rd finger from the 
top, and carry on down 8 fingers. It’s a dual sided board, no layers here. 

Thanks, 

Josh Rice

RE: idea for a universal disk interface

[shadoooo via cctalk]

Guy,
I understand that cylinder command has no particular timing requirements, while 
head command must be effective within microseconds. My doubt is, RAM access on 
high performance port could be fast enough to satisfy also the latter.
In case it couldn't or was not assured, I think the best strategy could be to 
preload only a small block of data for each head, for prompt start on head 
command; enough to manage safely RAM access latency.
Each block also would work as buffer for data of subsequent RAM accesses, until 
whole cylinder had been processed.
This strategy would remove the strict requirement of blockram capacity for the 
Zynq, and given that bigger models cost a lot, it would be a significant spare 
for anybody.
Furthermore,  support for any hypotetical disk with bigger cylinder (not SMD) 
or for tape with very large blocks or "infinite" streams could not be feasible 
with the whole cylinder design. I would prefer to avoid any such limitation, in 
way to possibly reuse the same data transfer modules for any media.

Andrea

interesting DEC Pro stuff on eBay

[Bjoren Davis via cctalk]

Hello Retronians,

I just saw some interesting DEC Professional items on eBay from 
smhelectronics261 (https://www.ebay.com/sch/smhelectronics261/m.html):


1. Pro-350 (and presumably -325) video board
   https://www.ebay.com/itm/294933607768
2. RD (hard disk) controller https://www.ebay.com/itm/294933620853
3. CTI RAM board https://www.ebay.com/itm/294933515548
4. RAM daughtercards https://www.ebay.com/itm/294933505973.  The
   description says "This added 512MB or Ram" but I think it is
   mistaken. The boards are marked "5415084" which I believe is the
   2-layer version of the board populated with 64 Kibit DRAMS, for a
   total of 128 KiByte/board or 256 KiByte for both boards (assuming
   that's actually what they're selling).
5. Something called a "DEC Digital Professional DMA tester diagnostic
   module Pro350" board https://www.ebay.com/itm/294933577848.

I've bought from this seller before and they seem to have had access to 
DEC-internal development stuff.  I bought a prototype TMS board and a 
prototype never-released high speed serial board from them.


#5 is especially interesting because, as far as I know, no production 
CTI board ever did DMA (not even the disk and Ethernet controllers, to 
everyone's disappointment).  Looking at the photo I see the name "Dave 
Iacobone".  I wonder if he is still around and remembers that board.


Just FYI: I, too, might bid on some of these items, but I thought it'd 
only be fair to let everyone know.


--Bjoren

Re: idea for a universal disk interface

[Glen Slick via cctalk]

I also have multiple ESDI controllers, more than one these flavors:

Dilog DQ686
http://www.bitsavers.org/pdf/dilog/2120-0137-1_DQ686_Nov89.pdf

Emulex QD21
http://www.bitsavers.org/pdf/emulex/QD2151002-J_QD21_Jun90.pdf

Sigma SCD-RQD11-EC (There seems to be multiple versions from different
vendors of this same basic board).
http://www.bitsavers.org/pdf/sigmaInformationSystems/400740-B_SDC-RQD11-EC_Disk_Ctrl_Man_Jul88.pdf

They all support block mode DMA transfers, and command queuing with
seek optimization. The Dilog DQ686 and Emulex QD21 are dual wide
boards. The Sigma SCD-RQD11-EC is a quad wide board and has 1MB of
cache memory (which takes up about a quarter of the board area). The
examples I have might only be populated with 512KB of cache memory.

I might have had close to a dozen working full height 5.25-inch ESDI
drives at one point. Unfortunately most of them have failed while
sitting idle over the last few years. Without checking now I don't
know if any of them still work. So the dozen or so Q-Bus ESDI
controllers don't have any use for me now. (Fortunately I also have
more Q-Bus SCSI controllers than backplanes to put them in).

I also have a single Andromeda ESDC ESDI controller. Never found a
manual for that one. Did eventually figure out how to get into the
on-board configuration utility.



On Tue, Apr 19, 2022 at 8:56 AM Douglas Taylor via cctech
 wrote:
>
> Once upon a time I used an Emulex QD21, but I sold it because the actual
> ESDI disks I had were a pain in the butt.  Always crashing.
> I still have a Webster (quad board) SRQD something.
> I think I had a Dilog board also.  It's been a while, probably 20 years.
> Doug
>
> On 4/18/2022 9:12 PM, Chris Zach via cctech wrote:
> > Interesting, what kind of ESDI controllers do you have? They got
> > advanced features like cache, ordered seeks, and burst mode/block mode
> > DMA?

Re: idea for a universal disk interface

[Douglas Taylor via cctalk]

Once upon a time I used an Emulex QD21, but I sold it because the actual 
ESDI disks I had were a pain in the butt.  Always crashing.

I still have a Webster (quad board) SRQD something.
I think I had a Dilog board also.  It's been a while, probably 20 years.
Doug

On 4/18/2022 9:12 PM, Chris Zach via cctech wrote:
Interesting, what kind of ESDI controllers do you have? They got 
advanced features like cache, ordered seeks, and burst mode/block mode 
DMA?


C


On 4/18/2022 6:09 PM, Douglas Taylor via cctech wrote:
Because of this I'm holding on to my DEC Qbus ESDI controllers!!!  
You never know

Doug

On 4/17/2022 4:35 PM, Guy Sotomayor via cctech wrote:
I chose ESDI and SMD fundamentally because the interface is 100% 
digital (e.g. the data/clock separator is in the drive itself). So I 
don't need to do any oversampling.


TTFN - Guy

On 4/17/22 11:12, Paul Koning via cctalk wrote:


On Apr 17, 2022, at 1:28 PM, shad via cctalk 
 wrote:


hello,
there's much discussion about the right  method to transfer data 
in and out.
Of course there are several methods, the right one must be 
carefully chosen after some review of all the disk interfaces that 
must be supported. The idea of having a copy of the whole disk in 
RAM is OK, assuming that a maximum size of around 512MB is 
required, as the RAM is also needed for the OS, and for Zynq 
maximum is 1GB.
For reading a disk, an attractive approach is to do a high speed 
analog capture of the waveforms.  That way you don't need a priori 
knowledge of the encoding, and it also allows you to use 
sophisticated algorithms (DSP, digital filtering, etc.) to recover 
marginal media.  A number of old tape recovery projects have used 
this approach.  For disk you have to go faster if you use an 
existing drive, but the numbers are perfectly manageable with 
modern hardware.


If you use this technique, you do generate a whole lot more data 
than the formatted capacity of the drive; 10x to 100x or so. Throw 
in another order of magnitude if you step across the surface in 
small increments to avoid having to identify the track centerline 
in advance -- again, somewhat like the tape recovery machines that 
use a 36 track head to read 7 or 9 or 10 track tapes.


Fred mentioned how life gets hard if you don't have a drive. I'm 
wondering how difficult it would be to build a useable "spin 
table", basically an accurate spindle that will accept the pack to 
be recovered and that will rotate at a modest speed, with a head 
positioner that can accurately position a read head along the 
surface.  One head would suffice, RAMAC fashion.  For slow rotation 
you'd want an MR head, and perhaps supplied air to float the head 
off the surface. Perhaps a scheme like this with slow rotation 
could allow for recovery much of the data on a platter that 
suffered a head crash, because you could spin it slowly enough that 
either the head doesn't touch the scratched areas, or touches it 
slowly enough that no further damage results.


paul

Re: idea for a universal disk interface

[Guy Sotomayor via cctalk]

The problem is that you don't get the cylinder and head information in 
the same command (they are 2 different commands). So when you're doing a 
seek, you don't know which track(s) to prioritize.  That is why during a 
seek command I will transfer the entire cylinder so when the head 
command arrives, it can be handled quickly.  That's the only way I could 
think of to ensure maximum compatibility with the controllers (e.g. I 
can provide identical timings to an actual drive...you never really know 
what assumptions a particular controller might have).


TTFN - Guy

On 4/18/22 10:26, shad via cctalk wrote:

Guy,
I agree on keeping Linux out of the loop, to allow fast access on head 
location, selection.
However, I'm not convinced on the fact that a whole cylinder must be on 
blockram to achieve this. Given that ram access is fast (on Zynq with PL 
working at 200MHz and HP port at 64bits I'm running at around 1200MB/s peak), 
logic can jump across the whole disk without the software intervention, it's 
just a matter of being able to calculate conversion from CHS to address and 
read with sufficient buffer.
Probably using Xilinx IP cores could be a severe limit, as these are really 
full of bugs and inefficient implementations... but are free, so you can't 
argue.

On software side, given that you can go also slow, there's no need for very 
complex driver development, just an user level UIO driver could make do.
About language, I know very well VHDL, and it's a little bit at higher level 
than Verilog, so development with implementation parameters is maybe a little 
easier.

About interfaces which doesn't have separated clock recovery: these need a sort 
of oversampling, but you don't need to store every sample, just the ones with 
state change. Leveraging on IOSERDES you can work at a multiple of internal 
clock.

Please keep in consideration that the idea is to develop a single device that 
can work both as drive and as interface, so implementation should be reversible.
Probably this is not very difficult to obtain, as fast data paths for read and 
write are already in opposite directions.

Andrea


I have proceeded as far as full block diagrams (still have to write all
of the verilog) and basic SW architecture.? This is why I've had this
discussion.? I've thought about this *a lot* and have gone through
several iterations of what will or will not work given timing constraints.

I have all of the components for putting a prototype together but I just
haven't had the time yet to write the verilog, the Linux device driver
and the "personality board".? That is, there is still a lot to do.? ;-)

Some requirements that I've put on my design:

   * straight forward SW architecture
   * SW is *not* time critical (that is I didn't want SW in the critical
     path of keeping the data stream)
   * Must be able to emulate any SMD/ESDI drive
   * Must be able to match performance of the drive (or better)
   * Must be able to work with any controller (ESDI or SMD...depending
     upon interface)

With those in mind, that's how I came up with my design.

I found that the Zynq has sufficient Block RAM to contain a full
cylinder of 512KB.? I'm keeping a full cylinder because that allows
everything to be done in verilog except for seeks (see SW not being
required to be in the critical path).? If I didn't do that, then SW
would have to be involved in some aspects of head switch, etc and those
can have tight (<< 100us) latencies and I just didn't want to try and
get Linux to handle that.? Yes, I could use some form of RTOS (I'm
actually in the middle of writing one...but that's still a ways away)
but I don't see any that are really up to what I need/want to do for
this project.

BTW, I'm basing my initial implementation on the Zynq 7020 which has 1GB
of DRAM.? However, I'm also planning on a "bigger/better" one based upon
the Zynq Ultrascale+ which has 4GB of DRAM so that I can support
multiple/larger drives.

The amount required by Linux doesn't have to be large...I plan on having
the KMD just allocate a really big buffer (e.g. sufficient for
containing the entire drive image).? Linux will run happily in
128MB-256MB since there won't be any GUI.? It could be significantly
less if I were to strip out everything that isn't needed by the kernel
and only have a basic shell for booting/debug.? My plan is to have the
emulated drive data and the configuration file on the SD card...so
there's no real user interaction necessary (and Linux would not be on
the SD card but on the embedded flash on the Zynq module).


I chose ESDI and SMD fundamentally because the interface is 100% digital
(e.g. the data/clock separator is in the drive itself). So I don't need
to do any oversampling.


--
TTFN - Guy

Re: Oracle Releases Solaris 11.4 "CBE" Free For Open-Source Developers / Non-Production Use

[Chris Zach via cctalk]

Wonder if there is a SPARC build. Guess it's too much to ask if it will 
run on my Sun 386i's


C


On 4/19/2022 11:12 AM, Mike Katz via cctalk wrote:
I don't know if this has been posted already or not so I thought I would 
show it here.


https://www.phoronix.com/scan.php?page=news_item&px=Oracle-Solaris-11.4-CBE

Oracle Releases Solaris 11.4 "CBE" Free For Open-Source Developers / Non-Production Use

[Mike Katz via cctalk]

I don't know if this has been posted already or not so I thought I would 
show it here.


https://www.phoronix.com/scan.php?page=news_item&px=Oracle-Solaris-11.4-CBE

Looking for Dennis Charles Komisky

[IBM System/3 via cctalk]

Hi ,

I am trying to contact Dennis Charles Komisky.

Cen anyone help me with his email address ?

Thanks !

Henk

Re: idea for a universal disk interface

[Paul Koning via cctalk]

> On Apr 18, 2022, at 6:44 PM, Mike Katz via cctalk  
> wrote:
> 
> Which is more generic.
> 
> ESDI, SMD or SCSI.
> 
> In my opinion, SCSI is as close are you are going to get to a universal 
> interface.
> 
> As for reading raw data from a drive.  The newer the drive, the higher the 
> bit density and lower the strength of the magnetic fields and hence the lower 
> the flying height.  You have to deal with linear (or horizontal) recording, 
> perpendicular recording, Heat assisted magnetic recording, microwave assisted 
> magnetic recording.  The latest technologies are approaching 1TB (yes that's 
> TB) per square inch.
> 
> If you spin the platters too slowly you will not be able to distinguish 
> individual magnetic fluctuations from noise.  What do you propose as your 
> maximum data density (in BPI) and what is the minimum speed you will need to 
> accurately decode it.

I know about some of the modern drive magic, but I wasn't talking about those 
at all.  My comments about recovering raw signals from disk surfaces is for 
much earlier disks, especially removable packs.  In more recent disks you 
always have the drive if you have the disk since they are the same thing.  (I'm 
ignoring "data recovery" services here that deal with mechanically failed 
drives; that's a specialized business and as you said it's increasingly 
difficult with modern drives.)  

If you consider 1960s through 1980s you're likely to run into disk packs for 
which the drives may be hard to find.  The mechanical tolerances of those 
devices require care but are not crazy difficult, as my RC11/RS64 example last 
week was meant to illustrate.  The bit densities are not all that high, nor the 
track densities.  Consider for example that the track positions on a 1311 drive 
are set by mechanical detents, and are low enough that no servo system is used 
at all.

My mechanical skills and tools are perhaps a bit better than some of the 
readers here, undoubtedly worse than others.  I could sketch a "spin table" 
that could handle, say, an RK05 pack.  Without a milling machine I can't build 
it, but that could be fixed, and I could refine my skills to make it work.  Do 
I plan to?  No, but if an interesting enough pack showed up I could imagine 
doing it.  The RA60 pack I have would be a bit more of a stretch -- more 
platters and higher densities, not to mention lack of documentation -- but it's 
still on the edge of possibilities.

So I think there are two different possible projects here.  One involves a 
generic controller/emulator for common disk to controller interfaces, like ESDI 
or SMD.  (Or SCSI but those are off the shelf items, right?)  I'd imagine there 
would be plenty of takers for that, just as there are for the MFM and floppy 
emulators.  The other, more difficult and less needed, is the pack reader that 
I was discussing.  There is a little overlap between the two but not much.

paul

Re: Felt pads for RX50

[Paul Berger via cctalk]

On 2022-04-18 21:49, Chris Zach via cctalk wrote:
Anyone know of a source for the felt pads that go on the non-head side 
of an RX50? Missing at least one here.


C


I successfully made replacements from self-adhesive felt punched out 
using a leather punch like you would use to punch holes in a belt.


Paul.

Re: IMSAI SIO2 cable part number

[ED SHARPE via cctalk]

probably others  out  there   that  can use  some of these cables  too... sad  
but  true  I  wish  I had   bought up all the loose IMSAI  parts  Micro-age 
redistribution  had  way back  then in  the  early 1980s    they had  parts  
and pieces  of leftovers and  half disassembled  IMSAI atuff stuff their techs  
screwed up! Ed#  In a message dated 4/18/2022 10:45:44 PM US Mountain Standard 
Time, cct...@classiccmp.org writes: 
Bill, Let me know right quick if you'll be at VCF East and I'll make you a 
pair, I have both kinds of IDC ends. I'm heading out first thing tomorrow 
morning though as I have work in the northeast before VCF East. Thanks,Jonathan 
   --- Original Message ---On Monday, April 18th, 2022 at 15:03, Bill 
Degnan via cctech  wrote:  >>> Hi all...> What is the 
cable partnumber for the IMSAI SIO2? I need to order a> set of cables. I 
thought in all of my boxes and boxes of cables I> might have one...but nope.>> 
Here is a picture:>> https://deramp.com/downloads/mfe_archive/010-S100 
Computers and Boards/00-Imsai/10-Imsai S100 Boards/Imsai SIO-2 dual serial 
IO/SIO with cables.JPG>> Thanks in advance.>> BIll

Re: Felt pads for RX50

[Joshua Rice via cctalk]

Never had to replace them, but from what i remember, from cleaning out 
an RX50 last year... they're thinner than cassette tape felt pads.



I imagine sticky back craft felt would be an adequate replacement. 
Cutting it/stamping it out might be the tricky part.



https://www.bakerross.co.uk/self-adhesive-felt-sheets-classpack - Craft 
felt


https://www.amazon.co.uk/Cutters-Stainless-Indentation-Ceramics-Dotting/dp/B07VDNY82V/ref=asc_df_B07VDNY82V/ 
- Clay cutters, might work, might not. Might be better off with a 
stanley knife and some steady hands


I'm really only hypothesising here... But if i was in your shoes, that's 
what i'd try.



Cheers,


Josh Rice


-- Original Message --
From: "Chris Zach via cctech" 
To: "CCTalk mailing list" 
Sent: Tuesday, 19 Apr, 2022 At 01:49
Subject: Felt pads for RX50
Anyone know of a source for the felt pads that go on the non-head side 
of an RX50? Missing at least one here.

C