[cctalk] Re: Getting floppy images to/from real floppy disks.

2023-05-25 Thread Tony Duell via cctalk
> 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

2023-05-25 Thread John Robertson via cctalk

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&page=1&type=things&sort=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

2023-05-25 Thread Fred Cisin via cctalk

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

2023-05-25 Thread Sellam Abraham via cctalk
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.)

2023-05-25 Thread Paul Koning via cctalk



> 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

2023-05-25 Thread Chuck Guzis via cctalk
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

2023-05-25 Thread Peter Coghlan via cctalk
>
> 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.

2023-05-25 Thread Antonio Carlini via cctalk

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.

2023-05-25 Thread Christian Kennedy via cctalk


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

2023-05-25 Thread Tom Stepleton via cctalk
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.)

2023-05-25 Thread Christian Kennedy via cctalk



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.

2023-05-25 Thread Guy Sotomayor via cctalk



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.

2023-05-25 Thread Paul Koning via cctalk



> 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

2023-05-25 Thread Rob Jarratt via cctalk



> -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.

2023-05-25 Thread geneb via cctalk

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.

2023-05-25 Thread Paul Koning via cctalk



> 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.

2023-05-25 Thread Chuck Guzis via cctalk
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.

2023-05-25 Thread Chuck Guzis via cctalk
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.

2023-05-25 Thread Chuck Guzis via cctalk
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.

2023-05-25 Thread Will Cooke via cctalk



> 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.

2023-05-25 Thread Guy Sotomayor via cctalk



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.

2023-05-25 Thread Paul Koning via cctalk



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.

2023-05-25 Thread ben via cctalk

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.

2023-05-25 Thread Chuck Guzis via cctalk
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.

2023-05-25 Thread Guy Sotomayor via cctalk



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.

2023-05-25 Thread Mike Katz via cctalk

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

2023-05-25 Thread Jesse Dougherty via cctalk
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.

2023-05-25 Thread Chuck Guzis via cctalk
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.

2023-05-25 Thread Tony Duell via cctalk
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

2023-05-25 Thread Harten via cctalk
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.

2023-05-25 Thread Harten via cctalk
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


--