test-drb November 2015

test-drb@ccmp.vtda.org

169 participants
223 discussions

Substituting DSHD for DSDD disks (or DS2D if you prefer)

by echristopherson＠gmail.com

I know Chuck Guzis has written about this, but I don't see that he's done so publicly in the last few years, so I thought I'd ask here about his and others' views on the perennial question of whether (some) 3.5" DSHD disks can be reliably used in DSDD-only drives. The oft-repeated claim is that writing can appear to work just fine, but that even a few months later read errors will occur. On <http://www.retrotechnology.com/herbs_stuff/guzis.html> Chuck was quoted as (actually, correct me if I'm wrong -- it's a little hard to be sure this was Chuck's words) as saying "Usually, they're just fine, with the error rate approximately the same, whether or not 2D or HD media was used." Just before that, he said "I think that the overall quality of DSHD 3.5" media isn't what it used to be, so that might contribute to the general impression that 3.5" HD diskettes used as 2D aren't reliable. I have problems enough finding reliable 3.5" DSHD floppies used as such." Chuck et al., what's your feeling now, both on the overall reliability of HD disks in DD drives, and on whether it depends on how recently the disks were produced? Elsewhere on the page (I don't recall now if it was Herb or Chuck that said it) it was conjectured that HD disks that have never been formatted as HD, -OR- disks that have gone through a good degaussing, will have better luck retaining data. What does everyone think about this? And would an electromagnetic library security system (the kind that's like a tube through which checked-out materials are put; often with a caution not to put tapes or floppies through it) be a suitable degausser? -- Eric Christopherson

8 years, 2 months

M9301-YB Bootstrap/Terminator ROM dumps / listings?

by jnc＠mercury.lcs.mit.edu

> From: Johnny Billquist bqt at update.uu.se > The per-device code are in separate PROMs that are used in both the > 9301 and 9312. Those are the ones with the device code as constants in > the beginning of memory space for the PROM, by the way. As I mentioned, the M9301-YA, at least, does not have this code. (See the listing.) Also, again on the M9301-YA, the various bootstraps, diagnostics, and console, are scattered through both banks (ditto), so one can't just replace a PROM or two to chance the supported devices; one would have to replace the entire set of 4 PROMs. > I hope you also are aware that both the M9301 and the M9312 have > different boot roms for some machines. I know that the 11/70 use > different roms with other tests than other PDP-11s, and I seem to > remember that one or two others do as well. (The 11/60 keeps popping up > in my brain...) I have yet to investigate the M9312's in depth, but I did know there are quite a few different versions of the M9301 (which amount to different ROMs: I know there are two different etch revisions of the card itself, but I think they are programming-wise identical). I don't know of any good list of the variants, but here are the versions I know of (device codes abbreviated to save typing): M9301-YA /04 and /34 OEM version; has basic diagnostics, console emulator, boots from various devices (RK, RP, TC, TM, DL, PC, TA, RX), supports auto-boot on power on, and also power-fail restart M9301-YB /04 and /34 end user version; has basic diagnostics, console emulator, boots from various devices (RK, RP, TC, TM, TA, RX, DL, PC, RJS, RJP, TJU), also power-fail restart M9301-YC /70 version; contains basic CPU, cache and memory diagnostics, boots from various devices (TM, TC, RK, RP, RK06, RJS, RJP, TJU, RX) M9301-YD All models; contains code to allow a terminal attached to the machine to be a terminal on some other line; also has boot code for RX and DDCMP M9301-YE All models; has basic diagnostics, console emulator; boots from low speed paper tape or DECnet; supports auto-boot on power on, and also power-fail restart M9301-YF All models (auto-start not available on /45, /50); has basic diagnostics, console emulator, boots from various devices (RK, RK06, RP, TC, TM, TA, RX, DL, PC, RJS, RJP, TJU) supports auto-boot on power on, and also power-fail restart M9301-YH /60 and /70 version; contains basic CPU, cache and memory diagnostics, boots from various devices (TM, TC, RK, RP, RK06, RJS, RJP, TJU, RX, PC) M9301-YH All models; has basic diagnostics, console emulator; boots from DECnet, and various devices (RX, TU, DL, DMC), also power-fail restart The -YA is the only one I have examined in detail. Noel

8 years, 3 months

Reinstalling SunOS 4.1.4 without CD drive

by echristopherson＠gmail.com

