Undercolor/850105/On Sig

Home Articles Companies Publications Hardware People Software Timeline ... Emulators Internet Resources
(Don't see something listed? Click "edit" and add it! Together we can build this database. When making a new info page, refer to this InfoBox Template for guidelines.)

---

UnderColor, Volume 1, Number 5, February 20, 1985

• Title: On Sig
• Author: empty
• Synopsis: A continuing story
• Page Scans: Link

Article

★★ Fm: Arthur Doyle (to Marty)

l hope they win despite themselves. It's been a good Chevy with never much of anything to depreciate. If compatibility becomes a problem with the Mod 9, why don’t they simply add a board that will run CoCo? Their manufacturing costs can't be much over $20/board.

•Fm: Arthur Doyle (to S. Trevor)

Maybe our luck will hold, and programmers such as Marty will upgrade our software to work with the new machine.

••Fm: Wayne Day (to Marty)

Condemn me if you will . . . the simple fact remains that if a programmer would include all the necessary routines for running his program in his file, it would be self-supporting, and run on any of the machines released so far.

For a programmer to not do so indicates one of a couple of things:

1. He does not care about future compatibility.

2. He intends to take care of future compatibility later.

3. He doesn’t know what compatibility is, and/or doesn’t care.

There are a couple of other possibilities, too, that can't be put down where children might get at them.

A good case in point is Colorcom/E. Anyone have problems with that one? Nope, ’cause Mark Davidsaver was smart enough and cared enough to write his own code—and Mark's program is one of the premier examples!

You have many, many times spoken ill of the programmers of the Basic ROMs we all have—yet, here you are saying that "no matter how bad they are, they must stay the same."

It doesn’t make sense, Marty, when Tandy told everyone from the very beginning not to use anything except the published entry addresses.

Take a look at Vidtex, for example . . . it checks to see which version you're using, and makes corrections based upon that info. That's a smart way around the problem of using direct calls to undocumented routines.

What about all the problems with JDOS and, though l haven't heard of too many people using it yet, Spectrum DOS? If a commercial program was self-sufficient, there wouldn't be the compatibility problems, would there?

No, I'll continue to stand by my belief . . . a programmer who doesn't build his product so that it is ROM-version independent is either lazy or doesn’t care. Or, he's not smart enough to do it, which means he probably shouldn't be foisting something off on someone in the first place.

(This sparked three replies, following.)

Fm: Marty (to W. Day)

I agree with the spirit of your remarks, but once again I feel that the lack of documented disk file I/O vectors in the R/S DOS is an unpardonable oversight, making it an unreasonable hassle to keep up with version changes. Example: Neither Colorcom/E nor Vidtex are likely to run on the O9 machine, because from what l hear Tandy will continue to support the documented vectors, but no others. As for detecting version numbers and then acting accordingly, that’s a band-aid solution—better than not trying to use a band-aid, but a band-aid nonetheless. It doesn't help you when a truly new ROM version comes out that you never heard of. Besides, there are a number of different ways to check version numbers. Some are better than others. Yes, in principle, the better, less lazy programmers will and do produce code likely to last longer and through more CoCo versions. But that in no way gets Tandy and Microsoft off the hook for their failure to include documented file handling vectors.

(One reply follows, marked ★.)

Fm: A. Flexser (to W. Day)

Wayne, I'm completely in Marty's corner on this one. Vidtex should be subject to the same criticism as other third party software, if you want to be consistent. In checking for ROM version, it is no different than virtually any other program that uses undocumented ROM calls. They were too "lazy" (by your definition) to write their own disk I/O, and they are therefore vulnerable to arbitrary ROM changes that R/S decides to foist on us. Does that make it a bad program? Decidedly not! They picked the most efficient way to accomplish what they wanted, given the asinine lack of file - handling vectors.

To have done otherwise would have chewed up a lot of memory space better used for the sake of a larger buffer.

(This has one reply, to be published next issue, marked ☆.)

Fm: Dennis Bathory Kitsz (to W. Day)

... or she. No wonder computing’s called a male priesthood.

★Fm: Wayne Day (to Marty)

I believe, Marty, we’re talking about two different things here ...

I would prefer, as probably most folks would, that Tandy and Microsoft use consistent entry points or vectors for the ROM calls, but they have chosen not to. That's an entirely different thing than what you condemned me for.

The point of my previous message that drew your intense ire was my contention that, due to laziness, lack of caring, or lack of knowledge, programmers who build software for the commercial market are not doing the best they could when they use undocumented ROM calls, instead of writing their own code so their programs would be ROM-version independent

Colorcom/E does it the right way — he wrote all his own code from what I understand. Vidtex did it another way.

Blaming Tandy because they played by the rules they established from the very beginning achieves nothing constructive. Encouraging software writers to learn more about the machine they are writing for, and encouraging them to write a self-sustaining code, would be doing more of a service to the CoCo industry.

(This drew three replies, following.)

Fm: A. Flexser (to W. Day)

P.S. Another nice thing about "laziness' is that you can have a certain amount of confidence that your disk routines have been reasonably thoroughly debugged to begin with. Davidsaver’s praiseworthy efforts to not use undocumented ROM

calls have cost me a couple of bad downloads, on account of his having no check for a disk full error (it just omits part of the file if there's no room, and doesn't say boo!)

(One reply follows immediately:)

Fm: Wayne Day (to A. Fiexser)

Hmmm . . . that's one I've never run up against . . . guess it's because I keep checking to see how much space I've got on the disk, huh?

(And two answer this, immediately following:)

Fm: Marty (to W. Day)

Experienced users and system freaks (like you and me) are less likely to be plagued with minor deficiencies than many others, as we’ve gotten good data handling habits and generally stick to them. But even experienced and intelligent folks like Art can still get trapped in a moment of weakness by lousy code, often encouraged by crummy operating systems like Microsplotch's.

and:

Fm: A. Flexser (to W. Day)

Or, yer just lucky!

Fm: John Ross (to W. Day)

Check out the programs from Spectral Associates. They work on all ROMs, and even the Dragon, because they contain all the code needed for and by the program. They don't dip into the ROMs at all! That’s the way it should be done!

(One reply follows, to be published next issue, marked by ★★.)

Fm: Marty (to W. Day)

Wrong again! It still would be possible to provide documented file handling calls in an upcoming ROM version. Tandy nearly did it in the Deluxe. But complacent apologists for lousy operating system design don't help matters!

(One reply follows:)

Fm: A. Flexser (to Many)

Of course, anyone using such documented calls would then be incompatible with all earlier ROM versions, which could be considered a serious drawback!

(A reply follows:)

Fm: Marty (to A. Flexser)

True as far as your statement goes ... but as of now there are two sets of file handling calls. If a third disk ROM is introduced with vectors, there will be three cases to cover; the undocumented calls from disk 1.0, the undocumented calls of disk 1.1, and the documented calls of disk 1.2. There’s nothing that can help that, outside of a time machine. However, if disk 1.2 has documented calls, it will at least nail

down the number of different ROM types to check for in file handling to three, forevermore, through whatever further revisions of the ROM ever occur. That, at least, will be worth something.

Wayne generally shows such good sense in his advice and observations. He really is a very savvy computer type with usually an outstandingly good overview of multifaceted problems. I'm really surprised to see him here defending what essentially every good programmer I've ever met has agreed was a major — probably the biggest — blunder in the design of the CoCo's ROMs. While it's true I welcome an opportunity to light into anyone and have a good, fair fight over an issue, I honestly wonder why Wayne picked that issue to defend.

(Two replies follow, to be published next month, marked ☆☆.)

(end)

Listings

None.