On Wednesday 15 January 2014 02:35:44 EBo did opine:

> On Jan 14 2014 9:14 PM, Gene Heskett wrote:
> > On Tuesday 14 January 2014 23:11:44 andy pugh did opine:
> >> On 15 January 2014 02:13, Dave Cole <[email protected]> wrote:
> >> > Assembler .. yep I remember doing some of that on 6800 Micros..
> >> 
> >> Very
> >> 
> >> > tedious.
> >> 
> >> Tedious? Ha! I used to _dream_ of an assembler, I wrote machine code
> >> in raw hex, from a paper list of mnemonics!
> >> (on the Z80)
> > 
> > Tedious? Just a bit.  I have on the shelf above me, paper and audio
> > cart
> > copies of some code I wrote without an assembler, in 1978 for an RCA
> > 1802.
> > It worked well, and was still in use 15 years later the last time I
> > checked.  Like you, I did the same thing on a Z-80 a year later.
> 
> Gene, thanks for the stroll down amnesia lane...  Back around the same
> time I was hired to write the OS for a monitoring system for a
> geothermal test well that used an RC
> Many years later (just prior to Y2K)A 1802!  The funding org was so
> tight that they could not afford to purchase one of the only assemblers
> for the thing.  So the entire OS, drivers, etc., was all written in
> hex...
> 
> One of my friends that worked with that engineer years later adapted
> the code and project for another purpose.  In the mid 80's we got to
> talking and I boasted that I could now write him a macro assembler for
> him in 24 hours (he had to buy me a case of coak-a-cola as pay.  Well I
> missed the 24h deadline, but had it working within 36h...  Now step
> forward to 1999.  My buddy check his code for Y2K issues and found one.
> He needed to go back to that ancient code (and the completely hacked
> together macro assembler I wrote over the course of a day and a half),
> he dusted off the tarball, recompiled the assembler in a more modern C
> compiler, it compiled with a few warnings (but nothing sever), made the
> change to his code, ran it through the assembler, and a day or two later
> had the Y2K bug patched...  As I recall he bought be another case of
> coke ;-)
> 
> BTW, I loved that chip.  You could do a multi-thread context switch in
> a single atomic operation.  It was WAY ahead of its time...

In a sense it was.  Its Achilles heel was that everything in and out of it 
had to go thru acca or accb, then moved to/from the register it was 
to/from.  A full machine cycle was several microseconds.  But despite that, 
it did manage to get my job done, which was run a tape machine with tight 
timing control, backwards and forwards, doing audio and video inserts to 
lay a new digitally generated academy leader on a commercial, and lay the 
cue tones on audio channel 2 to make it work with a Microtime Automatic 
Station Break machine.  All dead on the money frame accurate.

When I got done and it appeared to be working as desired, so I got curious 
as to how long it actually took to do what it needed to do 59.94 times a 
second, all of which started on the falling edge of house vertical drive 
from the sync generator, and had it set a flag bit I could watch on a scope 
when the falling edge of the drive came in, and turned it off as the last 
thing it did before going into the loop to wait for the next pulse.  It was 
done, had issued all the commands to the machine, and generated the video 
bytes that would be DMA'd to my 8.8 format 2 digit generator that made 
characters 103 horizontal lines high vertically and about 40 u-s wide since 
we needed to be able to read them from across the control room on a 5" B&W 
monitor.  Counted down from 9.9 to 1.9 seconds before the first frame of 
video that was to be switched to air.  With all that monkey business it was 
done in the middle of line 19 of each field. Nominally 1200 u-s.  I was the 
ACE at KRCR-tv in Redding CA at the time.

Another interesting chip, somewhat later time frame but still in the 
megacycle clock era was what was the TI-9900 in the TI-99/4A.  That thing I 
believe had only 2, 16 bit registers and the 16 bit alu.  All its actual 
registers were kept in memory!  Including its stack and program counter.  A 
"context" switch was as simple as pointing the internal register pointer at 
a new image of the registers.  It left the preceding procedure untouched 
while it executed a "subroutine", and when the subroutine was done, the 
pointer was reloaded with the base address of the register image it had 
left, and other than the time elapsed, neither process knew of the other.

But I think the lack of fast memory kept it out of the speed running when 
some of the other cpu's started cranking up the clocks.  That was in the 
era of 350ns dram, at $10 a kilobyte.

Yeah, memory lane.  Its a long winding road that for me stretches back to 
about 1939, on a farm in Madison County IA., where all those bridges 
Eastwood and Streep made a movie about were.  And I've covered most of the 
country west of the river working, till I came to WV in '84 & decided to 
ride it out, come what may, I had found my "place" at WDTV-tv.  The woof 
didn't like WV, left & took the kids a year later, and I wound up with an 
old maid music teacher I finally made legal in '89, so next Dec 2, we'll 
have 25 years in without ever strongly thinking of an Alaskan Divorce.  And 
by then I'll be 80.

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)
Genes Web page <http://geneslinuxbox.net:6309/gene>

Rotten wood cannot be carved.
                -- Confucius, "Analects", Book 5, Ch. 9
A pen in the hand of this president is far more
dangerous than 200 million guns in the hands of
         law-abiding citizens.

------------------------------------------------------------------------------
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments & Everything In Between.
Get a Quote or Start a Free Trial Today. 
http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk
_______________________________________________
Emc-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/emc-developers

Reply via email to