A very generous list member just gave me a SPARCStation 20 with SunOS 4.1.4 on it. I thought the first thing I would do would be to image its hard drive in my Linux PC, in case I ever wanted to start fresh. I assume that if I make a bitwise copy of it, I can later write those same bits out. But now I'm wondering what would happen if the disk developed marked bad sectors; would that make an exact image impossible to write onto it? I have a disc image of that release, but unfortunately no SCSI CD-ROM. It occurs to me that I could perhaps make a SunOS filesystem on Linux and untar things from either the install CD or the image of the original HD into it, but I don't know if that would produce something actually bootable. I'm hoping there would be some way within Linux to capture the actual format of the filesystem to use as a skeleton. Does anyone know if this is possible (viz. creating a valid, bootable filesystem and untarring files into it)? Or should I just invest in a CD-ROM drive? -- Eric Christopherson

8 years, 3 months

WD9000 Pascal Microengine floppy adapter (was Re: WD9000 Pascal microengine schematics available)

by spacewar＠gmail.com

The WD9000 Pascal Microengine main box does not include floppy drives. It can support up to four floppy drives, which can be either 8-inch (500 kbps transfer rate), or 5.25-inch (250 kbps transfer rate), as selected by a DIP switch setting on the WD900 board. Unfortunately the DIP switch directly controls the clock rate into the 1793 FDC chip, so it is not possible to mix 250 kbps and 500 kbps drives. However, it should be possible to mix 8-inch drives with high-density 5.25 inch or 3.5 inch drives that use the 500 Kbps transfer rate. The floppy connector on the back of the WD9000 box (and the WD900 board) uses a DC37S connector, and the pinout seems to be unique to the Pascal Microengine. My Microengines did not come with the floppy drives or cabling. I've designed a simple adapter PCB, and just got the first boards back from PCBWay today. I haven't yet finished assembling one because I screwed up ordering on some of the components and connectors. Photos: https://www.flickr.com/photos/22368471 at N04/albums/72157660580290148 The WD900 board uses an FD1791 double-density floppy controller. It appears that the main board may have been originally intended for the FD1771 single-density controller, as the board revs I've seen don't have a suitable double-density data separator built in. On one of my units, the FD1791 is on a daughterboard with a typical analog data separator design using the WD1691 floppy support logic and a 74LS629 VCO. My other board has the FD1791 on the main board, but has some significant rework to install an SMC FDC9216B digital data separator chip in place of one of the TTL chips originally used by the main board design. I've seen other WD900 boards with the FDC9216B modification, so I think this was rework done at manufacturing time, rather than a field change. One aspect of the floppy controller design seems a bit unusual. The WD controllers have a HLD output used to tell the floppy drive to load the head, and an HLT input (Head Load Timing) to indicate that the head is loaded. After the controller asserts HLD, it waits for HLT to go true before proceeding with read, write, or format operations. A typical 8-inch drive takes 35 ms to load the head, and maybe a few more for head settling. A common way to wire the controller is to use an external one-shot triggered by HLD, with its output wired to HLT, and adjusted for a time delay a little longer than the drive requires for loading the head. 8-inch drives typically can either be jumpered to use a dedicated head load control line on the interface to control the head load solenoid, or to automatically load and unload the head as the drive select signal is asserted and deasserted. Normal 8-inch drives have the head load solenoid to do what was previously described, and run the spindle motor either all the time, or whenever a disk is inserted and the door closed. 5.25-inch drives, and some later 8-inch drives such as the Tandon TM848, do away with the head load solenoid and instead are intended to operate with the spindle motor active only when the drive is selected, or when a motor control signal is active. As such, they don't require any head load time, but instead require a motor startup time that is even longer; the slowest drives require about a second for spinup. With a WD controller, this is also sometimes accomodated by using the one-shot between HLD and HLT. Some WD-based controller designs, such as those in the TRS-80 Model I, III, and 4, are only intended for 5.25-inch drives (or the 8-inch drives that use motor control and no head load solenoid), and tie the READY signal from the drive to the HLT input of the FDC. The WD900 board tries to acommodate these variations by bringing the HLT signal to its DC37S connector, for the system integrator to wire up as desired. The only complete Pascal Microengine system I've seen up close in recent history had a hand-wired drive cable to 8-inch drives, with the HLT signal simply tied to a +5V pin on the same connector. The net effect of that is that the FD1791 asserts HLD, delays 15ms if the h bit of the command is 1, and does not delay any further. Unless the drive can actually load its head that quickly, this doesn't seem ideal, but I suppose it works because the FDC won't be able to read a valid sector address field until the head is loaded. For a write operation, I'd worry that the head might not have fully settled by the time the actual write begins, possibly leading to unreliable writes. To support proper head load or motor spinup timing, I put an optional PIC microcontroller and DIP switch on the adapter, to act as a digital delay between HLD and HLT, with sixteen switch-selectable delays. The drive select lines are wired to PIC inputs, so if desired, firmware could actually use different delays for different drive selects, if you mix drives with different head load timing requirements. I haven't yet written any PIC code for it. The board should basically work as described above with HLT jumpered to +5V, without the PIC and related components installed. The adapter has both a 50-pin connector for 8-inch drives, and a 34-pin connector for 5.25-inch or 3.5-inch drives. It is intended for one connector or the other to be used, but not both. Even if you use a combination of drives that all use the 500 kbps transfer rate, having them cabled separately to the two connectors could result in termination problems. Naturally, only hours after ordering the PCBs I thought of improvements that I'd like to make to the design, but I don't anticipate that there will be a second run of boards. I don't presently have any bootable disk for the Pascal Microengine, so I'm not yet able to test the adapter. However, if anyone else needs such a thing, I have a small number of bare boards that can be made available inexpensively. (I don't have time to assemble boards other than for myself.) If there's any interest, I'll publish the Eagle design files, gerber and excellon files, a PDF of the schematic, and source and object code for the PIC firmware. The firmware will be GPLv3 licensed, and the other design files with be under a Creative Commons license, probably CC BY-SA 4.0.

