On 27/10/2011 20:28, leaknoil wrote: Sheesh, he's not exactly doing his best to sell it is he? blurred photos, card removed and resting on the bare metal case! hate to think what else it's been though. talk about bandwagon jumping.

On 10/28/2011 9:59 AM, Liam Proven wrote: Guy on the vintage computer forum contacted him and got this back: "Greetings, I used to be the service manager for both Pixar & Vicom. If you have read anything about the history of Pixar you will know that Steve Jobs decided to sell the HW division to Vicom. This was a sales demo machine that traveled up and down the east coast. This was not a standalone machine, it required a Sun 4 front end to drive. The P2 came standard with (2) boards, (FSP) Video Card, and (CHAP) Channel processor, both are in machine. The monitor has a few scratches as seen in photo and 1 tiny chip on upper corner that can easily be cleaned up. The screw on cover for the back side is missing that covered the boards, almost always discarded after install. This was a working machine several years ago. I spoke to the original P2 SW manager a few months back who ironically now works at Apple. He is still in touch with the HW design engineer so it's might be possible to get this fired up again if someone was willing to deal. My thought is this would be a fantastic acquisition for a museum or private collector to modify so it appears operational using a CD and flat screen playing old Pixar video's. This PIXAR machine is guaranteed to get everyone's attention wherever it's displayed"

$20K with reserve not met? The guy must be asking like $50K for it. I'm not sure its worth even $20K, but the glamour of it with Jobs recently having died will probably pull in some whales. -- "The Direct3D Graphics Pipeline" -- DirectX 9 version available for download <http://legalizeadulthood.wordpress.com/the-direct3d-graphics-pipeline/> Legalize Adulthood! <http://legalizeadulthood.wordpress.com>

On 10/31/11 12:50 PM, Jason McBrien wrote: Walt?

Richard wrote: It's a bit of a boat anchor if it needs a Sun 4 with custom software[1] on it which is long-gone - I mean OK, it might be possible to "get it running" but surely making it *do* something is another matter entirely? It's not exactly visually appealing, so although it might be nice for a museum as an artifact for preservation, I'm not even convinced that it'd be interesting as part of a display piece. "What's unique about this computer is the tomb stone design and matching monitor paint scheme." Heh :-) [1] Although Al's point about them already having one is noted - maybe the necessary is still floating around somewhere... cheers Jules

On 11/1/11 2:15 PM, "Steven Hirsch" <snhirsch at gmail.com> wrote: -snip- to send it to them and they have to process it. Their explination is that the software and knowledge is beyond the pricepoint of most people (software) and most people don't have the knowledge to decode a flux recording.... - Q: Is it true that at present, the only way to make IPF is to send it to SPS as the current software does not have the function to make IPF? Will the functions to make IPF images and write these back to disk be made available in the near future i.e are you guys working on enabling these functions for public use? A: KryoFlux is an imaging solution. It was made to ingest a broad range of source media and directly transfer standard formats into sector dump images. IPFs are made by preservationists that have a strong knowledge of disk coding, formats and protections. The software used for this, the CTA Software Preservation Analyser, is a highly specialised product that is available to institutions, archives and libraries. It is also available to private users, but its high price tag is very likely to be beyond what a private person is willing to invest. Preserving software is not a one-click process although the Analyser has advanced features built in that help working on a disk very fast. Nevertheless, in the hands of an untrained person, the analyser will not be of much use. Because of this, making IPFs is not available in DTC. These are two products with different functionality. It is planned to bring writing of stream and draft to DTC, but please understand that this is nor a priority, neither does this mean that such files can always be successfully written to disk. IPFs are not only analysed, they contain information on how the data is going to be written (instead of all other formats known to us which store data how it was read). It is easy to tell how data will be read back after it was written, but not how it was written, if you only know how it reads back. The Software Preservation Society is working closely with archives around the world and does offer inspection of data and generation of IPFs as a free service. This service is limited by the time available for this task. Q: Why isn't the Analyser available to the public for free, too? A: Because it's a very special product that was created over the last decade. Many many many man-hours of work went into the Analyser. In the hands of a preservationist it's a powerful tool, but will be totally unusable for the unexperienced user. Think of an IDE for C++ or similar. If you can't write programs (=understand MFM and other variants of disk coding) even the most advanced IDE will be useless. It is very easy to produce broken IPFs if you do not know what you are doing. The result would be a world full of broken IPFs or IPFs made from modified sources that would be "disguised" as genuine. Therefore it requires a huge amount of support to train new people on how to use it. This takes much time, time we would spend on playing with our kids, going to the cinema or having a good time with friends. It is not meant to sound ignorant or arrogant, but it is a high class product for a very small niche and people needing it can afford buying it. This will not only compensate us for the time spent, but also bring some revenue for further development and preservation in general. Because of the above the product does come with a protection device (dongle) that does contain the actual licence. We therefore can't give out demos easily. But: If you think you should have it because you want / can help please do not hesitate to contact us. Asking is always allowed. - end quote from FAQ-

