[Coco] CoCo 'Extended ADOS 3'--How do I get this working?
Kip Koon
computerdoc at sc.rr.com
Sat Sep 2 07:45:18 EDT 2017
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
More information about the Coco
mailing list