[Coco] Games that don't fit on floppies (was Super IDE vs. Drive Pak)

Joel Ewy jcewy at swbell.net
Wed Nov 16 00:44:00 EST 2011


On 11/15/2011 10:35 PM, Aaron Wolfe wrote:
> On Tue, Nov 15, 2011 at 10:40 PM, Brian Blake<random.rodder at gmail.com>  wrote:
>> On 11/15/2011 10:21 PM, Aaron Wolfe wrote:
>>> On Tue, Nov 15, 2011 at 10:02 PM, Brian Blake<random.rodder at gmail.com>
>>>   wrote:
>>>> data throughput increases; the  making of very large games with lots of
>>>> digitized and sampled sounds only makes sense to me - I could be WAAYYYY
>>>> off
>>>> on this...
>>> This recalls a topic that was recently discussed on the CoCo IRC
>>> channel.  We were talking about a new CoCo game that would benefit
>>> from mass storage, possibly only be practical with some form mass
>>> storage.  Some folks felt a CoCo game should run from standard CoCo
>>> floppies, or it wasn't a true (pure/proper/faithful/??) game.  Not
>>> sure what the proper word would be.. basically if it didn't run on a
>>> stock CoCo with FDD, it was sort of cheating.
>> Seriously?! I think that whole train of thought is absolutely ridiculous.
>> People in this group have spent years trying to extend the CoCo past it's
>> original boundaries, and now someone actually believes that if you don't
>> have have something that runs on a stock CoCo with stock FD its cheating?
>> That kind of thinking is dangerously old fashioned. Every retro group out
>> there is looking for new ways to extend their systems well beyond what was
>> possible in the '80's. Trying to re-constrain it now seems ludicrous...
>>
> well... I was on the side of "it's fine to use mass storage" so I
> can't claim to completely understand the other side of the discussion
> we had, but I think I get the gist of it.  Basically, it's about what
> is a coco and what isn't.. a question that comes up in various forms
> fairly often I guess.  How much can you change a system before it's
> not the same system anymore.  Mass storage is probably in the more
> "acceptable" range even for a purist I'd think.  Using a modern PC to
> provide services to the coco is more towards the other end.  Like any
> hobby, I guess there are some bounds to what is enjoyable, and making
> it too easy by using modern stuff threatens the enjoyment in some
> situations.  Some hobbies are full of rules about what is or isn't
> allowed, i'm certainly not in favor of anything like that.   There is
> a limit somewhere though.. for an extreme example look at the recent
> "new Commodore" for instance... it's a PC in a c64 case.  Thats well
> beyond where I'd stop considering something as part of the hobby.
>

Personally, I don't see any reason that a game (or any other program) 
that takes advantage of mass-storage is cheating.  Again, I had a hard 
drive on my CoCo 3 back in the day.  Even technologies and capabilities 
that are completely new, such as the networking in DW4 are perfectly 
legitimate in my opinion, and should be taken advantage of.  I guess I 
find the "What if..." game just as fun as pure old-school nostalgia.  
What if Motorola had continued to develop the 6809 and came out with a 
20+MHz version in the late '80s?  What if Tandy had developed a CoCo 3 
successor with a 12-bit palette and a 256 color graphics mode?  
CoCo3FPGA, for example, is a pretty logical extension of the CoCo 3 
architecture.  It bears more resemblance to the original than a modern 
PC does to an 8088 IBM PC.

I don't quite get why somebody would want to put a modern PC in a C-64 
reproduction case.  It's just a case mod, which can be fun and 
interesting in its own right, but I don't think it falls under the same 
retrocomputing rubric.

I have a DS-69B video digitizer that I used to use to make high-color 
pictures on the CoCo.  That was really fun and cool back in the day.  
But at this point, I would rather use a modern digital camera to take 
pictures to convert for display on the CoCo.  Why do I even want to see 
graphics on the CoCo, when I have dozens of newer computers of all kinds 
with "real" high-color and true-color displays?  I guess it's 
interesting to see how good you can make pictures look given the 
limitations of the display.  And it's interesting to remember what it 
was like to discover computer graphics and watch as they became more 
realistic and approached photographic representation.  And it is fun to 
think about what could have been done -- and maybe actually do it -- 
with one more iteration of the CoCo's design, as in the CoCo3FPGA.

