simulated peripherals, but with physical appearance (and handling)

[Henk Gooijen]

Starting a new thread, because this topic started in Rene Richarz thread "Logo for DIGITAL rack for PDP-11".

TU56

Two electronically (electro-mechanically) controlled audio tape decks would be a basis for a TU56 replica.

Cassettes with metal "tape reels" are available, but 3D printed replica DECtape reels to hold the cassette tape would be a lot nicer (but more work). Ditto for the reel hubs.

I need to read the TU56 operation, but I think that one track on the tape is used as clock.

As tape moves from one reel to the other, the diameters change. Without corrections this would mean that the tape speed is not constant over the head. I think DECtape does not need that. Some electronic design work is needed to read and write data to/from tape. If constant speed would be needed, you could use one track of the cassette tape to record (on an audio tape deck, before removing the spools from the cassette) an audio tone. When moving the tape on the TU56 replica you get the recorded tone and with some electronics (PLL) you control the reel motors so that the tone is (and remains) correct.

An other approach would be not to use existing cassette tape decks, but construct something using two stepper motors. Now the distance between the two motor axes is no longer hard defined (as with a cassette tape deck) and 60% sized DECtape reels with proper spacing becomes possible. Any tape deck (simple mechanical ones included) can be used as "donor" for the read/write and erase heads, and if you can find schematics the electronics might be re-usable too. But developing some electronics to connect the R/W and erase heads would not be too hard either.

The driver code in SIMH will need modifications!

RX02

I bought two nice looking 5.25" floppy drives (the ones that open with a small lid in the middle, not a lever on one side).

One day I will try whether the 3.5" USB hardware can also control a 5.25" floppy drive. That would simplify matters a lot: just two USB connections. If that proves not-working, a lot of work has to be done. The driver in SIMH needs serious modifications, because the current DY driver (and DX driver) simply read the entire "floppy" in memory. This has to be changed to reading/writing sectors and control the drive mechanism. It seems that the software-side is a lot more work than the hardware-side ...

RK05

The drive is finished, but on my desk in parts (need to be painted black). The 3D scan of a real RK05 cartridge is done, resizing the scan to print a cartridge at approx 60% (diameter ~20 cm) is easy. What needs to be done is creating a"box" inside the cartridge to hold the USB memory stick and the coupling link. The PCB for the switches and indicator lights (driven via I2C) is done and works. The RK05 driver in SIMH is modified. Needs to be tested ...

LPS11

This is a laboratory peripheral offering a 6-digit 7-segment display (counter), relay contact outputs, analog inputs and switch inputs (from my head, I could be wrong). Hardware-wise not too difficult, but it will need software to be added to SIMH.

just some thoughts ...

[Jon Brase]

For more than just the PiDP-11, I'd really like to come up with some retrocomputing standards for old-style removable storage that can be used across platforms (with devices for each platform possibly "dressed up" to look like vintage devices for the platform). Even 3.5" floppies and drives are becoming a rarer commodity these days, especially the disks: over the past decade or so, a significant number of PC floppies that once worked for me no longer work. There are two avenues of attack here, the "preserve the feel" avenue, using hobbyist-manufacturable equipment and media at historical bit densities, so that the media are approximately the size of legacy media, and the "convenience" avenue (this is the avenue most relevant to the PiDP-11), where we generate a standard for presenting image files on modern storage devices to legacy hardware (think of a legacy PC with all of its ATA and floppy ribbon cables going into one device, which is then attached by SATA to a modern HDD, or by USB to a flash drive). The latter avenue would not be so relevant to the PiDP-11, as any emulated system generally includes this by default, but might be useful for real-hardware PDP-11s or FPGA reimplementations.

In any case, even just restricting things to the PiDP-11, I think it would be best to develop drives and media that are hobbyist-manufacturable, rather than cannibalizing legacy hardware that is no longer manufactuered, where there is a limited number of existing drives and media that will eventually wear out. Using cassettes for tape drives is somewhat borderline here: the format is on the way out, but there does seem to be at least some number of  both tape decks and tapes manufactured, so depending on how long the afterlife of the format lasts, it may still be viable.

For floppies, OTOH, I think it would definitely be best to develop a new floppy format where drives and media can be made with parts that will be available to the average citizen for the foreseeable future, or at least are 3D-printable or otherwise home-manufacturable. The big sticking point here is probably the media: other than in already-manufactured cassette / VHS / floppy media, I don't think I've ever seen the magnetically coated film used in those products. I've certainly never seen it sold by the square foot, and I don't know if anyone will still be manufacturing it once cassettes are gone, nor do I know how a person could go about home-manufacturing a substitute.

Now, the densities used on floppy disks aren't all that great: you could get the same information-storage density printing/scanning black-and-white at 90 DPI (for 1.44 MB 3.5" disk), so it should in *principle* be hobbyist-doable, but ink-on-paper itself is write-once, which isn't what we need to make hobbyist manufacturable floppies, we'd need something rewritable.

Now, it may actually be possible to home-manufacture a legacy-compliant floppy drive and disk, in which case the future supply of equipment for that format is not so much of a concern. But barring that, I wouldn't be surprised if most currently-readable 3.5" media are toast 10 years from now, so I think we should look to determining if home-manufactured legacy-compliant drives are plausible, and for what to do to replace them if not.

 

LPS11

This is a laboratory peripheral offering a 6-digit 7-segment display (counter), relay contact outputs, analog inputs and switch inputs (from my head, I could be wrong). Hardware-wise not too difficult, but it will need software to be added to SIMH.

just some thoughts ...

Oscar has already provided proof-of-concept code for interfacing an I2C thermal sensor to SIMH, so the software side shouldn't be any big problem. And in the end, it's all software anyway: building hardware is just how we submit a card-deck at the computer-room front window of the universe. :-)

The peripheral I'd like to add to the list is a paper tape punch, or functional equivalent. I've seen a number of people that have implemented their own readers, but nobody that's implemented a punch. The easy way would probably be to frankenstein a receipt printer and just print black and white squares on the paper, but that way you have to pay for ink as well as paper. The hard way would be to actually perforate the paper, which would save the cost of ink and be more historically authentic (but add the need to periodically empty a chad bucket).

[Rene Richarz]

On Friday, November 15, 2019 at 8:04:30 AM UTC+1, Henk Gooijen wrote:

TU56

Two electronically (electro-mechanically) controlled audio tape decks would be a basis for a TU56 replica.

Cassettes with metal "tape reels" are available, but 3D printed replica DECtape reels to hold the cassette tape would be a lot nicer (but more work). Ditto for the reel hubs.

I need to read the TU56 operation, but I think that one track on the tape is used as clock.

As tape moves from one reel to the other, the diameters change. Without corrections this would mean that the tape speed is not constant over the head. I think DECtape does not need that. Some electronic design work is needed to read and write data to/from tape. If constant speed would be needed, you could use one track of the cassette tape to record (on an audio tape deck, before removing the spools from the cassette) an audio tone. When moving the tape on the TU56 replica you get the recorded tone and with some electronics (PLL) you control the reel motors so that the tone is (and remains) correct.

An other approach would be not to use existing cassette tape decks, but construct something using two stepper motors. Now the distance between the two motor axes is no longer hard defined (as with a cassette tape deck) and 60% sized DECtape reels with proper spacing becomes possible. Any tape deck (simple mechanical ones included) can be used as "donor" for the read/write and erase heads, and if you can find schematics the electronics might be re-usable too. But developing some electronics to connect the R/W and erase heads would not be too hard either.

The driver code in SIMH will need modifications!

I looked at this video https://www.youtube.com/watch?v=tOWt7LIOVJs and others and noted a few things which might be relevant for building a TU56 scale model:

1. The tape moves very fast. Much faster than any audio tape or audio cassette I have ever seen moving during recording/playback. Any specs available? I think we need therefore to consider the solution with 4 stepper motors driven by something like an Arduino. Any solution using the mechanics of an audio tape will most likely not look good enough.

2. The actual movement of the tape is barely visible. A solution in which just the reels are rotated with a short piece of fixed tape would probably look quite ok. A bit of fluttering will also be seen when the wheels move. The actual tape is wider than cassette tape and it will therefore be difficult to obtain.

3. There is a strange whispering noise, which could of course be recorded and played back on the scale model.

4. The "stars" holding the tape reel could be 3D printed. 

5. Maybe we can buy somewhere some white reels of similar (scaled) dimensions. Many cheap products sell on reels. If not, we need to 3D print or laser cut them. Only 4 of those are needed if we do not actually record or read back real magnetic tape.

6. I don't know whether the special switches to set the drive number are still available. If not, we need to 3D print them.

7. All the rest appears to be doable, including modifying simh to talk to something like an Arduino over I2C  for the turning reels and the switches and lights.

I think what I will do next is to get some stepper motors and a stepper motor board, and build a little mockup out of cardboard and printed photos. That way I will be able to see how good a TU56 scale model with turning wheels would look.

[Johnny Billquist]

Rene...

Be aware that it's tricky if you drive it with two motors, as the
relative speed of them will differ depending on how much tape is on one
or the other reel.

A real DECtape actually have to motors pulling in opposite directions,
and that force the tape to be stable, and kept tight against the heads.

It starts running when one side stops pulling that much. And then (or
course) it moves the tape onto the other reel.

The issue with speed difference between the two reels is not a problem
with real DECtape, since the tape have 8 tracks. There are three data
tracks, which are duplicated for better reliability. There is one mark
track, and one clock track. The clock track is what all reads and writes
are based on, so tape speed can vary pretty much by any amount without
any problems.

