Re: Winchester SA1004 file recovering

[Chuck Guzis via cctalk]

The simplest thing, if you can locate one, is to find a WD1000/WD1001
controller board and hook it to a PC.   Chances are overwhelming that it
was used to write the SA100x in the first place.

My first 5150 hard drive used such a setup--an SA1002, a WD1001 and a
very small hand-wired ISA card for interface.  I think I still have the
interface card somewhere.

--Chuck

Re: Greaseweazle

[Chuck Guzis via cctalk]

On 2/3/21 5:59 PM, Fred Cisin via cctalk wrote:

> He humbly acknowledged things that he didn't know, actively solicited
> comments and suggestions, and compiled a really nice collection of some
> of the weird formats.  (including a link to Chuck's F85 page)

I didn't ever send him an F85 diskette, just a sampling file from a
Catweasel.   One thing about those 5.25" 100 tpi diskettes is that data
is clocked at about 350 KHz, as opposed to 250 KHz for a standard drive.

The upshot is that even you find a 100 tpi drive, the drive electronics
probably will require a bit of "tweaking" to give a bit more headroom in
the bandpass.  When I tried a stock MPI 52 100 tpi model, I had to
modify it slightly to get it to work reliably; same for a Tandon
TM-100-4M.  I think Micropolis drives worked without modification, but
the ones I have are single-sided and so haven't been used in some time.

One of the things that I meant to get around to doing, but never did,
was to take one of my Drivetech 5.25" drives and add my own PCB to do
the micropositioning.  (Those drives have two positioning steppers on a
sort of lever arrangement--one for coarse and the other for fine).
Nominally, the drives are 192 tpi and use an embedded servo for the
high-capacity capability (which is why the drive couldn't format its own
high-capacity floppies).

--Chuck

Re: Winchester SA1004 file recovering

[David Gesswein via cctalk]

On Wed, Feb 03, 2021 at 10:43:48AM +0100, Enrico email.it wrote:
> 
> 
> A very dear friend first read in raw mode a 10MB Winchester hard disk model
> Shugard SA1004 from which the files were correctly extracted and then set up
> a test bench from which you can see in this video the complete system
> operating with the HD ed il controller Shugart SASI SA1403:
> https://www.dropbox.com/s/d9iacfgrnexso3o/GP%20T20%20con%20HD%20banco%20prov
> a.mp4?dl=0
> 
> Despite we having attempted different readings (even using cards from the
> first hard disk), using the same FLUXengine card
> (http://cowlark.com/fluxengine/doc/building.html) the raw file still does
> not present the Hard Disk directory, instead  we read the information of the
> files present but there may be bad bytes in these files and in the rest of
> the disk as well. 
> 

I have only heard of FLUXengine being used for floppies. Can it handle
hard drives? I hadn't heard of other boards that can read MFM hard drives
other than mine http://www.pdp8online.com/mfm/.

Other than the drive being faulty the biggest reason reading fails is
the heads are no longer on track. You can tell that by looking at a histogram
of the flux transition timing for a track. If they show peaks with
good nulls between them the data is likely recoverable. If they don't
you have to do something to shift the head position.
Example histogram from by unit for ST506 type drive.
https://groups.google.com/g/mfm-discuss/c/kjKez8vfapU/m/4XamyQJgCAAJ
The SA1004 is a stepper drive. Some people have had success on other stepper
drives with putting some rotation force or drag on the stepper to shift the 
heads. Creating a microstepper driver would give better control.

May be able to say more if you provide more information on what you have 
done and checked to try to recover the contents.

Re: HP Journal back issues

[J. David Bryan via cctalk]

On Wednesday, February 3, 2021 at 9:25, ED SHARPE via cctech wrote:

> Indeed this site is great for reference but alas are too lo-res for good
> museum display images.

They appear to be scanned at 150 dpi.

The ones here are scanned at 300 dpi:

  http://hparchive.com/hp_journals


  -- Dave

Re: Flip-Chip selloff (Al Kossow)

[Chris Zach via cctalk]

I remember how annoying it was when Ebay required all payments through 
paypal. I preferred checks and getting all the money.


With Ebay's cut plus I am sure the new payment cut will be above 
Paypal's it becomes less and less interesting to sell things there. But 
that's what happens when you have 100% of the market.


Why don't we just use bitcoin?

CZ

On 2/3/2021 5:01 PM, Al Kossow via cctech wrote:

On 2/3/21 1:57 PM, Al Kossow via cctech wrote:

On 2/3/21 1:29 PM, Michael Thompson via cctech wrote:


The RICM would happily accept any donated FlipChips


Almost everything sold yesterday.



and I won't go into how disgusted I am with eBay's new seller payment 
system

they forced everyone into on the first of the month.

What used to appear in my Paypal account instantly when a buyer paid
will now take a minimum of several days to appear in my bank account
and eBay takes their cut up front, rather than once a month.

Re: Flip-Chip selloff (Al Kossow)

[Al Kossow via cctalk]

On 2/3/21 1:57 PM, Al Kossow via cctech wrote:

On 2/3/21 1:29 PM, Michael Thompson via cctech wrote:


The RICM would happily accept any donated FlipChips


Almost everything sold yesterday.



and I won't go into how disgusted I am with eBay's new seller payment system
they forced everyone into on the first of the month.

What used to appear in my Paypal account instantly when a buyer paid
will now take a minimum of several days to appear in my bank account
and eBay takes their cut up front, rather than once a month.

Re: Flip-Chip selloff (Al Kossow)

[Al Kossow via cctalk]

On 2/3/21 1:29 PM, Michael Thompson via cctech wrote:


The RICM would happily accept any donated FlipChips


Almost everything sold yesterday.

Re: Flip-Chip selloff (Al Kossow)

[Michael Thompson via cctalk]

>
>
> Date: Tue, 2 Feb 2021 09:19:08 -0800
> From: Al Kossow 
> Subject: Flip-Chip selloff
>
> I don't have any equipment that uses them any more, so I'll be ebaying off
> my
> A-W series flip chips over the next few days. The W's and PT08 boards are
> up now
>
> https://www.ebay.com/itm/184647476832
> https://www.ebay.com/itm/184647420812
>

I am still maintaining a PDP-8/I & TC01, PDP-8/L, PDP-8/S, PDP-9 & TC02,
and PDP-12 for the Rhode Island Computer Museum.

The RICM would happily accept any donated FlipChips, especially the go-fast
B versions and anything else for the PDP-9. You can even get a charitable
tax deduction for the donation.

-- 
Michael Thompson

Re: PDP-11/70 debugging advice

[Josh Dersch via cctalk]

On Tue, Feb 2, 2021 at 12:30 AM Josh Dersch  wrote:

>
>
> On Sun, Jan 31, 2021 at 10:03 PM Fritz Mueller  wrote:
>
>>
>>
>> > On Jan 31, 2021, at 8:19 PM, Josh Dersch  wrote:
>> > Well, what's interesting here is that on my system, switch S4 (MAINT
>> STPR) steps the processor with switches S1 and S2 set to *any*
>> configuration.
>>
>> Hmm, would expect to see S2:1 S1:0 step by microinstruction, and S2:1
>> S1:1 step by clock phase.  The other two settings should free run the
>> microcode.  So yeah, sounds like something fishy there...  The TIG card has
>> more than a few analog components, and its not too unusual for these to get
>> hung up on the adjacent card and have a leg pulled or sheared from the
>> board.
>>
>> > Ah, and page II-6-20 (p. 178) indicates that when DCLO is asserted, it
>> asserts: "UBCE ROM INIT H - forces the ROM to ZAP.00 (200), and stops and
>> clears the Timing Generator and the Cache timing."
>>
>> Yup, that's one of the signals coming in to RAC E106.  Probing there
>> should indicate which of possible sources for ZAP is actually occurring
>> (UBCE ROM INIT H on pins 2 and 3 there).
>>
>> DCLO is a classic...  Make sure to 'scope it, because it sometimes has
>> troublesome spikes that don't show on a multimeter.  If you have H742s,
>> there are some wet tantalums on the control board that sometimes leak and
>> cause trouble with this.
>>
>> I'm sure you are raring to go -- hope those fans show up for you
>> tomorrow, and will be interested to hear what you find!
>>
>
>
> Small update; fans arrived today and they are now installed.  Voltages
> tested on the backplane at the points called out in the service docs, and
> all voltages dialed in to 5.05V.  Ripple is within tolerances -- about
> 200mV with some very short spikes that barely show up on my 'scope that go
> to 300mV or so.  Not sure if this is abnormal, I also saw these while
> burning the supplies in on the bench.
>
> Checked the AC LO and DC LO signals at all the points called out in figure
> 6-12 (p. II-6-22 of
> http://bitsavers.org/pdf/dec/pdp11/1170/EK-KB11C-TM-001_1170procMan.pdf)
> and appear to be correct.  Looked at most of them under the scope and no
> spikes (other than those in the ripple from the power supply.)
>
> Tomorrow I'll get some boards out on extenders and take a look at what's
> going on at the logic level.
>

Another quick update:  Had some time last night to poke at things.  I
started with the TIG, since I wanted to see if the crystal clock was
running at all and if the right clock source was being selected.  Sure
enough, TIGB XTAL H was a flat line.  Nothing happening at the crystal
itself either.  The crystal's casing was fairly corroded (which is
interesting, since nothing else on the board is) and after a tiny bit of
prodding one of the legs fell off, so I'm hoping that's the culprit.  New
crystal ordered and when it arrives we'll see...

- Josh

Re: Greaseweazle

[Fred Cisin via cctalk]

You're absolutely correct, however the only thing Al contributes (for 
the purposes of this particular discussion) are complaints about how 
other people are doing it wrong.


