Re: TC08 DECtape bootloader question
On Sat, Mar 20, 2021 at 7:19 PM Kyle Owen wrote: > However, it appears as though word count will be hit by the loading of the > first block. In fact, my instrumented version of SimH says it's overwritten > with a zero. If that's the case, it would seem as though the word count > overflow flag will never get set. Not to mention, the current address will > be updated next, causing data to be redirected to yet another position. > To continue this thought, it appears as though SimH does the following for a read data break: 0. Increment WC 1. Increment CA 2. Compute memory address from the extended memory bits from the TC08 and CA 3. Store the data from the tape at the memory address specified from 2. 4. Check if WC equals zero, and handle that accordingly >From what I can tell, both the PDP-8/E and the PDP-8/I set the WC overflow based on the carry out from the adders...so if WC happens to be overwritten with a zero, a carry out will never happen in the real hardware. In SimH, the entire WC is tested and compared to zero. This behavior seems different. Kyle
TC08 DECtape bootloader question
My understanding of the OS/8 TC08 bootloader (MI8-EC) is as follows: 0. Rewind tape 1. Set current address (07755) to 07600 2. Set word count (07754) to -0200 3. Read block 0 and wait for flag 4. Continue executing at 07600 However, it appears as though word count will be hit by the loading of the first block. In fact, my instrumented version of SimH says it's overwritten with a zero. If that's the case, it would seem as though the word count overflow flag will never get set. Not to mention, the current address will be updated next, causing data to be redirected to yet another position. But according to SimH, a write to the current address, 07755, never happens. How can this be? Any help would be appreciated! Kyle
Re: DECtape ancestry
> On Mar 20, 2021, at 4:21 PM, Kyle Owen via cctalk > wrote: > > On Sat, Mar 20, 2021, 16:13 Paul Koning wrote > >> Speculating here since I have no direct knowledge: the DECtape format >> allows read and write in either direction, while LINCtape only allows read >> and write forward. The bidirectional I/O capability was part of DECtape >> format from the start, and I suspect the desire was to keep that. > > > What systems took advantage of the bidirectional nature? > > Kyle DOS-11 for one (and thus RSTS, which reuses that format). DOS DECtape files are linked lists; each block contains a link to the next block. To allow for reading one block at a time, start/stop mode, DOS interleaves 4:1. If you're allocating a long file and the allocation reaches end of tape, allocation then continues in the reverse direction. The extreme case of a single file that takes up the whole drive looks like two up/down passes over the tape, each one touching 1/4th of the blocks in each direction. When a file is read, blocks are read in the same direction as they were written. The direction is given by the sign of the block number in the link word, negative means reverse. As Grant pointed out in the oral history interview, bidirectional DECtape I/O in the sense that you could read a block in the opposite direction it was written isn't all that useful. While the PDP-11 controller does the obverse complement thing, that just means you get the bits in the word correct but the 256 words are still in the opposite order. That could be handled, of course, but I haven't seen programs that do so. Well, one exception: the tape formatter does the write timing/mark forward, then write all in reverse, then reads (to check) forward. But those are test patterns so the job of dealing with the direction change is easy. paul
Re: DECtape ancestry
On Sat, Mar 20, 2021, 16:13 Paul Koning wrote > Speculating here since I have no direct knowledge: the DECtape format > allows read and write in either direction, while LINCtape only allows read > and write forward. The bidirectional I/O capability was part of DECtape > format from the start, and I suspect the desire was to keep that. What systems took advantage of the bidirectional nature? Kyle
Re: DECtape ancestry
> On Mar 20, 2021, at 4:07 PM, Kyle Owen via cctalk > wrote: > > Why did DEC not use the LINCtape format for the PDP-8? I assume maintaining > format compatibility between their low, mid, and high range systems was > important to them? I suppose there was no other good solution to > transferring large files across different DEC platforms than to use > magnetic tape...so I may have answered my own question here. > > Kyle Speculating here since I have no direct knowledge: the DECtape format allows read and write in either direction, while LINCtape only allows read and write forward. The bidirectional I/O capability was part of DECtape format from the start, and I suspect the desire was to keep that. Also, the DECtape format (ignoring the funny bit order in the PDP-1 case) is the same across all models except for the block size and count in the PDP-8 case. Chances are the desire was to reuse all that design. paul
Re: DECtape ancestry
Why did DEC not use the LINCtape format for the PDP-8? I assume maintaining format compatibility between their low, mid, and high range systems was important to them? I suppose there was no other good solution to transferring large files across different DEC platforms than to use magnetic tape...so I may have answered my own question here. Kyle
the question
Hi, I just wanted to thank Tony for asking the question (disability vs. masks) and particularly wanted to thank Robert for the kindness of answering it! I learned something today! Stan
ODE 2.1.1 documentation
Hello! Does anyone have any old documentation for ODE 2.1.1, or relatively close versions? I know "newer" versions have been released and have documentation available, but there are some changes in some of the config files that are very different from older versions. For example when creating a sandbox, in the sandbox directory there is a subdirectory called rc_files, that is supposed to have two files, "local" and "shared", but they don't work the same way that rc_files/Buildconf and Buildconf.exp work in newer versions... Anyone on here know anything about ODE, or any other sources of information? Many thanks!
Re: VCF Swap Meet in Wall, NJ
On 3/19/2021 7:00 PM, Bill Degnan via cctalk wrote: But, there have been no verified accounts of giant squid attacks in Wall, NJ. I know Evan is doing a lot of train installation at his house, but I suspect that and the Miata are distractions so we don't see the large pool sized aquarium in the basement. Thanks Jim
RE: VAXstation 2000 network & hardware guides (English & German)
These arrived this morning and they are scanned and OCR'd here:- https://1drv.ms/u/s!Ag4BJfE5B3onlY9td7hHhHPnUKV2bA?e=hDKwES I think I can scan at lower resolution and/or grey scale as these are a bit on the huge side Dave > -Original Message- > From: dave.g4...@gmail.com > Sent: 15 March 2021 13:39 > To: 'David Brownlee' ; 'General Discussion: On-Topic and > Off-Topic Posts' ; r...@jarratt.me.uk > Subject: RE: VAXstation 2000 network & hardware guides (English & German) > > David & Rob > Are these "loose leaf"? If so I am happy to scan, upload, and then pass the > paper to Rob who isn't far from me > Dave > > > -Original Message- > > From: cctalk On Behalf Of David > > Brownlee via cctalk > > Sent: 15 March 2021 09:43 > > To: r...@jarratt.me.uk > > Cc: General Discussion: On-Topic and Off-Topic Posts > > > > Subject: Re: VAXstation 2000 network & hardware guides (English & > > German) > > > > Hi Rob > > > > I forgot to mention I'm in the UK :) > > > > I had another email in from someone in Germany who has access to a > > book scanner - if you're setup to scan and upload EK-NETAA-UG-001 > > VAXstation & > > EK-VAXAB-IN-002 I'm happy to part them out to you as you emailed first > > - let me know > > > > David > > > > On Sun, 14 Mar 2021 at 19:25, Rob Jarratt > > > > wrote: > > > > > I would be interested in EK-NETAA-UG-001 VAXstation 2000, MicroVAX > > > 2000 and VAXmate Network Guide and the EK-VAXAB-IN-002 VAXstation > > 2000 > > > Hardware Installation Guide would be nice if you get no takers. You > > > don't say where you are located. I suspect shipping from the USA to > > > the UK would be too expensive, or is this in Germany? > > > > > > Regards > > > > > > Rob > > > > > > > -Original Message- > > > > From: cctalk On Behalf Of David > > > > Brownlee via cctalk > > > > Sent: 14 March 2021 18:08 > > > > To: General Discussion: On-Topic and Off-Topic Posts > > > > > > > > Subject: VAXstation 2000 network & hardware guides (English & > > > > German) > > > > > > > > I have acquired a tiny slice of Orange Wall, and wondered if > > > > anyone > > > would be > > > > interested - preference for anyone who is setup to scan and upload > > > > the missing bits to bitsavers or similar :) > > > > > > > > These seem to already be generally available online > > > > EK-NETAB-UG-002 Workstations and MicroVAX 2000 Network Guide > > > > EK-VAXAB-OM-002 VAXstation 2000 Owner's Manual (Covers how to > > > > replace your mouse balls, and details exciting options such as > > > > LN03, > > > > LN03 PLUS, LPS40, LA210, LA100, LA75, LA50. LGC01, LVP16, DF224, > > > > DF124, DF112, > > > VSXXX- > > > > AB :-p) > > > > > > > > These I cannot immediately find > > > > EK-NETAA-UG-001 VAXstation 2000, MicroVAX 2000 and VAXmate > > Network > > > > Guide > > > > EK-VAXAB-IN-002 VAXstation 2000 Hardware Installation Guide > > > > > > > > Likewise these German versions > > > > EK-NETGA-UG-001 VAXstation 2000, MicroVAX 2000 und VAXmate > > > > Netzwerk-Anleitung EK-A0305-IN 001 VR160 Installations-und > > > > Bedienungsanleitung > > > > EK-A0355-OG-001 Grafikkoprozessor (8 Bildebenen) fur die > > > > VAXstation > > > > 2000 > > > > Installations- und Bedienungsanleitung > > > > > > > > Thanks > > > > > > > > David > > > > > >