The mark track is essentially a one bit per row of control information.
As tapes group data into 18-bit words, and there are 3 bits per row, one
word takes 6 rows. That also means the control information on the mark
track is actually 6 bits wide in the end.
And the assigning of codes on the mark track is done in a very clever
way so that data read in one direction have a code for end-of-tape. The
same code read in the other direction is start-of-tape. Same story with
start-of-block and end-of-block.

And data blocks have the same code read in either direction.

This means that you can essentially read DECtape in either direction,
and get the data out.

> 2. The actual movement of the tape is barely visible. A solution in
> which just the reels are rotated with a short piece of fixed tape would
> probably look quite ok. A bit of fluttering will also be seen when the
> wheels move. The actual tape is wider than cassette tape and it will
> therefore be difficult to obtain.

It is very much wider. However, we are talking about a scaled down
version, so then I wonder if normal magtape would not possible be close
to the correct width...

> 3. There is a strange whispering noise, which could of course be
> recorded and played back on the scale model.

It's just the effect of the tape running fast over the heads.

> 4. The "stars" holding the tape reel could be 3D printed.

They flex, but yes, I would think 3D printing could do it. Same story
about the reels themselves...

> 5. Maybe we can buy somewhere some white reels of similar (scaled)
> dimensions. Many cheap products sell on reels. If not, we need to 3D
> print or laser cut them. Only 4 of those are needed if we do not
> actually record or read back real magnetic tape.

Hmm. I wonder where you would find any reels with a somewhat matching
width and shape... But maybe I just haven't thought about the right
source yet...

> 6. I don't know whether the special switches to set the drive number are
> still available. If not, we need to 3D print them.

You need them in a different scale anyway, so I would definitely expect
you need to print them. However, that would be the TU55. The TU56, which
is slightly more modern, use rather small thumb-switches. Similar to
what you might come across on an RK05 (if you ever saw one with a thumb
switch for selecting unit #), or some other stuff that I cannot recall
right now...

Johnny

--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: b...@softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol

[Digby R.S. Tarvin]

I spent a bit of time on improving peripheral support in the dtcyber mainframe emulator ( http://www.control-data.info/) which has a similar nostalgic appeal to me to the PDP11/70 emulation (the first machines I first encountered as a student in the late 70s).

The one that made the biggest difference was adding real tape drives. It originally used ".tap" files to emulate tape reels, with an 'out of sim' command interface used to load the tape files (similar to simh command line).

What I did was change the tape interface in the emulator support support new config file options allowing a configuration file to replace a line such as:

MT679,0,0,13,DeadstartTapes/nos_digbyt.tap

which pre-loads tape unit 0 with a tap file containing the boot loader with

MT679,0,0,13,/dev/sg0

Which causes it to use a physical SCSI tape drive. It made quite a difference to the feel of the emulator, even using  non-period readily available low capacity USB DAT tapes, to have a bank of four physical tape drives rather than reading and writing files. The cheapness and availability of low capacity 8mm and 4mm USB tape drives and media obviously results from the fact that 1-2GB media is not very useful for backups on contemporary systems now. But it is fine on historical machines with discs measured in hundreds of megs. 

The ultimate objective, of course, is to get my 9 track upright SCSI tape drives working - to provide the full visual experience of spinning reels. But being able to isssue a command in the emulated system which causes a physical tape to rewind or physically eject is still a huge advance over to interract with an emulation console of some form. 

Other small improvemends include things like modyifying disk emulations to provide some visual feedback and control. For example, an RK05 that was just a visual representation of an actual drive, but with LEDs controlled by the emulator to show when it is accessed, and perhaps a toggle switch for the write control, would be enough for me.

For printing, I implemented an audio supplement which produces 'line printer' noise while the printer output displays in a scrollable window on screen with appropriate delays. 

Improving the mainframe console has so far been a software effort - replacing the X11 font use with vector rendering based on the original hardware specs, and overlaying a background image from a real display, but I have plans for an FPGA implementaton and a replica of the original keyboard :)

--
You received this message because you are subscribed to the Google Groups "[PiDP-11]" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pidp-11+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/pidp-11/9072129f-4911-4c84-80f1-18fba3e08af4%40googlegroups.com.

[sunnyboy010101]

As the original tape on the DEC devices is reported as 3/4in, using 1/2in audio tape as the scaled tape would be within reason. Used 8-track audio tape machines are available on ebay, as are some parts, making it a good starting point for a replica.

The idea of 3d printing the hubs and reels is sound to me.

Starting with a used (scavenged?) 8-track audio recorder, you have an entire transport mechanism and tape path. It would require reconfiguration to remove the capstan, but otherwise it's certainly well on the way to a workable solution.

A further bonus is the 8-track head would offer the needed tracks.

[Jonathan Morton]

> On 4 Dec, 2019, at 11:50 pm, Johnny Billquist <b...@softjar.se> wrote:
>
>> 2. The actual movement of the tape is barely visible. A solution in which just the reels are rotated with a short piece of fixed tape would probably look quite ok. A bit of fluttering will also be seen when the wheels move. The actual tape is wider than cassette tape and it will therefore be difficult to obtain.
>
> It is very much wider. However, we are talking about a scaled down version, so then I wonder if normal magtape would not possible be close to the correct width...

What about VHS tape? That's already a lot wider than in audio cassettes.

- Jonathan Morton

[Stephen Casner]

On Wed, 4 Dec 2019, sunnyboy010101 wrote:

> As the original tape on the DEC devices is reported as 3/4in, using 1/2in
> audio tape as the scaled tape would be within reason. Used 8-track audio
> tape machines are available on ebay, as are some parts, making it a good
> starting point for a replica.

The reel-to-reel audio tapes and the tape in automobile 8-track
cartridges is 1/4", not 1/2".

-- Steve

[Sunnyboy010101]

Um, apples and oranges. Yes, audio reel-to-reel was 1/4in, and the
so-called 8-track car decks were also 1/4in tape (looped), but I'm
talking about semi-pro audio recording gear.

  I currently have TWO 1/2" reel-to-reel 8-track audio tape recorders
(both Tascam, different models from different years). Both use 1/2in
audio tape, which was all that was needed for 8-track audio recording.
There were larger tape widths (1in and 2in) for pro-audio recording for
16 track and higher.

I also had an AKAI MG1214 12-track audio tape system that used a
cartridge system that was like the betamax video tape but ran 12 tracks
linear recorded audio. Tape carts became impossible to source some years
ago (pre 2000) and the deck itself was something like 3.x ft by 2ft by
6-10in high and weighed in the neighborhood of "dwarf star alloy".

[Lars Brinkhoff]

Digby R.S. Tarvin wrote:

Which causes it to use a physical SCSI tape drive. It made quite a difference to the feel of the emulator, even using  non-period readily available low capacity USB DAT tapes, to have a bank of four physical tape drives rather than reading and writing files.

In a similar vein, I attached a modern thermal receipt printer to emulate the feel of a physical teletype.  Of course it doesn't look anywhere near a real teletype but still, getting the output logged to real paper was a boost.

I have suggested to some 3D people they make a teletype model, and then maybe I could print that and put it over the thermal printer.

For printing, I implemented an audio supplement which produces 'line printer' noise while the printer output displays in a scrollable window on screen with appropriate delays. 

I have long maintained we need to preserve the noises of historical hardware!

 

Improving the mainframe console has so far been a software effort - replacing the X11 font use with vector rendering based on the original hardware specs, and overlaying a background image from a real display, but I have plans for an FPGA implementaton and a replica of the original keyboard

I'm very interested in this.  The PDP-6 and 10 emulators have support for the Type 340 vector display, but there's room for improvement.  There are recurrent discussions about making a physically based simulation of the phosphor layers, electron beam, magnetic deflectors, etc.

 

[Lars Brinkhoff]

sunnyboy010101 wrote:

As the original tape on the DEC devices is reported as 3/4in, using 1/2in audio tape as the scaled tape would be within reason.

In interested in smaller models.  A standard audio cassette tape is 3.8 mm.  Using that for DECtape would be 1:5 scale which is about where I'd like to be.

[Digby R.S. Tarvin]

On Thu, 5 Dec 2019 at 17:39, Lars Brinkhoff <lars.br...@gmail.com> wrote:

Digby R.S. Tarvin wrote:

Which causes it to use a physical SCSI tape drive. It made quite a difference to the feel of the emulator, even using  non-period readily available low capacity USB DAT tapes, to have a bank of four physical tape drives rather than reading and writing files.

In a similar vein, I attached a modern thermal receipt printer to emulate the feel of a physical teletype.  Of course it doesn't look anywhere near a real teletype but still, getting the output logged to real paper was a boost.

I have suggested to some 3D people they make a teletype model, and then maybe I could print that and put it over the thermal printer.

I bought the bits for one of those wheelwriter customizations with the intention of using it as a hard copy console. I don't have any history with the old teletypes. We used to use decwriters back when I used real PDP11s. I do have a decprinter (decwriter without the keyboard) in my collection - for when I want to print on fanfold paper.

  

For printing, I implemented an audio supplement which produces 'line printer' noise while the printer output displays in a scrollable window on screen with appropriate delays. 

I have long maintained we need to preserve the noises of historical hardware!

 

Improving the mainframe console has so far been a software effort - replacing the X11 font use with vector rendering based on the original hardware specs, and overlaying a background image from a real display, but I have plans for an FPGA implementaton and a replica of the original keyboard

I'm very interested in this.  The PDP-6 and 10 emulators have support for the Type 340 vector display, but there's room for improvement.  There are recurrent discussions about making a physically based simulation of the phosphor layers, electron beam, magnetic deflectors, etc.

Thats exactly why I really need a hardware solution. The real console was really a dedicated minicomputer with two scope displays. the computer continuously wrote pixels using x/y co-ordinates, and the display duration was determined by phosphor fade. Writing more or less often allowd high/low intensity characters. On a conventional raster  you have to write a bunch of characters and periodically clear the screen to get rid of old data, but there is no 'end of update' separater, so getting the timing wrong produces a horrible flickering display. I need something gradually fades everything written to it in constant time. Either an FPGA driver, or maybe some custom GPU code.

[Lars Brinkhoff]

Digby R.S. Tarvin:

On a conventional raster  you have to write a bunch of characters and periodically clear the screen to get rid of old data, but there is no 'end of update' separater, so getting the timing wrong produces a horrible flickering display. I need something gradually fades everything written to it in constant time. Either an FPGA driver, or maybe some custom GPU code.

Yes, of course you need to age the display.  We actually have three different implementations of this for the DEC 340 display.  Two are plain software (but I'd like to move this go GPU), and one FPGA.

[Rene Richarz]

On Thursday, December 5, 2019 at 8:35:23 AM UTC+1, Digby R.S. Tarvin wrote:

 The real console was really a dedicated minicomputer with two scope displays. the computer continuously wrote pixels using x/y co-ordinates, and the display duration was determined by phosphor fade. Writing more or less often allowd high/low intensity characters. On a conventional raster  you have to write a bunch of characters and periodically clear the screen to get rid of old data, but there is no 'end of update' separater, so getting the timing wrong produces a horrible flickering display. I need something gradually fades everything written to it in constant time. Either an FPGA driver, or maybe some custom GPU code.

The more realistic a simulation, the better. But exponential fading, for example, is very easy to implement.

When I wrote tek4010 I experimented with quite some different ways to simulate the storage tube behavior on a modern screen. The problem with tek4010 is the very large number of vectors which can be on the screen.

The tube you want to simulate is not a storage tube. Therefore, there is a limited number of vectors which can be displayed (mainly due to the drawing speed in inch/second). Do you have any idea how large the number of vectors are, before things bekame too slow and flickering started? In my experience it might very well be possible to emulate the the fading behavior of of such a tube by keeping an updating table of vectors and redrawing them between each screen refresh with fading intensity (controlled by one adjustable parameter). The overstriking behavior of writing multiple times at the same position you would basically get for free.

In principle I am very interested to make such a simulator, but the problem is that I am now concentrating on the PDP-11. If there would be some simple Raspberry Pi software creating the vector input for such a simulator, and some youtube videos showing the real thing in action, then I could easily make such a simulator.

[Digby R.S. Tarvin]

Actually I didn't really know anything about the DEC 340, but looking it up, I see it has quite similar requirements.. I'll have to take a look at what you have some time. 

--

You received this message because you are subscribed to the Google Groups "[PiDP-11]" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pidp-11+u...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/pidp-11/7e4d9127-6a67-4383-8a35-618fc080b3ba%40googlegroups.com.

[Jon Brase]

On Thursday, December 5, 2019 at 12:39:46 AM UTC-6, Lars Brinkhoff wrote:

Digby R.S. Tarvin wrote:

Which causes it to use a physical SCSI tape drive. It made quite a difference to the feel of the emulator, even using  non-period readily available low capacity USB DAT tapes, to have a bank of four physical tape drives rather than reading and writing files.

In a similar vein, I attached a modern thermal receipt printer to emulate the feel of a physical teletype.  Of course it doesn't look anywhere near a real teletype but still, getting the output logged to real paper was a boost.

I have suggested to some 3D people they make a teletype model, and then maybe I could print that and put it over the thermal printer.

How are the ergonomics of that arrangement? I'm probably one of the younger people here, and I'd think that given the width of a typical receipt, you'd either wrap at a annoyingly short line length, or else have to use such a small font size as to induce considerable eyestrain, and I'd think that people who are old enough to have used the PDP-11 back in the day would tend to have more problems with eyestrain. Apparently full-size dot matrix printers are still produced today, so it might be possible to whip up some sort of Franken-DECwriter that uses full-width paper.

For receipt printers, what do you think of my idea upthread about using them for paper tape? From the number of hobby projects that can be found with a short Google search that implement tape/card readers vs. tape/card punches, readers seem to be much easier to implement, so using a receipt printer to just print black/white squares instead of punching holes might give you a "punch" that takes a fair bit less work to implement.

[Digby R.S. Tarvin]

The Cyber console wasn't really a vector display - each write to the display specified an co-ordinate on a 512x512 grid, and either drew a dot (for graphics) or a nominated character from a 6 bit character set.  The character drawing is vector based though - each character is defined and drawn using vector definitions, which means they can be scaled as required.

I have an implementaiton that stores stores earlier updates and displays the previous updates at lower intensity before  overlaying the new ones at full intensity, It can't do it fast enough to be immune from flicker if the double buffer switching isn't done at the right time though. A display update can be anything from a few characters to tens of thousands depening on the display selected and the operating system that is running.  To get good displays I find I have to adjust the timing for each OS.. Hardware fade could fix that.

[Henk Gooijen]

I know the guy that made that TU56 video, he's also in The Netherlands :)
Yes, TU56 tape moves fast. For the simulation we do not have to match that speed, but it would be nice to see a difference in reading/writing and (re)winding). Audio cassette tape is too small, I was thinking of "normal" audio tape deck tape. For me, the choice of tape is given by the head(s) to can get/use. 1/2 inch tape would be very nice, but heads are more difficult to obtain than the heads of an audio tape deck.

Stepper motors is a good choice (I think), servos (motor plus encoder) would also be a nice solution. As Johnny says, you have to keep the tape on low tension while the reel rotation speed changes with the amount of tape on the reel. That is why I proposed to record on one track an audible tone (using a good audio tape deck). If you run that tape on the "TU56", the frequency of the tone will change, because the tape speed changes depending on the amount of tape on the reel. That changes can be used to control the reel speed. The coils of the other reel can be short-circuited to provide some counter-pulling force to maintain the tape tension. Enough for lots of fun experiments ...

Personally, I want the *use* the tape as actual storage (just for fun), so a simple pice of tape that does not move (while reels rotate) is "not enough" for me. I would like to go one step further. The tape hubs ("stars") and scaled reels can be 3D printed, no doubt about that. Using audio tones for the data is "low density" bit it works (we all used that for our home computer when floppy drives were still too expensive). If we can be able to read in *both* directions?  Maybe ...

The switches for the TU56 (and the RK05) can be the same switches Oscar uses for the PiDP-11/70. I got two from Oscar, and spray-painted them grey for the RK05. Looks great! The thumb wheel switch to select the unit number is a standard component you can buy from DigiKey, Mouser, RS, Farnell, Jameco, etc. At least the one used on TU56. If you would build a TU55, you would have to construct some thumb wheel that looks like the real one.
The indicator lights may call for some clever solution.

> Digby R.S. Tarvin wrote:
> Other small improvemends include things like modyifying disk emulations to provide some visual feedback and control.
> For example, an RK05 that was just a visual representation of an actual drive, but with LEDs controlled by the emulator
> to show when it is accessed, and perhaps a toggle switch for the write control, would be enough for me.

That is already done :)  I use a USB stick inside a 3D printed (scaled) cartridge, but if you settle for just a front panel with the two switches and 8 indicator lights, it is done. You could do "some" work for a real-looking front door (RK05 and RK05/j) or keep it simple and use a black plate (RK05/f).