On 11/2/11 4:30 AM, Steven Hirsch wrote: And what prevents them from "archiving" anything you send them? My feelings exactly. I can't imagine any professional archive taking this group seriously, and it is completely opposite of CHM's policy of preserving and making available any information on underlying media formats that we find.

On Nov 2, 2011, at 1:28 PM, Mouse wrote: Well, this sounds like an opportunity. I've been interested for quite a while in writing a raw-ish USB disk interface for archiving my old Mac and Apple II disks using modern, more reliable drives. If there's actually a demand out there for simple hardware that can be talked to via an open specification, I'd be glad to hear others' thoughts on what a good spec would be. It's ridiculously easy to do A/D and D/A on modern micros, and even the cheap, easy-to-drive ARMs have USB interfaces. Should be a cheap board to build and stick a JTAG interface on to let people muck around with their own firmware as much as they want. I'm also interested in building a similar device for 1/2" tape archival, but that requires some serious mechanical and analog design expertise that I just don't have (and don't currently have the time to pick up). Any interested takers on the floppy bit, though? Should be easy to build up a prototype that'll talk to a Shugart interface for a handful of bucks (maybe $50 in prototype quantities, though I'm pulling that number out of the air based on recent projects). - Dave

On 02 November 2011 at 17:28 Mouse <mouse at rodents-montreal.org> wrote: Well, since I personally wrote the GUI for KryoFlux, I'd be very interested in what would work for you, even if you don't intend to use whatever changes we might make. The GUI was designed to be extremely easy to use, even for non-technical people such as those in libraries and archives. There are advanced features, but they are mostly hidden unless specifically wanted. I think it turned out pretty well, if I do say so myself. Some examples: http://www.softpres.org/kryoflux:ui:stream-plot http://forum.kryoflux.com/viewtopic.php?f=2&t=262 As it happens, even though I wrote the graphical user interface, I didn't need to know anything about how to talk to the hardware. The GUI just uses the existing software supplied. Anyone could have done it really. That is fair enough. If it is not suitable for you, then it's not. We do have the stream file/protocol documented at least: http://www.softpres.org/kryoflux:stream It would be nice to document it completely as you want, but we have very limited resources, and unless there is much demand for something, we would find it hard to prioritise it. I think you might agree that your requirement is a little unusual... :) Kieron

On 3 Nov 2011, at 00:46, Mouse wrote: I have the same problem I think. Can't stand black on white. It hurts by eyes. No, we don't have reverse video, but it is not black on white for the most part. Thanks for the idea though, I'll make a note of that. Absolutely. We also offer a command line tool that can be used for this. As it happens, we recently added preliminary support for scripting of the GUI so you can get the best of both worlds. Yes, I don't think I used any non-public info. It's all in the manual that comes with the product, and testing against it of course. The flux transition plots could be produced from the stream format document (well, actually, the stream format document was created while implementing support for them in the GUI). The most recent version is mostly fine in this regard. I use it mainly via keyboard when developing. I'm sure there can be improvements though - for example, I am not sure the configuration screens are easily navigatable by keyboard (although I am sure it works). Well, that depends on what you need to know. We try to put the complexity out of sight rather than hiding it. There are a few minor features missing though, that is true. I'm not sure if there is anything we "hide" - we show pretty much everything that the command line version shows - just in a different way. I am (partly) a user interface developer professionally, so simple UI's is important to my sense of well being :) I think this initially refered to the firmware protocol being documented. We should certainly do that, again factoring in our priorities. However, your suggestions are very useful, and we could improve in some of these areas. Yes, and thank you for taking the time to explain! Kieron