On Wed, 3 Feb 2021, Chris Hanson via cctalk wrote:
I think Al has contributed enormously to the archival and preservation 
of our industry history, which is exactly why I pretty much always want 
to hear more from him on anything related—and why my ears perk up when 
he says there's a better way to do something.


I agree.
Al, Chuck, ARD, (and many others). may not have the time, nor inclination, 
to do a full handholding tutorial or troubleshoot somebody else's problems.

They have provided a wealth of information.  I always learn something.
Within any gripes they make are gems of indentification of problems 
and things that may need to be addressed.
Such as the specific suggestions to try to check read validity as soon and 
quickly as possible to avoid unnecessary read attempts that further damage 
deteriorating disks.



My gripes about the Greaseweazle documentation should be construed as 
"suggestions for improvement"  :-)

I thought that the Fluxengine documentation was a really quite good start.
He humbly acknowledged things that he didn't know, actively solicited 
comments and suggestions, and compiled a really nice collection of some of 
the weird formats.  (including a link to Chuck's F85 page)

Re: Greaseweazle

[Fred Cisin via cctalk]

On Wed, 3 Feb 2021, Fred Cisin via cctalk wrote:
. . . 

Then try cylinder 36.
If the disk had been written on a 48tpi 35 track drive (SA400/SA390 used on 
TRS80 and Apple), then cylinder 72 of a 96tpi/cylinder 36 of 48tpi would not 
have been used.  If cylinder 72 does not read, but 36 gives a valid read that 
identifies itself as track 18, then it is most likely from a 35 track 48tpi 
drive, such as SA400.


That second attempt should have read cylinder 54/27, not 36/18
Again, to try to do most of the analysis on the less likely to be in use 
tracks.


THIRD attempt should be 36/18


Then, if you are feeling bold, cylinder 0
Cylinder 0 may be a different format than other parts of the disk, such 
as the continuation of FM for system tracks of CP/M even after the rest 
of the disk went to MFM.


Watch for what looks like it might be a DIRectory in the low tracks, OR 
for some formats the MIDDLE tracks (17,20, etc) for variants of TRSDOS, 
Microsoft Stand-Alone BASIC, etc.

Re: Greaseweazle

[Fred Cisin via cctalk]

ideally, you'd use a 96tpi drive on 48tpi and microstep the head 
positioner. you still have the problem of head clog.


Some "stupid ideas":
In line with trying to minimize possible damage during analysis of the 
format, try:

   Use a 96tpi drive.

   Try to read cylinder 72.  MOST OS's are aware of the lower reliability 
of inner tracks, and will try to write the data to the outer (lower 
numbered tracks)  Therefore, if the oxide comes off on your head, then it 
is less likely to be what you needed.


   See if you got a valid read.  USUALLY (not always), that cylinder will 
have the same number of bytes per sector, sectors per track, and heads per 
cylinder as the other tracks.


   If the track read identifies itself as track 36 (look at the CHRN 
fields if there is an IBM/WD style sector header) then it was presumably 
written on a 48tpi drive.
If it identifies itself as track 75, then it was probably written on a 
100tpi drive.  Switch to a 100tpi drive (MicropolisII, Tandon TM400-4M, 
etc.)


Then try cylinder 36.
If the disk had been written on a 48tpi 35 track drive (SA400/SA390 
used on TRS80 and Apple), then cylinder 72 of a 96tpi/cylinder 36 of 48tpi 
would not have been used.  If cylinder 72 does not read, but 36 gives a 
valid read that identifies itself as track 18, then it is most likely 
from a 35 track 48tpi drive, such as SA400.


Watch out for re-used disks.  If a formatted 5150 disk was reformatted by 
a single-sided machine, then you will have the single sided format on 
side A, and PC format on side B!
Similarly, a used 40/80 track disk reformatted by a 35 track machine will 
have different formats from the residual formatting on the high tracks.


Every even numbered cylinder of a 96tpi drive corresponds to a cylinder of 
a 48tpi drive.
Every multiple of 24 cylinders of a 96 tpi drive corresponds with a 
multiple of 25 cylinders of a 100tpi drive.
If you succeed in reading the track identification (CHRN in sector header 
in IBM/WD formats), then you have a clue of the tpi of the source drive.



If you managed a successful track read, then knowing the tpi, number 
of heads, bytes per sector, sectors per track, will let you avoid some of 
the otherwise unsuccessful read attempts (such as unnecessary revolutions 
of the media trying to read between tracks on 48tpi)




Is it worth the effort to modify the drive?
Reading both heads at the same time would halve the number of revolutions 
needed of deteriorating media.



I had some 8" diskettes for which I could get a successful read IFF I 
pushed gently on the side of the head with my finger.  I always intended 
to try to add a micrometer lead screw to the head positioning, but never 
got around to it.  Presumably, if the amount of offset from "correct" 
position is determined, it would probably be the same for most/all disks 
written with the same source drive.


Howzbout analog positioning?  Amlyn claimed to use "analog positioning 
with phase locked loop feedback" to find the tracks.  Did they?



If you have some semi-skilled assistants (interns, grad students, etc.) 
then some of the catch up of the backlog could be handed off to them for

  disks that aren't as likely to be damaged by a read attempt
  disks with a known/presumed/likely format
If you have a group of workstations (and a swivel chair), you could then 
step-in only when the assistant(s) encounters a problem.

Re: Greaseweazle

[Al Kossow via cctalk]

a much larger and more expensive solution.


Does it matter?
Do you buy Chinese junk tools as well?

It isn't like you're going to buy 100 or even 10 of the things.

If you are just starting out at this, and didn't collect a stash of
old floppy drives you're going to spend a lot more on the drives and
power supply than the imaging board. The same goes for an ISA PC and
floppy controller that supports FM if you want to use Imagedisk.

We're moving out the end of the long tail where even 3.5"
floppies were free for the taking. Ewaste laws haven't helped
the situation any.

Re: Greaseweazle

[Paul Koning via cctalk]

> On Feb 3, 2021, at 5:37 PM, Peter Corlett via cctalk  
> wrote:
> 
> On Wed, Feb 03, 2021 at 01:09:50AM -0800, jim stephens via cctalk wrote:
>> On 2/2/2021 11:51 PM, Peter Corlett via cctalk wrote:
>>> The Raspberry Pi Pico has a similar price to the Blue Pill and seems a
>>> much better machine for this task, although I haven't combed through its
>>> reference manual yet.
>> For capture and writing (if that's part of the design) I heard there's a
>> dedicated coprocessor for the GPIO pins. It might be useful for offloading
>> some of the proccessing from some external circuitry to do the capture or
>> output.
> 
> I have now pulled the reference manual to look at the GPIO stuff, and it is
> indeed very shiny. There's only space for 32 coprocessor instructions per
> GPIO bank, but that's possibly all you need: it is apparently possible to
> implement a full UART with handshaking in that.
> 
> Controlling a floppy is broadly the same level of complexity as a UART, so
> it seems that the Pico would be he perfect tool for the job. Now if only I
> could actually lay my hands on one...

Yes, I noticed the usual suspects are out of stock.  Need to look further.

My reaction was similar.  I like the dual CPUs, that means one could do hard 
real time stuff like wiggling I/O lines (for example DDCMP at a megabit per 
second) while the other does buffer management and talks USB protocol.  I 
didn't even realize there's a small I/O coprocessor, that's neat.  The TI 
engine in the BeagleBone Black has that sort of thing (a much larger one) which 
seems very useful if the job is particularly hard.  David Gesswein made great 
use of that for hard drive emulation.  But that's a much larger and more 
expensive solution.

paul

Re: R: Winchester SA1004 file recovering

[jim stephens via cctalk]

He offers everything from the $15 bare board up.  Next step up is doing 
the surface mount chips for you at $3.50, etc.


I'd do the bare board.  I can attest that the mfm emulator will work.  
I've not one the SA-1000 might have to work with him to do it 
yourself.   I recall he offered a kit option on that, and I had him 
build it up.

thanks
Jim

On 2/3/2021 5:36 AM, Enrico email.it via cctalk wrote:

It's a bit very expensive to shipping a SA-1000 from U.S. to Italy
almost over than 200 USD



-Messaggio originale-
Da: cctech [mailto:cctech-boun...@classiccmp.org] Per conto di jim stephens
via cctech
Inviato: mercoledì 3 febbraio 2021 12:18
A: Enrico email.it via cctalk
Oggetto: Re: Winchester SA1004 file recovering



On 2/3/2021 1:43 AM, Enrico email.it via cctalk wrote:

Any suggestion?

I believe Dave G's MFM emulator has an option to support the SA1000.

I have one in stock for a future project to try to extract data from
SA-1000's in DSD floppy / 8" drive subsystems.

https://www.pdp8.net/mfm/mfm.shtml

info is there about the SA-1000.

If you are having problems because the drives are dead, this won't
help.  It will inhale the contents and with
luck you can extract data.

I know with the ST-506 configuration of his hardware, you can then use
the emulator to replace the SA-1000.

If you need to recover the data, you may be out of luck, but if you need
a "working" SA-1000 and can format
it from utilities, then this may help.

thanks
Jim

Re: Flip-Chip selloff (Al Kossow)

[Steve Malikoff via cctalk]

Antonio said
> On 03/02/2021 22:22, John Foust via cctalk wrote:
>> At 04:01 PM 2/3/2021, you wrote:
>>> and I won't go into how disgusted I am with eBay's new seller payment system
>>> they forced everyone into on the first of the month.
>> A few months ago I sold on eBay some servers and NAS stuff for a client.
>> I thought it would be easy to see the detailed financial breakdown...
>> what it sold for, what came in, what was their cut, how much was shipping,
>> what went to PayPal, etc.  I couldn't find it for the life of me.
>>
>
> The paypal bit is easy: look at your paypal account! The ebay part is OK
> too:
>
>My Ebay->Summary. Account. Seller Account. All Account Activity.
>
> At least, in the UK, that works for me. Currently if I sell something
> the buyer pays with Paypal and I then send the stuff. It can still be
> reversed and I've not tried to empty my PayPal balance to see if it will
> let me ...
>
> Shipping you need to track yourself (although if you use ebay for that
> too then it might list it).

In the case of the items OP's thread is pertaining to, perhaps it's a bit of
a moot point for you in the UK and others on this international mailing list.
They are clearly listed there (but not mentioned here AFAIK) with
"Note, NO international shipping."

Re: Flip-Chip selloff (Al Kossow)

[Antonio Carlini via cctalk]

On 03/02/2021 22:22, John Foust via cctalk wrote:

At 04:01 PM 2/3/2021, you wrote:

and I won't go into how disgusted I am with eBay's new seller payment system
they forced everyone into on the first of the month.

A few months ago I sold on eBay some servers and NAS stuff for a client.
I thought it would be easy to see the detailed financial breakdown...
what it sold for, what came in, what was their cut, how much was shipping,
what went to PayPal, etc.  I couldn't find it for the life of me.



The paypal bit is easy: look at your paypal account! The ebay part is OK 
too:


  My Ebay->Summary. Account. Seller Account. All Account Activity.

At least, in the UK, that works for me. Currently if I sell something 
the buyer pays with Paypal and I then send the stuff. It can still be 
reversed and I've not tried to empty my PayPal balance to see if it will 
let me ...


Shipping you need to track yourself (although if you use ebay for that 
too then it might list it).



Antonio


--
Antonio Carlini
anto...@acarlini.com

Re: Greaseweazle

[Peter Corlett via cctalk]

On Wed, Feb 03, 2021 at 01:09:50AM -0800, jim stephens via cctalk wrote:
> On 2/2/2021 11:51 PM, Peter Corlett via cctalk wrote:
>> The Raspberry Pi Pico has a similar price to the Blue Pill and seems a
>> much better machine for this task, although I haven't combed through its
>> reference manual yet.
> For capture and writing (if that's part of the design) I heard there's a
> dedicated coprocessor for the GPIO pins. It might be useful for offloading
> some of the proccessing from some external circuitry to do the capture or
> output.

I have now pulled the reference manual to look at the GPIO stuff, and it is
indeed very shiny. There's only space for 32 coprocessor instructions per
GPIO bank, but that's possibly all you need: it is apparently possible to
implement a full UART with handshaking in that.

Controlling a floppy is broadly the same level of complexity as a UART, so
it seems that the Pico would be he perfect tool for the job. Now if only I
could actually lay my hands on one...

> I don't know what's included for the capabilities. And apparently since
> the chip is new, there's only assembler programming for it now.

It's a Cortex M0, so any compiler which can produce freestanding ARM code
can generate code for it. So that's gcc, clang, rustc, etc. I suspect I can
just use my existing embedded tooling after telling it to use a different
subarchitecture.

> There's a video comparing the Pico, ESP32, ESP32-S and Blue Pill. The latter
> was a bit low in resources compared to the others.

OTOH, I can actually buy a Blue Pill today from reasonably reputable local
suppliers such as Amazon or AZ-Delivery, and they only cost €15 for five
including delivery. The Pico will be a game-changer if/when there's actual
stock here on the Continent. Importing directly from the UK is no longer a
sensible proposition.

> I'll try to find it and post it if anyone's interested.

No rush, especially as I only suffer video as a last resort when information
is unavailable in any other form.

Re: Greaseweazle

[Warner Losh via cctalk]

On Wed, Feb 3, 2021 at 3:20 PM John Foust via cctalk 
wrote:

> At 03:37 PM 2/3/2021, Chuck Guzis via cctalk wrote:
> >"Reasonably quickly" is a relative term.   I've got samples here that I
> >had to cogitate over for a year.
> >Admittedly, these were items that were sui generis, but "quickly" was
> >not in the picture.
>
> Well, there's the balance between novice normal mode and expert mode.
>
> I heard people asking for a way to see the reults quickly so you could
> adjust the reading, abort if problems were spotted, or change tactics
> if weird data arose.  We want smart software for the novices and
> adjustable software for the experts.
>

My one big complaint about the kyroflux command line thing is that it
doesn't give a list of 'bad' tracks at the end so you have to scan the logs
to make sure the reading worked.  Of course, that's in 'sector mode' not in
flux capture mode... I wouldn't think to do the latter unless I could also
say "I expect this disk to be X format, please abort if that's not
plausibly true" and also to use that to inform retries maybe, but I haven't
thought through all the implications of the latter...

Warner

Warner

Re: Flip-Chip selloff (Al Kossow)

[John Foust via cctalk]

At 04:01 PM 2/3/2021, you wrote:
>and I won't go into how disgusted I am with eBay's new seller payment system
>they forced everyone into on the first of the month.

A few months ago I sold on eBay some servers and NAS stuff for a client.
I thought it would be easy to see the detailed financial breakdown...  
what it sold for, what came in, what was their cut, how much was shipping, 
what went to PayPal, etc.  I couldn't find it for the life of me.

- John

Re: Greaseweazle

[John Foust via cctalk]

At 03:37 PM 2/3/2021, Chuck Guzis via cctalk wrote:
>"Reasonably quickly" is a relative term.   I've got samples here that I
>had to cogitate over for a year.
>Admittedly, these were items that were sui generis, but "quickly" was
>not in the picture. 

Well, there's the balance between novice normal mode and expert mode.

I heard people asking for a way to see the reults quickly so you could 
adjust the reading, abort if problems were spotted, or change tactics
if weird data arose.  We want smart software for the novices and 
adjustable software for the experts.

- John

Re: APL\360

[Peter Corlett via cctalk]

On Tue, Feb 02, 2021 at 08:50:56PM -0700, ben via cctalk wrote:
> On 2/1/2021 6:07 AM, Peter Corlett via cctalk wrote:
[...]
>> You're describing a failing in C and similar languages stuck in the
>> 1960s. Here's a Rust method that does add-exposing-carry:

>> https://doc.rust-lang.org/nightly/std/primitive.u32.html#method.overflowing_add
> So why could this not have been done 30 earlier?

(I assume you mean "30 years earlier" here.)

Two reasons, one of which I was already aware of back then in 1991, and one
which is only obvious in hindsight.

The first is simple toxic masculinity. It's more manly to write stuff in
machine code (then) or C (now), apparently.

The second is a combination of Moore's Law and computer science. To handwave
wildly, Rust is what you get when you look at C++'s mistakes of the last
forty years and start again. If you've used a C++ compiler from the 1980s or
early 1990s, you'll have found the experience harrowing: computers were
still too slow and too small to do a good job, and various important
language design and code-generation techniques were not yet known and/or
were too impractical to implement. It all improved rapidly in the 1990s and
2000s, bringing us more or less to the top of the sigmoid curve.

u32::overflowing_add() returns a (u32, bool), i.e. a two-member struct.
Those early compilers cannot return structs directly, so the caller would
have to reserve space (on the stack, probably) and pass the address for the
function to fill in. That simple add-producing-carry has just become a
function with a half-dozen instructions, several of which are needed to
check the carry flag and convert it into a integer, plus many memory
accesses, just to provide a C wrapper around a simple add instruction. At
that point it does make sense to toss the compiler and write assembly
language.

Modern compilers do a lot of heavy inlining as a matter of course, will
split structs and perform dataflow analysis on individual elements, and
generally avoid memory access unless they absolutely have to.
u32::overflowing_add() should turn into a single add instruction and the
carry flag will probably be tested directly by a branch instruction and
never get converted to a boolean variable. It'll be as good as if not better
than hand-written assembler.

This is a particularly trivial function as well. Rust just wouldn't be
viable with 30 year old compiler technology.

>> The documentation doesn't explicitly say "carry" because Rust is
>> architecture-neutral and it's down to LLVM to decide how to express it in
>> machine code, but on x86 (and probably ARM) the boolean return value
>> comes directly from the carry flag.
> mincing words, sigh.

RISC-V doesn't have a carry flag. It handles overflow by e.g. using the BLT
instruction to branch if the result is smaller than the number being added
to. So documentation which assumes the world is x86 will not make sense here.

[...]
>> You "don't believe in objects" yet then describe a problem which only
>> exists due to the lack of them and then present OO pseudocode to solve
>> it. A lot of OO languages suck of course, but the fundamental idea of
>> encapsulation is not the bit that sucks.

> Are objects? they only way to solve this problem. I see a object as data
> structure tied to some code. What I would like to see data structures
> having fixed constants like array start and end of a structure for a array
> as variables when called into use.

There's no real difference between a "constant ... when called into use" and
a pure function which returns a value based on the structure elements.

>> Here's it in Rust, where it takes in an arbitrary
>> array (pedantically, "slice", a (pointer, element count)-tuple) and
>> determines its length at runtime:
>> 
>> pub fn clear_indexed(array: &mut [usize]) {
>>for index in 0 .. array.len() {
>>  array[index] = 0;
>>}
>> }

> I don't want Information hiding, I want to know what it does clearly. If I
> can't figure it out how can a computer program do it. Where does ".len()"
> find the size?

That is an implementation detail which you don't need to know to be able to
write Rust code. However, the len() method actually just returns the element
count from the (pointer, element count)-tuple. The function is so trivial
that it is guaranteed to be inlined so it's exactly the same as if you had
accessed the field directly.

Before you ask, no, you can't access the field directly for all of the
excellent reasons explained by every "introduction to OOP" tutorial which I
don't need to repeat.

[...]
>> pub fn clear_iterator(array: &mut [usize]) {
>>for elem in array {
>>  *elem = 0;
>>}
>> }

>> Both code fragments generate equivalent assembly in this trivial example
>> because the Rust compiler could prove at compile time that the index
>> variable can't go out-of-bounds. In more complex real-world code it
>> cannot reliably do so and will insert a run-time check which aborts if
>> the index is out-o

Re: Greaseweazle

[Chuck Guzis via cctalk]

On 2/3/21 1:00 PM, John Foust via cctalk wrote:
> 
> What I'm hearing is that these microcontroller standalone devices
> don't give any feedback on the reading process.  Couldn't they be more
> tightly coupled to a PC so the raw data could be displayed immediately
> and analyzed reasonably quickly?  Certainly they could send all
> the samples over USB quite quickly?

"Reasonably quickly" is a relative term.   I've got samples here that I
had to cogitate over for a year.

Admittedly, these were items that were sui generis, but "quickly" was
not in the picture.   Perhaps with some choice pharmaceuticals, my
thinking speed could be improved, but I haven't explored that yet.

You know--you get a disk that's thought to contain some information, the
identity of the originating system is unknown; no Rosetta stones to be seen.

For my purposes, clearly defined spectral peaks are the critical
thing--and that's done on my MCU implementation.

--Chuck

Re: Greaseweazle

[Al Kossow via cctalk]

On 2/3/21 12:31 PM, Chris Hanson wrote:

tools from project hosting sites like SourceForge, Bitbucket, GitLab, and 
Github a close second.



Some people tried to get a technical Greaseweasel discussion going on their 
github, and it is slowly
being adopted after a whole lot of nothing initially.

https://github.com/keirf/Greaseweazle/discussions

VAXstation 3100

[Richard Loken via cctalk]

Adam, I have a VAXstation sitting about three metres from me.  As is
usually the case, "it worked when I turned it off 20 years ago" I don't
remember how many years ago I turned it off.  I think it is a model 30
but casually looking at the box does not show me what model it is.  I
pulled out the nicad battery pack many years ago and it is sitting by
my left hand and it does not leak.

I have the system box, the expansion box with its little SCSI disk drive,
the RRD40 and its wierd disc caddies, and the VR--- monochrome monitor,
and probably the keyboard and mouse and documentation if I look around
for half an hour.

I have no idea where you are but I can send it to you for the price of
shipping which would be astronomical I expect.  I hesitate to ship the
monitor - that would be had work - but the other components can be managed.
--
  Richard Loken VE6BSV: "...underneath those tuques we wear,
  Athabasca, Alberta Canada   : our heads are naked!"
  ** rllo...@telus.net ** :- Arthur Black

Re: Greaseweazle

[John Foust via cctalk]

What I'm hearing is that these microcontroller standalone devices
don't give any feedback on the reading process.  Couldn't they be more
tightly coupled to a PC so the raw data could be displayed immediately
and analyzed reasonably quickly?  Certainly they could send all
the samples over USB quite quickly?

- John

Re: cctalk Digest, Vol 77, Issue 3

[emanuel stiebler via cctalk]

On 2021-02-03 15:29, Adam Thornton via cctalk wrote:
> As long as we’re talking about divesting: if anyone has a VaxStation that 
> they’d sell me for substantially less than eBay prices, I’d be interested.  I 
> have a 3100M38, but it doesn’t POST; indeed, a replacement mainboard would be 
> a place I could start.  (I did try burning new ROMs and replacing them, but 
> that wasn’t the problem).  I’d even consider swapping an 11/730 in unknown 
> condition (this is from the Kaur collection) for a working VaxStation, on two 
> conditions: you have to pick it up, and you have to take an RM80 drive with 
> it and dump it far enough away from my house that no one thinks it was me 
> what done it.

Where are you?

Re: Greaseweazle

[Chris Hanson via cctalk]

On Feb 2, 2021, at 7:58 AM, geneb via cctalk  wrote:
> 
> You're absolutely correct, however the only thing Al contributes (for the 
> purposes of this particular discussion) are complaints about how other people 
> are doing it wrong.

I think Al has contributed enormously to the archival and preservation of our 
industry history, which is exactly why I pretty much always want to hear more 
from him on anything related—and why my ears perk up when he says there's a 
better way to do something.

Also, I'm 100% with Al about not siloing projects _on social media sites like 
Facebook_. They're terrible for technical projects because they're specifically 
designed to surface "engaging" social information and push further engagement, 
rather than to actually preserve chronology, or to make it easy to refer back 
to or link to anything at all in the past. There is only forward, and only at 
the whim of The Algorithm.

Mailing lists are by far the best choice when it comes to collaboration on 
technical projects, with tools from project hosting sites like SourceForge, 
Bitbucket, GitLab, and Github a close second.

  -- Chris

Re: cctalk Digest, Vol 77, Issue 3

[Adam Thornton via cctalk]

As long as we’re talking about divesting: if anyone has a VaxStation that 
they’d sell me for substantially less than eBay prices, I’d be interested.  I 
have a 3100M38, but it doesn’t POST; indeed, a replacement mainboard would be a 
place I could start.  (I did try burning new ROMs and replacing them, but that 
wasn’t the problem).  I’d even consider swapping an 11/730 in unknown condition 
(this is from the Kaur collection) for a working VaxStation, on two conditions: 
you have to pick it up, and you have to take an RM80 drive with it and dump it 
far enough away from my house that no one thinks it was me what done it.

Adam

QIC 3M "Magnus 1.2" carts

[Chuck Guzis via cctalk]

I have received a few of the above-mentioned DC300-sized QIC carts for
recovery.   The usual stuff about tension bands applies, but I'm a bit
stymied.

The official specs for these tapes say that they're SLR 3.  I've tried
Tandberg SLR 3, 4 and 5 drives (any of which should be able to read
these) with no luck.  I've even tried an SLR2 QIC525, though why someone
would pay for more tape than they need is a mystery.

These would be ca. 1990 and most likely on a Mac, although the latter is
pure conjecture.

Before I unspool some of this tape and have a look with developer, am I
missing something?

--Chuck

Re: Greaseweazle

[Chuck Guzis via cctalk]

I'll add just a bit with respect to floppy disks on an MCU.

One reason to put histogram and peak-detection in the MCU firmware is
that for a disk you never know how far out of alignment the original
(recording) drive might be.  A drive used to record something out of
alignment can yield garbage on a blind capture.

A drive that allows for adjustment means that you can sample a track,
and adjust until you see nice clean peaks.   Blind-on-the-fly recovery
makes this a lot more difficult.  You can certainly add some primitive
decoding for FM, MFM, MMFM and a few varieties of GCR as a sanity check,
but looking at spectral peaks is a first-line diagnostic.

--Chuck

Re: Greaseweazle

[Al Kossow via cctalk]

On 2/3/21 10:34 AM, Paul Koning wrote:


Which might mean either (a) what I suggested is in practice not needed, or (b) 
existing software treats as unrecoverable disks that could be recovered with 
more sophisticated tools.  I have no idea which is correct.


More sophisticated tools aren't needed, until they are.

For the majority of people and applications none of this is necessary.

People have been using Imagedisk happily for a long time. Then you
have a one of a kind floppy eaten and you wish you hadn't used it.

And this happens in the middle of a batch of disks that had been reading
fine.

Re: Greaseweazle

[Paul Koning via cctalk]

> On Feb 3, 2021, at 1:27 PM, Al Kossow  wrote:
> 
> On 2/3/21 10:18 AM, Paul Koning wrote:
> 
>> Fair enough, but that means your real time processing needs to be sufficient 
>> to know where the tracks are.  And if the media are in bad shape, you may in 
>> fact want to capture each track N times at slight offsets from the nominal 
>> position, then do signal processing to recover the data as best you can.
> 
> That is in conflict with the requirement you spend as little time as you can 
> on shedding media
> ideally, you'd use a 96tpi drive on 48tpi and microstep the head positioner. 
> you still have the
> problem of head clog.
> 
> And, AFAIK, no existing software does any of this.

Which might mean either (a) what I suggested is in practice not needed, or (b) 
existing software treats as unrecoverable disks that could be recovered with 
more sophisticated tools.  I have no idea which is correct.

> 
>> Come to think of it, the techique of reading 1/2 inch tape with 36 track MR 
>> heads is somewhat similar: you get multiple readings of the same nominal 
>> data track and can use the additional data to help with recovery.
> 
> In practice, the channels smear together, that's why John Bordynuik went to 
> 36 tk 3490 heads from 18 tk 3480 heads on his 1/2" tape setups.
> 
> We saw this as well on the 6-track Whirlwind tapes using a 9-track head. 
> Fortunately 6 of the heads lined up cleanly.

Yes, I was thinking of that issue while looking into how a 10 track tape would 
look to, say, a 16 track instrumentation recorder head.  The picture looked 
marginal at best.

paul

Re: Greaseweazle

[Al Kossow via cctalk]

On 2/3/21 10:18 AM, Paul Koning wrote:


Fair enough, but that means your real time processing needs to be sufficient to 
know where the tracks are.  And if the media are in bad shape, you may in fact 
want to capture each track N times at slight offsets from the nominal position, 
then do signal processing to recover the data as best you can.



That is in conflict with the requirement you spend as little time as you can on 
shedding media
ideally, you'd use a 96tpi drive on 48tpi and microstep the head positioner. 
you still have the
problem of head clog.

And, AFAIK, no existing software does any of this.


Come to think of it, the techique of reading 1/2 inch tape with 36 track MR 
heads is somewhat similar: you get multiple readings of the same nominal data 
track and can use the additional data to help with recovery.


In practice, the channels smear together, that's why John Bordynuik went to 36 tk 
3490 heads from 18 tk 3480 heads on his 1/2" tape setups.

We saw this as well on the 6-track Whirlwind tapes using a 9-track head. 
Fortunately 6 of the heads lined up cleanly.

Re: Greaseweazle

[Al Kossow via cctalk]

On 2/3/21 10:17 AM, Mattis Lind wrote:

I have been looking into designing a 12 bit A/D with a differential amplifier in front which would sample at 6, 12 or 24 Mhz delivering the 
raw samples to the host over USB (FX2LP chips are good at pumping USB data). In this way I have all the info I can get and then applying 
various algorithms to the signal is the task of the host. If the host is quick it might even be able to do processing in 
real-time? (https://github.com/MattisLind/AnalogFluxReader ) Need to work on the layout now.


There is a prudaq cape for beaglebone that gives you two coherent a/d channels

Before i was locked out of my lab, I had my analog streaming usb setup from 
magtape hooked up to a floppy with a fluxengine to compare the
output of the read channel with the analog signal out of the preamp

There are a couple of pictures of it on my twitter feed, but twitter doesn't 
make it easy to find old tweets

Re: Greaseweazle

[Paul Koning via cctalk]

> On Feb 3, 2021, at 12:55 PM, Al Kossow via cctalk  
> wrote:
> 
> On 2/3/21 9:43 AM, Paul Koning via cctalk wrote:
> 
>> A nice benefit of capturing the raw waveforms and post-processing them is 
>> that you can do all sorts of very complex processing.  If the media are nice 
>> and clean then simple processing is sufficient.  If they are badly damaged, 
>> you may need more.  If you do the processing in real time you may not know 
>> what all is needed.  But if you do post-processing, you can add to the 
>> algorithms after data capture has been done, if what you have so far isn't 
>> yet good enough.
>> I can imagine techniques like digital filtering, adaptive filters, maximum 
>> likelihood decoders, etc.
>> In recovering data from tapes, with multiple tracks, people have often done 
>> this same sort of thing, full high bandwidth analog signal capture.  You 
>> don't even need to know at the time what the data format is.  If you think 
>> you know but you don't have it quite right, no matter,  you just change the 
>> software and run another pass through the captured waveforms.  No need to 
>> run the (possibly fragile) media through the machine again.
>>  paul
> 
> In the real world, this is fundamentally wrong.
> 
> You need to know you haven't captured garbage while the disk is still in the 
> drive
> and you want to minimize the time you spend dwelling on an individual track.

Fair enough, but that means your real time processing needs to be sufficient to 
know where the tracks are.  And if the media are in bad shape, you may in fact 
want to capture each track N times at slight offsets from the nominal position, 
then do signal processing to recover the data as best you can.

Come to think of it, the techique of reading 1/2 inch tape with 36 track MR 
heads is somewhat similar: you get multiple readings of the same nominal data 
track and can use the additional data to help with recovery.

> Magtape is a completely different issue where you attempt to get as much 
> information as you can
> before the tape sticks, tears off all of its oxide, or the head clogs.
> 
> Even if it doesn't stall, the motor can drag and goofs up the tape speed. 
> This is an issue
> for NRZI media.
> 
> We (CHM) have had amazing luck recovering 50+ year old 7, 9 and Whirlwind 
> tapes with analog
> recovery. See Len Shustek's talk at VCFW 2001 about the recovery software.

I will, thanks for the pointer.  I expect to need this in the not too distant 
future (for reading 1/2 inch 10 track tapes).

paul

Re: Greaseweazle

[Mattis Lind via cctalk]

Den ons 3 feb. 2021 kl 18:55 skrev Al Kossow via cctalk <
cctalk@classiccmp.org>:

> On 2/3/21 9:43 AM, Paul Koning via cctalk wrote:
>
> > A nice benefit of capturing the raw waveforms and post-processing them
> is that you can do all sorts of very complex processing.  If the media are
> nice and clean then simple processing is sufficient.  If they are badly
> damaged, you may need more.  If you do the processing in real time you may
> not know what all is needed.  But if you do post-processing, you can add to
> the algorithms after data capture has been done, if what you have so far
> isn't yet good enough.
> >
> > I can imagine techniques like digital filtering, adaptive filters,
> maximum likelihood decoders, etc.
> >
> > In recovering data from tapes, with multiple tracks, people have often
> done this same sort of thing, full high bandwidth analog signal capture.
> You don't even need to know at the time what the data format is.  If you
> think you know but you don't have it quite right, no matter,  you just
> change the software and run another pass through the captured waveforms.
> No need to run the (possibly fragile) media through the machine again.
> >
> >   paul
> >
>
> In the real world, this is fundamentally wrong.
>
> You need to know you haven't captured garbage while the disk is still in
> the drive
> and you want to minimize the time you spend dwelling on an individual
> track.
>
> Magtape is a completely different issue where you attempt to get as much
> information as you can
> before the tape sticks, tears off all of its oxide, or the head clogs.
>
> Even if it doesn't stall, the motor can drag and goofs up the tape speed.
> This is an issue
> for NRZI media.
>
> We (CHM) have had amazing luck recovering 50+ year old 7, 9 and Whirlwind
> tapes with analog
> recovery. See Len Shustek's talk at VCFW 2001 about the recovery software.
>
> There is some hardware work going on to recover double-sided floppies
> using A/D channels
> digitizing both sides of the disk simultainiously, and recovering 4-track
> pre-QIC cartridge
> tapes the same way.
>

I have been looking into designing a 12 bit A/D with a differential
amplifier in front which would sample at 6, 12 or 24 Mhz delivering the raw
samples to the host over USB (FX2LP chips are good at pumping USB data). In
this way I have all the info I can get and then applying various algorithms
to the signal is the task of the host. If the host is quick it might even
be able to do processing in real-time? (
https://github.com/MattisLind/AnalogFluxReader) Need to work on the layout
now.

Re: Greaseweazle

[Chuck Guzis via cctalk]

On 2/3/21 9:36 AM, Mattis Lind wrote:

> So you store a full track worth of data and then write it to the
> SD-card. Then move the flux-length data over to a PC and do post
> processing there, right?
> 
> Isn't there performance in the CPU to do the actual decoding as well?
> FM, MFM, GCR or whatever into data. Find marks, check CRC and all that
> stuff?

Sure, more than enough.  But the MCU has to be programmed to do these
things; when dealing with an unfamiliar or problematical sample, it's
easier to move the data to the Big Machine and play with things
there--and there's a "permanent record" of the sampling data.

Were I dealing with lots of known samples, I'd probably include the
deciphering routines.  But in the end, the recovered data has to go back
to the customer, so it's going to wind up on the Big Machine anyway.

I incorporate a function on the MCU that attempts to find the "peaks" in
the spectral information, just as a way to tell if I'm doing things
right.  Same for verifying the drive spindle RPM.

--Chuck

Re: Greaseweazle

[Al Kossow via cctalk]

On 2/3/21 9:55 AM, Al Kossow via cctalk wrote:


In the real world, this is fundamentally wrong.

You need to know you haven't captured garbage while the disk is still in the 
drive
and you want to minimize the time you spend dwelling on an individual track.


When you are recovering a batch of hundreds of disks, you want to know before 
you
start the next disk that either it completely read OK, or had problems. Out of 
the
thousands of disks I've read, I'd guess maybe 100 were problem children and of 
those
either they were copy protected, shed themselves, or weren't MFM or FM.

I have cartons of hard-sectored or funny format soft-sectored disks to do that 
are
of high historical value but were too time-consuming to do anything with while 
I've
been trying to work down the backlog.

Re: Greaseweazle

[Al Kossow via cctalk]

On 2/3/21 9:43 AM, Paul Koning via cctalk wrote:


A nice benefit of capturing the raw waveforms and post-processing them is that 
you can do all sorts of very complex processing.  If the media are nice and 
clean then simple processing is sufficient.  If they are badly damaged, you may 
need more.  If you do the processing in real time you may not know what all is 
needed.  But if you do post-processing, you can add to the algorithms after 
data capture has been done, if what you have so far isn't yet good enough.

I can imagine techniques like digital filtering, adaptive filters, maximum 
likelihood decoders, etc.

In recovering data from tapes, with multiple tracks, people have often done 
this same sort of thing, full high bandwidth analog signal capture.  You don't 
even need to know at the time what the data format is.  If you think you know 
but you don't have it quite right, no matter,  you just change the software and 
run another pass through the captured waveforms.  No need to run the (possibly 
fragile) media through the machine again.

paul



In the real world, this is fundamentally wrong.

You need to know you haven't captured garbage while the disk is still in the 
drive
and you want to minimize the time you spend dwelling on an individual track.

Magtape is a completely different issue where you attempt to get as much 
information as you can
before the tape sticks, tears off all of its oxide, or the head clogs.

Even if it doesn't stall, the motor can drag and goofs up the tape speed. This 
is an issue
for NRZI media.

We (CHM) have had amazing luck recovering 50+ year old 7, 9 and Whirlwind tapes 
with analog
recovery. See Len Shustek's talk at VCFW 2001 about the recovery software.

There is some hardware work going on to recover double-sided floppies using A/D 
channels
digitizing both sides of the disk simultainiously, and recovering 4-track 
pre-QIC cartridge
tapes the same way.

Re: Greaseweazle

[Paul Koning via cctalk]

> On Feb 3, 2021, at 12:36 PM, Mattis Lind via cctalk  
> wrote:
> 
>> ...
> 
> So you store a full track worth of data and then write it to the SD-card.
> Then move the flux-length data over to a PC and do post processing there,
> right?
> 
> Isn't there performance in the CPU to do the actual decoding as well? FM,
> MFM, GCR or whatever into data. Find marks, check CRC and all that stuff?

A nice benefit of capturing the raw waveforms and post-processing them is that 
you can do all sorts of very complex processing.  If the media are nice and 
clean then simple processing is sufficient.  If they are badly damaged, you may 
need more.  If you do the processing in real time you may not know what all is 
needed.  But if you do post-processing, you can add to the algorithms after 
data capture has been done, if what you have so far isn't yet good enough.

I can imagine techniques like digital filtering, adaptive filters, maximum 
likelihood decoders, etc.

In recovering data from tapes, with multiple tracks, people have often done 
this same sort of thing, full high bandwidth analog signal capture.  You don't 
even need to know at the time what the data format is.  If you think you know 
but you don't have it quite right, no matter,  you just change the software and 
run another pass through the captured waveforms.  No need to run the (possibly 
fragile) media through the machine again.

paul

Re: Greaseweazle

[Mattis Lind via cctalk]

Den ons 3 feb. 2021 kl 18:00 skrev Chuck Guzis via cctalk <
cctalk@classiccmp.org>:

> On 2/3/21 7:14 AM, dwight via cctalk wrote:
> > I'm curious as to how the sampling code looks. Do you use the timers?
> > Dwight
>
> Exactly.  You run the sample timer in "capture" mode using DMA.  There's
> a little trick in this when handling high-denisty fisks in thatthe DMA
> counter is limited to 65K "items" (bytes, words, doublewords), so
> there's a small amount of trickery to get more than 64K samples (grab
> the DMA TC interrupt and restart the transfer 64K down the line).  Other
> than handling the interrupts, the MCU is sitting around staring at navel
> lint.
>

So you store a full track worth of data and then write it to the SD-card.
Then move the flux-length data over to a PC and do post processing there,
right?

Isn't there performance in the CPU to do the actual decoding as well? FM,
MFM, GCR or whatever into data. Find marks, check CRC and all that stuff?

/Mattis

Re: Greaseweazle

[Chuck Guzis via cctalk]

On 2/3/21 7:14 AM, dwight via cctalk wrote:
> I'm curious as to how the sampling code looks. Do you use the timers?
> Dwight

Exactly.  You run the sample timer in "capture" mode using DMA.  There's
a little trick in this when handling high-denisty fisks in thatthe DMA
counter is limited to 65K "items" (bytes, words, doublewords), so
there's a small amount of trickery to get more than 64K samples (grab
the DMA TC interrupt and restart the transfer 64K down the line).  Other
than handling the interrupts, the MCU is sitting around staring at navel
lint.

The reason for using the faster F4 MCUs is the higher clock rate (I
clock the sampling timer at 14, 28, 33 or 56 MHz) and the memory.  Data
is stored to SD card (the F4 has full-speed 4 bit SDIO).  The F407 is
perfect for the job (and lots of others, in that it has somewhere around
40 pins of 5V tolerant GPIO).  A half-meg of program flash lets you do
pretty much whatever you want.   The same MCU that I use for my tape work.

So long as there's support for USB ACM on the host (could be changed to
serial or WiFi), the software on the PC that eventually reads the data
off of SD can be anything.

I reserve the F103 "blue pill" cheapies for more mundane tasks.   You'll
find one such published on Github by me for using the
often-on-sale-for-less-than-$3 IBM IR keyboards as standard
PS2-interface keyboards.  In, fact, the interface to the host could be
anything--USB, serial, parallel.  The keyboards are all NIB,
decent-quality rubber-dome models.

We live in today's world where MCUs are in everything, in toys, light
bulbs--you name it. The low-end OTP ones from China can be literally had
for pennies.   We are surrounded by computers to an extent never
imagined by my old EE Prof whom I asked what he thought about the
potential of a monolithic computer-on-a-chip.   (He couldn't see any).

Well, to his credit, I still can't find one that makes up my bed or
washes my windows.  I suspect that those too, are mostly a matter of time.

--Chuck

Re: Flip-Chip selloff

[Ethan Dicks via cctalk]

On Tue, Feb 2, 2021 at 12:19 PM Al Kossow via cctalk
 wrote:
> I don't have any equipment that uses them any more, so I'll be ebaying off my
> A-W series flip chips over the next few days. The W's and PT08 boards are up 
> now
>
> https://www.ebay.com/itm/184647476832
> https://www.ebay.com/itm/184647420812

The PT08 board set is intriguing (I have an -8/S with no TTY interface)

-ethan

Re: Greaseweazle

[dwight via cctalk]

I'm curious as to how the sampling code looks. Do you use the timers?
Dwight



From: cctalk  on behalf of Mattis Lind via 
cctalk 
Sent: Wednesday, February 3, 2021 5:01 AM
To: Al Kossow ; General Discussion: On-Topic and Off-Topic 
Posts 
Subject: Re: Greaseweazle

Den ons 3 feb. 2021 kl 13:25 skrev Al Kossow via cctalk <
cctalk@classiccmp.org>:

> On 2/2/21 11:51 PM, Peter Corlett via cctalk wrote:
>
> > I have a pile of Blue Pill boards, and using it to read floppies was an
> > obvious application. However after running the numbers, it turned out
> there
> > isn't enough RAM to buffer an entire track from a HD floppy. It also has
> a
> > broken USB implementation just to liven things up a bit.
>
> a small performance list of STM32 parts and where they are used
>
> STM32F103C8T6  72MHz M3  64K Flash  20K RAM  FS Original blue pill
> STM32F411CEV6 100MHz M4 512K Flash 128K RAM  FS Latest WeAct black pill
> STM32F407VET6 168MHz M4 512K Flash 196K RAM  HS Board Chuck likes
> STM32F730x8T6 216MHz M7  64K Flash 176K RAM  HS Eric's GW / GW
> Lightning
>

The performance difference between the STM32F103 and any of the M4 (and M7)
chips is even bigger (than what the MHz tell) since there is a small cache
in the M4 (and M7) called ART which is intended to give close to zero wait
states when reading from flash. The STM32F103 has 2 wait states on flash
reads when running at 72 MHz. Unless you put code the code in RAM there
will be a performance hit on the 103. Unfortunately RAM is a scarce
resource on the 103 as well so you have to plan well to do that.

If one wants more buffer memory there is also the STM32F407ZET board which
uses the bigger 144 pin chip. On the back of those boards are pads for a
ISSI IS62WV51216 chip 512k x 16 chip.

What I think is kind of strange with the WeAct board is that they are not
identical in pinout to the blue pills. On one side all the pins are shifted
on step. I have no idea why they designed it that way.

Re: Flip-Chip selloff

[Mark Linimon via cctalk]

On Tue, Feb 02, 2021 at 07:10:14PM -0800, Christopher Zach wrote:
> I've had 30+ years to acquire this "stuff". :-)

I turned 65 last year ...

mcl

Re: Flip-Chip selloff

[Tom Uban via cctalk]

I suspect many of us are in similar situations. I have been collecting and 
storing
my treasures for about 35 years. I even recently moved it all into one nice 
climate
controlled space. (It has mostly all been in climate controlled space, but now 
it
is all in the same space with room to work on it.)

At this point in my life, reviewing how much time I have been able to find in 
the
previous years to play with my hoard, I am realizing that I have way more than I
will ever be able to enjoy. Then I consider that the others like me are also 
coming
to a similar conclusion and as a result there is likely lots of equipment 
looking
for homes other than the scrap heap.

With museums that seemed like they were funded and safe for the foreseeable
future closing with uncertain ends, I worry (just as others) that we are the 
only
ones who will be the custodians of these wondrous marvels of human genius.
As those who understand and care for such marvels pass, the number of people
who care also dwindle.

I've come to realize that perhaps it isn't just the theory that I might one day 
be
able to retire and enjoy keeping my mind engaged with tasks of restoring old
PDP-11s to their former glory, but that the 35 years of collecting and storing
might lead to a younger generation's wonder in seeing what led to the technology
they have at present. Perhaps they don't care and all is for not...


On 2/2/21 5:28 PM, Josh Dersch via cctalk wrote:
> Since we're talkin' sell-off... on the off chance that anyone has a TC11 or
> TC01/08 gathering dust (for something less than eBay prices), I, uh...
> could use one.  Along with many other people, I suppose.
>
> - Josh
>
>
> On Tue, Feb 2, 2021 at 3:12 PM Bill Degnan via cctalk 
> wrote:
>
>> I think it's good to hold onto that which is realistic to support, no point
>> in holding hardware hostage in a rodent and moisture-vulnerable old
>> garage.  We don't live forever.
>> b
>>
>> On Tue, Feb 2, 2021 at 5:57 PM Chris Zach via cctalk <
>> cctalk@classiccmp.org>
>> wrote:
>>
>>> What do I have...
>>>
>>> Decsystem/20 CPU box+supply (blt.ai.mit.edu), pdp11/05/83/24/23+/150, 2
>>> 8L's, an 8/e, 3 RL02, RM80, RX02,TK50,2 Professional 380's. And a
>>> Minc-11/MiniMINC.
>>>
>>> Several Perqs, that HP 1000e thing, and a few dozen MFM disks.
>>>
>>> A pair of Sun 386i's, Nextstation, NS Turbo, Turbo Color
>>>
>>> Probably a lot more.
>>>
>>> On 2/2/2021 4:13 PM, Bob Smith wrote:
 I am down to 2 vaxes and an 11, along with 10 Alphas, a pro380 and two
 DECMante II boxes.
 bb

 On Tue, Feb 2, 2021 at 1:48 PM Chris Zach via cctalk
  wrote:
> Might be a good time: I remember my dad saying I should encase each
>> one
> in lucite plastic and sell them as paperweights. That was 30 years ago
> but it would have preserved them well :-)
>
> C
> (Went from 3 8/I's to 2 8/L's so progress?)
>
> On 2/2/2021 1:22 PM, Zane Healy via cctalk wrote:
>> On Feb 2, 2021, at 9:19 AM, Al Kossow via cctalk <
>>> cctalk@classiccmp.org> wrote:
>>> I don't have any equipment that uses them any more, so I'll be
>>> ebaying off my
>>> A-W series flip chips over the next few days. The W's and PT08
>> boards
>>> are up now
>>> https://www.ebay.com/itm/184647476832
>>> https://www.ebay.com/itm/184647420812
>> That makes me wonder if I shouldn’t do the same.  That would be part
>>> of a camera lens, which may, or may not take up less space. :-)
>> Then again I’ve been saying I need to downsize my collection for the
>>> better part of 20 years.
>> Zane
>>
>>
>>

