On Feb 22, 2022, at 12:27 PM, Joshua Rice via cctalk <cctalk at classiccmp.org> wrote: I have a generic 5.25? (not sure of brand) in my dell GX1 but it writes plain SSDD floppies in RX50 format no problem. The RX33 was a pretty standard PC floppy drive AFAIK, just configured (with jumpers) to work as an RX33. You may find better milage configuring it as a PC floppy drive, as PUTR expects to work on PC drives at the device level. Having a real RX33 might be throwing it off. Don?t take it as gospel, since i?ve not got an RX33 to test it with. Not sure if PUTR can copy images to a floppy, as i?ve only used it to build a bootable RT11 disk, and make a few RT11 disks out of the contents of images mounted by PUTR. You might find it better to work on a blank formatted floppy and build up from there.

I was wondering how well a Greaseweasel would write floppies for my Rainbow.

Also, I saw that someone had images for Venix-86 Rainbow and I was wondering if they would be interested in sharing them.

Thanks Ray Sent from my Verizon, Samsung Galaxy smartphone Get Outlook for Android<https://aka.ms/AAb9ysg> ________________________________ From: cctalk <cctalk-bounces at classiccmp.org> on behalf of Paul Koning via cctalk <cctalk at classiccmp.org> Sent: Tuesday, February 22, 2022 1:17:12 PM To: Joshua Rice <Rice43 at btinternet.com>; cctalk at classiccmp.org < cctalk at classiccmp.org> Subject: Re: Installing an operating system on the 11/83 - update. cctalk at classiccmp.org> wrote: plain SSDD floppies in RX50 format no problem. (with jumpers) to work as an RX33. You may find better milage configuring it as a PC floppy drive, as PUTR expects to work on PC drives at the device level. Having a real RX33 might be throwing it off. Don?t take it as gospel, since i?ve not got an RX33 to test it with. build a bootable RT11 disk, and make a few RT11 disks out of the contents of images mounted by PUTR. You might find it better to work on a blank formatted floppy and build up from there. I have a utility to go between real floppies and images, it's included with my RSTSFLX utility. It can deal with interleaving, so (for example) you can have an image file in logical block order as they usually are, and copy that to a floppy in the correct physical order. Or you can have an image that's in physical order, as you would use for the xHomer fork of SIMH. Look for svn://akdesign.dyndns.org/flx/trunk -- the program I mentioned is rx50.py. I have no idea if this can be made to work on Windows, but it runs fine on Linux. (I did once, long ago, write code for DOS -- DJGPP -- to access the PC floppy in the right way to read/write RX50 format floppies, but while that works fine under Win95 it probably won't work under WinNT derivatives.) paul

Rod, Not sure an RX33 (if 1.2MB equivalent) would write working RX50 800k (double density) disks. Very different drives.

I've successfully put an actual RX-50 drive on my PC, and written RX-50 images using PUTR. You might try that route.

- John Singleton On 2/22/2022 11:20 AM, Rod Smallwood via cctalk wrote:

I read that you can indeed use a standard 1.2 Meg drive and that you can also use DSHD 5.25 disks in place of RX50s. Is there any truth in this? If there is it will be much easier and cheaper to make disks for my Rainbow.

On 2/22/2022 7:00 PM, Ray Jewhurst wrote: As Chuck noted, I'd think you'd want to use 360K media -- not DSHD diskettes... and ensure that the 1.2MB drive is slowing down to 300RPM with a data rate of 250KHZ. These features will depend on the 1.2MB drive you have, as well as your FDC and imaging software. - John Singleton

Writing a 360KB or RX50 diskette with a 1.2MB drive is a path to a lot of frustration.? Not only do you have to double step the drive (software often takes care of that part), but the tracks written will be narrower than a real RX50 / 306KB drive, providing a smaller signal/noise ratio. ?And, if you don't start with completely magnetically erased media, any left over junk in any data left over may be picked up by the RX50 head.

From http://home.iae.nl/users/pb0aia/vax/rx50.html

On Feb 22, 2022, at 22:59, Ethan Dicks <ethan.dicks at gmail.com> wrote: ?On Tue, Feb 22, 2022 at 10:43 PM Jay Jaeger via cctalk <cctalk at classiccmp.org> wrote: A real RX50 is an 80-track drive. You are correct that writing a "360K" floppy on a high-density drive is not a good idea, but a real RX50 _is_ 80 tracks, just single-sided, for a total of 400KB per disk.

-ethan

On Tue, Feb 22, 2022 at 4:36 PM js--- via cctalk <cctalk at classiccmp.org <mailto:cctalk at classiccmp.org>> wrote: Rod, Not sure an RX33 (if 1.2MB equivalent) would write working RX50 800k (double density) disks. Very different drives. The RX-33 is the same sort of drive that you had in your PC if you wrote RX-50s with your PC. Back in the day, lots of people used RX50.SYS to have it setup the transfer rates, RPM and sectors per track parameters so that you could read/write them on a PC running DOS. The parameters are basically the same ones you need to write the 360k DOS floppies, only with twice the number of tracks and 10 sectors per track instead of 9 (this is done by making the track gaps smaller and eeking an extra sector out of the deal, but using at the same data rates).

I've successfully put an actual RX-50 drive on my PC, and written RX-50 images using PUTR. You might try that route. Did you have difficulties with Pin34 not being the change disk pin? That's what I ran into when I tried this many many years ago... Warner