8 years, 4 months

IBM PS/2 Model 70 HARD DRIVE NEEDED

by mokuba＠gmail.com

Got a hard down situation and need to re-install/recreate the BBS system I had running. HDD makes swishy noises when shaken, haven't tried stirring yet. I /guess/ a bootable MCA SCSI card would work too... ;) I had the 160MB drive, but anything above 30 would work - i guess i'll just have to use a SCSI Drive for the file storage area once i get an MCA SCSI card .... -- Gary G. Sparkes Jr. KB3HAG

8 years, 4 months

QIC Tape help with CRC - Dwight?

by microtechdart＠gmail.com

While I'm new to speak up here, I've been watching for a while. I've also used the name "MightyFrame" on groups, although that email address is not registered with this list. A few months back, I published a page decoding QIC-24 format. http://mightyframe.blogspot.com/2015/08/qic-24-tape-data-block-format-decod… Dwight posted a very meaningful response to this about the CRC on my site, and it has taken me this long just to get to it. Thanks again for that, Dwight! This project has gone very well for me, with one hangup...the CRC. I've never calculated one of these before, and I'm struggling with this one. I have a QIC-24 block of data attached in a .txt file, and I just can't get the calculations to work. For my simple understanding so far, I'm using an online calculator to test this: http://bit.ly/1YbHUZ7 That URL is pre-programmed with the polynomial and the "message" that should provide the CRC result of 0xE8CE (decimal 59598) But, it doesn't. I created this file, wrote it to tape, then read it again and tested it. It is 100% correct for the QIC-24 tape system. This is block 3 of 4 of the file that I have extracted, and am testing here. The ANSI QIC-24 standard booklet (X3.136-1986) says something that I know is a clue, but I just don't understand. "The cyclical redundancy check (CRC) shall consist of two bytes, calculated over the 512 bytes of interchange data, and the 4-byte block address, *starting with all ONEs, CRC initial value*, and using the CRC Generating polynomial: x16 + x12 + x5 + 1 *"starting with all ONEs, CRC initial value"*? What does THAT mean? Do I need to do some kind of register shift? xorin or xorout? I've even played with http://reveng.sourceforge.net/, but I'm having trouble even understanding the meaning of the input values and parameters with this. I appreciate any feedback that anyone can give, here. -- Thanks, -AJ http://MicrotechM1.blogspot.com http://MightyFrame.com

8 years, 4 months

Random question about a Byte Magazine Cover

by mark＠wickensonline.co.uk

OK so this has been bugging me for a while. During a stint working at Morgan-Smith Electronics in Hatfield UK (they made diverse electronic systems including industrial PCs and radio alarms) I went through the boss's discarded vintage computer magazine collection and one particular issue I remember finding very interesting. IIRC it was a Byte Magazine (certainly the graphic was very in keeping with Byte cover artwork). I wonder if anyone recalls it - Google image searches have pulled a blank which means it either wasn't Byte (and just looked like it) or hasn't been scanned. The cover had a painted image of a white cliff face draped in vines with an 'Adventurer' in the foreground - you can imagine what the theme was. Anyone have any ideas? Maybe it wasn't Byte? Of course all this really quite irrelevant in the grand scheme of things, but it would help me scratch an itch at the very least. Thanks! Mark.