Re: Greaseweazle

[Paul Koning via cctalk]

> On Feb 3, 2021, at 9:53 AM, Mattis Lind  wrote:
> 
> Den ons 3 feb. 2021 kl 15:07 skrev Paul Koning via cctalk 
> :
> 
> ...
>> I haven't used RPi at all, since when I looked at it some years ago the SOC 
>> technical information was secret. Contrast the BeagleBone, for which there 
>> is a 5000 page manual.
>> 
> The Pico is quite different. They use their own chip for the Pico, the 
> RP2040. There is a 637 page manual 
> https://datasheets.raspberrypi.org/rp2040/rp2040-datasheet.pdf

Nice to know.  Thanks!

> Unlike the other Rpi this is more like the STM32 chips where you develop 
> C/C++  or Python to run directly on the bare metal. No Linux involved.

That makes it like Arduino.  Time for some more studying...

> The early Rpi used Broadcom chips. And like most Broadcom stuff you almost 
> needed signing a NDA to get a glance of the pinout of the chip. 

Exactly.  Broadcom had all sorts of strange notions.  The BBB uses a TI chip, 
which was always fully documented.

paul

Re: Greaseweazle

[Mattis Lind via cctalk]

Den ons 3 feb. 2021 kl 15:07 skrev Paul Koning via cctalk <
cctalk@classiccmp.org>:

