Newbie question about loading and running 8K BASIC in simh

[MogensB]

Hi,

I am trying to load and run 8K BASIC from paper tape in my simh PDP-8.

However, I don't think I am doing it right... I get the READY. prompt and then it just locks.

I follow this procedure in simh:

Initially, I prepare the RIM loader and then do:

sim> att ptr binload.bin

sim> go 7756

CTRL-E

sim> e 7777

7777: 5301

sim> att ptr dec-08-lbasa-a-pb.pt

sim> go 7777

HALT instruction, PC: 07701 (KCC)

sim> go 1000

READY.

And then it stops responding, no keyboard echo.

So - something was loaded, but I am not sure if it is the right paper tape file? And I am also not completely sure if 1000 is the correct entry point?

Am I wrong in my expectation that this 8K BASIC is an interactive BASIC?

Regards,

MogensB

[Steve Tockey]

Hi,

I can't say if the tape image you have is the right one. But answering a couple of your questions:

*) Is 01000 the correct entry point?

According to the 8K BASIC user's guide ( http://www.bitsavers.org/pdf/dec/pdp8/basic/DEC-08-LBSMA-A-D_8K_BASIC_Jul73.pdf), yes it is. See page 58.

*) Is 8K BASIC interactive?

Yes, it is. See the same manual, e.g., page 6.

One other thing to mention is that when BIN Loader halts, you should be sure to look at the contents of the Accumulator register. If the AC is 0000 then the checksum on the tape matched the computed checksum on reading the tape in. Any value other than 0000 in the AC means that either the tape image is somehow corrupt or there was an error reading it in (the second possibility is highly unlikely, IMHO).

Are you only interested in 8K BASIC for the PDP-8? There are several options for running BASIC on PDP-8s. For example, EduSystem is a whole series of versions. See the EduSystem Handbook:

http://bitsavers.trailing-edge.com/pdf/dec/pdp8/tss8/EduSystemHandbookJan73.pdf

I frequently run EduSystem 20 version C on my PiDP-8/i's. A known good tape image for Edu20C can be found here:

https://www.dropbox.com/sh/wuvrx36j48mf76c/AAAlihF5zSB36YMihbIM1FiIa?dl=0

Cheers,

-- steve

[Vincent Slyngstad]

OK, I had a look at this, and found that it is hung in interrupt service.  The 6663 at location 6641 always skips, so it thinks the line printer is ready, services it (issues a 6667 instruction), and returns.  But it never got as far as checking for TTY input, which is after the line printer.  So keyboard input is never seen.

Try typing 'd 6644 7000' to SIMH after loading dec-08-lbasa and things should get better.

Why is SIMH skipping on the 6663 instruction?

Vince

[MogensB]

Hi Vincent,

Thank you very much for spending some time on the problem, with your suggested patch (d 6644 7000) I now have the 8K BASIC running!

I am still too much of a PDP-8 newbie to fully understand why this works.

Following your advice, which works well, I also tried to do a set lpt disabled before loading BASIC, and that workaround also seems to work (obviously, the LPT is not ready when it is disabled).

Regards,

Mogens

[Vincent Slyngstad]

On Sunday, June 13, 2021 at 2:46:02 AM UTC-7 MogensB wrote:

Hi Vincent,

Thank you very much for spending some time on the problem, with your suggested patch (d 6644 7000) I now have the 8K BASIC running!

I am still too much of a PDP-8 newbie to fully understand why this works.

Following your advice, which works well, I also tried to do a set lpt disabled before loading BASIC, and that workaround also seems to work (obviously, the LPT is not ready when it is disabled).

I got curious and the input routines are usually pretty simple :-).

I think what's going on is that SIMH has arranged that the "printer" is "out of paper", since there's no output file attached.

Since the line printer isn't ready (and printer interrupts will be disabled anyway after the first one), that doesn't generate an interrupt request.  However, the way that interrupt service routine is written, only a single device is serviced per interrupt.  So, when it notices the "error" condition on the printer, it tries to clear it and return.  That leaves the keyboard interrupt request still unserviced, so the interrupt is taken again,.  Since nothing has actually changed, the process repeats endlessly.

My patch removes the "jmp iret" after the printer code, replacing it with a NOP.  Then interrupt service falls through onto the terminal input check, and the input interrupts can get serviced.

Vince