🚀 go-pugleaf

In article <1990Aug5.070528.4522@amd.com> phil@brahms.amd.com (Phil Ngai) writes:
>In article <833@hls0.hls.oz> geoff@hls0.hls.oz (Geoff Bull) writes:
>|AMD have dropped plans to supply PALASM90 for Suns and Apollos.
>
>I don't speak for AMD, in fact, I'm not even working for them right
>now, but I couldn't resist:
>
>PALASM90 for Suns? Which Suns? Sun-3? Sun-386i? Sparc? Which OS of
>the week? (when we upgraded the OS, it broke "less".) Which window
>system? Suntools? Sunview? X? News? Now take all these choices and
>multiply them together. Sun-3 with X. Sun-3 with News. Sun-3 with
>Sunview. Sparc with X. Sparc with News. Sparc with Sunview. etc.
>

What's the big issue over supporting PALASM on multiple machines ?
the original PALASM, or PLPL (also from AMD) used a straightforward
command line interface that did the job of converting a written input
to a JEDEC textfile output perfectly adequately (within the limitations
of PALASM's syntax).

Who needs coloured screen, menus, etc etc - I'd much rather be able to
use 'make'! There may be a limited use for schematic capture, but that
seems to be rather against the point of a PAL designs as _software_.
Even state machines can be adequately defined using text - and have been
for years.

Leave the pretty stuff for the PC users - just give the rest of us a
compiler that provides a useful syntax and keeps up to date with the
PAL technology.

-adrian

-- 
------------------------------------------------------------------
Adrian Godwin          | -------- < standard disclaimer > -------- 
agodwin@acorn.co.uk    | -- This quote intentionally left blank --