>
>
> > On Feb 3, 2021, at 2:51 AM, Peter Corlett via cctalk <
> cctalk@classiccmp.org> wrote:
> >
> > On Tue, Feb 02, 2021 at 09:20:01AM -0800, Chuck Guzis via cctalk wrote:
> > [...]
> >> When I last proposed the STM32F407, I was met with "Oh, but the Blue
> Pill
> >> is cheaper". Okay, use the Blue Pill, but my code won't work with it.
> Not
> >> once has anyone contacted me and said "I'd like to try my hand at doing
> >> this, what can you tell me?". I've described the methodology of using an
> >> MCU elsewhere several times.
> >
> > I have a pile of Blue Pill boards, and using it to read floppies was an
> > obvious application. However after running the numbers, it turned out
> there
> > isn't enough RAM to buffer an entire track from a HD floppy. It also has
> a
> > broken USB implementation just to liven things up a bit.
> >
> > The Raspberry Pi Pico has a similar price to the Blue Pill and seems a
> much
> > better machine for this task, although I haven't combed through its
> > reference manual yet.
>
> I haven't used RPi at all, since when I looked at it some years ago the
> SOC technical information was secret. Contrast the BeagleBone, for which
> there is a 5000 page manual.
>

The Pico is quite different. They use their own chip for the Pico, the
RP2040. There is a 637 page manual
https://datasheets.raspberrypi.org/rp2040/rp2040-datasheet.pdf
Unlike the other Rpi this is more like the STM32 chips where you develop
C/C++  or Python to run directly on the bare metal. No Linux involved.