The discussion of tape width, is probably a given result, depending on the heads you can obtain. I had not thought of the "old" 8-track audio tape!  With an 8-track head you could go quite a way similar to the real TU56!
VHS tape is an option as well, and of course real "open reel" tape.

I am convinced we can make something that looks like a TU56 and operates similar!
I should do some work on the RK05 in the coming holidays ...

[Lars Brinkhoff]

 Rene Richarz wrote:

In principle I am very interested to make such a simulator, but the problem is that I am now concentrating on the PDP-11.

If you want to stay in the PDP-11 fold, there is the GT40 vector display which is a PDP-11/05 with a VT11 thingy and a VS60 thingy.  (I'm vague on what those thingies are.)

The GT40 is supported by SIMH and Phil Budne's vector display simulation which is also used for the PDP-10 Type 340 display.

[Lars Brinkhoff]

Jon Brase:

 I attached a modern thermal receipt printer to emulate the feel of a physical teletype.

How are the ergonomics of that arrangement? I'm probably one of the younger people here, and I'd think that given the width of a typical receipt, you'd either wrap at a annoyingly short line length, or else have to use such a small font size as to induce considerable eyestrain

You are right to be concerned.  I had to use a smaller font and even then I only get 64 characters across.

 

and I'd think that people who are old enough to have used the PDP-11 back in the day would tend to have more problems with eyestrain.

I'm young enough to not have used a PDP-11.  But old enough to have bifocals.

For receipt printers, what do you think of my idea upthread about using them for paper tape?

Hmm, that's interesting too.  I used the widest paper rolls available, but a more narrow one might conceivably resemble paper tape... especially with poor eyesight. ;-)

[Rene Richarz]

On Thursday, December 5, 2019 at 9:38:45 AM UTC+1, Digby R.S. Tarvin wrote:

I have an implementaiton that stores stores earlier updates and displays the previous updates at lower intensity before  overlaying the new ones at full intensity, It can't do it fast enough to be immune from flicker if the double buffer switching isn't done at the right time though. A display update can be anything from a few characters to tens of thousands depening on the display selected and the operating system that is running.  To get good displays I find I have to adjust the timing for each OS.. Hardware fade could fix that.

Exactly. Are you sure that you cannot operate fast enough if you have one drawing canvas which is multiplied my a factor smaller than 1 in regular intervals and constantly add new vectors (or coordinates) while they are coming in? I have the feeling that fading calculations every 100 msec would be sufficient, and I am sure that one can draw vectors as fast as they are coming in.

If I understood Lars properly, his concern is that if you send a pair of x/y coordinates, followed by a second pair after a given short time, how well does the deflection circuit behave. Would it draw a straight vector, or a curve based on the "capacity" of the deflection circuit? Would it draw at an intensity which depends on the actual x/y difference between the last and the current point, or even worse at the speed the beam moves at any time? If such effects are really visible then I believe that one needs a hardware solution.

I am a physicist and therefore very interested in a "physical" simulation, but for those who are just using a simulator it is better to just simulate things that one can actually see on the screen.

[Lars Brinkhoff]

Henk Gooijen wrote:

 Audio cassette tape is too small

Too small according to what criteria?  For the PiDP-11, certainly.  But I'm 3D printing much smaller models. 

[Henk Gooijen]

OK, audio cassette tape would be fine. I just would like to see a bit "wider" tape.

BTW, 8-track cassette player/recorder does not add anything, as it still plays/records 2 tracks at a time.

Access to the other tracks is achieved by *moving* the position of the heads (perpendicular to the tape motion).

There is no 8 tracks access at the same time!

[Lars Brinkhoff]

Rene Richarz wrote:

If I understood Lars properly, his concern is that if you send a pair of x/y coordinates, followed by a second pair after a given short time, how well does the deflection circuit behave. Would it draw a straight vector, or a curve based on the "capacity" of the deflection circuit? Would it draw at an intensity which depends on the actual x/y difference between the last and the current point, or even worse at the speed the beam moves at any time? If such effects are really visible then I believe that one needs a hardware solution.

That's not quite what I was getting at, or maybe they are the least of my concerns.  I would like to see something similar to cool-retro-term, but for vector displays.  But even cool-retro-term has some irksome flaws, so let's not copy those.

 

I am a physicist and therefore very interested in a "physical" simulation, but for those who are just using a simulator it is better to just simulate things that one can actually see on the screen.

Certainly, effects that are essentially invisible to a human observer can be left out.

There's no need to go all supercomputer level physical model.  But a little more attention to detail, inspired by physics, would be nice.

[Henk Gooijen]

Not sure if this is useful ...

Last year, an article was in Nuts & Volts, the AGC (Arduino Graphics Controller), IIRC.

I have built it, but never used it so far (no time ...).

It is capable of drawing in a 4096 x 4096 dot field. The X and Y output connect to an oscilloscope, and are controlled by ADCs which are loaded using DMA!

That functionality is only available on one of the Arduino boards. By using that technique, it was possible to draw up to 14,000 vectors without flickering!

The non-DMA version could only do 700 vectors.

Characters are supported, and several levels of intensity (by redrawing the vectors), so that could also be used for fading out.

A few months later, in Nuts & Volts was another vector graphics controller presented, not using an Arduino, but ... (I forgot).

If interesting, I can look it up.

[Mike Katz]

For the tape drive motors, we could use stepper motors.   There are many
inexpensive motors and controllers available from the do it yourself 3D
printers and CNC machines.  This gives us very precise control of both
motors to maintain tension and the rapid change of motion and direction
of DECTape drives.

[Mike Katz]

U-Matic professional video tape cartridges use 3/4" tape.  Just another
source of magnetic tape.

[Geoffrey McDermott]

I think that you're vastly simplifying the effort to EMULATE (not simulate) a reel-to-reel tape drive of any type.

Simulating a peripheral like a disk drive with Ready and Load indications is simple, as you're not actually reading or writing data from your simulated hardware. But, actually reading and writing data from moving magnetic tape is vastly more complicated and difficult.

Simulating a TU56 would be relatively easy, as the tape 'motion' would just be eye candy, and not actually related to data access. I've designed both tape and floppy based peripherals in my career, and they are much more complex is all areas than are obvious.

I wouldn't even attempt to emulate a TU56 at the hobby/enthusiest level.

Having said that, your ideas have merit, but implementation will be at best a PITA, and require significant more effort than what you think it will take. GOOD LUCK.

[Lars Brinkhoff]

Henk Gooijen:

Last year, an article was in Nuts & Volts, the AGC (Arduino Graphics Controller), IIRC.

it was possible to draw up to 14,000 vectors without flickering!

A few months later, in Nuts & Volts was another vector graphics controller presented, not using an Arduino, but ... (I forgot).

If interesting, I can look it up.

Please do.  I have a Tektronix XY display waiting to be fed with sweet vector graphics.  14000 vectors sounds impressive.

I searched for "arduino graphics controller" and nothing useful turned up.  Was it Arduino Graphics Interface?

[David Johnson]

https://www.nutsvolts.com/magazine/article/the-arduino-graphics-interface-part-1

https://www.nutsvolts.com/magazine/article/the-arduino-graphics-interface-part-2

--
You received this message because you are subscribed to the Google Groups "[PiDP-11]" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pidp-11+u...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/pidp-11/ddb0690c-a70c-43ad-86e6-5e697018acd1%40googlegroups.com.

[Dave Babcock]

What I think that Digby is referring to is Cadetwriter.  Cadetwriter is a general-purpose, printing ASCII terminal based on a Wheelwriter 1000 typewriter.  For around $150 in parts, a Wheelwriter typewriter, and about 4 hours of work, you can have a robust teleprinter ala Teletype, DECWriter, etc.  Expendables [fan-fold paper and ribbons] are readily available from Staples.

The terminal is a by-product of the Computer History Museum's IBM 1620 Jr. project and is completely open source.  Several people have already built or are in the process of building their own.

Full documentation is available at:   https://github.com/IBM-1620/Cadetwriter

There is a message board for those building or using Cadetwriters at:   https://cadetwriter.slack.com

It was recently written up at:  https://hackaday.com/2019/11/14/upgrade-board-turns-typewriter-into-a-teletype

Thanks,
Dave

[Jon Jackson]

THE ARDUINO GRAPHICS INTERFACE — PART 1   https://www.nutsvolts.com/magazine/article/the-arduino-graphics-interface-part-1

https://nutsvolts.texterity.com/nutsvolts/201802/?folio=22&pg=22#pg22 

THE ARDUINO GRAPHICS INTERFACE — PART 2     https://www.nutsvolts.com/magazine/article/the-arduino-graphics-interface-part-2

https://nutsvolts.texterity.com/nutsvolts/201803/?folio=46&pg=46#pg46 

 

--

You received this message because you are subscribed to the Google Groups "[PiDP-11]" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pidp-11+u...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/pidp-11/4e5e06cf-d3c5-40da-9112-2a8fb9cbaa12%40googlegroups.com.

[Lars Brinkhoff]

Thanks!

David Johnson and Jon Jackson wrote:

https://www.nutsvolts.com/magazine/article/the-arduino-graphics-interface-part-1

https://www.nutsvolts.com/magazine/article/the-arduino-graphics-interface-part-2

[Jon Brase]

On Thursday, December 5, 2019 at 3:12:00 AM UTC-6, Lars Brinkhoff wrote:

For receipt printers, what do you think of my idea upthread about using them for paper tape?

Hmm, that's interesting too.  I used the widest paper rolls available, but a more narrow one might conceivably resemble paper tape... especially with poor eyesight. ;-)

 

Do we need to use the exact same on-paper format, though? You could do two or more characters side-by-side and/or print human-readable metadata (such as the hex codes or ASCII characters corresponding to the bits printed) off to the side . As I understand, paper tape back in the day often had ASCII characters for each punched character printed in ink in the same space as the punches. That wouldn't be possible if we're using ink/no ink instead of hole/no hole for 1/0, but it could be printed off to the side. 

I can think of a few niftier uses for the extra width, but they'd require:

1a) Integration of the reader and printer. 