On 11/2/2011 5:24 PM, Kieron Wilkinson wrote: (Kieron replying to someone else) Hi. I find it interesting what different (fairly independently developed) designs have in common for this type of job of reading floppies. ie, How did other smarter-than-me people accomplish the same task? Was my solution better or worse? I built an open source(java client software) and open hardware (HDL released) solution for reading amiga floppy disks, and it was(is?) a whole lot of fun developing it. Learning both the amiga-specific stuff and the technology stuff. My blog is at http://techtravels.org/amiga/amigablog/ which is ATM being reworked(but completely online and available), again. I'm starting to add some generic FPGA notes, examples, etc. I played with a few different microcontroller designs (using a 50mhz Parallax SX, which was really well suited to the task) and then eventually a Xilinx FPGA approach. When I saw your links above, they reminded me of my analysis of my amiga floppy data on my posts here http://techtravels.org/?p=362 and http://techtravels.org/?p=263 These are obviously generated outside of my client software, but could be integrated with a little work. Based on the number of unique non-search-engine hits my blog has taken over the years, there is a fair number of people who dabble in this stuff. I get email every few months about a new project from someone working on the task. Your screen shots look pretty sweet. Thanks Keith

On Wed, 2011-11-02 at 13:28 -0400, Mouse wrote: By watching the series of DiscFerret training livestreams I'm toying with the idea of running over the Newtonmas and New Year holiday? Oops. I've let the cat out of the bag now....! -- Phil. philpem at philpem.me.uk http://www.philpem.me.uk/

On Wed, 2011-11-02 at 21:22 +0000, Kieron Wilkinson wrote: The problem as I see it is that some of the WIPs (e.g. the one covering RNC Copylock Amiga track re-generation) are outright incomplete. They state that the data can be regenerated from the seed value, but do not explain how this is done. This is the type of information I'd like to see, and indeed is the type of information I'm trying to collate and disseminate via the DiscFerret Wiki: http://discferret.com/wiki/Category:Disc_formats -- Phil. philpem at philpem.me.uk http://www.philpem.me.uk/

On Wed, 2011-11-02 at 07:30 -0400, Steven Hirsch wrote: The software is being worked on by myself and two other developers. We have an IRC channel on Freenode (irc.freenode.net), predictably enough called #discferret. And I'm always on the lookout for more developers :) I've been quiet for several reasons: 1) I tend to stay out of OT discussions, and there have been a lot of those on-list recently. 2) Every time I've commented on a thread like this, I've been dragged into some type of flame battle. Some people really don't like the idea of alternatives being mentioned -- to the extent that I mentioned the DiscFerret on one classiccmp web-forum, and ended up having ALL my posts removed (several dozen messages), and my account blocked. Complete with a message from the admin to the effect of "your opensource project harms commercial interests, and we have few enough commercial suppliers left as it is". I've stopped trying... As I've said elsethread, I see the three devices as serving different parts of the same market: - Kryoflux -- hobbyists who "just want a disc image". Turn-key, no fiddly switches or buttons to press. - DiscFerret and (to some degree) Catweasel -- Tinkerers. People who want to look under the hood, see how things are done. The sort of folks who buy a car, then immediately go out and buy the Workshop Manual, Haynes manual and all the special tools required. If SPS (or anyone else) wants to use some of my research, they're welcome to do so under standard academic terms -- provide credit ("cite your sources!"). For the pages on the DiscFerret wiki which I didn't write (look at the history), credit the original author... Similarly I'd expect any research done on the subject (or at least that based on my research) to be released under a fair and non-discriminatory policy. GFDL, Creative Commons Atribution-ShareAlike, something like that. Cheers, -- Phil. philpem at philpem.me.uk http://www.philpem.me.uk/

On 11/3/2011 2:44 PM, Steven Hirsch wrote: My introduction to the internet was more-or-less through IRC in the late 80's as a kid. I did BBS's starting around 1983/1984. Multi-line BBSs were rare, fun, and in demand. The best of the local ones had between 4 and 8 lines. Considering that normal message boards usually had at least a day of lag between exchanges, real time communication that "chat" provided, was awesome. A friend from a BBS said, "if you think 7 or 8 people chatting at time is cool, try IRC," giving me a "public" account on the local university's unix box. Really opened up a world of excitement...... never really played with unix or really any OS besides MSDOS, CocoII, and AmigaDOS.......... IRC, for as much of a troll-haven as it is, and a time-sucking procrastinator's dream, really has a redeeming value to it. Since it was around before the www, it was a pretty good source of information at the time and quenched the instant-gratification thirst. (even if it was at the expense of being slightly unreliable) I still pop in from time to time on some channels --- and am always happily surprised when an old friend pops up to say hi. You should try it for a little while. There are some software packages/sites that offer unofficial real-time support through it. Keith