The early Rpi used Broadcom chips. And like most Broadcom stuff you almost
needed signing a NDA to get a glance of the pinout of the chip.


>
> In any case, for work like this an Ardiuno might be sufficient and quite
> possibly easier to use.  I've used the ARM based Arduinos, they have quite
> a lot more memory, faster execution, and native USB.  In fact (if you
> should need it for something else) host side USB, not just device side.
> The Adafruit "Trinket" is great for cases where not much I/O is needed;
> there are a variety of others that have a dozen or so I/O connections, all
> for $10 or thereabouts.
>
> paul
>
>

R: Winchester SA1004 file recovering

[Enrico email.it via cctalk]

It's a bit very expensive to shipping a SA-1000 from U.S. to Italy
almost over than 200 USD



-Messaggio originale-
Da: cctech [mailto:cctech-boun...@classiccmp.org] Per conto di jim stephens
via cctech
Inviato: mercoledì 3 febbraio 2021 12:18
A: Enrico email.it via cctalk
Oggetto: Re: Winchester SA1004 file recovering



On 2/3/2021 1:43 AM, Enrico email.it via cctalk wrote:
> Any suggestion?
I believe Dave G's MFM emulator has an option to support the SA1000.

I have one in stock for a future project to try to extract data from 
SA-1000's in DSD floppy / 8" drive subsystems.