Part of the appeal of old computers for me is that their simplicity 
makes it possible for mere mortals actually to extend their 
capabilities.  It engages my imagination in a very different way to 
think of how I could do something new with a CoCo 3, or CoCo3FPGA, or an 
SWTPC.  Modern PCs are boring as machines, because almost everything one 
might want to do with them either has already been done, or is too 
difficult for an individual to implement because the hardware is not 
hobbyist-friendly.  It's inspiring to see what individual members of the 
CoCo world have done, and that makes me want to contribute something 
myself -- even if it's just taking advantage of the capabilities that 
somebody else has provided.

It seems like a shame to me that if somebody has worked out a color map 
for 256 artifact colors on the CoCo 3, or added network facilities for 
OS-9, or implemented a CoCo on an FPGA, that these capabilities should 
never get used for anything more than a demo.  I say that if we have 
DriveWire and CoCoNet, we would be fools not to write software that uses 
the capabilities they provide.

JCE
>>> I wonder how other folks feel about that.  Where do you draw the line
>>> on what is right and what is not I guess.  It's a concept I struggle
>>> with in DriveWire a lot, where we can often do things either on the
>>> CoCo side or the PC side (and it's usually a lot easier to do them on
>>> the PC side, but it feels wrong).  There have to be some lines drawn
>>> somewhere I guess.
>> Not really, lines aren't necessary. You've made the app do what you wanted
>> it to do. You graciously released it for public consumption, took input and
>> ideas and expanded on the original. The decision is up to you to add
>> functionality that you feel may be cheating - it's up to the user to decide
>> if they want to use it in that manner, or if they feel it's a cheat...
>>
> The example that comes to mind is a set of API calls I removed after
> reconsidering things.. there used to be calls to fetch web pages, just
> send the command and DW returned the HTML.  However, that really
> didn't seem right to me, for whatever reason.  So, now a program on
> the CoCo has to open a TCP socket, speak HTTP to the web server, and
> parse the returned data itself.  Maybe a subtle difference, but it
> felt like the first case was having the PC do too much for the CoCo...
> cheating i guess, even though it made writing OS9 programs that deal
> with web content a bit easier.
>
>>> Personally, I think a game that requires mass storage is OK and "true"
>>> since there were mass storage options available in the CoCo's heyday,
>>> even if they never gained much popularity.  However, I can see the
>>> point that there have to be some limits or what you have isn't a
>>> "coco" anymore.
>> I'm throwing the bull$9!7 flag on this.. if it's running on a CoCo,
>> regardless of what mass storage device is used, it's STILL a CoCo.
>>
>>> It would have been impractical to release a game
>>> requiring anything beyond FDD back in the day I think, since the
>>> installed base was far to small to support software requiring anything
>>> more.. so maybe I'm wrong.  Anyway I thought there might be some
>>> interesting opinions on that in this group.
>> Actually, I think it was technically infeasible to introduce a game of other
>> software that went beyond the limits.  People like Roger and Nick (and
>> probably Steve) have fought with that for years - how to cram all 5,000
>> features you want into a space that can hold 500. Been reading Rainbow a lot
>> lately for a few articles I'm working on - from the clubs advertised, the
>> CoCo had a pretty good installed base - but was always held back by Tandy,
>> and without proper support from your parent company, well...
>>
> Yes, squeezing functionality out of the CoCo is a big part of the fun
> and history.  Maybe using mass storage is seen as a cop out or
> avoiding part of the challenge.. if you can't make the game work from
> floppy, you haven't properly embraced the systems limitations?  Not
> entirely sure, like I said I was on the other side of the discussion.
>
>> I remember AutoCAD 2.62 - installed it on my first PC - took 10 SD/HD
>> floppies. The CoCo's OS couldn't handle programs like that, which is why we
>> are stuck with vdisks to this day. If I'm right about Roger's plans, I can't
>> wait to see how he accomplishes it. As I said earlier, I could be dead
>> wrong...
>>
>> I don't know if my opinion is interesting... hostile, maybe...
> Stronger reaction than I would have expected, but interesting.
>
>>
>>
>> --
>> Coco mailing list
>> Coco at maltedmedia.com
>> http://five.pairlist.net/mailman/listinfo/coco
>>
> --
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco
>




More information about the Coco mailing list