Oh, they're always good for a laugh. Expecially if you compare them to the official factory manual to see what Haynes left out (both entire sections -- they seem not to bother with the diagnostic codes for mdoern cars) and steps in a particular procedure. At one thime they claiemd that 'every manaul is based on a complete strip-down and rebuild'. They're stopped saying that now, IMHO it's no lonter true. The recent Haynes manauls are often reprinted bits of the official manaul (some diagrams are identical). And it's clear in amny caes they;'ve nto actually tried to do the repair. The tool is avaialble locally... 'locally' is either a misprint for 'luckily' or the name of a small village in Wales. Actualyl, I wish they would include dimentioned drawings of the special tools. A lot of them could be made in a home workshop... -tony

On 3 Nov 2011, Philip Pemberton wrote: As you are commenting on our product (something I have avoided doing on yours you might notice), I think we need a more balanced view than simply saying our product is for hobbyists. I see KryoFlux as being from the people who have spent 10 years working on the technology and research doing this, who actively preserve thousands of games with very complicated formats and protections. KryoFlux is a result of that research, a product that is used right now for real preservation, both by us, and by small and large archives and libraries. It's a product for people who are not willing to gamble on the authenticity or integrity of their data. It has been through a huge amount of testing, and is now used in the wild by hundreds of people. Not only does it support raw imaging of flux transitions, we also support output of sector image formats for pretty much all major home platforms of the last 25 odd years (as well as a few strange ones). We even support complete imaging of flippy disks (with a suitable drive) too. People can tinker at a deeper level with KryoFlux - aside from the fact there are plenty of "buttons to press" (we just don't stick them in your face), various people have written their own tools (decoders, analysers, converters) around our technology already. The hardware is open, and the formats are documented. I'm biased for sure, but I do think it is an extremely well designed, robust solution, and it is getting better all the time (some exciting new features in the works right now in fact). Kieron

On 3 Nov 2011, Philip Pemberton wrote: 1) The nature of IPF is read-only. It is a mastering format, there would be no point writing to it. 2) We've only recently opened the source (which is pretty well documented), so give us some time... It's something we want have done, sure. Either that or done by somebody else could help so we can concentrate on actually preserving stuff. Maybe you want to help with that Phil? Give a little back? It shouldn't be that hard from the source, but would take time, sure. 3) See (2) Reverse-engineering from the source code? I don't really know what you mean by that. Ah... you want to write IPFs... I don't think that really needs "reverse engineering". You need to try and understand how the code works. It's not simple for sure - that is because it was a very hard problem to solve (mastering disks as they were originally on commercial Trace hardware, with scripted writing). There are also ports for Linux, Mac and AmigaOS in there too. Yes, exactly. IPFs are intended for a specific purpose - preserving commercial games as they were originally produced. For many other uses, like backups of a personal collection, it is probably better to use a simpler format. Yep, that is cool. We don't currently have much interest in imaging hard drives I have say. We are working in the area of perfect commercial software preservation, it's built specifically to help with that. Yeah, I'd like to see this added to KryoFlux. The thing holding it up is that don't have disks to test. Kieron

