[Coco] Re: reissue of Tandy's Little Wonder -- schematics needed

farna at att.net farna at att.net
Tue Feb 7 21:26:20 EST 2006


Specifically, I need schematics of all CoCo models except the CoCo3 (I was supplied that!), the MPI, and any disk drive controllers. If you don't have the ability to scan as a high res file (either TIF or JPG, 200 dpi grey scale is good) but have a hard copy you can copy, please drop me an e-mail for a mailing address. If you only have one or two of the above that will be just fine! 

--
Frank Swygert
Publisher, "American Independent 
Magazine" (AIM)
For all AMC enthusiasts
http://farna.home.att.net/AIM.html
(free download available!)

 -------------- Original message ----------------------
From: coco-request at maltedmedia.com
> Send Coco mailing list submissions to
> 	coco at maltedmedia.com
> 
> To subscribe or unsubscribe via the World Wide Web, visit
> 	http://five.pairlist.net/mailman/listinfo/coco
> or, via email, send a message with subject or body 'help' to
> 	coco-request at maltedmedia.com
> 
> You can reach the person managing the list at
> 	coco-owner at maltedmedia.com
> 
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Coco digest..."
> 
> 
> Today's Topics:
> 
>    1. Re: Ben (Benoit Bleau) still	here?
>       QuestionsconcerningOmniDisk/OmniFlop (Torsten Dittel)
>    2. Questions concerning OmniDisk/OmniFlop (Benoit Bleau)
>    3. Re: Re: Help needed: problems with RETRIEV(E)ing DSK images
>       (Alex Evans)
>    4. [Color Computer] 68881/68882 & the CoCo (Mike Pepe)
>    5. Re: Minesweeper (Mark McDougall)
>    6. Re: Re: Help needed: problems with RETRIEV(E)ing DSK images
>       (Ward Griffiths)
>    7. Re: Minesweeper (Mark McDougall)
>    8. Re: Minesweeper (Robert Gault)
>    9. Re: Minesweeper (Ward Griffiths)
>   10. Re: Minesweeper (Diego Barizo)
> 
> 
> ----------------------------------------------------------------------
> 
> Message: 1
> Date: Tue, 07 Feb 2006 01:55:39 +0100
> From: Torsten Dittel <Torsten at Dittel.info>
> Subject: [Coco] Re: Ben (Benoit Bleau) still	here?
> 	QuestionsconcerningOmniDisk/OmniFlop
> To: coco at maltedmedia.com
> Message-ID: <43E7F00B.37724699 at Dittel.info>
> Content-Type: text/plain; charset=us-ascii
> 
> > I will let the list know how it goes.
> 
> Great! Maybe renaming the OmniFlop files to "*.DSK" will just work...
> CU l8r
> Torsten
> 
> 
> 
> ------------------------------
> 
> Message: 2
> Date: Mon, 06 Feb 2006 19:56:35 -0500
> From: Benoit Bleau <benbleau at gmail.com>
> Subject: [Coco] Questions concerning OmniDisk/OmniFlop
> To: CoCoList for Color Computer Enthusiasts <coco at maltedmedia.com>
> Message-ID: <43E7F043.3060701 at gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
> 
> Torsten Dittel wrote:
> >> I will let the list know how it goes.
> >>     
> >
> > Great! Maybe renaming the OmniFlop files to "*.DSK" will just work...
> > CU l8r
> > Torsten
> >
> >
> >   
> Yes, that's what I did. and rename them to .os9 for OS9 disks.
> 
> --
> Ben
> 
> 
> ------------------------------
> 
> Message: 3
> Date: Mon, 6 Feb 2006 15:53:40 -1000
> From: Alex Evans <alxevans at concentric.net>
> Subject: Re: [Coco] Re: Help needed: problems with RETRIEV(E)ing DSK
> 	images
> To: CoCoList for Color Computer Enthusiasts <coco at maltedmedia.com>
> Message-ID: <2126410B-FBF1-484A-9757-A10E875D5B09 at concentric.net>
> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
> 
> 
> On Feb 6, 2006, at 1:02 PM, Phill Harvey-Smith wrote:
> 
> > Ward Griffiths wrote:
> >> The only difference between low-density and high-density (or SS  
> >> and DS for
> >
> > Do you mean Single and Double density, I think Single and double  
> > sided is determined by the number of heads in the drive :)
> 
> Actually he is talking about the difference in the data clock.   
> Single and double density are actually encoded differently (FM vs  
> MFM), but double (low) and (double) high density differ by the data  
> rate, even the 2.88 M 3.5" floppies use the same encoding scheme, but  
> at a higher data rate.
> 
> 
> 
> 
> ------------------------------
> 
> Message: 4
> Date: Mon, 06 Feb 2006 22:07:29 -0500
> From: Mike Pepe <lamune at doki-doki.net>
> Subject: [Coco] [Color Computer] 68881/68882 & the CoCo
> To: ColorComputer at yahoogroups.com
> Message-ID: <43E80EF1.1020409 at doki-doki.net>
> Content-Type: text/plain; charset=ISO-8859-1
> 
> I've got a couple of Motorola FPU's in my stash here.
> 
> In looking at the manuals, it seems that interfacing the FPU to the CoCo 
> is pretty straightforward. It takes 32 addresses, so it would be a good 
> candidate for the MPI and switching the whole $FF40-$FF5F SCS address range.
> 
> Anyone ever do this before? I'm sure it's been done.
> 
> -Mike
> 
> 
> Brought to you by the 6809, the 6803 and their cousins! 
> Yahoo! Groups Links
> 
> <*> To visit your group on the web, go to:
>     http://groups.yahoo.com/group/ColorComputer/
> 
> <*> To unsubscribe from this group, send an email to:
>     ColorComputer-unsubscribe at yahoogroups.com
> 
> <*> Your use of Yahoo! Groups is subject to:
>     http://docs.yahoo.com/info/terms/
>  
> 
> 
> 
> 
> ------------------------------
> 
> Message: 5
> Date: Tue, 07 Feb 2006 14:18:47 +1100
> From: Mark McDougall <msmcdoug at iinet.net.au>
> Subject: Re: [Coco] Minesweeper
> To: CoCoList for Color Computer Enthusiasts <coco at maltedmedia.com>
> Message-ID: <43E81197.6000804 at iinet.net.au>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
> 
> Arthur Flexser wrote:
> 
> > An interesting mathematical problem, more or less equivalent to
> > finding a formula for the expected number of dart throws when there
> > are N squares and i darts, and a dart must be rethrown if it hits a
> > square already occupied by another dart. Any takers?
> 
> I can think of one approach. Place the numbers from 1 to 338 in an 
> array. Choose a random number from 1-338 and that's your first number. 
> Then remove that number from the array by shifting all the numbers above 
> that down 1 space in the array. Then generate a random number from 
> 1-337. And so on...
> 
> Trouble is, shifting numbers takes time, although one can use mempcy for 
> example. But at least it's deterministic and order N, unlike re-throwing 
> 'darts' as your remaining squares diminish.
> 
> The other problem is getting the random number in the correct range in 
> the first place. One solution is to use the modulus of a very large 
> random number. As long as the number is large enough (eg. 32 bits), it 
> shouldn't affect the uniform distribution too much.
> 
> Regards,
> Mark
> 
> 
> 
> ------------------------------
> 
> Message: 6
> Date: Mon, 6 Feb 2006 22:20:29 -0500
> From: Ward Griffiths <wdg3rd at comcast.net>
> Subject: Re: [Coco] Re: Help needed: problems with RETRIEV(E)ing DSK
> 	images
> To: CoCoList for Color Computer Enthusiasts <coco at maltedmedia.com>
> Message-ID: <200602062220.29896.wdg3rd at comcast.net>
> Content-Type: text/plain;  charset="iso-8859-1"
> 
> On 02/06/2006 08:53 pm, Alex Evans wrote:
> > On Feb 6, 2006, at 1:02 PM, Phill Harvey-Smith wrote:
> > > Ward Griffiths wrote:
> > >> The only difference between low-density and high-density (or SS
> > >> and DS for
> > >
> > > Do you mean Single and Double density, I think Single and double
> > > sided is determined by the number of heads in the drive :)
> >
> > Actually he is talking about the difference in the data clock.
> > Single and double density are actually encoded differently (FM vs
> > MFM), but double (low) and (double) high density differ by the data
> > rate, even the 2.88 M 3.5" floppies use the same encoding scheme, but
> > at a higher data rate.
> 
> No, I was talking about telling the media apart.  There is no definite visual 
> or manual method of distinguishing between the various types of 5.25" media, 
> unless the disk jacket has a label put there by the manufacturer that hasn't 
> peeled off or been covered up over the past couple of decades.
> 
> Well, there _is_ hard-sectored media, and that's always low-density, but I 
> haven't seen a hard-sectored 5.25" floppy since 1981.
> -- 
> Ward Griffiths    wdg3rd at comcast.net
> 
> I think boys might benefit from owning a Barbie doll; every young man
> should understand what an expensive proposition it is to cohabitate with
> a narcissistic woman built like a stripper.  --  Tony Woodlief
> 
> 
> ------------------------------
> 
> Message: 7
> Date: Tue, 07 Feb 2006 14:50:16 +1100
> From: Mark McDougall <msmcdoug at iinet.net.au>
> Subject: Re: [Coco] Minesweeper
> To: CoCoList for Color Computer Enthusiasts <coco at maltedmedia.com>
> Message-ID: <43E818F8.1030907 at iinet.net.au>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
> 
> Mark McDougall wrote:
> 
> > Trouble is, shifting numbers takes time, although one can use mempcy for 
> > example. But at least it's deterministic and order N, unlike re-throwing 
> > 'darts' as your remaining squares diminish.
> 
> Actually, now that I've had a few more minutes to think about it...
> 
> You wouldn't actually need to store the numbers in an array. When you 
> generate a new number, you only need to know how many numbers already 
> chosen are numerically less than or equal to that number, and add that 
> count to get the actual value you'll use.
> 
> So you need only to keep a (sorted?) list of numbers already chosen.
> 
> For example, suppose the 1st number is 42. Store that in the list. The 
> 2nd random number generated is 6. Since there are no chosen numbers 
> below that, store 6 in the list. The 3rd random number is 78. Since we 
> already have 2 numbers in the list below 78, we add 2 and store 80 as 
> our 3rd number (since 80 would've been shifted down twice in our array).
> 
> Obviously, as the list length increases it takes longer to count the 
> entries below the random number, but there are ways to speed the search, 
> such as storing sorted lists, trees and/or using binary chop etc. But at 
> some point, it's going to be quicker to use an array as I first 
> suggested. It all depends on your worst-case scenario.
> 
> Regards,
> Mark
> 
> 
> 
> ------------------------------
> 
> Message: 8
> Date: Mon, 06 Feb 2006 23:15:19 -0500
> From: Robert Gault <robert.gault at worldnet.att.net>
> Subject: Re: [Coco] Minesweeper
> To: CoCoList for Color Computer Enthusiasts <coco at maltedmedia.com>
> Message-ID: <43E81ED7.5060108 at worldnet.att.net>
> Content-Type: text/plain; charset=us-ascii; format=flowed
> 
> That is exactly what I tried, but shifting the numbers is indeed much 
> too slow. This method in Basic takes about 40 seconds, while the dart 
> throw method takes about 5.
> 
> However, if the setup was written in assembly, then I think this might 
> be faster than the dart throw. That would not, however, be a fair 
> critique of Diego's program.
> 
> Mark McDougall wrote:
> > Arthur Flexser wrote:
> > 
> >> An interesting mathematical problem, more or less equivalent to
> >> finding a formula for the expected number of dart throws when there
> >> are N squares and i darts, and a dart must be rethrown if it hits a
> >> square already occupied by another dart. Any takers?
> > 
> > 
> > I can think of one approach. Place the numbers from 1 to 338 in an 
> > array. Choose a random number from 1-338 and that's your first number. 
> > Then remove that number from the array by shifting all the numbers above 
> > that down 1 space in the array. Then generate a random number from 
> > 1-337. And so on...
> > 
> > Trouble is, shifting numbers takes time, although one can use mempcy for 
> > example. But at least it's deterministic and order N, unlike re-throwing 
> > 'darts' as your remaining squares diminish.
> > 
> > The other problem is getting the random number in the correct range in 
> > the first place. One solution is to use the modulus of a very large 
> > random number. As long as the number is large enough (eg. 32 bits), it 
> > shouldn't affect the uniform distribution too much.
> > 
> > Regards,
> > Mark
> > 
> > 
> 
> 
> ------------------------------
> 
> Message: 9
> Date: Mon, 6 Feb 2006 23:15:42 -0500
> From: Ward Griffiths <wdg3rd at comcast.net>
> Subject: Re: [Coco] Minesweeper
> To: CoCoList for Color Computer Enthusiasts <coco at maltedmedia.com>
> Message-ID: <200602062315.42889.wdg3rd at comcast.net>
> Content-Type: text/plain;  charset="iso-8859-1"
> 
> On 02/06/2006 07:23 pm, Arthur Flexser wrote:
> 
> > An interesting mathematical problem, more or less equivalent to finding a
> > formula for the expected number of dart throws when there are N squares and
> > i darts, and a dart must be rethrown if it hits a square already occupied
> > by another dart. Any takers?
> 
> I recall an assignment like that in my first BASIC course (on an HP) when I 
> was fresh out of the USAF in '78.  Populate a linear array with values equal 
> to the locations.  Randomly swap elements until you get tired.  Put a dart in 
> the coordinates represented by the first i elements.
> 
> DIM B(338)
> FOR E=1 to 338
> B(E)=E
> NEXT E
> FOR L=1 TO 32767
> I=RND(338)
> J=RND(338)
> T=B(I)
> B(I)=B(J)
> B(J)=T
> NEXT L
> -- 
> Ward Griffiths    wdg3rd at comcast.net
> 
> I think boys might benefit from owning a Barbie doll; every young man
> should understand what an expensive proposition it is to cohabitate with
> a narcissistic woman built like a stripper.  --  Tony Woodlief
> 
> 
> ------------------------------
> 
> Message: 10
> Date: Mon, 06 Feb 2006 23:35:02 -0500
> From: Diego Barizo <diegoba at adinet.com.uy>
> Subject: Re: [Coco] Minesweeper
> To: CoCoList for Color Computer Enthusiasts <coco at maltedmedia.com>
> Message-ID: <43E82376.9010603 at adinet.com.uy>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
> 
> Thanks Robert.
> This is just the kind of feedback I needed.
>  The new version will be CoCo 3 specific, with much better (I hope) 
> graphics.
> 
> Robert Gault wrote:
> 
> > Hi Diego,
> >
> > Minesweeper is a nice little program. Good job!
> 
> <snip>
> 
> > 3) It is not necessary to initialize variables to zero in Basic, it's 
> > automatic. That means line 60 is not needed. However, since the 
> > program restarts not with RUN but GOTO50, it is necessary to find a 
> > fast way to zero out the array on a rerun. Change line 40 to   40 
> > CLEAR:DIM M(27,14) and make the program restart with GOTO40.
> 
> I never realized that I could reinitialize a DIM after a CLEAR!
> 
> I've also just finished reading your article in CoCoNutz about "The art 
> of BASIC programming". I remember that years ago I run into a similar 
> article, but couldn't remember the recommendations they gave. Even a few 
> months ago I "googled" for something that will help me with the GOTOs 
> and GOSUBs.
> Now I'll always write my subroutines on the top of the listing, the most 
> used first.
> 
> Thanks again.
> Diego
> 
> 
> 
> ------------------------------
> 
> _______________________________________________
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco
> 
> 
> End of Coco Digest, Vol 30, Issue 20
> ************************************





More information about the Coco mailing list