1b) Likely an alternate paper path as well.

2) Or else make tape handling for the user a lot more laborious.

So they probably aren't feasible.

Two concerns I do have about receipt printers as "tape punches":

1) Receipt stock is generally fairly flimsy, and would likely crumple easily in handling and jam in the reader. Is it possible to use heavier stock in receipt printers?

2) Paper tape was, to my understanding, generally fanfold, whereas receipt paper is generally continuous roll, and the leftover curl and lack of pre-defined crease lines would make the receipt stock to store compactly, as hand-folded creases would likely contribute to jamming issues, and, folded or not, the receipt stock wouldn't lie flat.

[Johnny Billquist]

On 2019-12-05 09:42, 'Henk Gooijen' via [PiDP-11] wrote:
> I know the guy that made that TU56 video, he's also in The Netherlands :)
> Yes, TU56 tape moves fast. For the simulation we do not have to match
> that speed, but it would be nice to see a difference in reading/writing
> and (re)winding). Audio cassette tape is too small, I was thinking of
> "normal" audio tape deck tape. For me, the choice of tape is given by
> the head(s) to can get/use. 1/2 inch tape would be very nice, but heads
> are more difficult to obtain than the heads of an audio tape deck.

I also just realised/remembered that DECtape is actually 10 track, so
we'll probably never going to properly implement the same thing anyway...

> Stepper motors is a good choice (I think), servos (motor plus encoder)
> would also be a nice solution. As Johnny says, you have to keep the tape
> on low tension while the reel rotation speed changes with the amount of
> tape on the reel. That is why I proposed to record on one track an
> audible tone (using a good audio tape deck). If you run that tape on the
> "TU56", the frequency of the tone will change, because the tape speed
> changes depending on the amount of tape on the reel. That changes can be
> used to control the reel speed. The coils of the other reel can be
> short-circuited to provide some counter-pulling force to maintain the
> tape tension. Enough for lots of fun experiments ...

Note that DECtape is actually not a constant tape speed thing. It's a
pure reel to reel system, where tape speed over the heads vary a lot.
There is no precise control over the tape speed. The pulling motor will
just pull as much as it can, and the motor controlling the feed reel
will just be applying a small force in order to keep the tape tensed.

