At 12:35 PM 8/3/2026, Len Shustek wrote:
>It sounded like David has already done that, and has digitized the analog
>track data. That's what my "just software" program expects as input.
I should clarify: not a conversion of the analog track data into the encoded
bits, but digitizing the magnetic flux waveforms at a rate that provides
about 15-30 samples per cycle. The software then finds the peaks (or
zero-crossings), derives the clock when necessary, and decodes the bits.
https://www.vintagecomputer.net/browse_thread.cfm?id=833
New TU56 Tape Images Available for simH use. I will post updates on this
thread, but if anyone is interested in messing around with the images
using simH, feel free to download and explore/use.
Bill
In London (and I think some other UK cities) there's a free newspaper
available on public transport, called the Metro.
It has a small item each day called 'Today in History' giving events
that happened on that date. Today's includes the entry :
'1977 : Tandy released the TRS-80, one of the first personal computers
made available to the consumer market.'
Pleased to see a classic computer getting a mention.
-tony
Let's talk about QIC-24 (Quarter-Inch Cartridge) recording format tape
drives. I have an Archive Viper 2150S drive and a few Tandberg QIC 1000 /
TDC4120's. I have a collection of tapes that have had their elastic
repaired to my satisfaction. I can see the tapes advance using the rewind
command etc. Some of the tapes read fine and I can pull their data.
My question is - a few of the tapes are not readable, I am using standard
linux tape commands fed to the SCSI drive. I am wondering if Sun tapes are
formatted differently and must be read in Sun tape drives. Could there be
different types of physical BOT holes, or are they all the same? Is there
something that makes a tape un-readable unless it's in a
Sun/Windows/Linux/VMS environment? I am just trying to get the data, not
use the data. At least not yet.
My bench system is Linux Debian 7.
I realize the tapes I have that I can't read may just be bad. Or maybe
they're simply not formatted. I just don't want to give up until I am sure
I have tried everything and know as much as possible.
Any ideas?
thanks
Bill
Paul Terrell, Liza Loop, Daniel Kottke and Ronald Wayne as they recreate
history by presenting Liza with a replica Apple 1 and then discuss the
early days at Apple. Bring all your burning Apple questions as you may have
an opportunity to ask them of the panel. Rumor is that Woz will be there!
Jeff Brace
VCF Evangelist
VCF West Sat Aug 1 at 4:3PM At the Computer History Museum in Mountain
View, CA.
Ronald Wayne discusses his time at Atari and Apple, how he authored the
original Apple partnership agreement, designed Apple's first logo and
worked on the Apple-1. Q&A session followed an autograph signing.
Jeff Brace
VCF Evangelist
Doesn’t time fly by? The Z80 processor could be bought in July 1976. It
along with Intel’s 8080 were the backbone of classic computing 50 years ago.
Happy computing,
Murray 😊
There have been a few versions of the utility imd2raw.c floating around
that will take Dave Dunfield's ImageDisk-created images (i.e. an .IMD file)
and make a linear binary image devoid of any metadata. This is similar to
the function of Dave's IMDU.COM program's /b switch.
I've corrected a problem with the assumption that all imd2raw.c descendants
to date have made: sectors that have a skew (i.e. not 1-1 interleaved)
weren't linearized correctly. The skewed sectors need to be written out in
"sorted" order, which is not necessarily captured/physical order. This is
easily verified by comparing output from "IMDU /b" to earlier imd2raw
outputs on any .IMD that has a sector skew that isn't 1, 2, 3 [...].
It's up on github here:
https://github.com/RetroFloppy/imd2raw
