Subject: DECmate II and os/278

From: [email-masked] (alex svirsky)
Date: 6 Sep 1994 18:02:04 GMT

Hi!  A couple of days ago I made an os/278 system disk for
the DECmate, from the Teledisk file, and I have been playing with it
since, but I have a couple questions:
	I have been trying to set up basic for os/278 with no luck.  I
got basic.pa, basic.tx, bcomp.pa, and bload.pa from sunsite.unc.edu, and
I followed the instructions regarding pal, load and save found in the
*.pa file headers.  With basic.sv, bload.sv, and bcomp.sv on rx50:
typing "basic" gets the RX50 spinning and the heads move a bit, and then
the message "INCOMPLETE SYSTEM" appears and I get the system prompt.  I
am using a DECmate II with ROM 31Z if that makes any difference.  I
haven't tried it on my DECmate III yet.
	I also tried to get focal to work, but didn't seem to have much
luck with that.  I assume it is because it wasn't written for the
DECmate.  Is there an os/278 version?
	I am unfamiliar with most programming except for basic, but I am
trying to change that.  I got a copy of DEC's Intro to Programming for
the PDP8 (1969).  It has been useful.
	Another question came up while writing this.  Kermit-278 froze 4
times while writing this post.  The only fix I know of is to exit Kermit
and run it again from the prompt.  It happens while typing rapidly while
the host trys to update the screen.

	It's a long list of questions, but people here seem to know what
they are talking about.

	Thanks for the help!
	Alex Svirsky			[email-masked]

---

From: [email-masked] (Charles Lasner)
Date: 8 Sep 1994 09:53:54 GMT

In article <[email-masked]>,
>haven't tried it on my DECmate III yet.

Using the DECmate II with the 31Z ROM revision means a few things, but 
not anything you mentioned.  But since you do have one of these things, 
let me elaborate:

1)	All of these revision machines were *supposed* to be eliminated 
in favor of upgrades.  Clearly they were not!

2)	Some of them have an unreliable RX50 circuit which is easily 
fixed by a few wires worth of ECO.  If you lack a few green wires near 
the RX50 connector, then you need to upgrade.  Contact 
[email-masked] for details of all hardwre upgrades except for ROM's; 
I do those :-).

3)	Assuming the few green wires are present, you most certainly 
won't have the big ECO that adds scads of green wires.  The most obvious 
sign is lack of the graphics board two-prong connector on the area 
underneath the graphics board-specific connector.  Newer boards have the 
connector soldered into the board; older ones have it glued on and 
connected to ECO green wires.  31Z goes away along with this ECO, thus it 
would be bizarre that you have old ROM's on a newer board, etc.

4)	Unless the graphics ECO is done, you can't use the graphics board 
option, but if you upgrade the ROM set, you can use anything else, 
including the APU/XPU boards, RX78 or hard disk and controller.  The 
APU/XPU is not afected by the ROM revision.

5)	Version 31Z is ignorant of the newer format of slushware.  It 
loads it in (painfully slowly) in the wrong format!  The newer-type 
slushware actually checks for this, and includes a routine for the benefit 
of 31Z that *reloads* all of the slushware all over again (also painfully 
slowly!) in the proper format.  (The first slushware block is always read 
in by any version correctly.  Within this block is the code that checks 
if the other 19 blocks were misread, etc.)  You can really get noticeable 
boot time improvement if you use a system written on an optimized 
diskette (using FDFORMAT, TELEDISK, etc.) since this is literally the 
worst-case of all DECmates.  (Better still, also upgrade the ROM's!)

6)	Newer slushware expects the ROM to handle four functions correctly:

	i)	Setup panel
	ii)	Halt panel
	iii)	RX50 boot operation
	iv)	Boot-best-available-device operation

Note that on DECmate III or floppy-only DECmate II function iv becomes 
function iii.

If the ROM is 31Z, then all operations become i which is incorrect.  The 
most annoying is that HLT shouldn't go to SETUP, since it means you can't 
continue from the HLT, etc.

7)	A hard disk isn't supported at all.  Obsolete attempts are made 
to control a possible hard disk, but this is thoroughly obsolete, and not 
supported in the released version of the disk controller, etc.

Re BASIC:

Try adding a copy of BRTS.SV.

>DECmate.  Is there an os/278 version?

You may be a victim of stray interrupts.  In spite of the 
incompatibility, FOCAL's lame console handling is compatible with the 
subset of the real -8 interface simulated in the DECmate!  You may need 
to incorporate a patch to inhibit some devices, etc.

>	I am unfamiliar 
with most programming except for basic, but I am
>the PDP8 (1969).  It has been useful.

Only if you avoid any advanced discussion of peripherals will it be useful!

>the host trys to update the screen.

Yes, a known limitation is that for high-speed connections, this can 
happen especially if the screen support for a VT-100 family terminal is 
enabled.

One of my long-term projects is to rewrite the slushware to allow "hooks" 
for comm port character grabbers.  The problem stems from the fact that 
the DECmate simulates a VT-220-like terminal in CP memory which is 
enterred by trapping the console instructions, etc.  Since the comm port 
is a real, semi-normal interrupting peripheral, these CP routines might 
take too long to get back to the -8 code that is the terminal program 
within Kermit-12.  PDP-8-style interrupts are *not* a solution to this 
problem!  The only way to handle it is to allow for comm port character 
buffering *during* the CP memory routines.  Note that CP memory is not 
interruptible by the comm port, but the comm port flags can be checked, 
and the characters grabbed, etc.  A complication is that the flag is 
shared by the output as well as the input, thus a calling program (such 
as a replacement for Kermit's terminal routine) would have to check 
periodically for CP-induced output flag changes, as well as CP-induced 
buffered characters, etc.  Anyone familiar with the last few versions of 
TECO-8 will understand the logic here.  In TECO-8 the high-speed escape 
sequences of a console terminal could get lost; buffering routines called 
by highly used subroutines guaranteed that characters wouldn't get lost.  
Lossage of this type isn't possible in the simulated case of the DECmate, 
but instead this output problem is present, etc.

>	It's a long list of questions, but people here seem to know what

Hope that makes a dent in it :-).

>	Alex Svirsky			[email-masked]

cjl