There are few quicker ways to lose me as a potential customer than to insult me. And I consider telling me that I am not clever enough to do something to be doing just that (it may be true that I can't work out how to decode the data, but I'll decider that for myself... As a more general question, what advantage(s) does this product have over the DiskFerret, which I understnat to be completly 'open'? -tony

On 2 Nov 2011, at 21:39, Tony Duell wrote: . . . AND is it a USB device?

On 11/2/11 4:32 PM, "Kieron Wilkinson" <lists at softpres.org> wrote: I apologise for paraphasing, the tone of what I wrote was what I read into it from y'alls FAQ... - "Preserving software is not a one-click process although the Analyser has advanced features built in that help working on a disk very fast. Nevertheless, in the hands of an untrained person, the analyser will not be of much use." - What is the use of providing software, hardware and a -supposedly- open disk image format when one cannot apparently create that disk image format (presuming it was designed to be a universal image archive format) with the supplied software? If it will be added later, that is great.

On Wed, 2011-11-02 at 23:32 +0000, Kieron Wilkinson wrote: Correct me if I'm wrong, but I was under the impression that: 1) The IPF library was read-only 2) There were no publicly-available documents covering the IPF file format 3) No documents have been released as part of the source dump (thus satisfying (2)) Thus, creating an IPF would involve reverse-engineering the format from the source code (which I have not examined closely, but appears to be somewhat Windows-centric and lightly commented based on the few files I've examined). Once the format was r/e'd, you could then write a library to create IPFs... Seems a lot of work. I'd rather put the effort into writing a .MFI (MESS Floppy Image) R/W library... I'm going to pull out a 9mm and shoot myself in the foot here. * Kryoflux and DiscFerret are two separate things. * Kryoflux does a good job of imaging most floppy discs * Key differences between DiscFerret and Kryoflux: * DiscFerret uses "store and forward" acquisition. KryoFlux (AIUI) streams data directly to the PC. This means DiscFerret is slightly slower to read and write discs (by around 1 minute). * DiscFerret has more usable I/O lines, plus the 4-bit bidirectional High Speed I/O link (four pins which may be programmed for any purpose; GPIO, SPI, etc. and used for I/O expansion) * DiscFerret captures data at a much higher resolution (approx. 4x Kryoflux's peak rate, and twice the Mk4 Catweasel). This means you can image hard drives (ST506 type) and 2.88MB floppy discs, with suitable adapter cables. * DiscFerret has full support for both hard-sectored and soft-sectored media, including reading individual sectors. CW could do this too, AIUI. On the down side, DiscFerret is currently lacking in software. I have a tweaked version of CWTOOL which sort-of works with DFI images, but falls over quite a lot. Disc reading works, but writing needs work (mainly timing characterisation and modelling). The DiscFerret is no better. They're sold more or less at cost... -- Phil. philpem at philpem.me.uk http://www.philpem.me.uk/

On Tue, 2011-11-01 at 17:15 -0400, Steven Hirsch wrote: There's development code to do this with the DiscFerret. I've been holding off on releasing it because I wanted to do a "universal" (script based) version... at this point I'm tempted to abandon that and go with the C/C++ "recompile to add a new format" version. I do have a Northstar MFM codec, and a preliminary Layer 1 codec for Amiga discs (physical-layer en/dec only, no sector splitting or ADF writing). -- Phil. philpem at philpem.me.uk http://www.philpem.me.uk/

On 11/03/2011 07:16 AM, Philip Pemberton wrote: Sounds like a perfect application for loadable modules. -Dave -- Dave McGuire New Kensington, PA

On Nov 4, 2011, at 12:48 PM, Ray Arachelian wrote: Even without the JIT, it's plenty fast on modern machines. I think the primary benefit of Lua is that it's very easily embedded and extended, and it compiles very cleanly on quite a few platforms. It also has a pretty small memory footprint even with a reasonably complete standard library (which, for scripting disk format conversions, you could probably slim down), something that lot of "embeddable" scripting languages don't. Python is another option, though it's somewhat larger and more ponderous than Lua. For older machines, it may be wholly inappropriate. - Dave

I loved Lua on PalmOS. Plua was a joy to write apps in, but it came along too late. -- ------------------------------------ personal: http://www.cameronkaiser.com/ -- Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckaiser at floodgap.com -- Those wise enough to avoid politics are governed by those who aren't. ------

On 04/11/11 10:00 PM, Cameron Kaiser wrote: Here's one for Lua fans that I just stumbled on: "How the embeddability of Lua impacted its design" http://queue.acm.org/detail.cfm?id=1983083 --Toby

On 11/04/2011 04:32 PM, Mouse wrote: That would be an interesting idea. VMWare Tools uses a similar thing, if when the guest boots up it doesn't have the right modules for the current kernel, it will compile them at startup and load them. I'm not sure if it's necessary to have compilers in the kernel, it may make things more difficult and possibly dangerous in some ways. A JIT kernel module might work, but what would it buy over a userland JIT one? Or are you wanting a whole OS built from Lua?

On 4 Nov 2011 at 15:05, Cameron Kaiser wrote: At the expense of sounding like an old fuddy-duddy, who gives a rat's ass about a GUI or a scripting language for something like this? Without someone the stature of Bob Pease to back me up, I'll stick my foot into this thread at the expense of losing it by saying I've seen very few digital designs that could compete with a well adjusted analog PLL data separator and associated filters. --Chuck

At 09:23 PM 11/4/2011, Eric Smith wrote: After all, legacy media (and the equipment that made it) can have problems. Which method handles problems best? Are some problems (like misaligned tracks) only solvable by alternative reading hardware? - John