8 years, 4 months

Project Oberon and OberonStation (resend)

by wmaddox＠pacbell.net

[Yahoo's webmail client garbled the last link -- resending] The revived 2013 re-issue of Niklaus Wirth's Oberon system is a joy to behold.? If you've never heard of Oberon before, it is a minimalistic education-oriented language and operating system designed after Wirth had taken a (second) sabattical at PARC in the 80's. The new version runs on a custom RISC processor, implemented in an FPGA, instead of the NS3032 in the orginal Ceres workstations.?? Originally, it required a Digilent "Spartan 3 Starter Kit" with a custom-built daughterboard providing a few additional connectors.? This board is no longer made, however, and no other FPGA development board appears to provide the 32-bit wide fast SRAM the Oberon CPU required. Recently, a new board, the OberonStation,? has come onto the market that was designed specifically for Oberon, and will boot up Oberon 2013 out of the box.?? It also looks like an excellent platform for other retro-style FPGA CPU designs that want to stay away from complex SDRAM controllers and the caches they like to feed. My OberonStation arrived a couple of days ago, and it's really amazing to see what can be done with a hardware and software stack that is small enough to actually read and understand. https://www.inf.ethz.ch/personal/wirth/ http://www.projectoberon.com/ http://oberonstation.x10.mx/

8 years, 4 months

Oberon and the OberonStation (retro-style FPGA computing)

by wmaddox＠pacbell.net

The revived 2013 re-issue of Niklaus Wirth's Oberon system is a joy to behold.? If you've never heard of Oberon before, it is a minimalistic education-oriented language and operating system designed after Wirth had taken a (second) sabattical at PARC in the 80's. The new version runs on a custom RISC processor, implemented in an FPGA, instead of the NS3032 in the orginal Ceres workstations.?? Originally, it required a Digilent "Spartan 3 Starter Kit" with a custom-built daughterboard providing a few additional connectors.? This board is no longer made, however, and no other FPGA development board appears to provide the 32-bit wide fast SRAM the Oberon CPU required. Recently, a new board, the OberonStation,? has come onto the market that was designed specifically for Oberon, and will boot up Oberon 2013 out of the box.?? It also looks like an excellent platform for other retro-style FPGA CPU designs that want to stay away from complex SDRAM controllers and the caches they like to feed. My OberonStation arrived a couple of days ago, and it's really amazing to see what can be done with a hardware and software stack that is small enough to actually read and understand. https://www.inf.ethz.ch/personal/wirth/ http://www.projectoberon.com/ OberonStation - The Oberon computing platform --Bill | ? | | ? | ? | ? | ? | ? | | OberonStation - The Oberon computing platform/*{{{*/* html .tiddler {height:1%;}body {font-size:.75em; font-family:arial,helvetica; margin:0; padding:0;}h1,h2,h3,h4,h5,h6 {font-weight:bold; | | | | View on oberonstation.x10.mx | Preview by Yahoo | | | | ? |

8 years, 4 months

flash (or ide) storage for unibus 11?

by jhfinedp3k＠compsys.to

>Noel Chiappa wrote: > > From: Jerome H. Fine > > > both DEC and DSD needed a bounce buffer managed by software > >Love that term, "bounce buffer" (I wrote a whole package to support them in a >packet switch I did) - I'm officially adopting it, right now! :-) > > Noel > Hey - anything that anyone writes is automatically copyrighted. So first you need permission to use that! I will try and figure out who the person was that first used that phrase so we can both use it. I did not mention that the concept worked quite well with the DEC RX02 and the DSD RX03 when a PDP-11/73 was used. But when version 1.0 of that device driver was used with a PDP-11/23, the transfer rate was painfully slow because the interleave gap was not long enough relative to the time needed to bounce the buffer. Since the DMA silo had already been emptied into the bounce buffer, the solution was to immediately initiate the next READ into the silo and then bounce the buffer (for a READ request, of course). That allowed the READ of the next sector on the floppy media to be performed by the controller while the CPU was performing a transfer out of the bounce buffer into the user buffer one word at a time. I don't need to test the timing on any slower CPU since, as far as I know, none support an MMU which would be required to use a Mapped RT-11 monitor. I may have the exact details and terminology incorrect - it was about 20 years ago. Jerome Fine

8 years, 4 months

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

1997

test-drb November 2015