https://www.pdp8.net/mfm/mfm.shtml

info is there about the SA-1000.

If you are having problems because the drives are dead, this won't 
help.  It will inhale the contents and with
luck you can extract data.

I know with the ST-506 configuration of his hardware, you can then use 
the emulator to replace the SA-1000.

If you need to recover the data, you may be out of luck, but if you need 
a "working" SA-1000 and can format
it from utilities, then this may help.

thanks
Jim

Re: Greaseweazle

[Paul Koning via cctalk]

> On Feb 3, 2021, at 2:51 AM, Peter Corlett via cctalk  
> wrote:
> 
> On Tue, Feb 02, 2021 at 09:20:01AM -0800, Chuck Guzis via cctalk wrote:
> [...]
>> When I last proposed the STM32F407, I was met with "Oh, but the Blue Pill
>> is cheaper". Okay, use the Blue Pill, but my code won't work with it. Not
>> once has anyone contacted me and said "I'd like to try my hand at doing
>> this, what can you tell me?". I've described the methodology of using an
>> MCU elsewhere several times.
> 
> I have a pile of Blue Pill boards, and using it to read floppies was an
> obvious application. However after running the numbers, it turned out there
> isn't enough RAM to buffer an entire track from a HD floppy. It also has a
> broken USB implementation just to liven things up a bit.
> 
> The Raspberry Pi Pico has a similar price to the Blue Pill and seems a much
> better machine for this task, although I haven't combed through its
> reference manual yet.

