[Coco] OS9 Pascal

Gene Heskett gene.heskett at verizon.net
Sun Aug 12 11:07:45 EDT 2007


On Sunday 12 August 2007, Willard Goosey wrote:

Darn, I just realized I wrote the weekly paper here, the whole thing.

[...]
>>Not impossible Willard, but with my approach, chances are pretty slim.
>
>Well, Pascal was designed as a teaching tool, and alot of its
>"features" are aimed at keeping newbies from doing stupid things.
>
>I again recommend Kernighan's "Why Pascal Is Not My Favorite
>Programming Language".
>
>>The MW C compiler?  Donbesilly.  Its entirely possible to wound
>>oneself with it.
>
>What, you've never seen that text file?  "How To Shoot Yourself In The
>Foot With A Programming Language" or something like that.  It goes
>like this:
>
>C -- You shoot yourself in the foot.
>Pascal -- The compiler won't let you shoot yourself in the foot.
>BASIC -- You shoot yourself in the foot with a water pistol.
>Assembly -- You shoot yourself in the foot with a vulcan cannon.
>[etc]

Hehe, and no, I've not seen it. :)

OTOH, the first program I ever wrote for a real job, not just an exercise, was 
in assembly, sort of.  I had an idea, an outline so to speak, and treated 
each function as a subfunction of something larger, until I had it down to 
reading the status of a port, checking the bit I'd tied to house vertical 
drive, looping back to read it again if it was true, and falling through to 
run the control loop if it was false.  The box?  A Quest Super Elf board, RCA 
1802 based.  It had a whopping 256 bytes of ram, but had an S-100 buss, so I 
bought it a backplane, and 4k of 300ns static ram on a board I had to build 
that cost us $300 in the late 70's.  The final code was about 1200 bytes, 500 
or more of which were lookup tables for character fonts on 5x7 video displays 
or timing constants.  I also built the video it needed, a huge 120 line 
high "8.8" display by hand.  That took 6 bytes of DMA per video frame to 
service.

What did it do?  Interfacing with the remote control connectors on Sony 
2800/2850 3/4" U-Matic VCR's that had had an aftermarket remote editing 
control kit installed in them, it could search for, by pushing buttons on a 
pendant I'd made, and find the first frame of video that was supposed to be 
switched to air, take another button push to tell it how long the commercial 
was, a third button controlled whether or not a new academy leader was video 
inserted onto the tape, and a final button that said do it.  It would then 
back the machine up about 15 seconds, roll it forward, do the video insert of 
a new leader that counted down from 9.9 seconds to 1.9 seconds and triggered 
a 1 second audio cue tone for an audio insert on channel 2 as the 5.0 came up 
in the video, then turn the insert off again.  Then it let the tape roll for 
the programmed time, usually 24.9 seconds for a 29.9 spot, insert that audio 
cue tone again, roll it on to 29.9 seconds and rewind it back to the 1st 
frame so you could check to see if the machine lost track of the time.

This all worked with a gizmo microtime made that could, using those tones, cue 
up all the tapes, and then play as many spots as you had programmed it to do 
for that station break at hand, all as perfectly timed as the audio cue tones 
on the tapes were.  It also saved a generation of dubbing quality loss by 
doing this to productions finished commercial because up till then they were 
dubbing a copy of the very badly worn master tape with the tones on it, then 
dubbing the commercial to that tape for the actual air play.

I needed to keep time better than the stations sync clock, so I wrote an 
algorithm that assumed the station generator was a rubidium standard which it 
wasn't, but kept time to within a second in several decades with that sources 
accuracy limits.

All that without an assembler!  I was looking up the nemonics for what I 
wanted to do next in the RCA programmers manual for the 1802, translating 
that into the hex value and entering it into that memory location with the 
simple hex editor that came with the Super Elf board.  I put a 6 volt gel 
cell in as a battery backup for the ram, and dedicated an old, off speed 
broadcast cart recorder as the recovery mechanism for really long power 
failures.  It didn't crash, and the last time I checked with Norman, the CE 
at KRCR in Redding CA, circa 1995, it was still in daily use and they had no 
plans to replace it. 14 years.  They'd had to give it a new battery.

Yes, you CAN shoot yourself in the foot with assembly, but I submit that if 
you manage that, then you weren't paying attention and you will get what you 
deserve.

A couple of years later, I built an automatic transmission system for an FM 
transmitter, using MicroProfessor boards, Z-80 based (what a cluster fudge 
that cpu is!) using the same basic tools, looking up the operation I wanted 
to do next in Rodney Zacks Z-80 book (and finding all of Rodney's errors 
too...).  For that one I built an eprom burner and used eproms and dram.
It didn't crash either unless Rodney's errors bit me, in which case find it, 
fix it, wipe the eprom and reburn.  Slow since I was using sunlight to wipe 
those 2716's.  Or one Z-80 of the pair was flaky, I had to write a routine to 
discover if it had actually done one operation or had ignored it, in which 
case do it again till it worked, but that wasn't Rodney's fault.

So when I discovered the coco, and its 6809 cpu in 1985, I was in hog heaven, 
here was a cpu with some real smarts & I had a ball with it.  You all have 
the opportunity to run some of my code, and to my knowledge, the only 
miss-cue in all that was the version of rbf.mn that had the BackAR bit 
incorporated.  If you weren't paying attention, that one would bite you and 
wipe your drive.  I never ran with dmode /dn SAS=8, usually $20 minimum, so 
it didn't byte me.

I also did some stuff in Basic09 for WDTV-5 that was used several times a day 
for around 13 years.  Power failures did crash it though cuz I never got 
around to either putting in an RTC, or putting the B09 startup in the 
startup, after reminding folks they first had to type 'dos' then set the 
clock, then start the app itself...  OTOH, it sat there and did its thing 
from power outage to power outage, exactly what I asked of it.

I think there is a difference in attitudes vis-a-vis coding practice when you 
are doing code for someone who has no clue whats under that button, he just 
expects it to work when he pushes it.  So you DO handle the errors, silently 
if possible, noisily if the user needs a clue bat application...  In no event 
was a true crash ever tolerated.

The higher level language can be quicker (also many times slower when you 
can't figure out how to make a simple 5 line routine work due to an obscure 
syntax error on your part) to the finished product, yes, but IMO its also 
many times easier to trim your toenails with a 20mm Vulcan too.  Particularly 
if you don't have a clue what that higher level language is actually doing at 
the machine code level.  Learn that machine level code FIRST!

-- 
Cheers, Gene
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Consultant, n.:
	An ordinary man a long way from home.



More information about the Coco mailing list