[Coco] CoCo 'Extended ADOS 3'--How do I get this working?
Arthur Flexser
flexser at fiu.edu
Sat Sep 2 14:09:10 EDT 2017
You could also access those floppies with un-Extended ADOS-3, which has the
advantage of not requiring burning into an EPROM. You just can't have a
mixed configuration with different numbers of tracks on different drives,
which requires Ext. ADOS-3. (As I noted in my reply to Al, 35-track disks
can still be read, but not written to, if all drives are configured as 80
tracks.)
I don't recollect if ADOS for the CoCo 1/2 supported 80 tracks or not.
Art
On Sat, Sep 2, 2017 at 7:45 AM, Kip Koon <computerdoc at sc.rr.com> wrote:
> Hi Art,
> Hmm, I may have been thinking of an earlier ADOS then. It has been so
> long ago since I used ADOS. Maybe it was the Coco 1 or 2 version I'm
> remembering. Thank you for correcting me Art. It sounds like Extended
> ADOS 3 is what I need to use to access my floppies then, but I still need a
> way to archive them to images though. I'm still trying to figure that out,
> but no solutions have presented themselves yet. I could use some help
> figuring this out.
> Has anyone else been able to archive old 80 track DSDD floppies to images
> that used ADOS in a similar manner? If so, I would be interested in
> knowing how you managed to do it. Thank you in advance for any help you
> care to give. Take care my friends.
>
> Kip Koon
> computerdoc at sc.rr.com
> http://www.cocopedia.com/wiki/index.php/User:Computerdoc
>
> -----Original Message-----
> From: Coco [mailto:coco-bounces at maltedmedia.com] On Behalf Of Arthur
> Flexser
> Sent: Saturday, September 02, 2017 4:11 AM
> To: CoCoList for Color Computer Enthusiasts
> Subject: Re: [Coco] CoCo 'Extended ADOS 3'--How do I get this working?
>
> 1. You shouldn't have needed to patch Extended ADOS-3 for 80-track DSDD
> operation. It already supports that; you just need to configure it so
> that it knows which drives have which number of tracks. Even if you
> reassign the drive numbers, which you can do on the fly, it still keeps
> track of a physical drive's properties like drive capacity and step rates.
> You may possibly have patched it so that the two sides of a double-sided
> drive are treated as a single drive rather than the two sides being treated
> as separate drives. I'm not sure how much advantage there is to doing
> that, since you're still limited to 3 double-sided drives by the hardware.
> (I do seem to recall an article in one of the CoCo magazines describing
> how someone got around this limitation with some logic circuitry that
> allowed access to an additional drive if, say, both drives 1 and 2 were
> simultaneously selected in the drive mask byte.)
>
> 2. A problem with the sort of project you're suggesting is that it can be
> difficult to maintain compatibility with a lot of programs. Depending on
> your priorities, that might not be seen as a big loss.
>
> Art
>
>
> On Sat, Sep 2, 2017 at 12:51 AM, Kip Koon <computerdoc at sc.rr.com> wrote:
>
> > Hi Guys,
> > Reading this thread and a few others over the years has got me
> > thinking of trying various Disk Basic modifications I used to run back
> > in the day when all I had were floppy drives for storage.
> > 1st I had just SSDD 35 track floppy drives like everybody else started
> > with, but I quickly outgrew them. Next I upgraded to 40 track DSDD
> > floppy drives and still I eventually outgrew them as I found more
> > things to do with my Cocos. Then the next upgrade was, you guessed
> > it, 80 track DSDD floppy drives which I kept running for years. As I
> > found a use for this large capacity, I outgrew this as well.
> > Eventually when 1.44MB 3.5" floppy drives came to be, I again upgraded
> > my Cocos to 3.5" floppy drives across the board as they seemed more
> > reliable. I had 3.5" floppy drives on everything. I could only use
> > the 720KB capacity though so it was essentially the same capacity as
> > the 5 1/4" 80 track floppy drives I had been running. I always wished I
> could have used the 1.44MB capacity of
> > those 3.5" floppy drives. At each iteration of upgrades, I always kept
> > one of the earlier floppy drives on hand to transfer data files as I
> > needed them. For many years, I routinely used 80 track DSDD floppy
> > drives on a daily basis. Then I used 3.5" floppy drives almost
> > exclusively. I have used several DECB versions over the years and
> > they all had their strengths and differences. I'd like to use them
> again.
> > I was wondering since only 2 slots are currently able to access the
> > disk controller instead of all 4 slots, is there a way that can be
> > created to be able to easily switch from 1 Disk Basic version to
> > another without having to reflash different versions over and over
> > again into the same block of flash memory. Rather, have all of them
> > in flash somewhere and have some type of mechanism setup to remember
> > which DECB rom to boot up with and still have the capability to switch
> > from 1 to another sort of on the fly kind of like SDC-DOS does but for
> > the CoCo3FPGA. Maybe use 1 Disk Basic as kind of a Master Disk Basic
> > able to switch to any of the other Disk Basics as needed. This would
> enable us to use any Disk Basic we desire.
> > Back in the day I was a big user of DSDD 80 track 5 1/4" floppy drives
> > and I have literally thousands of 5 1/4" floppies in storage most of
> > which are much larger in capacity than the standard single-sided 35
> > track format that the Coco was born with. The 35 track format was a
> > good start, but it has to and needs to be matured into a format that
> > can take full advantage of what the CoCo3FPGA has to offer as well as
> > the real Cocos. I think this type of feature would be great to have
> > on the CoCo3FGPA at least, as well as all the Cocos in general. I
> > have been thinking about this particular feature for the CoCo3FPGA for
> > several years now. I have always wanted it for my real Cocos, but a
> > common supported multiple format standard never solidified. I wish it
> had.
> > I just cannot in any way use many of my old floppies on the modern
> > variations of the Coco 3 including the CoCo3FPGA these days because
> > the 35 track single-sided format is still the only floppy format that
> > is "officially" supported. I can't even read these old floppies in
> > such a way easily that gives me the ability to at least transfer all
> > the data from 1 disk into 1 disk image and be able to use that image
> > no matter the capacity size of the source floppy.
> > If we were to have a new standard for all possible floppy capacities
> > for floppy images in DECB with an easy method to specify which one the
> > user wished to use stored somewhere on the floppy image, then I for
> > one would be more than willing to convert my collection to the new
> > format as time permitted. That way, no matter which format floppy the
> > user put into their drive, the new higher capacity DECB would be able
> > to recognize the format and not clobber the higher capacity disks or
> > disk images rendering the contents unusable. We would be able to use
> > these original disks in their original form save for the addition of
> > the new part of the disk that has the multiple floppy format data. I
> > feel this has been sorely lacking in DECB ever since the beginning.
> > Tandy did not have the foresight to include the disk format onto the
> > floppy disk somewhere and respect the format used on that disk. Once
> > higher capacity floppy drives were possible, Tandy never used the
> > additional capacity in DECB nor ever implemented them for the Cocos.
> > Tandy never treated the Coco 1, 2 or 3 and definitely not the
> > unfinished Coco 4 seriously. I think it is high time we take control
> > of DECB's disk abilities and give it a more mature disk format
> > handling capability that preserves all the data on the disk no matter
> what the capacity is.
> > What do you all think? Pros and cons are welcome in a civil manner.
> > No flamers please. This is a serious idea that has been rolling
> > around in my head for quite some time now. After this has been hashed
> > out, I'd like to see something come of this. Any of you experts have
> > any serious ideas as to how this should be properly handled and
> > implemented? If someone has already done this, I would definitely
> > like to know about it. After all, had Tandy actually done this years
> > ago, we would have had to change anyway. Sometimes growing is
> > painful, but after the pain is gone, great gains can be realized. I'd
> > really like to hear all of your thoughts on this. Let's give the
> > DECB'ers a really nice upgrade! One that we all can be proud of as a
> community of Color Computer Enthusiasts.
> > I know of one person that took the Coco 3 eprom and condensed it way
> > down taking out all the logic that melded the 3 individual roms
> > together as they were added into the Coco line over the years to come
> > up with one great image without losing any of its capabilities. I'd
> > like to know what became of that project. I was tracking its
> > development for a time then lost track of it. The results of that
> > project gives more room for further upgrades to DECB. Besides, 16KB
> > Disk Basics have been successfully implemented and used for years and
> > the CoCo3FPGA can make use of 16KB rom images. Extended ADOS 3 is just
> one example. I'm sure there are probably others as well.
> > Extended ADOS 3 is one Disk Basic I have used in the past and I
> > patched the heck out of it primarily increasing the floppy disk
> > capacities up to and including DSDD 80 track floppy formats. I have a
> > DEC Dual floppy cabinet that I pulled the 2 full height floppy drives
> > out of and installed 4 half height floppy drives into - 2 floppy
> > drives were 40 track DSDD and the other 2 were 80 Track DSDD. Sadly
> > the 4th floppy drive of course didn't work, but I didn't know it
> > wouldn't work back then. I still think it is a fault of the disk
> > controller design as well as the design of the DECB rom and not a
> > fault with the floppy drives themselves. Other OS's use all the higher
> floppy capacities so why not us.
> > I think it is way past time to give DECB a permanent across the board
> > high disk capacity upgrade since the high capacity floppy drives
> > definitely can handle the higher capacities. Keep every other aspect
> > of DECB intact. A bidirectional transfer program or set of programs
> > can be written to transfer data files between the old and new floppy
> > formats much like the Toolshed set of programs does with actual floppies
> and floppy images.
> > A bigger jump table at the very beginning of DECB can be used to give
> > the user access to all the routines they would need and have used over
> > the years. That way further enhancements can be made without
> > continually "breaking" user programs with each DECB enhancement. Just
> > add all the higher disk capacities into DECB and the mechanism to
> > protect the data integrity for all formats into the new higher
> > capacity DECB. There are those that have only floppy drives running
> > that could really use their higher capacity drives to their fullest.
> > I know I have many times using specially modified DECB rom images.
> > If you have read this far, then you are at least interested in this
> > feature at some level. Let's figure out a way to make this work.
> > DECB is the only area I can see that has never really matured well at
> > least in its floppy storage capabilities. Let's give this due
> > consideration. Instead of objections, let's find the challenges and
> > make it a rewarding experience. We will be all the better for it. What
> do you say?
> >
> > Kip Koon
> > computerdoc at sc.rr.com
> > http://www.cocopedia.com/wiki/index.php/User:Computerdoc
> >
> > -----Original Message-----
> > From: Coco [mailto:coco-bounces at maltedmedia.com] On Behalf Of Arthur
> > Flexser
> > Sent: Friday, September 01, 2017 2:25 PM
> > To: CoCoList for Color Computer Enthusiasts
> > Subject: Re: [Coco] CoCo 'Extended ADOS 3'--How do I get this working?
> >
> > Hard to tell...possibly a corrupted file or an emulator bug. Has
> > anyone else here succeeded in getting Ext. ADOS-3 working in one of the
> emulators?
> > (I seem to recall that someone did a long time ago, don't remember
> > which emulator. Jeff Vavasour's, maybe. I think Jeff mentioned he
> > had to do a few tweaks to get emulated Ext. ADOS-3 working.) Make
> > sure the file starts with ASCII "DK" (44, 4B, I think).
> >
> > An ideal next step would be to burn it into an EPROM and see if it
> > works on a real CoCo 3.
> >
> > Art
> >
> > On Fri, Sep 1, 2017 at 2:07 PM, Steven Wallis <stevenw890 at gmail.com>
> > wrote:
> >
> > > Yes ADOS 3 (the original and one with my customizations) works fine
> > > when run directly from BASIC and also when renamed to DISK11.ROM in
> > MESS/MAME.
> > > I was careful when using the customizing program not to make any
> > mistakes.
> > >
> > > When I try Extended ADOS 3 with VCC 1.42 & VCC 2.0.1b the startup
> > > message is fine and entering the Date, but then after a few seconds
> > > things get screwy like the text going from true lowercase to black
> > > on green, and it starts displaying @ symbols over and over.
> > >
> > > If the startup message works in VCC it should work in MESS/MAME too.
> > > Anyways I don't care about using VCC until it is more mature, I just
> > > want to use MESS/MAME.
> > >
> > >
> > > On Thu, Aug 31, 2017 at 11:10 PM, Arthur Flexser <flexser at fiu.edu>
> > wrote:
> > >
> > > > I would first check if the (Un-Extended) ADOS-3 file works okay,
> > > > which
> > > can
> > > > be run from RAM. You should be able to run that from the ADOS-3
> > > > disk
> > > with
> > > > RUN"ADOS3". (You might have to change the filename; it's been a
> > > > very
> > > long
> > > > time...)
> > > >
> > > > I would also check the customizing programs to make sure that
> > > > things are terminated properly, like the startup message. If
> > > > there's no final
> > > quote,
> > > > or whatever it's supposed to end with, screwy things like that
> > > > will
> > > happen.
> > > >
> > > > Art
> > > >
> > > > On Thu, Aug 31, 2017 at 10:26 PM, Steven Wallis
> > > > <stevenw890 at gmail.com>
> > > > wrote:
> > > >
> > > > > Does anyone know how to get the Color Computer 3 "Extended ADOS 3"
> > > > working?
> > > > > Here are the steps I have done, but it isn't working properly yet.
> > > > >
> > > > > I'm using MESSUI64 1.87 from www.progettosnaps.net/messui/
> > > > >
> > > > >
> > > > > 1. From the "ADOS 3" disk RUN"CUSTOMIZ.BAS", save your ADOS file
> > > > > as MYFILE.BIN
> > > > >
> > > > > 2. Copy MYFILE.BIN file to the "Extended ADOS 3" disk.
> > > > >
> > > > > 3. Run "ECUST.BAS", use default settings and save it (it will
> > > > > use EPROM.BIN).
> > > > >
> > > > > 4. Copy EPROM.BIN from the .DSK image to a hard drive folder.
> > > > >
> > > > > 5. Edit EPRON.BIN, remove the first 5 bytes and the last 5
> > > > > bytes, save
> > > > it.
> > > > > So it is now 16,384 Bytes.
> > > > >
> > > > > 6. Copy EPROM.BIN into \MESS\Roms
> > > > >
> > > > > 7. I used HashMyFiles.zip to find the EPROM.BIN hashes.
> > > > > www.nirsoft.net/utils/hash_my_files.html
> > > > >
> > > > > 8. Edit \MESS\Hash\coco_cart.xml and add these lines near the end:
> > > > > <software name="extendedados3">
> > > > > <description>ADOS 3 Extended 1</description>
> > > > > <year>1989</year>
> > > > > <publisher>SpectroSystems</publisher>
> > > > > <info name="developer" value="SpectroSystems" />
> > > > > <info name="author" value="Arthur J. Flexser" />
> > > > > <info name="serial" value="26-9991" />
> > > > > <part name="cart" interface="coco_cart">
> > > > > <dataarea name="rom" size="16384">
> > > > > <rom name="EPROM.BIN" size="16384"
> crc="7f0edf28"
> > > > > sha1="6ca61e29c136ec8201492ca7f9eb050912f3582d" offset="0" />
> > > > > </dataarea>
> > > > > </part>
> > > > > </software>
> > > > >
> > > > > 9. Run MESSUI64, load EPROM.BIN into the Cartridge slot.
> > > > >
> > > > > 10. Start Color Computer 3 emulation.
> > > > >
> > > > >
> > > > > It starts up but it is screwy. Instead of the startup message, I
> > > > > get 8 graphics characters; then the cursor shows up.
> > > > > Only some of the Ctrl keys seem to work. Key repeat works. The
> > > > > new DOS commands work.
> > > > >
> > > > > Thank you in advance!
> > > > >
> > > > > --
> > > > > Coco mailing list
> > > > > Coco at maltedmedia.com
> > > > > https://pairlist5.pair.net/mailman/listinfo/coco
> > > > >
> > > >
> > > > --
> > > > Coco mailing list
> > > > Coco at maltedmedia.com
> > > > https://pairlist5.pair.net/mailman/listinfo/coco
> > > >
> > >
> > > --
> > > Coco mailing list
> > > Coco at maltedmedia.com
> > > https://pairlist5.pair.net/mailman/listinfo/coco
> > >
> >
> > --
> > Coco mailing list
> > Coco at maltedmedia.com
> > https://pairlist5.pair.net/mailman/listinfo/coco
> >
> >
> > --
> > Coco mailing list
> > Coco at maltedmedia.com
> > https://pairlist5.pair.net/mailman/listinfo/coco
> >
>
> --
> Coco mailing list
> Coco at maltedmedia.com
> https://pairlist5.pair.net/mailman/listinfo/coco
>
>
> --
> Coco mailing list
> Coco at maltedmedia.com
> https://pairlist5.pair.net/mailman/listinfo/coco
>
More information about the Coco
mailing list