Originally I wrote my RX50 floppies on a Windows PC. The drive was a plain old 5.25 inch PC drive, normally used for 9 sector per track PC floppies. It turns out some BIOS operations will reset it to 10 sectors, which is RX50 format, and then BIOS int13 operations can read and write it. I coded up support for that in RSTSFLX, which can be found on my Subversion server (in branches/V2.6). The original version was built with Borland C++, but I switched to DJGPP which made all that much easier. No CMOS or other magic needed, just an application that knows how to speak int13. And of course an old enough Windows, or plain DOS, which allows you to do those operations. Subsequently I moved all this to Linux. There is (was?) a tool -- fdparm? -- that you could use to tweak the floppy layout settings. A simple entry in its config file would give the RX50 layout. Then it's just a matter of handling the sector interleaving, track skew, and odd track numbering. With just a few more lines of code, the application can handle the parameter setting so no prior setup is needed, which is what I ended up doing in RSTSFLX (in C). The latest version does this as well, but in Python. So as far as I can see, all this stuff is perfectly easy if you just use a plain ordinary floppy drive.

On Tue, 22 Feb 2022, Bill Gunshannon via cctalk wrote: Certainly! The Coco used a Western Digital 179x controller. I don't remember which specific one, and for simple stuff like this, it won't matter much. The WD doesn't have the "flash blindness" that sometimes interferes with the NEC 765 series when reading disks where the first sector is too soon after the index pulse. The WD has a semi-raw track read that is real handy (The NEC has a multiple sector read, but not a raw track read) There have been some programs on the Coco for reading and writing some other formats. ISTR Dr. Marty did one on the Coco for reading PC disks. (probably published in Rainbow) The TRS80 Model 3 and 4 also used 179x controllers. With very different operating systems (The Randy Cook family of OS). Look for by Mike Gingel, as a program running on TRS80. Also, "Trakcess" is very handy for analyzing disks, although you need to do some trivial mods to it for double sided, etc. Looking at the program of Trakcess will make it easy to get the basics to do almost anything that you want to do. William Barden did a nice pamphlet on disk I/O for TRS80. Then Harv (HC) Pennington wrote very extensively about the internals of TRS-DOS. Until August 1981, when the 5150 came out, my disk format conversion work was on TRS80. The TRS80 model 1 used the 1771 controller which was single density only. And, the original SA400 single sided drive on it only got 35 tracks. Be careful, the second side signal on the cable is used on the Model 1 as drive select for the fourth drive! (Tandy wasn't planning on DS drives) But, the retrofit "Doubler" added a 179x controller. As a REAL programmer, you can shoot yourself in the foot with any language or operating system! (Is that the definition of programmer?) -- Grumpy Ol' Fred cisin at xenosoft.com

Hi, folks. ?? I've a HP 9915A computer with an interesting problem.?? The motherboard utilizes a ceramic Intel D8048 chip.?? The problem is that this 8048 has a crack right across the top middle of it, and half of the top of the chip has begun to separate. ? Powering up the machine as-is unsurprisingly results in no activity.?? HOWEVER, if I push firmly on the cracked area with my finger the machine starts to operate normally.?? All appearances are that clamping down the separating piece of the chip re-establishes any broken wire connections within the chip. ?? I've obtained a replacement P8048AH.?? My question is: do these chips simply swap like a CPU, or -- as I fear -- is the 8048 a pre-programmed piece???? More simply put, is this a repairable problem?? Or am I SOL? ?? Any thoughts welcomed. - John Singleton

As Paul said, the 8048 is mask programmed. However, I agree it is readable. I "think" if you follow the "verify" step in the linked datasheet you can read from the rom. https://www.ceibo.com/eng/datasheets/Intel-8048-8049-8050-plcc-dip.pdf Will

As the chances of success are highly improbable, looks like I'm SOL on this particular motherboard.

On Sat, Feb 26, 2022 at 5:19 PM js--- via cctalk<cctalk at classiccmp.org> wrote: My bench is rather full at the moment and will be for a few more weeks... But if you get no other help and you can wait a bit, I believe one of my old EPROM programmers can read the 8048/8748 with the right adaptor, and the schematic of that is in the manual. I also have a working (I hope) HP9915. So I could have a go at making said adaptor, extracting the 8048 from my HP9915, and readng it out. You would then have to find somebody who could program the ROM image into an 8748. -tony

On Mar 28, 2022, at 12:24 PM, js--- via cctalk <cctalk at classiccmp.org> wrote: ? Hi, folks. With the help of the extremely talented people here, the far less talented me was able to repair this seemingly impossible problem and get the 9915 functional. The process was to: 1) burn a new 8748 CPU with the 9915's 8048 ROM code. I used a Data I/O 2900 for this purpose. 2) remove the remnants of the original 8048 CPU 3) install a new milled 40 pin socket 4) install the 8748 into that socket and power-on test. Thanks to Paul Berger, Will Cooke, and Wayne S for their useful suggestions. A very special thanks to Tony Duell for offering to go to great lengths to help. A very, very special thanks to Dave McGuire for having done all the hard work in retrieving the 8048's code to begin with (which he had done already for someone else), then providing the 8048 ROM code to me in hex format, plus guidance on how to fix the problem all the way through. - John S.