[cctalk] Re: Getting floppy images to/from real floppy disks.
> Would it be possible to build a small computer, 8088/8086 > just for this? > I don't see why not, but given the choice I'd pick just about any other processor family. Probably a 68000. -tony
[cctalk] Re: Recovering floppies attacked by mould
On 2023/05/25 5:11 p.m., Sellam Abraham via cctalk wrote: Tom, You may save yourself some time with this nifty contraption ==> https://www.ebay.com/itm/303620862566 It's a floppy disk cleaning apparatus. You place the floppy disk into the frame, apply your cleaning solution and cloth to the index opening, and then manually spin the disk. Sellam If you have a 3D printer then Thingiverse has 3.5 and 5.25 inch floppy cleaner files: https://www.thingiverse.com/search?q=floppy+disc+cleaner=1=things=relevant John :-#)# On Thu, May 25, 2023 at 3:36 PM Tom Stepleton via cctalk < cctalk@classiccmp.org> wrote: Greetings, Amidst all the floppy archiving discussion, here's a slightly different question: The weather is warmer now where I live, so it's starting to be a good time to do messy work outdoors. I have some mouldy floppy diskettes that I'd like to try to read (mostly 5.25"), plus a good flux reader. What is the best way to attempt to image these floppies? My thinking right now is that for each floppy I can attempt this procedure: - remove the mouldy cookie from the infected disk jacket; discard the latter - give the cookie the best clean I can (how?) and allow to dry - place the cookie in a clean disk jacket - attempt to image - clean floppy drive heads Does this seem like a sensible plan? If so, what would be the best way to clean as much mould off the cookie as I can? Tools that come to mind are distilled water (tap water here is full of chalk), dish soap, cyclomethicone, and of course more fearsome solvents. I have kimwipes, microfibre cloths, and... 200-grit sandpaper, I guess :-) Thanks for any advice, --Tom -- John's Jukes Ltd. 7 - 3979 Marine Way, Burnaby, BC, Canada V5J 5E3 Call (604)872-5757 (Pinballs, Jukes, Video Games) flippers.com "Old pinballers never die, they just flip out"
[cctalk] Re: Recovering floppies attacked by mould
On Thu, 25 May 2023, Sellam Abraham via cctalk wrote: Tom, You may save yourself some time with this nifty contraption ==> https://www.ebay.com/itm/303620862566 It's a floppy disk cleaning apparatus. You place the floppy disk into the frame, apply your cleaning solution and cloth to the index opening, and then manually spin the disk. It looks handy for mild cleaning, where the cookie doesn't need to be removed from the jacket. Some disks should be removed, and discard the old jacket, and not even put the disk into another jacket until it has had some cleaning. If leaving the disk in the jacket, . . . I have encountered plenty of 5.25" and 8" disks, where the disk doesn't turn freely. Rub the edge of the disk/jacket on a corner of a table, firmly enough that it is bowing SLIGHTLY. Do that for all four edges of the floppy jacket. The disk will now turn free-er. -- Grumpy Ol' Fred ci...@xenosoft.com
[cctalk] Re: Recovering floppies attacked by mould
Tom, You may save yourself some time with this nifty contraption ==> https://www.ebay.com/itm/303620862566 It's a floppy disk cleaning apparatus. You place the floppy disk into the frame, apply your cleaning solution and cloth to the index opening, and then manually spin the disk. Sellam On Thu, May 25, 2023 at 3:36 PM Tom Stepleton via cctalk < cctalk@classiccmp.org> wrote: > Greetings, > > Amidst all the floppy archiving discussion, here's a slightly different > question: > > The weather is warmer now where I live, so it's starting to be a good time > to do messy work outdoors. I have some mouldy floppy diskettes that I'd > like to try to read (mostly 5.25"), plus a good flux reader. What is the > best way to attempt to image these floppies? > > My thinking right now is that for each floppy I can attempt this procedure: > - remove the mouldy cookie from the infected disk jacket; discard the > latter > - give the cookie the best clean I can (how?) and allow to dry > - place the cookie in a clean disk jacket > - attempt to image > - clean floppy drive heads > > Does this seem like a sensible plan? If so, what would be the best way to > clean as much mould off the cookie as I can? Tools that come to mind are > distilled water (tap water here is full of chalk), dish soap, > cyclomethicone, and of course more fearsome solvents. I have kimwipes, > microfibre cloths, and... 200-grit sandpaper, I guess :-) > > Thanks for any advice, > --Tom >
[cctalk] Re: MCAS (was: Re: Getting floppy images to/from real floppy disks.)
> On May 25, 2023, at 6:29 PM, Christian Kennedy via cctalk > wrote: > > > On 5/25/23 12:30, Chuck Guzis via cctalk wrote: >> ...and we still get gems like the Boeing 737MAX... > > I get your point, but it's a bad example. MCAS worked precisely as > specified, and while one could have a discussion regarding if those > specifications were wrong, the logic was that a MCAS failure was > indistinguishable from any other 737 trim runaway and was to be handled in > the same fashion. Perhaps this is an example of Brooks' observation that most > bugs in software are in fact bugs in specification. I'm not sure that observation is true anymore, with the "hack it until it stops crashing" approach to software development that seems to have been brought to us by the PC and gaming culture. In my work (storage servers) I would from time to time see bug reports closed by the engineer as "works as designed". I would remind them that they are only permitted to say that if (a) the program matches the spec, AND (b) the spec is right. I would say "if you're not able to stand on a conference center stage and explain to an audience of 1000 customers why the spec is right, you can't use 'works as designed'. The bug may be in the spec rather than in the code, but it's still a bug. Fix it." paul
[cctalk] Re: Recovering floppies attacked by mould
On 5/25/23 15:35, Tom Stepleton via cctalk wrote: > Does this seem like a sensible plan? If so, what would be the best way to > clean as much mould off the cookie as I can? Tools that come to mind are > distilled water (tap water here is full of chalk), dish soap, > cyclomethicone, and of course more fearsome solvents. I have kimwipes, > microfibre cloths, and... 200-grit sandpaper, I guess :-) Sounds like a workable plan--I use distilled water and Kodak Photflo (a wetting agent), lint-free wipes and air-drying. I usually coat the cookie with a drop or two of cyclomethicone before reading, just as a precaution. --Chuck
[cctalk] Re: Rainbow H7842 PSU Fault
> > This evening I went to check Vstart for any oscillation. However, all of a > sudden, the current draw is down to 85mA and PWM has started working. I am > at a loss to explain it. I wondered if there might be a dry joint, but I > have tried a few light taps and shakes and it continues to work. Perhaps > your idea of some debris causing a short might explain it, otherwise I just > don't know. > This one is a real doozie :-( > > I am thinking I may put it back together and test with a light bulb in series. > Go for it. I can't think of anything else to suggest trying at the moment. Regards Peter.
[cctalk] Re: Getting floppy images to/from real floppy disks.
On 25/05/2023 19:47, Paul Koning via cctalk wrote: Not only that, but all correctly implemented GigE devices will fall back not just to 100 but also to 10 Mb/s. That's part of standards conformance, and from what I can tell even low cost devices like D-Link or Netgear do this. Yes, including half duplex mode. In ~1997 my ISP provided a Terajet 410 and that was very fussy about what it would talk to; I couldn't get it to talk to my PC or laptop at the time at 100MB/s ... in the end I just connected to it via a small DEChub at 10MB/s and it worked perfectly. Right now my motherboard has a 2.5GB/s ethernet port and it needed poking with ethtool to autonegotiate at 1Gbps with a TP-LINK TL-SG116. No idea why yet and I probably won't know until I have a chance to power both off and prod. So your statement about "correctly implemented GigE devices" is technically correct (the best kind of 'correct'!) but I have yet to be convinced that it's not describing the null set :-) Antonio -- Antonio Carlini anto...@acarlini.com
[cctalk] Re: ***SPAM*** Re: ***SPAM*** Re: Getting floppy images to/from real floppy disks.
On 5/25/23 13:38, geneb via cctalk wrote: That wasn't a software problem, that was a criminally cheap management problem - they deleted the comparator for the AoA indexer to save money. Yes, but probably not Boeing's. AoA disagree was an available option that most /airlines/ explicitly elected not to purchase. Part of the AD was requiring that system, plus limiting MCAS authority so that if you hadn't noticed the trim wheel whacking you in the side of the leg you at least couldn't get into a situation where it would take three people to overpower the combined trim and aeroloading forces, and notably, sim time to review trim runaway procedures. It's not reassuring how many crews got trim runaway wrong in the sim. AoA disagreement on the B737 is weird anyway. Each AoA sensor drives one half of the cockpit stall avoidance systems, so the way you typically tell that a sensor has failed is when the stick shaker on one side starts going nuts while the other one doesn't. Honestly, the biggest blame here probably belongs on the doorstep of Southwest. -- Christian Kennedy, Ph.D. ch...@mainecoon.com AF6AP | DB0692 | PG00029419 http://www.mainecoon.comPGP KeyID 108DAB97 PGP fingerprint: 4E99 10B6 7253 B048 6685 6CBC 55E1 20A3 108D AB97 "Mr. McKittrick, after careful consideration…"
[cctalk] Recovering floppies attacked by mould
Greetings, Amidst all the floppy archiving discussion, here's a slightly different question: The weather is warmer now where I live, so it's starting to be a good time to do messy work outdoors. I have some mouldy floppy diskettes that I'd like to try to read (mostly 5.25"), plus a good flux reader. What is the best way to attempt to image these floppies? My thinking right now is that for each floppy I can attempt this procedure: - remove the mouldy cookie from the infected disk jacket; discard the latter - give the cookie the best clean I can (how?) and allow to dry - place the cookie in a clean disk jacket - attempt to image - clean floppy drive heads Does this seem like a sensible plan? If so, what would be the best way to clean as much mould off the cookie as I can? Tools that come to mind are distilled water (tap water here is full of chalk), dish soap, cyclomethicone, and of course more fearsome solvents. I have kimwipes, microfibre cloths, and... 200-grit sandpaper, I guess :-) Thanks for any advice, --Tom
[cctalk] MCAS (was: Re: Re: ***SPAM*** Re: ***SPAM*** Re: Getting floppy images to/from real floppy disks.)
On 5/25/23 12:30, Chuck Guzis via cctalk wrote: ...and we still get gems like the Boeing 737MAX... I get your point, but it's a bad example. MCAS worked precisely as specified, and while one could have a discussion regarding if those specifications were wrong, the logic was that a MCAS failure was indistinguishable from any other 737 trim runaway and was to be handled in the same fashion. Perhaps this is an example of Brooks' observation that most bugs in software are in fact bugs in specification. I can even sorta understand the thought processes behind the specs. While there were two hull losses, there have been many, many, many more MCAS failures; the only time they resulted in holes in the ground is when the trim runaway procedures weren't followed -- that being a sort of sobering thought given that there are all sorts of other things that can lead to that happening beyond MCAS. -- Christian Kennedy, Ph.D. ch...@mainecoon.com AF6AP | DB0692 | PG00029419 http://www.mainecoon.comPGP KeyID 108DAB97 PGP fingerprint: 4E99 10B6 7253 B048 6685 6CBC 55E1 20A3 108D AB97 "Mr. McKittrick, after careful consideration…"
[cctalk] Re: Getting floppy images to/from real floppy disks.
On 5/25/23 13:21, Paul Koning via cctalk wrote: On May 25, 2023, at 3:30 PM, Chuck Guzis via cctalk wrote: On 5/25/23 10:06, Guy Sotomayor via cctalk wrote: The way SPARK works is that you have code and then can also provide proofs for the code. Proofs are you might expect are *hard* to write and in many cases are *huge* relative to the actual code (at least if you want a platinum level proof). ...and we still get gems like the Boeing 737MAX... --Chuck Yes. The problem is the gap between informal understanding and formal description. For many programmers, that gap occurs when the program source is created. If the programs are subjected to formal proofs, the gap occurs when the formal specs are written. So such things are largely a non-solution. They may help a little if the gap to the formal spec is smaller. If, as Guy is saying, the formal spec is larger than the code, then obviously that won't be the case. In our particular case, we spend about 10x developing all of the "safety" collateral (requirement docs, architecture docs, design docs, etc) than actually writing, debugging and testing the code. Part of the problem is that most of the automotive safety standards were developed for fairly simple use cases (1000s to a few 10's of 1000s lines of code). In our particular case, we're looking at 10's of millions of lines of code and we've discovered that a lot of the processes specified by the standards do not scale well to that level of code. :-/ Languages other than C and C++ have advantages in that they detect, or avoid, a whole lot of bugs that C/C++ ignore, like bounds violations or memory leaks. So Ada can be helpful in that some bugs are harder or impossible to create, or more likely to be detected in testing. But, in spite of having taken a very interesting week-long course on program proofs by pioneer E.W. Dijkstra, I don't actually believe in those things. I don't either. ;-) Proofs are *hard* and take a special way of thinking about the problem. For example, prove that a doubly linked list points only to elements allowed in the linked list (e.g. things that have only been placed on the list) and that the forward and backward pointers actually point to the elements they're supposed to...and that's one of the simpler things that needs to be proved. It gets *really* interesting when you try and prove that the scheduler is actually scheduling the way it's supposed to. :-/ The 737MAX is a classic example of designers turning off their brains before doing their work. It is obvious even to me (who have never created safety-sensitive software) that you don't attach systems with single points of failure such as non-replicated sensors to a control system whose specific purpose is to point the airplane nose DOWN. If you do your work with your brain disabled you can't produce correct software, with or without formal proofs. Yes, in self-driving cars we do "sensor fusion" which allows us to derive (and validate/replicate) data from various sensors. For example, we use cameras, LIDAR, etc to validate each other's data. The point is to not have a "single point of failure". -- TTFN - Guy
[cctalk] Re: ***SPAM*** Re: ***SPAM*** Re: Getting floppy images to/from real floppy disks.
> On May 25, 2023, at 4:38 PM, geneb via cctalk wrote: > > On Thu, 25 May 2023, Chuck Guzis via cctalk wrote: > >> On 5/25/23 10:06, Guy Sotomayor via cctalk wrote: >>> >> >>> The way SPARK works is that you have code and then can also provide >>> proofs for the code. Proofs are you might expect are *hard* to write >>> and in many cases are *huge* relative to the actual code (at least if >>> you want a platinum level proof). >> >> ...and we still get gems like the Boeing 737MAX... >> > That wasn't a software problem, that was a criminally cheap management > problem - they deleted the comparator for the AoA indexer to save money. So? We know managers often don't know engineering or reliability, that's why we have engineers. It's not just the job of the engineer to follow orders; it's also his job to make the right thing happen, and to complain if it isn't. Engineers keeping quiet has been a key contributor in many spectacular failures, from the 737 MAX to the two Space Shuttle failures. paul
[cctalk] Re: Rainbow H7842 PSU Fault
> -Original Message- > From: Peter Coghlan via cctalk > Sent: 20 May 2023 09:20 > To: 'General Discussion: On-Topic and Off-Topic Posts' > > Cc: Peter Coghlan > Subject: [cctalk] Re: Rainbow H7842 PSU Fault > > > > Ok, it looks like there is not a severe leak from the -12V line to ground > then. > > I am puzzled by the extra current draw on Vstart by the bad PSU but I'm not > sure that tracking this down would lead us to the real problem. > > On the other hand, did you mention at one point that Vstart was varying? > If this is the case, the reason for this would probably need to be found and > fixed independent of whether it leads to finding the main problem as this is > supposed to be a stable supply. > > I don't think there is likely to be any serious leakage via E1b because the > link > to the -12V line is via a 75K resistor which would limit any leakage current > to > roughly 160uA. Of course this applies if the resistor really is 75K and > doesn't > have carbon deposits bridging the tracks and connections around it to > somewhere else. > > I would suggest looking carefully at the resistors around E3d to make sure > they have the correct values, especially the 360K resistor and making sure > there is no debris etc around these components that could be bridging any > connections associated with them to somewhere else, also that no > connections have been severed. Problems here could be leading to E3d > falsely triggering when there is no real overload. > > It might be useful to check the voltages and resistor values in the -12V > regulator and compare with same in the good power supply, especially the > voltage across the zener diode. > > > > > > > Is this the same PSU whose chopper transistor exploded a while back? > > > Could there be any carbon deposits remaining on the board or > > > conductive remnants wedged under components etc causing leakage > from > > > the -12V line to ground? > > > > The component nearest to the exploded transistor is the 10uF capacitor > > on the output of the 12V regulator. There are some carbon deposits on > > it. I did a cursory check for resistance and ESR and it seemed OK. > > > > This capacitor is probably there to ensure the 7812 doesn't oscillate. > Looking > at Vstart with an oscilloscope should confirm that this is not an issue. If > it > doesn't have excessive leakage current and has approximately the correct > capacitance, it is probably ok. However, if there is gunk trapped underneath > it around the leads, this might account for the extra current draw on Vstart. > > The explosion could have had other bad effects. Maybe E3 got damaged by a > surge in its power supply when the transistor blew up? Maybe the -12V > rectifier was affected? It is probably not as robust as the rectifiers for > the > other lines and the chopper transistor shorting would have likely caused a > big current pulse in the chopper transformer primary, leading in turn to > surges at it's secondaries. Also the diode in parallel with the 51R sense > resistor might be suspect. > > I'm not sure how to test these components comprehensively without trying > replacements for them. > > If the 7812 was damaged at the time of the explosion, other components > powered from Vstart could have experienced surges as well. Maybe stuff on > the input side of the 7812 too? > This evening I went to check Vstart for any oscillation. However, all of a sudden, the current draw is down to 85mA and PWM has started working. I am at a loss to explain it. I wondered if there might be a dry joint, but I have tried a few light taps and shakes and it continues to work. Perhaps your idea of some debris causing a short might explain it, otherwise I just don't know. I am thinking I may put it back together and test with a light bulb in series. Regards Rob
[cctalk] Re: ***SPAM*** Re: ***SPAM*** Re: Getting floppy images to/from real floppy disks.
On Thu, 25 May 2023, Chuck Guzis via cctalk wrote: On 5/25/23 10:06, Guy Sotomayor via cctalk wrote: The way SPARK works is that you have code and then can also provide proofs for the code. Proofs are you might expect are *hard* to write and in many cases are *huge* relative to the actual code (at least if you want a platinum level proof). ...and we still get gems like the Boeing 737MAX... That wasn't a software problem, that was a criminally cheap management problem - they deleted the comparator for the AoA indexer to save money. 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://scarlet.deltasoft.com - Get it _today_!
[cctalk] Re: Getting floppy images to/from real floppy disks.
> On May 25, 2023, at 3:30 PM, Chuck Guzis via cctalk > wrote: > > On 5/25/23 10:06, Guy Sotomayor via cctalk wrote: >> > >> The way SPARK works is that you have code and then can also provide >> proofs for the code. Proofs are you might expect are *hard* to write >> and in many cases are *huge* relative to the actual code (at least if >> you want a platinum level proof). > > ...and we still get gems like the Boeing 737MAX... > > --Chuck Yes. The problem is the gap between informal understanding and formal description. For many programmers, that gap occurs when the program source is created. If the programs are subjected to formal proofs, the gap occurs when the formal specs are written. So such things are largely a non-solution. They may help a little if the gap to the formal spec is smaller. If, as Guy is saying, the formal spec is larger than the code, then obviously that won't be the case. Languages other than C and C++ have advantages in that they detect, or avoid, a whole lot of bugs that C/C++ ignore, like bounds violations or memory leaks. So Ada can be helpful in that some bugs are harder or impossible to create, or more likely to be detected in testing. But, in spite of having taken a very interesting week-long course on program proofs by pioneer E.W. Dijkstra, I don't actually believe in those things. The 737MAX is a classic example of designers turning off their brains before doing their work. It is obvious even to me (who have never created safety-sensitive software) that you don't attach systems with single points of failure such as non-replicated sensors to a control system whose specific purpose is to point the airplane nose DOWN. If you do your work with your brain disabled you can't produce correct software, with or without formal proofs. paul
[cctalk] Re: ***SPAM*** Re: ***SPAM*** Re: Getting floppy images to/from real floppy disks.
Just wondering what's marking Guy's posts with ***SPAM***. It's beginning to look like a Monty Python sketch. --Chuck
[cctalk] Re: Getting floppy images to/from real floppy disks.
On 5/25/23 12:13, Will Cooke via cctalk wrote: > Eclipse is a a java dog and keeping it up to date between versions is a pain, > but in my experience the benefits Mike mentioned are well worth it. For an editor, I use Joe--available on platforms from MSDOS to Linux X64 as well as Windows. It's basically a re-hash of WordStar, which goes way back to the 8080 CP/M days. Of course, current Joe knows some C syntax, does correct highlighting, etc. About 40 years ago, I used emacs with the electric-C addon. It was okay. I still code my makefiles by hand. --Chuck
[cctalk] Re: ***SPAM*** Re: ***SPAM*** Re: Getting floppy images to/from real floppy disks.
On 5/25/23 10:06, Guy Sotomayor via cctalk wrote: > > The way SPARK works is that you have code and then can also provide > proofs for the code. Proofs are you might expect are *hard* to write > and in many cases are *huge* relative to the actual code (at least if > you want a platinum level proof). ...and we still get gems like the Boeing 737MAX... --Chuck
[cctalk] Re: Getting floppy images to/from real floppy disks.
> On 05/25/2023 11:13 AM CDT Mike Katz via cctalk wrote: > > > Chuck, > > I agree with you that well written and commented C is the way to go. > > The advantage to an IDE comes with debugging and easy access symbols and > variables. > Some IDEs can be convinced to use standard makefiles. I have used Eclipse that way. So you still have fully buildable (and maintainable) code should an "upgrade" break stuff or the tool becomes unavailable. Eclipse is a a java dog and keeping it up to date between versions is a pain, but in my experience the benefits Mike mentioned are well worth it. Will
[cctalk] Re: ***SPAM*** Re: ***SPAM*** Re: Getting floppy images to/from real floppy disks.
On 5/25/23 10:00, Chuck Guzis via cctalk wrote: On 5/25/23 08:58, Guy Sotomayor via cctalk wrote: ADA and SPARK (a stripped down version of ADA) are used heavily in embedded that has to be "safety certified". SPARK also allows the code to be "proven" (as in you can write formal proofs to ensure that the code does what you say it does). Ask me how I know. ;-) I was aware of Ada's requirements in the defense- and aerospace-related industry. Is that where your experience lies? Is SPARK the "magic bullet" that's been searched for decades to write provably correct code? I'm familiar with it from the higher end automotive perspective (self-driving cars). Even when using C/C++ we have *lots* of standards that we have to adhere to (MISRA, CERT-C, ISO-26262, etc). The way SPARK works is that you have code and then can also provide proofs for the code. Proofs are you might expect are *hard* to write and in many cases are *huge* relative to the actual code (at least if you want a platinum level proof). -- TTFN - Guy
[cctalk] Re: Getting floppy images to/from real floppy disks.
On 2023-05-25 5:52 a.m., Tony Duell via cctalk wrote: > ... > It is not unheard-of for classic PCs -- even ISAbus ones -- to have > 10Mbps ethernet. Most, if not all, 100Mbps ethernet ports will fall > back to that. Not only that, but all correctly implemented GigE devices will fall back not just to 100 but also to 10 Mb/s. That's part of standards conformance, and from what I can tell even low cost devices like D-Link or Netgear do this. Yes, including half duplex mode. paul
[cctalk] Re: Getting floppy images to/from real floppy disks.
On 2023-05-25 5:52 a.m., Tony Duell via cctalk wrote: On Thu, May 25, 2023 at 1:54 AM Mike Stein via cctalk wrote: I realize he's a bit eccentric, (even more so than many of us ;-) ), but I I am not 'a bit eccentric'. There is absolutely nothing mild about my eccentricities! But it sounds like he'll explore one of the flux-transition gizmos; good luck, Tony, and I hope you enjoy the experience! I've got a Greaseweazle V4 now. I haven't got the software working yet and I am treading carefully as an early attempt managed to mangle the drivers for my USB-RS232 cable which I depend on for a lot of work but I suspect I will get it working in the end and it will do what I need. At least it's open-source so I can read the software source code (maybe I'll have to learn Python). And I have schematics. What is odd is how many things were _not_ suggested. For example : A RPi can read files off a USB stick. Hang a floppy controller chip, possibly with buffer RAM, off the user port connector of one of those. Come up with a parallel interface between an RPi user port and ISAbus. Use that to transfer the disk images to a classic PC and go from there. It is not unheard-of for classic PCs -- even ISAbus ones -- to have 10Mbps ethernet. Most, if not all, 100Mbps ethernet ports will fall back to that. So use that to transfer the disk image. A disk image is almost certainly less than a megabyte for a classic machine, so it won't take long. USB interfacing is hard, but SD cards are a lot simpler. So use a card reader thing to transfer the files to an SD card and design an interface for that to ISA bus. CF cards are essentially the same interface as PATA (IDE) disk drives. Go from there. Just about any of those would have been easier and more likely to use bits from my junk box/computer collection than trying to get an old, but not too old, PC -tony Would it be possible to build a small computer, 8088/8086 just for this?
[cctalk] Re: ***SPAM*** Re: Getting floppy images to/from real floppy disks.
On 5/25/23 08:58, Guy Sotomayor via cctalk wrote: > > ADA and SPARK (a stripped down version of ADA) are used heavily in > embedded that has to be "safety certified". SPARK also allows the code > to be "proven" (as in you can write formal proofs to ensure that the > code does what you say it does). Ask me how I know. ;-) I was aware of Ada's requirements in the defense- and aerospace-related industry. Is that where your experience lies? Is SPARK the "magic bullet" that's been searched for decades to write provably correct code? Now, let's hear from the Nim, Zig...etc. enthusiasts. There's a YT video that claims that Zig code execution is faster than assembly. Exactly how does that work? --Chuck
[cctalk] Re: ***SPAM*** Re: Getting floppy images to/from real floppy disks.
On 5/25/23 07:55, Chuck Guzis via cctalk wrote: On 5/25/23 04:52, Tony Duell via cctalk wrote: For the programming language, I stick with C, not C++, not Python and plain old makefiles--that's what the support libraries are written in. I don't use an IDE, lest I become reliant on one--a text editor will do. I document the heck out of code. Over the 50 or so years that I've been cranking out gibberish, it's nice to go back to code that I wrote 30 or 40 years ago and still be able to read it. That's basically what I do too. It's too easy to get stuck with an unsupported environment. A text editor and makefiles mean that I can (generally) port my code over to any new environment fairly easily. I'm all too aware of the changing trends in the industry--and how quickly they can change. I remember when there was a push in embedded coding not long ago to use Ada--where is that today? ADA and SPARK (a stripped down version of ADA) are used heavily in embedded that has to be "safety certified". SPARK also allows the code to be "proven" (as in you can write formal proofs to ensure that the code does what you say it does). Ask me how I know. ;-) -- TTFN - Guy
[cctalk] Re: Getting floppy images to/from real floppy disks.
Chuck, I agree with you that well written and commented C is the way to go. The advantage to an IDE comes with debugging and easy access symbols and variables. I worked for Software Development Systems working on their Freeform (text based) and Single Step (windows based) debuggers. Which gave me an up close experience with both types of interfaces. Over the years I have used printf and blinking LEDs for debugging but the ability to put breakpoints and watchpoints in code is immeasurable. I have used GCC/GDB and command line debuggers and yes typing "bp 0x1234 -r 6 -h" works quite well, however, double clicking on a line also works quite well and can be a little faster/easier to use. Hover over a variable to get it's value is also very convenient. This is similar to the model editor (Vi) vs non-modal editor (emacs, brief) debate. It comes down to personal preference. I have been programing since 1972 and have worked on all types of systems, compilers, assemblers, editors, IDE's, emulators, etc. And, over the years, I have found what works best for me (for example, I have been using the brief editor keyboard layout for over 30 years) and that works best for me. However, I have gone from simple assemblers without any debugging at all to full IDE's and TBH, for me, I find the IDE easier to use than command line debugging tools. The auto make generation that comes with IDE's is quite nice also. I will admit to using gcc/gdb for simple C code development without leaving the slickedit environment. Mike On 5/25/2023 9:55 AM, Chuck Guzis via cctalk wrote: On 5/25/23 04:52, Tony Duell via cctalk wrote: USB interfacing is hard, but SD cards are a lot simpler. So use a card reader thing to transfer the files to an SD card and design an interface for that to ISA bus. That's my approach with my own setups. 32GB SD cards are very inexpensive and quite fast. So, rather than depend on a USB interface to transfer data real-time to a PC, I use the SD card as intermediate storage, later transferring the data off using either a card reader or YModem-1K via serial port or USB. The side benefit is that the SD card is large enough that I'll have a hard time filling it with things like floppy images over the next few years--so I've got an automatic backup. USB (or serial) is used mostly for commands and status (TTY emulator) and can be run from a cheap tablet. The MCU I use does have ethernet support, but I've found that to be unnecessary--the data volume isn't that great. For the programming language, I stick with C, not C++, not Python and plain old makefiles--that's what the support libraries are written in. I don't use an IDE, lest I become reliant on one--a text editor will do. I document the heck out of code. Over the 50 or so years that I've been cranking out gibberish, it's nice to go back to code that I wrote 30 or 40 years ago and still be able to read it. I'm all too aware of the changing trends in the industry--and how quickly they can change. I remember when there was a push in embedded coding not long ago to use Ada--where is that today? It's not that I resist technological change--I can and have written C++ and Python (what version?). On my desk sits a MicroPy board. I look forward to advances in technology, but I'm also aware of how "bleeding edge" trends can wither and get lost almost overnight. How many of you program in Zig? I imagine that in about 5 years, the main conversation will be about using an AI to write code. Of course, there will be a new language to instruct the AI... --Chuck
[cctalk] HP 1000 A400, A600, A700, A900, A990 Servers, parts, & accessories
Hi all, we are getting overstocked on the 1000 series stuff and wanted to see if anyone needed anything. We have most everything you could have in the 1000 A-series hardware. If anyone needs any loaded up A990 boxes we have a bunch of them configured below for $1,400.00 A990 Server 14-slot Micro 1000 Server 1 x 12990x A990 CPU 1 x 12221B 8MB Memory 1 x C2247A 1GB SE SCSI Internal disk drive 1 x C150xx DDS DAT Internal Tape Drive 1 x 12016A SCSI Controller board 1 x 12009A HP-IB Interface board 1 x 12005A Serial Interface board 1 x 12006A Parallel interface board 1 x 12040A Asynchronous Multiplexer Interface (MUX) board 1 x 02430x Voltage Jumper Board 1 x 12230A Front-plane memory connector (CPU to memory connector) Feel free to email if you need any HP 1000 hardware. Thanks Jesse Dougherty Cypress Technology Inc je...@cypress-tech.com
[cctalk] Re: Getting floppy images to/from real floppy disks.
On 5/25/23 04:52, Tony Duell via cctalk wrote: > USB interfacing is hard, but SD cards are a lot simpler. So use a card > reader thing to transfer the files to an SD card and design an > interface for that to ISA bus. That's my approach with my own setups. 32GB SD cards are very inexpensive and quite fast. So, rather than depend on a USB interface to transfer data real-time to a PC, I use the SD card as intermediate storage, later transferring the data off using either a card reader or YModem-1K via serial port or USB. The side benefit is that the SD card is large enough that I'll have a hard time filling it with things like floppy images over the next few years--so I've got an automatic backup. USB (or serial) is used mostly for commands and status (TTY emulator) and can be run from a cheap tablet. The MCU I use does have ethernet support, but I've found that to be unnecessary--the data volume isn't that great. For the programming language, I stick with C, not C++, not Python and plain old makefiles--that's what the support libraries are written in. I don't use an IDE, lest I become reliant on one--a text editor will do. I document the heck out of code. Over the 50 or so years that I've been cranking out gibberish, it's nice to go back to code that I wrote 30 or 40 years ago and still be able to read it. I'm all too aware of the changing trends in the industry--and how quickly they can change. I remember when there was a push in embedded coding not long ago to use Ada--where is that today? It's not that I resist technological change--I can and have written C++ and Python (what version?). On my desk sits a MicroPy board. I look forward to advances in technology, but I'm also aware of how "bleeding edge" trends can wither and get lost almost overnight. How many of you program in Zig? I imagine that in about 5 years, the main conversation will be about using an AI to write code. Of course, there will be a new language to instruct the AI... --Chuck
[cctalk] Re: Getting floppy images to/from real floppy disks.
On Thu, May 25, 2023 at 1:54 AM Mike Stein via cctalk wrote: > > I realize he's a bit eccentric, (even more so than many of us ;-) ), but I I am not 'a bit eccentric'. There is absolutely nothing mild about my eccentricities! > But it sounds like he'll explore one of the flux-transition gizmos; good > luck, Tony, and I hope you enjoy the experience! I've got a Greaseweazle V4 now. I haven't got the software working yet and I am treading carefully as an early attempt managed to mangle the drivers for my USB-RS232 cable which I depend on for a lot of work but I suspect I will get it working in the end and it will do what I need. At least it's open-source so I can read the software source code (maybe I'll have to learn Python). And I have schematics. What is odd is how many things were _not_ suggested. For example : A RPi can read files off a USB stick. Hang a floppy controller chip, possibly with buffer RAM, off the user port connector of one of those. Come up with a parallel interface between an RPi user port and ISAbus. Use that to transfer the disk images to a classic PC and go from there. It is not unheard-of for classic PCs -- even ISAbus ones -- to have 10Mbps ethernet. Most, if not all, 100Mbps ethernet ports will fall back to that. So use that to transfer the disk image. A disk image is almost certainly less than a megabyte for a classic machine, so it won't take long. USB interfacing is hard, but SD cards are a lot simpler. So use a card reader thing to transfer the files to an SD card and design an interface for that to ISA bus. CF cards are essentially the same interface as PATA (IDE) disk drives. Go from there. Just about any of those would have been easier and more likely to use bits from my junk box/computer collection than trying to get an old, but not too old, PC -tony
[cctalk] Rexon 30 aka CMC 7030 information needed
Recently i digged out a system called Rexon 30, which was sold in germany/europe as a CMC 7030. The OS called RECAP BB was stored on a combined hard/removeable disk drive. There is no floppy or tapedrive at all. BB stands for a version of Business-Basic. The removeable pack got lost but there is a little hope that the OS is still on the fixed disc. There will be a lot of work for me before i can try to power up this system again. Maybe it never will. If anyone has information and/or software stored for this system, i would be glad if he/she can part it with me. Rolf --
[cctalk] Re: Getting floppy images to/from real floppy disks.
In message Mike Stein via cctalk wrote: > I realize he's a bit eccentric, (even more so than many of us ;-) ), but I > think we're being a little hard on Tony, especially considering the many > contributions he's made to our hobby over the years with reverse-engineered > schematics and other obscure documentation. > > If there weren't so much water between us I'd happily drop off a small > form-factor vintage PC that'd probably serve to extract/archive/whatever > numerous diskette formats with the various format conversion programs of > the day. > > But it sounds like he'll explore one of the flux-transition gizmos; good > luck, Tony, and I hope you enjoy the experience! > > m > I also looked for a unique way to preserve data from old floppies. By now my equipment has grown and grown. Two old PC/ATs with different operating systems and different controlers incl. one catweasel MK4. Beside this stands a separate housing with different floppy drives and own power supply. For softsectored floppies that is enough gear, but meanwhile i came across some hardsectored ones. I bought a kryoflux with little, not to say no success on hardsecored disks. Now i have the Fluxteen here and i support the developer where i can. We managed writing hardsectored floppy for the Smaky 6, a swiss made computer. Things are going on if we all support him. At the moment he is implementing Apple II formats. I think this system a worth a closer look. Rolf --
