[Coco] No more dream ports

[Kip Koon]

Steve,
Your software development system sounds very interesting.  How about sharing
all the details with us on how you did your Coco software development.  I
for one am very interested.  I'm not asking you to share you games' source
code of course, just the process you used to create them.  It would be of
great use to us. Free, Shareware, a product?  Your choice of course.  After
all it is your design.  Just a thought my friend.
Kip

-----Original Message-----
From: coco-bounces at maltedmedia.com [mailto:coco-bounces at maltedmedia.com] On
Behalf Of Steve Bjork
Sent: Thursday, April 25, 2013 10:58 AM
To: CoCoList for Color Computer Enthusiasts
Subject: Re: [Coco] No more dream ports

As I said before, I did have better text editors and better assemblers
because I wrote them for my own use.  As for macros, the way most
programmers use them hide the true code and never see the waste they are
creating.  I use very few macros (if any) in my CoCo source code.  I would
like to see the code and check if there are any cycles I can take out of a
loop.  Macros can hide so much.

Yes, in the beginning I used a CoCo to write the code.  But in the final
years of CoCo coding, I was using an Amiga for sound work, PC for writing
and assembling code. There was a system on both a PC and the CoCo for
creating and editing the graphics objects and screen maps.

All of this data would flow into a 256k static RAM drive that would load in
the code and data into a CoCo for testing.  The total time from Assembling
the code to running on the CoCo was just seconds.  (It took longer to reach
over and type DOS [enter] on the CoCo than the Assembling and transfer
time.)

As for Debuggers and emulators, I never needed them.  (Nor would they help
me at any time.)  We had Documentation available and it was indexed,  they
were call books.  Most of the so called modern Documentation of today are
just scans of the books we had back then.

The key to my coding was the Libraries that I created over the years.  
Once you got a code working on one project, it was easy to reuse to write
the next.  This is why it only took about 30 days to write Rampage.  Most of
that time was spent on the sound & graphics since the game engine was
already done.

Yes, having an assembler and emulator running on a modern PC would help
someone new to get started coding on a CoCo.  If I was to create a new
development system, I would based around modern tools and use the internet
to share information.

But in no way did my development system handicap my work or what I could do
with the CoCo.  The only limit was the time I could put into create new
techniques.  Time is money and it was my job to get the projects done on
time.

It was only when I had time (after the Tandy projects) to come up with new
techniques used in Z-89 and Marty's Nightmare.

Steve

On 4/25/2013 6:34 AM, Luis Antoniosi (CoCoDemus) wrote:
> better text editors, better assemblers, more powerful macros, instant 
> assembling time, launching the code on emulator, etc.
>
> How much time can you gain with the modern tools ? Not to mention all 
> the documentation available and indexed.
>
>
> On Wed, Apr 24, 2013 at 11:32 PM, Steve Bjork
<6809er at srbsoftware.com>wrote:
>
>> On 4/24/2013 7:33 PM, Luis Antoniosi (CoCoDemus) wrote:
>>
>>> Of course I was talking to make from scratch and not port, also C on 
>>> coco sucks.
>>>
>>> I do agree with all hardware limitations and I never dreamed about a 
>>> wolf-3d clone but some sort of 3d game with some texture mapping.
>>>
>>> But one thing we have now: new tools that allows us to squeeze every 
>>> cpu cycle on those CPUs and emulators to debug and test it line by 
>>> line. just look at the C64 demo scene to see how far they went. but 
>>> of course, as I said demo is not a game. a demo is all controlled and
cycle counted.
>>>
>>>   What do you mean by the new tools that we have now?
>> When I was coding for the CoCo, I had everything I needed to squeeze 
>> every CPU cycle of the CoCo.  (Remember, 25% of my coding time was 
>> used for creating the tools used in my coding.)  I see nothing that 
>> came out since I work the CoCo to make for faster code.  Yes, we have 
>> learned a few new technique in writing code or using the hardware.  
>> But still, these technique only give us a few percent of game
improvement.
>>
>> I never had the need for emulators or debuggers.  My code had a 
>> developer OS built in.  This would give me the timing/resource 
>> information on very code/graphic object in the game.  (I would remove 
>> the OS when creating the final version for sell.)  As for debugging, 
>> I only needed to look at the source code or the timing/resource 
>> information to know what was going and how to fix.
>>
>> As for squeeze every CPU cycle, I knew the timing cycle and byte 
>> count of every instruction that I wrote.  Little things like using 
>> the LDY was really the LDX instruction with a Pre-Byte header before 
>> it.  So, I try not to use the Y register since loading took an extra
clock and extra byte.
>>   (It should be noted that LEAX and LEAY was the same speed and 
>> size.)
>>
>> Back in those days, we coded "down to the metal."  We knew just how 
>> the
>> 6809 and the CoCo's hardware work.  This is something that's lost on 
>> modern coders.  Once a year, I still give a talk at UCLA to the new 
>> programmers for one of my old professors. (Well, his replacement 
>> since he retired a decade ago.) My two hour talk covers how to "know 
>> and own your code" and cut out the waste.  After all, wasteful code cost
money.
>>
>> Yes, we will learn new ways to do things.  But none of the new 
>> technique will make CoCo any newer than a 30 year old computer.
>>
>> Steve
>>
>>
>> --
>> Coco mailing list
>> Coco at maltedmedia.com
>> http://five.pairlist.net/**mailman/listinfo/coco<http://five.pairlist
>> .net/mailman/listinfo/coco>
>>
>
>


--
Coco mailing list
Coco at maltedmedia.com
http://five.pairlist.net/mailman/listinfo/coco