The design is nice in that way. It's very forgiving of differences
between drives, environment, and even physical problems with the tape.
That's the whole point of the clock track.

And one trick was really to just apply some breaking force to the tape
when formatting, in order to fit more blocks on the tape.
Once formatted, the clock was defined, and everything worked just fine
with a bit higher density.

Johnny

--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: b...@softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol

[Rene Richarz]

I know that this thread is about building functional physical devices, but before starting to make a physical TU56 tape drive, I want to make a TU56 software simulation for my rack. This youtube video

https://youtu.be/t7yNIhn-i4I

shows the proof-of-concept for such a simulation running on the screen in my PiDP-11 rack. Making all the switches and lights functional and hooking the simulation up to simh will be easy. But making nice looking turning reels and "stars" is difficult, because I do only have pictures with a strong perspective distortion at present.

The only thing I really need to get from somebody who has a real TU56 is a set of good frontal pictures of a reel on the "star", viewing exactly in the rotation axis. The set should be at angles in steps of 45° if possible, and the reel should have a nice label so that one can actually see the motion. If it is only one picture exactly on the axis and without shadows then I can of course also rotate it using image processing software such as GIMP.

[Henk Gooijen]

Well, "functional physical" might be a bit too much, but we can try :)
Very nice video, I had to look twice to notice that the TU56 is an image on a display! When the tape moves it is more obvious, so the simulated movement might be improved.
Also note how the lamps glow on/off. See https://www.youtube.com/watch?v=ZGBS8mBAfYo

I will go to my "museum" (200 square meter former pig stable) and make pictures of my TU56 and (empty) tape reel. I am not a good photographer though ...
 

[Rene Richarz]

On Friday, December 6, 2019 at 10:39:55 AM UTC+1, Henk Gooijen wrote:

Also note how the lamps glow on/off. See https://www.youtube.com/watch?v=ZGBS8mBAfYo

 

I think I understand the function of the 3 switches and the thumb switch. Can you confirm that the left switch had 2 positions, and the other 2 switches had 3 positions?

About the glowing lights. Is the left "write" light always on if the write switch is in the enabled position, or only if there is an actual write ongoing? Is the "remote select" light on only if the right switch is in the remote position and the host actually reads or writes?

Simulating the reel movements is very difficult, given the actual screen refresh rates of such a simulation. The reels are almost acceptable in my opinion. I just need the better picture because rotating the label using image processing software turned out to be difficult due to the perspective view. The real problem is the "stars". Without some good frontal pictures it is almost impossible to make them look right while they are turning.

I'm looking forward to having a tek4010 graphics demo running from TU56 tape, with the tape drive, the PiDP-11 lights and the tek4010 graphics all nicely in sync! Once that's all working, building a physical model with stepper motors is feasible and makes sense. Whether we will ever be able to do actual tape read/writes at high enough speed and density I doubt, but of course I would be happy being proven wrong.

[Jon Brase]

On Friday, December 6, 2019 at 4:21:12 AM UTC-6, Rene Richarz wrote:

About the glowing lights. Is the left "write" light always on if the write switch is in the enabled position, or only if there is an actual write ongoing? Is the "remote select" light on only if the right switch is in the remote position and the host actually reads or writes?

Simulating the reel movements is very difficult, given the actual screen refresh rates of such a simulation. The reels are almost acceptable in my opinion. I just need the better picture because rotating the label using image processing software turned out to be difficult due to the perspective view. The real problem is the "stars". Without some good frontal pictures it is almost impossible to make them look right while they are turning.

Motion blurring might help you here, particularly with the reels. The label image is too crisp while the reel is in motion, which makes the refresh rate more noticeable. The stars seem to be fairly well motion blurred already.

Anyways, it probably looks worse for you given that you're in the room, but viewing it on Youtube, where everything is squashed down onto a 2D screen anyway, it's very good. One doesn't immediately notice the Raspian taskbar on the "bezel" of the tape drive.

[oscarv]

Rene,

I love that TU56-on-a-display!

With 10" HDMI displays costing almost nothing, and a $5 Pi Zero all that's need to do the graphics (if you don't want to use the PiDP's Pi, see post below), I think this is a hugely promising idea. It also lends itself to other devices.

Kind regards,

Oscar.

[oscarv]

My 2 cents on Rack Ideas:

It would be a great idea to standardise on some 'rack' construction. Cheap and cheerful, I would opt for aluminium L profiles as Henk mentioned. You can get them anywhere.

Secondly, maybe we should then have some reference drawing of a rack panel in Inkscape, with standard dimensions. This would allow anyone to make a rack panel: such drawings can be sent to a laser cutting shop, any laser cutting shop, and made for a few dollars. Laser cutters can actually not only cut, but with the right plastic material (black surface on white substrate) also do beautiful lettering on a panel.

Thirdly, I'd like to hear thoughts on the electronics side of things. Here is my idea:

We have an I2C port on the PiDP, and one free I/O pin.

Why not make a standard Unibus device (in simh) that can send/receive packets of data to any I2C device. The Pi has pullups on the I2C port, so you can daisy-chain any I2C device (5V or 3.3V!) onto that with just a bit of wire. Nothing else needed. The problem with I2C is that if the PiDP is Master, all the other devices are Slaves. Meaning they can not signal the PiDP when data is available. Here, the free I/O pin comes in: any slave can signal the PiDP that data is ready by pulling that pin low. Again, it then does not matter whether your rack-mounted device is 5V or 3.3V.

With the above, you have:

- a virtual Unibus device that can talk to any I2C device

- a standard reference panel drawing that can be modified for anyone's project, and send to a laser cutter anywhere. Plus a standard 'rack' construction - L profile.

- a setup where you can use an Arduino, Pi Zero or whatever as I2C slaves, each with their own I2C address, with interrupt line. Within the PDP-11 simulation, all you need is to send & receive I2c packets. Making programming for any such peripheral as simple as it gets. An Arduino can deal with the nitty-gritty of whatever peripheral needs to be driven.

And this would lead to... a small web site with builder's home-made peripherals, easily downloaded and replicated at minimal cost without anyone needing to deliver parts or kits.

Kind regards,

Oscar.

[oscarv]

Here is my idea for a physical "demonstration TU56":

Two cassette players at $17 each:

You basically remove the case, mount the mechanism behind a pretty laser-cut panel, from black-coated material with white substrate, so you can engrave all the TU56 artwork/lettering. Available everywhere.

Then, put in cassette tape without it case. A thin laser-cut cover is put behind and in front of both spindles to give it TU56 looks (+/-).

Another laser-cut part from thicker material makes for a dummy TU56 head and tape guide above the spindles.

As there's no hope of making the tape hold any data (it's demonstration-only), I'd argue for the tape to be in a loop; so there's no beginning and end it can bump into. A wilder idea would be to put the index track on it. Not much use IMHO.

The cassette mechanism would basically be in fast-forward or rewind mode. Fast enough to get a TU56 kind of feeling ;)

Yes, the two spindles are too close to each other. But this would be a valid compromise: you only need two cheapo cassette players, and laser-cut four 'spindle covers' plus a tape guide/head. Add a replica rack panel, the requisite switches and a $2 Arduino with a few dollars of bits and pieces to drive it all. Cheap and cheerful.

The fit is not too bad, a cassete tape is 4" wide, a PiDP rack panel has about 12" width:

Still, I perhaps like Rene's TU56 on-a-display even more. The ambition is to bring across the experience, not the actual TU56.

Kind regards,

Oscar.

[Johnny Billquist]

On 2019-12-06 11:21, Rene Richarz wrote:
>
>
> On Friday, December 6, 2019 at 10:39:55 AM UTC+1, Henk Gooijen wrote:
>
>
> Also note how the lamps glow on/off. See
> https://www.youtube.com/watch?v=ZGBS8mBAfYo
> <https://www.youtube.com/watch?v=ZGBS8mBAfYo>
>
> I think I understand the function of the 3 switches and the thumb
> switch. Can you confirm that the left switch had 2 positions, and the
> other 2 switches had 3 positions?

Yes, the write protect switch have two positions, and it stays in
whatever position you put it in.

The offline, local, remote switch have three positions, and it stays in
whatever position you put it in.

The switch with the arrows have three positions, and it always goes back
to neutral when you release it.

> About the glowing lights. Is the left "write" light always on if the
> write switch is in the enabled position, or only if there is an actual
> write ongoing? Is the "remote select" light on only if the right switch
> is in the remote position and the host actually reads or writes?

I seem to remember that the "write" lamp is on when you are write
enabled mode.

Actually, all this information is available in the manual. See
http://www.bitsavers.org/pdf/dec/dectape/tu56/DEC-00-HRTC-D_TU56_Mantenance_Manual_Jan73.pdf
page 12.

And for remote, it is only on when remote is selected, and the
controller have selected the drive.

> Simulating the reel movements is very difficult, given the actual screen
> refresh rates of such a simulation. The reels are almost acceptable in
> my opinion. I just need the better picture because rotating the label
> using image processing software turned out to be difficult due to the
> perspective view. The real problem is the "stars". Without some good
> frontal pictures it is almost impossible to make them look right while
> they are turning.

There are more schematic drawings of the "star" in that manual I linked
to above as well.

> I'm looking forward to having a tek4010 graphics demo running from TU56
> tape, with the tape drive, the PiDP-11 lights and the tek4010 graphics
> all nicely in sync! Once that's all working, building a physical model
> with stepper motors is feasible and makes sense. Whether we will ever be
> able to do actual tape read/writes at high enough speed and density I
> doubt, but of course I would be happy being proven wrong.

I think stepper motors do not make sense, but that's just me. :-)
Any simulation can obviously use whatever density you want. It will not
be possible to tell by the human eye anyway.
Speed is also a rather relative question.

[Johnny Billquist]

