> On Jan 19, 2024, at 10:34 PM, Rodney Brown <rdbrown0au(a)gmail.com> wrote:
> ...
>
> I'm not a polymath who keeps lots of Assembly mnemonics in my head, so I hoped the "IEEE Standard for Microprocessor Assembly Language" IEEE Std 694-1985 1985 doi:10.1109/IEEESTD.1985.81632 would have taken off. I think only the Motorola 88000 used it and C probably was far more prevalent. I think the HPPA 1.1 then started the trend of SIMD instructions, so the portability would have reduced.
I had never heard of that IEEE standard, and it doesn't seem to have gone anywhere. Which makes sense; assemblers represent the architectural choices of the hardware, so standardizing them is a strange notion. You could standardize a style of construction (making it sort of a "meta-standard") but that isn't very interesting. The general style of opcode and operands had been the predominant style by then, and for a long time before. Other styles, like CDC 6000 Compass (CPU side) or stranger examples seen on Electrologica, haven't been used in ages.
About the only style issue that would be nice to have consistent is ordering: does destination come first, as with ARM and IBM 360, or source first as with PDP-11 and VAX? Then again, I suppose that's just about as hard a problem as byte order.
paul
Forth was ported to an HP-2100 in 1972, by Elizabeth Rather, so had early
history on HP hardware, though from what I can it it was never a product
available from HP.
I don't know if Forth Inc ever supported Forth on HP machines.
Anthony Pepin provided a Forth to the HP3000 Contributed Library in
September 1982, though I think his looks like a virtual machine, I don't
remember trying it in the day.
Thanks to Gavin Scott's "system" and J. David Bryan's SIMH HP-3000 emulator,
I can look at it now.
As Anthony Pepin observed, Forth implementations at the time assumed a
von Neumann architecture. The HP 3000 with a Harvard architecture implying
read-only code with a different address space, needs more thought.
Why Forth?
I've never been a Forth programmer, but as I understand it,
compilers/interpreters weren't standard with HP 3000 Systems, nor were
there
scripting languages like awk, sed & perhaps the Bourne shell on Unix.
A Forth interpreter supporting the HP 3000's supported types & the
mathematical
functions in SL.PUB.SYS (the system shared library), even without
compilation,
would have been bettered by the Unix dc (RPN calculator) only for it's
multi-precision maths.
HP 3000 types (using kludged C <stdint.h> style
int16_t => INTEGER, uint16_t => LOGICAL, int32_t => DOUBLE
f32_hp3k_t = REAL, f48_hp3k_t => LONG REAL
COMPLEX & Packed Decimal?
A Forth supporting code compiled to Data space would have been a useful tool
for learning & testing & perhaps as a scripting language.
With Date & Actuarial procedures added, I suspect our Actuarial students
would
have found it useful. Don't know if it would have been seen as useful at
educational institutions like RMIT here in Melbourne, Australia that had
3000s.
Assemblers in Forth seem to be a common thing, it would be possible to
assemble the Data space code with minor peephole optimization, and the
necessary
translation from modifying the Next Data instruction variable to
branches in the
code. That and the Dictionary entry could then be written out as an
input file
for PATCH.PUB.SYS, allowing the interpreter to be extended without
understanding
the USL format.
I've finally read some of Koopman, Philip (1989) "Stack Computers: The
New Wave" looked a little at his Harris RTX-2000 MS-DOS Emulator source,
and at
James Bowman "J1: a small Forth CPU Core for FPGAs".
Like the HP 3000, the Harris RTX-20[01]0 & the J1 are 16-bit machines with a
16-bit instruction width (soley for the Harris & J1).
Other than the HP 3000, the architecture use the sign bit to use the
instruction
value as a call-target address or decode an ALU operation with some Forth
special sauce.
I've wondered for a while whether the HP 3000 XEQ instruction which
executes a
stack adressable 16-bit word (0..15 deep on the Stack-Up stack (S register))
has been used for anything other than exiting to clean up the stack on a
Ctl-Y
trap.
A virtual Forth machine where negative int16_t values give a negated call
address, with the least-significant bit selecting Code or Data.
Almost all 16-bit HP 3000 instructions are positive.
Below is an SPL sketch of the virtual machine interpreter
Nonsense @ characters are *Fix Me*s
equate Deepest = 15, Dict'Sz = 1024, Padded'Dict'Sz = Dict'Sz + 16;
integer X = X;
logical PB'Address; << Poor Name>>
logical bu'S'15;
pointer restore'S'15;
logical S'15 = S - 15;
logical D'Dict'Used := 0;
logical Code'Offset;
label Next'Word, Execute'TOS, ...
integer array D'Dict(Padded'Dict'Sz);
<< Code must immediately follow, need to access padding perhaps >>
Next'Word:
TOS := D'Dict(Code'Offset);
if < then begin << Call (int16_t < 0) >>
Return'Stack'X := Return'Stack'X + 1;
Return'Stack(Return'Stack'X) := -((Code'Offset + 1) & LSL(1)));
assemble(NEG, DUP);
if TOS then begin << Odd => PB (Code) address >>
PB'Address := TOS & LSR(1);
Assemble (@); << Indirect Jump through PB'Address Variable >>
else begin << Even Data Address >>
TOS := TOS & LSR(1);
assemble(DUP);
if TOS >= D'Dict'Used then begin
Error(@);
end
else begin
Code'Offset := TOS; << Weak bounds check >>
goto Next'Word;
end;
end
else begin << (int16_t >= 0), HP-3000 16-bit instruction >>
Execute'TOS:
bu'S'15 := S'15; << Needs testing, backup the value >>
@restore'S'15 := @S'15; << Save Data address of stack element >>
S'15 := TOS; << Save the instruction as deep as possible >>
assemble(XEQ 14); << Needs testing probably wrong depth number >>
<< Execute the instruction just deposited >>
restore'S'15 := bu'S'15;
Code'Offset := Code'Offset + 1;
goto Next'Word;
end;
<< Not sure how to handle end of the Forth code in Data
Could call to a PB (Code) address or do an indirect branch through
a procedure local to the handle code. So in data, a sentinal of
sorts>>
<< Have Execute'TOS as a label for flexibily >>
<< Basically, Search the DB (Data) Forth dictionary, if found interpret
the data
code, otherwise search the PB (Code) Forth dictionary, if found jump to and
execute the the code directly. >>
<<Restoring & Saving the Status register around each XEQ instruction use,
would be better as a teaching tool & allow using Condition Code effects
when the
Forth word is compiled to Code space. >>
--
The output from BUILDINT.PUB.SYS over a copy of SPLINTR.PUB.SYS gives
the type
signatures of the System Intrinsics and compiler library routines.
This could be curated & processed to generate shims for calling from the
Forth
interpreter, though the Option Variable Procedures would take some thought.
There seem to be ~600 declarations, some of which are duplicate entry points
for the Fortran compiler library for REAL & LONG REAL functions. (ie
RAND & RAND' etc), so you'd need 3 or
more code segments to get around ~256 STT (Segment Transfer Table) limit to
call everything.
Virtual Stack machines executing directly on the HP 3000 stack was what
our COCAM
language did.
Comments? Were HP doing anything like this in the labs?
Philip Koopman's Stack page at CMU
http://users.ece.cmu.edu/~koopman/stack.html
>Message: 17
>Date: Mon, 15 Jan 2024 12:52:15 -0500
>From: Bill Gunshannon <bill.gunshannon(a)hotmail.com>
>Subject: [cctalk] Re: WWVB
>To: cctalk(a)classiccmp.org
>Message-ID: <SA1PR17MB5737C194F181927517114C55ED6C2(a)SA1PR17MB5737.nam
prd17.prod.outlook.com>
>Content-Type: text/plain; charset=UTF-8; format=flowed
>
>On 1/15/2024 10:47 AM, Chris Elmquist via cctalk wrote:
>> On Sunday (01/14/2024 at 09:55PM -0600), Chris Elmquist via cctalk wrote:
>>> There are a number of WWVB simulator projects out there that will transmit a weak but usable signal to your clock after getting sync’d from ntp or GPS NMEA time messages. They were developed to help people develop receivers :-) One in particular uses an AVR and it should be pretty simple to make it do the “old protocol”. You’d then hide this behind your clock and it will sync to it instead of the actual WWVB signal. Solves the protocol problem and the weak signal problem from real WWVB with one little circuit.
>>>
>>> If Google does not provide, I can dig up some links tomorrow.
>>
>> Hmm. Strange. I did follow-up shortly after the above post with this
>> link,
>>
>> https://www.instructables.com/WWVB-Simulator/
>>
>> but I don't see that that made it to the list.
>>
>> Chris
>>
>
>It did. I got it.
>
>bill
Your original email with the link did not make it into the digest, which is what I receive.
Chirs, Did you also send it directly to Bill. Perhaps that is what he got.
Bob
This is kind computer related but maybe more ham radio related
but I figure if anywhere, here is the place to find an answer.
I have a SkyScan ATOMIC CLOCK.
It is supposed to get its time from WWVB.
The antenna icon that is supposed to mean it is receiving
WWVB is on.
Your probably wondering why I keep saying "supposed to".
The clock is always wrong. Slow by about 2 minutes.
Is there a known problem with WWVB?
bill
Hi folks -- long time no post.
I'm wondering if there's anyone who would be interested in trying to fix my
Shugart 850/851 8-inch floppy drive. It was new old stock when I bought it,
and hasn't been used much, but last time I tried it, it would no longer
read any data from the back of a floppy, only from the front. I use it with
a Catweasel and my cw2dmk software, so I was able to try a few experiments
from the software side. What I see is just plain noise coming out on the
data line when reading the back.
It's possible of course that some unobtainium chip has gone bad, so I don't
expect much. But it would be nice if someone with more electronics skill
than me, and more knowledge about these drives in particular, would be
willing to take a look at it.
The drive is of course big and tough to ship, so it probably only makes
sense for someone within driving distance (I can drive it over or you can
come by), which means being in the SF Bay area. I live in Palo Alto right
near downtown.
FWIW, the drive and a power supply are mounted in a case that I made by
ripping the guts out of a surplus desktop PC case. The power supply seems
fine and the drive can read the front of disks fine.
Thanks for any help,
Tim
Hi!
Due to a broken water line, I ended up with a blown BM200-3601 power
supply in a HP workstation. These seem to be notoriously failing due
to bad caps, but mine was fine until flooded.
Found few offers in the USA (~ 1400 US-$), but adding taxes and
shipping to Germany, that would probably end at around 2000 €. That's
well beyond what I'd be willing to spend on it. :(
Thanks,
Jan-Benedict
--
For those needing a decent price on hotels, check out the hotel blocks
page: https://vcfed.org/vcf-east-hotel-blocks/
Thanks!
Jeff Brace
VCF National Board Member Chairman & Vice President
Vintage Computer Festival East Showrunner
VCF Mid-Atlantic Event Manager
Vintage Computer Federation is a 501c3 charity
https://vcfed.org/ <http://www.vcfed.org/>
jeffrey(a)vcfed.org
