[Coco] No more dream ports

[Steve Bjork]

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>
>>
>
>