How would you create a tape loop without making the resulting thing look
rather different than a DECtape? Remember, the DECtape runs the tape
between two reels.

As far as "functional" goes. You definitely do a tape that actually
worked. Use the normal tape head, and move the tape over to open reels.
Data could be read/written. The biggest problem would be that since a
real DECtape is clocked you can reliable rewrite data anywhere. This
could be a problem when simulating...

Johnny

On 2019-12-06 17:01, oscarv wrote:
>
> Here is my idea for a physical "demonstration TU56":
>
> Two cassette players at $17 each:
>
>

> You basically remove the case, mount the mechanism behind a pretty
> laser-cut panel, from black-coated material with white substrate, so you
> can engrave all the TU56 artwork/lettering. Available everywhere.
>
> Then, put in cassette tape without it case. A thin laser-cut cover is
> put behind and in front of both spindles to give it TU56 looks (+/-).
> Another laser-cut part from thicker material makes for a dummy TU56 head
> and tape guide above the spindles.
>
> As there's no hope of making the tape hold any data (it's
> demonstration-only), I'd argue for the tape to be in a loop; so there's
> no beginning and end it can bump into. A wilder idea would be to put the
> index track on it. Not much use IMHO.
>
> The cassette mechanism would basically be in fast-forward or rewind
> mode. Fast enough to get a TU56 kind of feeling ;)
>
> Yes, the two spindles are too close to each other. But this would be a
> valid compromise: you only need two cheapo cassette players, and
> laser-cut four 'spindle covers' plus a tape guide/head. Add a replica
> rack panel, the requisite switches and a $2 Arduino with a few dollars
> of bits and pieces to drive it all. Cheap and cheerful.
>
>

> Still, I perhaps like Rene's TU56 on-a-display even more. The ambition
> is to bring across the experience, not the actual TU56.
>
> Kind regards,
>
> Oscar.
>

> --
> You received this message because you are subscribed to the Google
> Groups "[PiDP-11]" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to pidp-11+u...@googlegroups.com

> <mailto:pidp-11+u...@googlegroups.com>.

> To view this discussion on the web visit

> https://groups.google.com/d/msgid/pidp-11/6f34f57b-e0f0-4490-89ce-36b8389cfe06%40googlegroups.com
> <https://groups.google.com/d/msgid/pidp-11/6f34f57b-e0f0-4490-89ce-36b8389cfe06%40googlegroups.com?utm_medium=email&utm_source=footer>.

[Oscar Vermeulen]

Johnny,

On Fri, 6 Dec 2019 at 19:57, Johnny Billquist <b...@softjar.se> wrote:

How would you create a tape loop without making the resulting thing look
rather different than a DECtape?

It would be a potential compromise... for simplicity.

 

As far as "functional" goes. You definitely do a tape that actually
worked. Use the normal tape head, and move the tape over to open reels.
Data could be read/written. The biggest problem would be that since a
real DECtape is clocked you can reliable rewrite data anywhere. This
could be a problem when simulating...

Yes, I once had the idea that the clock signal could be on the tape, and nothing more. But it adds complexity to something that will never be more than a mock-up. Trying to hide that it's a mock-up makes it no better, I think. All that is of value is the aesthetics and the visual experience of seeing how the tape spools between blocks.

All in all, I think Rene's on-screen TU56 animation is the smarter idea (that Youtube clip looks good). It gives the visuals (as long as you do not power off...) and does not pretend to be something that it is not. Still, a simple physical tape is something worth considering. But making it read some data is not really practical.

BTW - I once looked at the cost of getting 10-track tape heads made. But that is *way* too expensive.

Kind regards,

Oscar.

[Rene Richarz]

On Friday, December 6, 2019 at 12:02:35 PM UTC+1, Jon Brase wrote:

 

Motion blurring might help you here, particularly with the reels. The label image is too crisp while the reel is in motion, which makes the refresh rate more noticeable. The stars seem to be fairly well motion blurred already.

Thanks Jon. 

Using the TU56 reel size and tape speed specs I calculated 500 rpm for the rotation speed of the wheels of the TU56. Using "circular motion blur" in GIMP is therefore the right way to make the moving reels look realistic. I don't have much experience with image manipulation, but the more I learn the more I am surprised how much can be done with a free program. I have done the leftmost reel and it looks great while it is turning. 3 more reels and all the switch positions still do be done and then back to programming, which I know and like best.

By the way, is BSD all set up to talk to the simh tape device (I guess using tar and a device in /dev), or do we need to build a kernel? If something needs to be prepared in BSD I would be happy if you or somebody else could do that, so that I can concentrate to the TU 56 emulator and the mods in simh.

Regarding simh. I read somehwere that the TU56 driver already reads and writes to files. What I therefore think is required is a menu in the TU56 emulator to "change reels" (switch files), and a way to exchange a few bits of information (drive number, reading, writing, rotational direction) between the emulator and the driver. I also read that the TU56 had to back up a bit between reading several files sequentially, because it could not stop and start the tape fast enough. I have to find out which part of the system (BSD, simh, TU emulator) is supposed to do that.

Rene

[Johnny Billquist]

On 2019-12-07 08:26, Rene Richarz wrote:
>
>
> On Friday, December 6, 2019 at 12:02:35 PM UTC+1, Jon Brase wrote:
>
> Motion blurring might help you here, particularly with the reels.
> The label image is too crisp while the reel is in motion, which
> makes the refresh rate more noticeable. The stars seem to be fairly
> well motion blurred already.
>
>
> Thanks Jon.
>
> Using the TU56 reel size and tape speed specs I calculated 500 rpm for
> the rotation speed of the wheels of the TU56. Using "circular motion
> blur" in GIMP is therefore the right way to make the moving reels look
> realistic. I don't have much experience with image manipulation, but the
> more I learn the more I am surprised how much can be done with a free
> program. I have done the leftmost reel and it looks great while it is
> turning. 3 more reels and all the switch positions still do be done and
> then back to programming, which I know and like best.
>
> By the way, is BSD all set up to talk to the simh tape device (I guess
> using tar and a device in /dev), or do we need to build a kernel? If
> something needs to be prepared in BSD I would be happy if you or
> somebody else could do that, so that I can concentrate to the TU 56
> emulator and the mods in simh.

If we are talking DECtape, then I think the answer is no, as I don't
think 2.11BSD even have support for DECtape. It's not a tape in the
normal sense of the word either.

> Regarding simh. I read somehwere that the TU56 driver already reads and
> writes to files. What I therefore think is required is a menu in the
> TU56 emulator to "change reels" (switch files), and a way to exchange a
> few bits of information (drive number, reading, writing, rotational
> direction) between the emulator and the driver. I also read that the
> TU56 had to back up a bit between reading several files sequentially,
> because it could not stop and start the tape fast enough. I have to find
> out which part of the system (BSD, simh, TU emulator) is supposed to do
> that.

Be careful what you write here. "TU" emulator don't make sense. TU is a
rather generic name for tape drives, which covers different things. You
had, for instance the TU10, which is a very old drive, connected to a
controller on a Unibus or Omnibus. 7 or 9 track. 9 track was only 800
bpi. (7 track had even lower densities...)
Then you have things like the TU77 which is a Massbus 9-track drive with
vacuum columns, which handles 800 and 1600 bpi, and then you have things
like the TU81 which is a rather modern drive doing 1600 and 6250 bpi,
with TMSCP, and have direct control of reels with no vacuum nor spring
loaded arms.

All of those are traditional tapes.

TU55 and TU56 on the other hand are DECtapes. These are something very
different. The closest thing to DECtapes are actually floppies. They
have very little in common with traditional tape drives.

2.11BSD have support for various 9 track tape drives, but no support for
DECtape.

As far as starting and stopping, and so on goes, it does depend on the
controller. I can't remember to which level the DECtape controller for
the PDP-11 does the work for you. But if you request block # to it, then
it would be responsible for backing up and handling all the low level stuff.
If, on the other hand, it's the type where you start the motor, and then
are expected to process the mark track info, then you are probably
responsible for also backing up and do everything else yourself as well.

Johnny

[Rene Richarz]

On Saturday, December 7, 2019 at 8:44:18 AM UTC+1, Johnny Billquist wrote:

2.11BSD have support for various 9 track tape drives, but no support for
DECtape.

Oh, I was not aware of that.

That's a bit of a problem. I would really like to use an emulated tape drive with BSD. So I could of course emulate a 9 track tape, but then this would not be very useful for some other operating systems on the PiDP-11 and the PiDP-8. I think DECtape is what one sees on many historical pictures of PDP-11 and PDP-8 systems. Therefore, making a DECtape emulator makes most sense in my opinion.

But then web servers and some other things were also not available on historical BSD. So hooking BSD somehow up to DECtape is hopefully not a major sin either. Maybe without some of the bells and whistles of DECtape, but hopefully with the high transfer rate of roughly 80 kbits/sec.

[Jon Brase]

On Friday, December 6, 2019 at 5:55:36 PM UTC-6, oscarv wrote:

Johnny,

On Fri, 6 Dec 2019 at 19:57, Johnny Billquist <b...@softjar.se> wrote:

How would you create a tape loop without making the resulting thing look
rather different than a DECtape?

It would be a potential compromise... for simplicity.

 

As far as "functional" goes. You definitely do a tape that actually
worked. Use the normal tape head, and move the tape over to open reels.
Data could be read/written. The biggest problem would be that since a
real DECtape is clocked you can reliable rewrite data anywhere. This
could be a problem when simulating...

Yes, I once had the idea that the clock signal could be on the tape, and nothing more. But it adds complexity to something that will never be more than a mock-up. Trying to hide that it's a mock-up makes it no better, I think. All that is of value is the aesthetics and the visual experience of seeing how the tape spools between blocks.