I haven't used RPi at all, since when I looked at it some years ago the SOC 
technical information was secret. Contrast the BeagleBone, for which there is a 
5000 page manual.

In any case, for work like this an Ardiuno might be sufficient and quite 
possibly easier to use.  I've used the ARM based Arduinos, they have quite a 
lot more memory, faster execution, and native USB.  In fact (if you should need 
it for something else) host side USB, not just device side.  The Adafruit 
"Trinket" is great for cases where not much I/O is needed; there are a variety 
of others that have a dozen or so I/O connections, all for $10 or thereabouts.

paul

Re: Greaseweazle

[Mattis Lind via cctalk]

Den ons 3 feb. 2021 kl 13:25 skrev Al Kossow via cctalk <
cctalk@classiccmp.org>:

> On 2/2/21 11:51 PM, Peter Corlett via cctalk wrote:
>
> > I have a pile of Blue Pill boards, and using it to read floppies was an
> > obvious application. However after running the numbers, it turned out
> there
> > isn't enough RAM to buffer an entire track from a HD floppy. It also has
> a
> > broken USB implementation just to liven things up a bit.
>
> a small performance list of STM32 parts and where they are used
>
> STM32F103C8T6  72MHz M3  64K Flash  20K RAM  FS Original blue pill
> STM32F411CEV6 100MHz M4 512K Flash 128K RAM  FS Latest WeAct black pill
> STM32F407VET6 168MHz M4 512K Flash 196K RAM  HS Board Chuck likes
> STM32F730x8T6 216MHz M7  64K Flash 176K RAM  HS Eric's GW / GW
> Lightning
>

