Washington state surplus has a Large lot of Media up
for grabs. Mostly 9 track tapes but there is some 4477
disk packs in there.
this is a large lot. 7000 lbs
No info about being bulk erased
http://www.publicsurplus.com/sms/auction/view?auc=738159
-Jerry
Here's an update from the KryoFlux team and it's for sure the hottest
thing that I have been given the pleasure to reveal over the last
twelve months. The post is long, but we have been very productive. :)
You might have noticed it's gotten a bit quiet after adding write
support to KryoFlux last summer. The reason is that behind the scenes
the next big thing has been prepared. We always felt that the C64
community was lacking a format that would give them the opportunity to
feed raw data more or less reliably into emulation. It turned out that
G64 was in fact capable of working for an estimated 95% of all
scenarios out there, but implementation in many emulators is so bad
that things the format has to offer simply don't work in emulation.
It's been a while since we said we'd not touch G64 as G64 was "bad",
"not working" and "giving people a false impression about preserving
things". While we stand firm that G64 is not the grail of a
preservation format, we must apologise for being stubborn in regard to
supporting it. Gladly many of you were stubborn, too, requesting G64
being supported, which finally led to the decision to do it right and
correct things as needed.
We turned to?Pete Rittwage?and his?C64 Preservation Project. We in
fact?had been in touch for years and we were happy Pete shared the
vision we?had and decided to not let us have the fun on our own:?"I am
more than?happy to?help push technology forward. ?I knew the
limitations of what I was doing?with the old 1541 hardware and was
excited to hear that work was being?done on the 64 with Kryoflux. ?I
was glad to fill a gap until more?high-resolution disk imaging was
available."? While this is flattering, it?would be an understatement
to call Pete's work a gap filler - his NibTools?are very much
appreciated among the C64 community. Another helping hand came from
Robert McIntyre?who already had helped modifying 5.25" drives to allow
for one-pass dumping of flippy disks.?The following months were spent
on research and getting things done, which finally led to a few
conclusions:
a. C64 preservation is still possible today, but results largely
depend on media quality and storage.
b. About 90% of games can be imaged with a 1541, 95% can be imaged
with KryoFlux and the last 5% can be imaged with KryoFlux as well, but
representation will need a more sophisticated format like our own IPF.
c. Nearly all emulators are "broken" in regard to G64 image support.
While some will go beyond the limit of 7928 bytes per track (which
seems to be the maximum track size chosen by many programmers), some
even don't support half tracks. This protection technique utilises the
fact that the 1541 has a head designed for a 40 track drive, but
features a stepping mechanism that can address 80 tracks. VICE, the
most popular, has several flaws in the floppy support code which makes
it impossible to use such images unaltered.
If you take the time to read Pete's pages
(http://www.c64preservation.com/) you will find many details on how to
modify or alter images to make them work in emulation. While some
changes are needed because the 1541 alters data before handing it over
to the host computer (which means this also happens with other devices
that work directly with it) the other half of changes are needed to
work around flaws present in certain emulators.
We decided it would not make much sense to release KryoFlux with
capabilities that would go beyond those of the emulators around which
is why we decided to also update VICE and give it extended G64 support
to load many images properly without any user interaction.?While
Softpres' Istv?n F?bi?n worked on creating an intelligent conversion
algorithm for DTC that would transform stream data into meaningful G64
representations, Robert focussed on exorcising VICE and fix/add the
features needed to make the 1541 in VICE behave like the real device.
To give the emulation the precision needed to also run the most
advanced protection methods, the trio even delved into the schematics
and created a logic model that was verified shortly after by Pete by
writing special test files back to disk with modified versions of
Nibtools and then comparing results. The data was seen as predicted.
So, after many months of research and hard work, about 1,000 C64 games
dumped, and many many emails later, we are proud to present:
1. DTC with enhanced G64 export.?Rated in percent, the success should
be good for 85%. Please make sure to not toss your stream files (which
are mandatory for generating G64 files) - you might need them to fix
images that won't work when we release the next version. If you get an
error telling you there was a problem converting to G64 - be sure
there was and the image is bad. DTC will refuse to convert to G64
directly from a floppy disk. You must create STREAM files first, to
avoid unnecessary stress applied to the ageing medium. Please read the
manual (especially page 19 and 20) about how this new exciting feature
works.
2. PREVIEW version of VICE with enhanced G64 support.?This is our
special gift to the community, and we're sure many users will
appreciate it. You won't need a KryoFlux to benefit from it, many
images that are floating around and needed to be fixed will now work
right away. We'll hopefully be working with the VICE team to get our
updates included in the official sources, but until that happens?we'll
continue to provide a second fork (W32 build as of today, source code)
on our site which will have extended G64 support.?The new circuitry
simulation code allows VICE to read data recorded at a?certain bitcell
density to be read back at a different bitcell density.?e.g. data
recorded at 3.5us to be read back at 3.5us correctly as well?as get
the expected results when reading at say 3.25us timing setting. E.g.
all RapidLok protected titles rely on this to be working ?Please note
that this preview does not yet enable half-track support, which will
come in an update within the next month. Please see the README file
included with the builds for further limitations, this still is a
PREVIEW version.
Here is a picture of a game that for sure won't run on an unmodified
version of VICE: "Defender Of The Crown" by Cinemaware.
http://kryoflux.com/pics/dotc_raiding.jpg
It features?V-MAX! v2 protection and performs a precise density check
on the disk as?soon as the player goes raiding. This image will not
run in the current?official build of VICE. To give you a chance to try
this new feature,?the G64 for "Defender Of The Crown", courtesy of CW
Holdings, Inc., is?included with the VICE build on our website. The
new build of VICE will?also run many other G64 files now that did fail
before. If you ever?tried some of?the early Rainbow Arts or Magic
Bytes titles (so called?BetaSkip protection by MWS), like Giana
Sisters, Turrican or Blue Angel?69... all of these should work
flawlessly now.
All of the above is available as of today. Just head over to
http://www.kryoflux.com?and grab the download of your choice.
We'd love to hear your thoughts on this. Please visit our forums (
http://forum.kryoflux.com ) and let us know!
Kieron
The KryoFlux Team
In case anyone finds this of interest/amusement...
Retrocomputing with a VAMP stack: VAX, Apache, MySQL & PHP
What to do with a VAX workstation, based on an architecture first
released by Digital Equipment Corporation in 1977 and finally closed
out by Compaq at the end of the last millennium?
The obvious option would be to dig out an ancient copy of VMS, or
maybe an early UNIX tape, but what then? Could it run the latest
Apache or screen, and how will I be able to connect it to a native
IPv6 network (when we finally get there :) ?
As an alternative, lets see if a current OS and software can run on a
machine with an architecture older than some of the *parents* of
modern developers...
[continued at http://netbsd0.blogspot.co.uk/2012/06/retrocomputing-with-vamp-stack-vax.ht…
]
Is there a reference somewhere that tells me exactly the spec of various DEC
cables?
For example I think I need a BC13B (connects VCB02 to monitor, keyboard and
mouse), but I have a BC19S which *seems* identical. All I can find are
resellers that list part numbers, one or two name the cables, but don't give
the technical information that gives me any idea if these two are
interchangeable or not.
Thanks
Rob
If anyone owns an Apple-1, the peak of the bubble has arrived. Sell yours
NOW and then buy it back after the bubble bursts.
In the meantime, maybe buy a nice tulip to replace it.
--
Sellam Ismail VintageTech
------------------------------------------------------------------------------
International Man of Intrigue and Danger http://www.vintagetech.com
Whatsoever a man soweth, that shall he also reap...The truth is always simple.
I have looked through bitsavers and some other old vax manual repositories online and I haven't found a manual for the DEC VT1300. I did an installation and service manual for the VR320 monitors I have, but they only cover the display. I have worked out alot of details about the vt1300 system, and have gotten one working 100%, but haven't figured out what terminal emulation the terminal personality of the unit uses. It works 95% with the vax 3900 I have it attached to, but from time to time I see what I assume as vt100 control codes in the output stream. I assumed that that unit used vt100 emulation out of the box, and that the vax console would go this way as well, but perhaps I'm wrong. It could be that the vax is vt52 some other terminal type by default, or that the 1300 does vt102, or vt220...
Kevin
On 15 Jun 2012, at 09:14, jim s <jws at jwsss.com> wrote:
> Is there a place with a description of all that one needs to set up to
> get the vax cluster going? I'm thinking that my vmware system could
> host 4 to 8 linux boxes w/o a problem, but given the time I have to put
> into projects, I'd love to get pointers on where the best starting point
> is rather than a lot of hunting. I've got pretty good familiarity with
> all the bits a pieces, but the devil is usually in the details when you
> start to try to find all the parts. I'd certainly document what it
> takes to get it onto a multi vmware / simh system.
I'm working on it for RaspberryPi, the procedure, minus the part about
preparing the OS SDHC card, is likely to be similar.
> I've been doing some firewall testing with success on the setup, and if
> the traffic is routeable on the vmware virtual switches, I'd like to use
> this a another test of that.
Sounds like an unteresting project, it could really prove viable with
something like a 4-thread i3 or i5 and 4GB of RAM to share out between
the VMs. I'd probably run a SSD or high speed disk for the partitions
to maximise I/O speed.
--
Mark Benson
http://markbenson.org/bloghttp://twitter.com/MDBenson
Uses SIMH on a pair of Raspberry Pi boards. Pretty slick:
http://www.designspark.com/content/raspberry-pi-vax-cluster
g.
--
Proud owner of F-15C 80-0007
http://www.f15sim.com - The only one of its kind.
http://www.diy-cockpits.org/coll - Go Collimated or Go Home.
Some people collect things for a hobby. Geeks collect hobbies.
ScarletDME - The red hot Data Management Environment
A Multi-Value database for the masses, not the classes.
http://www.scarletdme.org - Get it _today_!
Buying desktop hardware and installing a server OS doesn't make a
server-class system any more than sitting in a puddle makes you a duck.
[Cipher in a.s.r]