For my part, I'm more interested in the experience of using the tape than of looking at it. Digby's practice upthread of attaching simh tape devices to the device files for modern USB tape drives appeals to me. If feasible, I'd like to have a hobbyist tape architecture that closely replicated the historical use of tapes across manufacturers (e.g, mounting separate reels onto the drive rather than just a self-contained catridge) wtihout emulating the look of any manufacturer, and having a consistent form-factor and on-tape format  across the retrocomputing world. That would allow multiple projects to pool their resources to implement such a thing, and would make it useful to more people. Having look-alikes to legacy hardware would be a lower priority for me (and could be done with something like Rene's animation), and trying to emulate the actual technical minutiae of a given tape drive model (number of heads, signal protocol and encoding used to represent data on tape, etc) is not at all a priority, as long as the emulated software sees a tape drive that behaves as it expects.

[Johnny Billquist]

On 2019-12-07 11:21, Rene Richarz wrote:
>
>
> On Saturday, December 7, 2019 at 8:44:18 AM UTC+1, Johnny Billquist wrote:
>
> 2.11BSD have support for various 9 track tape drives, but no support
> for
> DECtape.
>
>
> Oh, I was not aware of that.
>
> That's a bit of a problem. I would really like to use an emulated tape
> drive with BSD. So I could of course emulate a 9 track tape, but then
> this would not be very useful for some other operating systems on the
> PiDP-11 and the PiDP-8. I think DECtape is what one sees on many
> historical pictures of PDP-11 and PDP-8 systems. Therefore, making a
> DECtape emulator makes most sense in my opinion.

Well, support exists in pretty much all DEC operating systems, as far as
I know. :-)

> But then web servers and some other things were also not available on
> historical BSD. So hooking BSD somehow up to DECtape is hopefully not a
> major sin either. Maybe without some of the bells and whistles of
> DECtape, but hopefully with the high transfer rate of roughly 80 kbits/sec.

Hardly a sin, but it would require that someone writes a device driver
for it.

[Rene Richarz]

I have finished the offline version of the TU 56 tape emulator. That was fairly easy, because I had done very similar things in the past. If you want to try it, you can download it from my TU 56 github repo. The readme.md file describes the usage, which is very simple. You can basically just operate the switches and wind the tape in offline mode.

Thanks to David Gesswein and Henk Gooijen for their pictures and Jon Braze for the idea to use circular motion blurring.

Next step is to somehow hook it up to BSD. Having never done anything like that before makes it difficult to get started. Bare with me if the following is naive.

I have found the various PiDP-11 tape drivers in SimH https://github.com/simh/simh/tree/master/PDP11, the information in BSD (for example "man mt" and man "man 4 mtio"), and the devices /dev/*mt*

I can also see the following in /opt/pidp11/systems/2.11bsd/boot.ini:

; enable one tape device on a TMSCP controller

set tq enabled

I guess this means that I could use "mt" to, for example, rewind that tape. But

mt -f /dev/mt0 rewind

just gives the error message

/dev/mt0 Input/output error

Maybe somebody can help me to get started. Do I have to mount the tape drive first, and if yes, how? Which SimH tape driver would it use? Is there a way to see some simh diagnostics?

I am quite sure that once I understand how to issue a "rewind" command, and can see some diagnostics in the SimH driver, I can modify that driver to talk to my TU56 emulator, even if it simulates another tape drive and not DECtape.

[Johnny Billquist]

No no no no.

As I said before, the TU56 is *not* a magtape. You must totally erase
that concept from your head. Ignore the mt commands, they are for tapes.
Also ignore any device drivers, or information you might find about
tapes. They are totally useless in this scope.

The DECtape is a *disk*, although a slow one.

As such, you don't even have a rewind command for DECtape. However, you
can do a seek to block 0, if you want to. But again, think of it as a disk.

That also leads to a few more points if someone wants to write a device
driver for 2.11BSD. Remember, the DECtape is a disk (have I repeated
that enough now?). As such, start with something like the RX01, and
change things from there. Remember that the tools to install disk labels
needs to also deal with this new disk. Not sure any changes are needed,
but maybe some defaults might need to be created and so on.
And then, when using the DECtape, you need to create a label, and then
create a file system on the tape, followed by mounting it somewhere.

Johnny

On 2019-12-08 11:22, Rene Richarz wrote:
> I have finished the offline version of the TU 56 tape emulator. That was
> fairly easy, because I had done very similar things in the past. If you
> want to try it, you can download it from my TU 56 github repo

> <https://github.com/rricharz/Tu56>. The readme.md file describes the

> --
> You received this message because you are subscribed to the Google
> Groups "[PiDP-11]" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to pidp-11+u...@googlegroups.com
> <mailto:pidp-11+u...@googlegroups.com>.
> To view this discussion on the web visit

> https://groups.google.com/d/msgid/pidp-11/f56f2ff1-c5b0-4602-a307-560331c46468%40googlegroups.com
> <https://groups.google.com/d/msgid/pidp-11/f56f2ff1-c5b0-4602-a307-560331c46468%40googlegroups.com?utm_medium=email&utm_source=footer>.

[Jon Brase]

On Sunday, December 8, 2019 at 4:38:37 AM UTC-6, Johnny Billquist wrote:

That also leads to a few more points if someone wants to write a device
driver for 2.11BSD.

   Johnny

Man pages tp (1) and tp (5) seem to claim that /bin/tp supports DECTape, which would indicate that there is already a driver. 

[Rene Richarz]

Interesting. Hopefully somebody knows more about this.

With a bit of help I‘m now able to use  mt and tar in BSD with the TQ tape driver. I had to add „attach tq0 filename“ in boot.ini and use /dev/rmt0. I can now happily tar data in BSD from and to a Linux file. It will take some considerable effort to understand the SimH TQ driver, but if we cannot find a BSD DECtape driver, I will just pretend the TU 56 is a tape (I know it isn‘t) and handle only sequential read/writes in BSD. Of course we can implement all the wonderful DECtape stuff for the DEC operating systems.

[Johnny Billquist]

Except of course there is no device driver for it. Dare I venture a
guess that some old/other version of Unix had DECtape support, and this
tool and format got carried over to 2.11BSD, but support for the
hardware is not in there...

Probably also worth noting that the tp format is noted in the man page
to not be very portable, and tar is recommended instead.

tar, by the way, can write to both tapes and disks... So it can be used
on DECtape, even without a file system, just as it can be used on a
floppy... :-)

Johnny

[Johnny Billquist]

It's as much about how the hardware interface looks like, as it is what
the software then does.

A magtape have a hardware interface that matches what you expect. The
hardware can do read/write at the current position with arbitrary length
blocks (well, within limits), and it can skip blocks and files forward
and backward. And when writing, any data beyond that point is
essentially lost, and you get a new logical end of tape where your write
ends.

A DECtape do not have these same properties. DECtape work with fixed
blocks, and they have numbers. And you can directly seek to any block.
And then you can read/write that block. And of course you can replace
the content of any block, and there is no such thing as an end of file
or end of tape mark in the magtape sense. There is an end of tape
indicator though, which always is at the end of the tape. Same as the
magtape physical end of tape.

Johnny

[Lars Brinkhoff]

Rene Richarz wrote:

I am a physicist and therefore very interested in a "physical" simulation

I started a simple OpenGL shader which takes some number of points as input and updates a floating point texture to simulate the energy stored at each point on a CRT display.  Actually, each point has two floating points because the Type 340 display has two types of phosphors.

As a physicist, do you have any input to how a simulation should work?  For example, I have assumed that for each time unit a fixed percentage of energy dissipates.

[Ville Laitinen]

I'm guessing the v7 tc driver is for dectapes

https://www.tuhs.org/cgi-bin/utree.pl?file=V7/usr/sys/dev/tc.c 

Like other device drivers it's extremely confusing to read.

Armed with that and the TC01 manual one could probably create a device driver for 211bsd easily.

The manual actually contains enough information to use the drives without a device driver assuming one has access to the controller memory locations.

-V

On Sun, Dec 8, 2019 at 4:48 PM Johnny Billquist <b...@softjar.se> wrote:

Except of course there is no device driver for it. Dare I venture a
guess that some old/other version of Unix had DECtape support, and this
tool and format got carried over to 2.11BSD, but support for the
hardware is not in there...

[Jon Brase]

On Sunday, December 8, 2019 at 9:17:18 AM UTC-6, Lars Brinkhoff wrote:

Rene Richarz wrote:

I am a physicist and therefore very interested in a "physical" simulation

As a physicist, do you have any input to how a simulation should work?  For example, I have assumed that for each time unit a fixed percentage of energy dissipates.

I'm not a physicist, but my guess is that you have a certain number of excited phosphor molecules, and they return to their ground state with a certain half-life. So it would be an exponential decay.

[Rene Richarz]

Yes, you get an exponential decay if the number of molecules going back to the ground state is proportional to the number of still excited molecules. And yes, that  means that you can just multiply the remaining intensity with the same number < 1 during each identical time period.

I haven‘t looked in detail into you application. The exponential decay is certainly a good assumption, but in reality things are sometimes a bit more complex. There may me effects which cause the decay to deviate a bit from a simple exponential curve. But I doubt that one would see such deviations without using a very accurate measurement tool. Also, if you display the result on a conventional screen, you might have to adjust for the non-lineary of the display. Doubling the rgb values doesn‘t necessarily mean that the eye observes twice the intensity, for example.

[Jonathan Morton]

> On 8 Dec, 2019, at 6:27 pm, Rene Richarz <rene.r...@bluewin.ch> wrote:
>
> Also, if you display the result on a conventional screen, you might have to adjust for the non-lineary of the display. Doubling the rgb values doesn‘t necessarily mean that the eye observes twice the intensity, for example.