The performance difference between the STM32F103 and any of the M4 (and M7)
chips is even bigger (than what the MHz tell) since there is a small cache
in the M4 (and M7) called ART which is intended to give close to zero wait
states when reading from flash. The STM32F103 has 2 wait states on flash
reads when running at 72 MHz. Unless you put code the code in RAM there
will be a performance hit on the 103. Unfortunately RAM is a scarce
resource on the 103 as well so you have to plan well to do that.

If one wants more buffer memory there is also the STM32F407ZET board which
uses the bigger 144 pin chip. On the back of those boards are pads for a
ISSI IS62WV51216 chip 512k x 16 chip.

What I think is kind of strange with the WeAct board is that they are not
identical in pinout to the blue pills. On one side all the pins are shifted
on step. I have no idea why they designed it that way.

Re: Greaseweazle

[Al Kossow via cctalk]

On 2/2/21 11:51 PM, Peter Corlett via cctalk wrote:


I have a pile of Blue Pill boards, and using it to read floppies was an
obvious application. However after running the numbers, it turned out there
isn't enough RAM to buffer an entire track from a HD floppy. It also has a
broken USB implementation just to liven things up a bit.


a small performance list of STM32 parts and where they are used

STM32F103C8T6  72MHz M3  64K Flash  20K RAM  FS Original blue pill
STM32F411CEV6 100MHz M4 512K Flash 128K RAM  FS Latest WeAct black pill
STM32F407VET6 168MHz M4 512K Flash 196K RAM  HS Board Chuck likes
STM32F730x8T6 216MHz M7  64K Flash 176K RAM  HS Eric's GW / GW Lightning

Re: Winchester SA1004 file recovering

[jim stephens via cctalk]

On 2/3/2021 1:43 AM, Enrico email.it via cctalk wrote:

Any suggestion?

I believe Dave G's MFM emulator has an option to support the SA1000.

I have one in stock for a future project to try to extract data from 
SA-1000's in DSD floppy / 8" drive subsystems.


https://www.pdp8.net/mfm/mfm.shtml

info is there about the SA-1000.

If you are having problems because the drives are dead, this won't 
help.  It will inhale the contents and with

luck you can extract data.

I know with the ST-506 configuration of his hardware, you can then use 
the emulator to replace the SA-1000.


If you need to recover the data, you may be out of luck, but if you need 
a "working" SA-1000 and can format

it from utilities, then this may help.

thanks
Jim

Re: Greaseweazle

[Christian Corti via cctalk]

On Tue, 2 Feb 2021, Al Kossow wrote:

Copy protection is just a pain in the ass.

A tiny, tiny fraction of what I work with has any and
I'm very happy it is mostly used on consumer computers
which are being archived by others so I don't have to.


:-))
This is also my attitude. I just don't care about fancy copy protection 
schemes, it is not my domain.


Christian

Re: Greaseweazle

[Christian Corti via cctalk]

On Tue, 2 Feb 2021, Al Kossow wrote:

Do you make these available online?

I found your version of IMD here 
ftp://computermuseum.informatik.uni-stuttgart.de/utils

not under source control.


Ups, I see that this is a very old version. I'll update this with my 
current version and I'll write some notes on the usage etc. But it will 
need some time, the source is on my PC at work and currently doing home 
office.


I hate the fact that there are dozens of siloed projects in this problem 
space.


Yes, me too. It started several years ago as a "quick" way of imaging 
floppys on my PC that obviously is Linux only. But now, I think I could 
just publish it and have everyone play with it :-)


Christian

R: Winchester SA1004 file recovering

[Enrico email.it via cctalk]

Correct addess of the video test:

https://www.dropbox.com/s/d9iacfgrnexso3o/GP%20T20%20con%20HD%20banco%20prov
a.mp4?dl=0


The email cuts the link address to the video file. please join the first
with the second piece and paste it in your browser.

Enrico

Winchester SA1004 file recovering

[Enrico email.it via cctalk]

Hello everyone,
in Italy in 1981 there was an explosion in creating new machines following
the introduction of microprocessors. 

I have several "General Processor T-Model" machines that used CP / M 2.2
operating system. 
Here you can see the photos of the 1st acquisition
https://www.vintagesbc.it/wp-content/uploads/2012/10/Foto3775.jpg (this is a
master machine with modified CP/M system that provides shared resources via
rs232 to two slave machines) and the 2nd acquisition
https://www.vintagesbc.it/wp-content/uploads/2012/10/Foto3430.jpg (these are
two compositions: a machine with CP/M system with a pair of BASF 6104 drives
and a second machine with an HD + FD 8" box and a further box with a pair of
REMEX RFD4000 8" drives). 
The machines of the second acquisition were in a better condition. 

A very dear friend first read in raw mode a 10MB Winchester hard disk model
Shugard SA1004 from which the files were correctly extracted and then set up
a test bench from which you can see in this video the complete system
operating with the HD ed il controller Shugart SASI SA1403:
https://www.dropbox.com/s/d9iacfgrnexso3o/GP%20T20%20con%20HD%20banco%20prov
a.mp4?dl=0

The problem arose later when we tried to extract the raw file from the 10MB
Winchester hard disk model Shugard SA1004 of the 1st acquisition in the same
way. Visually, the hard disk had certainly suffered atmospheric damage, but
the electronic boards were functioning correctly. 

Despite we having attempted different readings (even using cards from the
first hard disk), using the same FLUXengine card
(http://cowlark.com/fluxengine/doc/building.html) the raw file still does
not present the Hard Disk directory, instead  we read the information of the
files present but there may be bad bytes in these files and in the rest of
the disk as well. 

Unfortunately this content is unique in its kind and we would like at least
to extract the operating system and/or the files of its initialization in
order to be able to correctly reproduce the functioning of this system. 

The last option would be to take the hard drive to a clean room hoping that
the hard drive platters are not scratched.

Any suggestion?

Enrico - Pisa (ITALY)

RE: re: HP Journal back issues

[ED SHARPE via cctalk]

Indeed this site is great for reference but alas are too lo-res for good museum 
display images.

I do use this as a reference source  but need paper copies sometimes  to hi res 
scan some times!

Ed#
On Tuesday, February 2, 2021 Richard Milward via cctalk 
 wrote:
You can find HP Journal issues at 
https://worldradiohistory.com/HP-Journal.htm 

The World Radio History site is a fantastic resource in general, I use 
it regularly.
**Richard

Re: Greaseweazle

[jim stephens via cctalk]

On 2/2/2021 11:51 PM, Peter Corlett via cctalk wrote:

The Raspberry Pi Pico has a similar price to the Blue Pill and seems a much
better machine for this task, although I haven't combed through its
reference manual yet.
For capture and writing (if that's part of the design) I heard there's a 
dedicated coprocessor for the GPIO pins.  It might be useful for 
offloading some of the proccessing from some external circuitry to do 
the capture or output.


I don't know what's included for the capabilities.  And apparently since 
the chip is new, there's only assembler programming for it now.


There's a video comparing the Pico, ESP32, ESP32-S and Blue Pill. The 
latter was a bit low in resources compared to the others.


I'll try to find it and post it if anyone's interested.

thanks
Jim