prirun / p50em

Prime 50-Series Emulator
Other
37 stars 10 forks source link

Punch/reader devices? #31

Open WA6YDQ opened 3 years ago

WA6YDQ commented 3 years ago

Per line 1676 of em.c, no punch or reader devices are defined. Am I missing something, or is there no code for these?

If not, will this be something that may be included at a later time?

Thanks!

drboone commented 3 years ago

Tape readers and punches were only supported on the early SOC (System Option Controller) and even earlier Option A/Option B boards as far as I know. Card readers and punches were supported by URC (Unit Record Controller) boards. None of these are implemented. The emulator framework certainly supports adding such things, should someone feel so motivated. No one has expressed such motivation yet. :)

WA6YDQ commented 3 years ago

Got it. It would be a simple way to read in/output large text files from the outside world under program control. Not a lot of motivation for it, but I am having fun playing with my new toy here!

hashbackup commented 3 years ago

I think most people use Kermit to get files into/out of the emulator.

I first started using Primes (a P400) in 1977, then went to work for them in 1980 for 18 months. I used them until the early 90's when the company started its decline. In that whole time I saw one card reader hooked to a Prime but no card punch, tape punch, or tape reader.

Funny story: when I was an OS specialist at Prime, another analyst (Hi Andre!) took me to DeVlieg Machine Co to help debug a printer problem. They said sometimes their line printer printed really fast like it was supposed to (600 lpm or something), but sometimes it printed really slow, like 60 lpm. When we got there it was printing fast, so we just hung around a while. When it started printing slow, I was running "usage" to see if the system got really slow (it didn't) or was paging like crazy (it wasn't). The printer is driven by mpcdim, so I started fiddling with the switches to display the counter of mpcsem, the semaphore mpcdim waits on when it is idle, to try to figure out what was going on. While doing this, all of a sudden it starts printing fast again. WTF? We're scratching our heads trying to figure it out, then it starts going slower again. I happened to notice that a lady in the room threw a batch of cards into the card reader at the same time the printer slowed down. Bingo!

It turns out that one mpc board could support 2 printers and a card reader. Both printers could print at their highest speed, but when cards were being read, it locked up the board, firmware, or Primos driver (can't remember which) until the card was finished reading. Since the card reader read about 60 cpm, whenever it was activated it would slow the printer down to 60 lpm too! Got a good laugh out of that one. The answer to the customer was "Sorry, don't use your card reader if you need to print fast."

drboone commented 3 years ago

Kermit can work for some file transfer. I usually create a tarball on the outside and use UX_TAPE to read it in PRIMOS. Going the other way, I create a MAGSAV tape and read it with one of the unix-side MAGRST tools.

Having a URC would be fun from a historical perspective, too. Perhaps some motivation will visit me someday!

drboone commented 3 years ago

Heh, Jim's comment popped onto the screen above my compose box just as I was reaching for the Comment button.

hashbackup commented 3 years ago

If anyone wants to try this, the MPC/URC controller is very straightforward compared to other controllers, especially if you only support printing. There should be an LBD (Logic Block Diagram) book floating around somewhere. I donated one to the Computer History Museum if Dennis doesn't have it. It will show all of the I/O commands for the board, how it affects various status registers, etc. By looking at that and the Primos source in primos>ks>mpcdim.pma, you should be able to implement a printer. These are assigned as devices PR0 or PR1, and you can use the simple "prmpc" command to dump a file to the printer without having to mess with configuring the Prime spooler (the queued print job handler).

As a good example, you could take a look at the emulator's tape driver, and specifically, the write section. The tape controller uses DMC I/O, like the MPC/URC controller. Emulating an MPC would be way easier because it's output-only.

Give it a shot - you'll have fun!

drboone commented 3 years ago

https://sysovl.info/pages/blobs/prime/archhw/LDS1933%20URC%201975.pdf

WA6YDQ commented 3 years ago

I never thought of using Kermit. Hmmm. My first prime was a 550 that my college purchased in late '79/early '80 and also my 1st real computer. I loved that thing! There was a card reader (probably used to read the old fortran cards used on the older IBM it had). If it was used, I never saw it in operation.

Thanks for the quick replies!

hashbackup commented 3 years ago

The other thing you can do if you have lots of data is use the Unix version of magsav/magrst to create tape images on Unix that can then be read into the Prime. Or it also works the other way, where you use magsav on the Prime to create a tape image, like mt0 in the emulator directory, then you can read that in Unix with the Unix magrst program. The Unix magsav/rst tools will try to autodetect text files and flip the high-order bit appropriately for the target system, and also fix line endings and compression. On the Prime, lines in a text file could be blank-compressed, so that has to be expanded for Unix. And each line had to be an even number of bytes by adding a trailing zero to the newline character if necessary. That zero has to be removed when writing to Unix or added when writing to Prime. Taken together, these 3 things (and the 128KB segment limit and no byte addressing) are the main reasons Prime had so much trouble trying to bridge customers over to more modern system architectures.

WA6YDQ commented 3 years ago

Just tried that - it works very well! The emulated tape might be the solution, but does require operator intervention (convert to tape format, then run magrst from the telnet session). Then have a compiled program (fortran, whatever) open the file, read it it, act on it. I guess the only difference with not having a card reader is the extra step of running magrst (which is not a problem at all).

This is all basically a toy setup for me anyway. The tape solution is functionally the same (file called mt0) vs. a file called CARDDECK or some such. Works for me.

hashbackup commented 3 years ago

You can also check out expect, to automate all this. It's like the old DOS Procomm / Crosstalk scripts that let you automate a communication session with a host: wait for this, send these keystorkes, wait for that, etc.