The search term is "gamma correction" for this bit. It means that you can run your physics sim in linear intensity colourspace, and still have a way to convert it to a voltage to apply to the display pixels.

- Jonathan Morton

[Lars Brinkhoff]

Rene Richardz wrote:

I haven‘t looked in detail into you application. The exponential decay is certainly a good assumption, but in reality things are sometimes a bit more complex. There may me effects which cause the decay to deviate a bit from a simple exponential curve. But I doubt that one would see such deviations without using a very accurate measurement tool.

Thank you.  I agree those deviations are probably not very important.

Do you think there would be any energy transfer in the space dimensions of the CRT?  E.g. does a brightly lit point also make the neighboring area glow?

[Digby R.S. Tarvin]

On Mon, 9 Dec 2019 at 00:29, Rene Richarz <rene.r...@bluewin.ch> wrote:

With a bit of help I‘m now able to use  mt and tar in BSD with the TQ tape driver. I had to add „attach tq0 filename“ in boot.ini and use /dev/rmt0. I can now happily tar data in BSD from and to a Linux file. It will take some considerable effort to understand the SimH TQ driver, but if we cannot find a BSD DECtape driver, I will just pretend the TU 56 is a tape (I know it isn‘t) and handle only sequential read/writes in BSD. Of course we can implement all the wonderful DECtape stuff for the DEC operating systems.

That is a nice way of transferring files between BSD2.11 and the host Raspian system, which seems nicer than the ftp I was using (especially with the problem creating a network connection directly between the two). Dont know why I didn't think of that before. On the mainframe emulator I had to use simulated card reader/punch, because it had no compatible tape archiving program.

Of course I would also like to modify simh to let me associate physical SCSI (which includes USB in Linux) tape drives with an emulated tape device. It sounds as though the TQ might be one to look at for that.

DigbyT

[Rene Richarz]

On Sunday, December 8, 2019 at 10:54:18 PM UTC+1, Digby R.S. Tarvin wrote:

On Mon, 9 Dec 2019 at 00:29, Rene Richarz <rene....@bluewin.ch> wrote:

With a bit of help I‘m now able to use  mt and tar in BSD with the TQ tape driver.

 

That is a nice way of transferring files between BSD2.11 and the host Raspian system, which seems nicer than the ftp I was using (especially with the problem creating a network connection directly between the two).

The tape files that the TQ driver creates, have to be converted in Raspbian before they can be read with tar. I have written a small recipe with some examples on how to use the tape driver to backup your home directory and to transfer files. I have also slightly modified the required perl scripts to reference perl properly in Raspbian.

See the pdf file referenced under "Using the TQ tape driver" in my BSD repo: https://github.com/rricharz/pidp11-2.11bsd

Please let me know if something needs to be added or corrected.

[Jon Brase]

On Sunday, December 8, 2019 at 11:47:42 PM UTC-6, Rene Richarz wrote:

See the pdf file referenced under "Using the TQ tape driver" in my BSD repo: https://github.com/rricharz/pidp11-2.11bsd

Please let me know if something needs to be added or corrected.

Careful!!!

Your instructions suggest:

sudo leafpad boot.ini

You shouldn't run graphical applications with sudo. Formerly, there were variants of sudo for this task, such as gksu. Now, those have been deprecated, and it's preferred to use pkexec to run graphical applications with root privileges.

Another option is to use sudoedit (or the -e) option to sudo, with the SUDO_EDITOR environment variable set appropriately. This runs the editor unprivileged on a temporary file, then copies the temporary file over the original as root when the editor exits.

[Rene Richarz]

On Monday, December 9, 2019 at 3:05:16 PM UTC+1, Jon Brase wrote:

 

Your instructions suggest:

sudo leafpad boot.ini

You shouldn't run graphical applications with sudo....

Thanks, Jon. I have removed that and left only "sudo nano boot.ini" there. It's a bit strange. A quick search on the internet showed lots of "sudo leafpad", but none mentioning that this should not be done. Just shows again that the internet is very useful, but also full of bad advice.

[Jonathan Morton]

> On 8 Dec, 2019, at 10:16 pm, Lars Brinkhoff <lars.br...@gmail.com> wrote:
>
> Do you think there would be any energy transfer in the space dimensions of the CRT? E.g. does a brightly lit point also make the neighboring area glow?

In general the beam produces a Gaussian spot on the phosphor at any given instant. The width of that spot depends on the beam focus, and is one of several reasons why TVs never made good VGA monitors; analogue broadcast TV expects a wide beam focus while displaying 80-column text or a WIMP desktop requires a sharp focus. It's possible for the focus to be biased to be sharper horizontally than vertically, and vice versa, but a vector terminal would probably have it circular.

A good-quality CRT shouldn't show any wide-area artefacts beyond that. However if you set up a basic 20MHz CRT oscilloscope at maximum brightness with no input signal and a slow sweep, you might see a faint disc of glow around the very bright trace point. I think it would be reasonable to leave this out of a terminal emulation.

- Jonathan Morton

[Chase Covello]

Thanks, Jon. I have removed that and left only "sudo nano boot.ini" there. It's a bit strange. A quick search on the internet showed lots of "sudo leafpad", but none mentioning that this should not be done. Just shows again that the internet is very useful, but also full of bad advice.

As far as I understand, it's not because it's a security risk (you need to trust anything you run as root anyway), but because graphical apps create a lot of hidden configuration files that will then be owned as root. Then when you run the same program as your user, things might not work. You can always chown the files back once you find them. See this page for more information:

https://askubuntu.com/questions/270006/why-should-users-never-use-normal-sudo-to-start-graphical-applications

[Jon Brase]

I'll note again that you can use:

SUDO_EDITOR=leafpad sudoedit boot.ini

or, equivalently,

SUDO_EDITOR=leafpad sudo -e boot.ini

As this does not run the editor as root, so there's no risk of changing the ownership of user configuration files.

There's also the option of using pkexec, although I don't know if Raspbian distrubutes the appropriate pkexec configuration files to make leafpad work using pkexec (which refuses to run graphical applications as root unless specifically configured otherwise, per application).

[Johnny Billquist]

Without looking at your document, I'd just like to point out that yes,
tape "files" needs a special format, because they simulate tapes. Tapes
have records with lengths. Recorded when written, and reads will only
read the current record. If you try to read more, you will only get as
much as was in the record, and if you read less, the rest of the record
is discarded, which means a second read will not get the rest, but will
instead get data from the next record.

And there are two common file formats for tapes, which simh understand.
One is where each records is preceded by a two byte length field. Tape
marks are indicated by 0 length records.
The second format have 4 byte length fields, and each record have the
length both before and after the data. Again, tape marks are indicated
by a 0 length record. And 0 length records only have the length once.

Obviously, no such format information is required for disks, since
blocks are of fixed length. And it's the same with DECtape. Blocks are
of fixed length, so no need for length information, nor tape marks.

Johnny

[Henk Gooijen]

I am still working on the RK05 drive ... it is looking good, 3D printing the cartridge is still a problem.

I have the software modifications added in SimH.

I stumbled on one problem I just cannot get fixed it seems: the control of the ON CYL lamp.

ON CYL must be off when the drive does a seek operation.

I have added print statements in pdp11_rk.c (attached), but to my surprise RKCS_SEEK never occurs ???

(you can find all print statements with "printf("\t\tpdp11_rk.c")

I would expect that deleting/adding files to the drive, or a "format RK0:" would imply several head movements, thus seek operations.

I just don't see them, so the ON CYL lamp is lit all the times.

Can somebody point me in the right direction, or tell what I seem to miss?

Thanks!

Henk

[Henk Gooijen]

After some good reading of the RK05 documentation, I noticed the following:

"For a write function, the controller first performs a seek operation ...". The same goes for any read operation!

So, in the function rk_go() the requested function is only initiated. I turn off the ONCYL lamp, and in the function rk_svc() I turn on the ONCYL lamp.

Now, I notice a very brief blink of the ONCYL LED. Adjusting the rk_swait and rk_rwait from 10 to 1000 makes the ONCYL lamp clearly visible flashing, alternated by RD or WR flashing.

In the function rk_set_done() the operation is finished, so I simply turn off the WR and RD LED.

This looks more like it, hurray!

[Neil Higgins]

A non-expert comment: ONCYL (the real one) is probably very physical - driven by the cylinder servo electronics, and maybe having a link back into some kind of “ready” status” for reading and writing - maybe even the “ready” bit in the CSR, albeit there are probably several conditions to be met for “ready”.

[Henk Gooijen]

Thanks Neil.

Yes, ONCYL will only lite up if the head no longer moves. It is described in the doc.

Major progess! The disk cartridge is printed, hurray!  It is printed in two halves, upper and lower. Each half took 20 hours to print!

In the picture you see a real RK05 cartridge, the tiny 7 cm diameter experimental test print, and the final 21 cm (approx 60% scaled) version.

Next step, use a Dremel to cut the opening/pocket for the magnetic USB stick connections ...

[Neil Higgins]

Dude!

That is way cool!

[Henk Gooijen]

With some breaks, I have been working on PiDP-11/70 related projects.

I have made a few web pages describing the ideas. It is too late, but I realize now that I should have taken more pictures.

The PiDP-11/70 in a metal box is finished, and the RK05 has the finish line in sight.

I have put the scribbles online. Goto www.pdp-11.nl and scroll down in the navigation tree at the left side. In the folder "my projects" at the bottom is a folder "PiDP-11/70". If you click *on* the folder you get some introductory text at the right side, if you *open* the folder you see links to these projects.

[Brian Makin]

perhaps interesting?
https://hackaday.com/2022/09/26/tiny-dongle-brings-the-hard-drives-song-back-to-updated-retrocomputers/