rcgldr

I don't have a synchromesh floppy, or the original CP/M floppies.They're either stored somewhere that I haven't found yet, or I was counting on the ATR-8000 to read/write 5.25 inch floppies for CP/M stuff. I haven't found the 5.25 inch floppy drives I used for the ATR 8000 either, just the ATR 8000 and a heavy cabinet with two full height 8 inch floppy drives, and ADM monitor via the serial port. I have no clue if it sill works yet. That will be a project for next week. What INIT does is read the boot sectors from the currently installed disk, and it does this before any user prompts, so if you're running INIT, it's already read in the boot sectors from the CP/M floppy that INIT was run from. To get around this, I used the debugger (ZSID) to load but not run INIT, then I switched to the Doubler floppy disk, and then run INIT from the debugger. This resulted in INIT copying the boot sectors from the doubler floppy disk (it reads two tracks, but the doubler only needs 5 sectors on the first track, the extra copy doesn't matter, there's nothing on on the doubler floppy disk. The same method could be used to copy 256 byte boot sectors from any floppy.

I'm an old guy, started programming in high school back in 1967 on a monrobot, which had a typewriter console, paper tape reader and punch and used a drum memory. https://en.wikipedia.org/wiki/Monrobot_XI The next year we got an IBM 1130 with a line printer, and on Saturdays, the school had a class at an IBM data center, on an IBM 360 model 25 or 30, whatever was available that day. https://en.wikipedia.org/wiki/IBM_1130 In the 12th grade, I also went to a Control Data data center to program a CDC 3150. They also had a CDC 6600 there, but I rarely programmed on it, due to the demand and cost of it. https://en.wikipedia.org/wiki/CDC_3000_series https://en.wikipedia.org/wiki/CDC_6600 My first job was in 1973, a multi-computer, multi-threaded, database application using multiple HP 2100 mini-computers. There were 10 CDC 9760 hard drives, each one bigger than the mini-computers. https://en.wikipedia.org/wiki/HP_2100 http://www.computerhistory.org/storageengine/cdc-disk-drive-departs-from-ibm-standards

Assuming you own some type of PC, you would probably want to start out with basic "console" programs. If you use Windows, Visual Studio Express is free, and includes an IDE (integrated development environment), where you edit, build, and debug all from the same window, and it supports C, C++, assembly, C# (mostly a Microsoft specific language), ... . I use Visual Studio Express 2015, as it was the last "non-community" version of Visual Studio. On the small chance your still using Windows XP, Visual Studio 2010 is the latest version, and you'll need to download an ISO file to install it. Netbeans provides a similar development environment for Java and is also free. Various types of sorting programs seem to be popular for learning.

A standard Indus GT is double density and has 2048 bytes of ram, and it appears the intent was to allow an emulation mode, but other than the "doubler", I don't know if there were any other emulation modes, maybe it needed one to work the the Commodore 8 bit computers. The first 3 sectors are 256 bytes, so in my case, making copies required using CP/M mode on an Indus with a ram charger. A PC with a 5.25 inch floppy drive could do this, but the floppy drive needs to be slowed down to about 288 rpm. There's a rpm utility for the Atari 8 bit computers to help set this. I recall adjusting the speed on some very old full height 5.25 inch floppy drives to use with an ATR 8000, using a small screw driver to turn the input to some timing circuit on the drive. I don't know if this is possible on a 5.25 inch floppy that could be purchased today. In another thread I created about copying such a floppy, I got a few responses, but I don't have the software or hardware that was mentioned, and no current way to transfer external files to the Atari.

In case anyone is following this thread still, I've ordered a SF314 double sided drive. It only needs to run long enough for me to go through a set of floppies I may have missed when doing backups some 20+ years ago. If it continues to work beyond that, it's an added benefit. Surprisingly, it turned out that my Atari 400, 130XE, 1050 floppy drive and Indus GT floppy drive (with ramcharger and CP/M) are also working. If I get interested in the games, I may get some type of emulator.

I can now make copies of the Indus "doubler" boot floppy for standard Indus drives (the ramcharger is not needed). Currently the only way I can make these is with a Indus drive with ramcharger, a CPM bootable floppy with a debugger and the init program. The init program copies the boot sectors, but it reads the boot sectors before any user prompts. By using the debugger, I can load the init program, switch to the "doubler" boot floppy, then start the init program running from within the debugger, in which case it reads the "doubler" boot sectors, and then prompts the user to switch to the destination floppy, optionally format the destination floppy and then copy the boot sectors. It also initializes the CP/M directory to empty, which is unneeded in this case, but doesn't cause any problems. I'd like to mail a copy of a "doubler" floppy disk to someone here who has some way of doing an image backup of this floppy or whatever tools the community uses here for this type of stuff. From what I recall, one of the local retailers back in the 1980's was giving away the Indus "doubler" for free to customers that purchased an Indus drive. I wasn't aware at the time of how rare it was.

I'm able to make copies of the Indus doubler now, using the CP/M "zsid" debugger, and the "init" program. The "init" program reads the boot sectors, then prompts the user to insert a destination floppy, then optionally formats the destination floppy and writes the boot sectors. I use "zsid init.com" to load "init" into memory, then switch to the Indus doubler floppy, then start "init" running from the debugger, which then reads in the "doubler" boot sectors (instead of the cp/m boot sectors). I post another thread specific to the Indus doubler.

CP/M is booting on my Indus, and I have ZSID debugger on the CP/M floppy, and backup of the source code on a PC. I may be able to figure out how to create a small program to read 3 sectors, pause to switch floppies, and then write 3 sectors. The other option is to get the ATR8000 from storage, which means the ATR8000, a 8 inch floppy drive, and a 5.25 inch floppy drive that I've slowed down to be Atari compatible. The rpm program shows speed as 288 rpm, I previously thought it was 300 rpm.

The floppy is an Indus bootable floppy that makes it "double" compatible. I probably used an ATR8000 to create it. I've got the ramcharger for the Indus, and CP/M, so I'll see if there's a way to use that to copy the disk later on.

Looks like I only need to copy sectors 1 to 3, but as double density. I can't find SCOPY.COM on my versions of spartados. If I download a utility on my PC, how do I get it transferred to the 130XE? I found a sector copy utility by Dave Small, but it appears to be a single density copy.

I want to be able to format (if not part of the copy operation) and copy a floppy image. I actually only need the first 16 sectors. I've tried sparta dos, dos 2.5, and mydos 3.0, but I don't seem to be getting anywhere, as the disk copy programs seem to assume these are DOS floppies. I need to be able to copy the first 16 sectors from one floppy drive to the other.

I found a copy of the instructions. INDUS CPM 2.2 This document explains the specifics of your Indus GT based CPM 2.2 system. The CPM system runs in the Indus GT disk drive, which contains a Z80 microprocessor, and 64K of ram (thanks to the ram charger). The Indus drive in turn, communicates with your Atari computer. Most of the time, the Atari computer acts as a terminal, but is also used to send data to the printer, and also to operate a second disk drive. The basic nature of this environment is that the Indus is the boss, and the Atari is the slave processor in a network based system. Requirements: Indus GT disk drive with 64K ramcharger board, configured as drive 1; an Atari home computer with at least 48K. Optionally a second double density capable drive, and an Atari compatable printer (or 850 interface connected to a printer). Boot up: Insert the terminal disk into the Indus drive and boot the Atari (with Basic disabled if an XL or XE type computer). You will see a menu "A: TRM40", and "B: TRM80". TRM40 is a 40 column terminal program suitable for TV's, TRM80 is an 80 column usually requiring some type of monitor. Press the "A" key for TRM40 or "B" for TRM80. After the terminal program has been booted, insert the CPM disk into the Indus and while holding down the "drive type" button, press the "error" button; this will boot up CPM, which will ask you to hit the return key to continue. At this point your are booted up and running CPM. Terminal emulation TRM40 emulates an ADM-31, and TRM80 emulates an ADM3A. TRM40 control keys: ^bk sp - screen toggle ^3 - cursor display lock/unlock ^; - left shift screen ^. - right shift screen Second disk option A second drive may be used with CPM, this will be slow as data must pass thru the Atari computer. To use drive "2" as double density, specify CPM disk "B:". To use drive "2" as single density, specify CPM disk "C:". When transferring CPM files from a double density disk to another double density disk, it is faster if the destination disk is put in drive "1" (CPM "A:") and the source disk in drive "2" (CPM "B:"). Note drive "1" must always be used as a double density disk. Only drive "2" can be access as a single density drive (as CPM disk "C:"). Printer option Any standard Atari printer (or printer hooked up via an Atari 850 interface) can be accessed using the standard CPM conventions. CPM.SUB This was the CPM procedure used to install all of the Digital Research patches for CPM 2.2, and to create EXSUB.COM. EXSUB is used to get out of XSUB state (refer to the CPM manual). INIT.COM INIT is used to initialize a floppy disk for Indus CPM. Init can format a disk, generate a bootable disk, and optionally erase a directory. Run the "INIT" program and remove your main disk, insert a fresh disk, and reply to the prompts as asked. You can optionally format a disk, and optionally erase the directory. INIT always will copy the boot information, creating a bootable disk. ICDS.COM ICDS is used to copy files to/from an Atari DOS compatable diskette. The Atari DOS diskette must be a double density (256 byte sectors) disk, such as XLDOS or MYDOS. ICDS is similar to Atari DOS, with the addition that CPM disks are supported. Run ICDS from drive "1" (CPM disk "A:") and place the Atari DOS disk in drive "2". To specify a CPM file, prefix the file name with "A:", to specify a DOS file prefix the name with "2:". The following commands can be used: A - display a directory (specify "A:", or "2:") C - copy a file (or files, wild cards supported) D - delete a file H - display help menu When transferring a file from Atari format to CPM format, or vice versa, you will be asked for text file translation, answer yes if the file is a text file. The conversion mainly involes converting the Atari end-of-line character into a CPM carriage return-line feed sequence (or vice versa). As an example, the following would be entered after a "C" command to copy an Atari file named "TEST.TXT" to a CPM file of the same name: 2:TEST.TXT,A: In this example, text translation would be desired (enter "Y"). Note: MYDOS style subdirectories are supported with ICDS. The following tables describe the structures of the double density and single density disks used by Indus CPM. These tables are the disk parameter blocks used by CPM to organize the data on a disk. This information should be used to configure "alien" disk programs available on other non-Indus based CPM systems to transfer data to an Indus compatible CPM disk. Double density: 40 tracks, 18 256-byte sectors per track DW 36 ;# CPM RECS/TRK DB 3,7,0 ;1K AU PARAMS DW 170 ;171*1K=171K DISK SIZE DW 63 ;64 DIR ENTRIES DB 0C0H,000H ;DIR PARAMS DW 16 ;CSV SIZE DW 2 ;TRACK OFFSET ; interleave = 1 Single density: 40 tracks, 18 128-bytes sectors per track DW 18 ;# CPM RECS/TRK DB 3,7,0 ;1K AU PARAMS DW 84 ;85K DISK SIZE DW 31 ;63 DIR ENTRIES DB 080H,000H ;DIR PARMS DW 8 ;CSV SIZE DW 2 ;TRACK OFFSET ; ;interleave = 5 DB 01,06,11,16 DB 03,08,13,18 DB 05,10,15 DB 02,07,12,17 DB 04,09,14

I worked on a CP/M implementation for the Indus drive with the ramcharger that expands the memory to 64K. I don't know what changes Indus made to the released version as I wasn't even aware that they had released it or even the ramcharger. After the terminal program is loaded, insert the CP/M disk and press "drive" and "error" buttons at the same time to boot from floppy disk. In 40 character mode, the terminal will auto-scroll left and right (I don't recall if there was a way to force the screen to shift left or right other than it followed the cursor). The 80 character mode is a 3x5 font, barely readable, but it works. Although it's slow, the monitor program will allow CP/M to operate with a second floppy, which doesn't have to be an Indus drive. The data path is Indus <-> Atari (monitor program) <-> other floppy drive. There was also a bootable "doubler" program for a standard Indus drive (no ramcharger needed), that switches to Indus to be compatible with the 1050's "doubler" mode (19 microseconds per bit which is about 52.6 kilo-baud) . I don't know if Indus released this or not. Again, you press "drive" + "error" buttons at the same time to boot this floppy. After that the Indus will be "double" compatible. I have a copy of this "double" floppy that is still working, but I don't know how to duplicate it. I need someway to format and image copy a 5.25" floppy (only need the first 16 sectors or so to be copied). I have a working Atari 400 and also a 130XE, and the 130XE can boot into Spartdos 2.3, so I may be able to image copy the floppy. If I recall correctly, the Atari floppy disk drives spin at 300 rpm instead of 360 rpm. This is an issue if using an ATR 8000 as an Atari 8 bit disk drive interface. You'll need to adjust the speed on a 5.25" floppy drive down to 300 rpm in order to make the drives "compatible" with Atari drives. I recall a program that I think ran on the Atari (might have been the ATR) that displayed the rpm as you adjusted the speed. All of my ATR stuff is in storage and I don't know if it works.

The development kit I bought included a 520ST upgraded to 1MB, with the intent of using the extra memory as a ramdisk, which sped up builds on a floppy only system. I have multiple copies of "development" floppies, but I only formatted one of them to be PC compatible, and that is the only one I can read (on a PC), as I don't have a working double sided floppy drive for the Atari yet (I'm ordering one, but it will take a while).

I've seen a few posts with links to thegamearchives.net, but the web site doesn't appear to be working now.

Ran out of time trying to edit my original post. I had a few boot floppies I made from the Atari ST developer tool set (I was doing consulting work for an Atari ST developer), and fortunately for me, one of them was formatted to be PC compatible, so I now have the tool set backed up on a PC, and I made a new Atari floppy. I don't have a working double sided drive for the Atari ST, but I may purchase one later. Later Atari switched to a different compiler for it's developer tool set, but I recall that the code generated by the Alcyon compiler was smaller and faster than the other compiler (don't recall what the other compiler was). Has anyone else here used the Alcyon compiler? If so what was your opinion of it versus the other compilers for Atari ST?

I may have a working copy of this on one of my floppies, but currently I don't have any working double sided floppy drives. update - Fortunately I had formatted one of my developer boot floppies to be PC compatible, and was able to back it up on a PC.

The issue with 10 sectors per track, at least on older PCs, was a combination of BIOS and the Intel 8272 floppy disk controller during writing, not formatting, due to gap 3 size, the gap between sectors. The Intel 8272 manual states a recommended value of 27 bytes for gap 3 for 512 byte sector writes (where it would actually write 27 bytes of gap 3 pattern during a write). The gap 3 size is one of the write command parameters, and I don't know the actual gap 3 numbers that were used in the BIOS of most mid 1980 PCs, only that it was an issue for 10 sectors per track on some PCs. The Atari ST's WD1772 fdc only writes 1 or 2 bytes of gap 3 during writes, so shorter gaps wasn't an issue. Sundog would not work if you just formatted a floppy and copied the file, but as you mentioned, a "track copy" program was good enough. I seem to recall that Sundog wouldn't run if the floppy was write protected, and that it always wrote a save game file, which would be a reason for wanting a backup or a modified version (no copy protection) of Sundog (in case something went wrong). I don't know if other games were like this. Considering that most of the 8 bit Atari cartridge games had been modified to be able to run from a floppy disk, I assume that most Atari ST games were similarly modified to remove copy protection, so I don't know how popular "track copy" programs were. It only needs to run long enough for me to go through a set of double sided floppies that I found in a different location than where I had stored most of my old stuff and had backed up 20+ years ago (this set may have been more recent, I'm not sure). These may be all duplicates from a prior backup, but I can't know for sure until I have some way to read them (assuming they're still readable). As for old stuff, I have a working Kenwood KR-8010 stereo receiver and a pair of Saras model 30 speakers from 1978 which all still work, and I use them as my computer stereo (although most of the time I just use headphones). Still I don't expect 30 year old computer stuff to last much longer, and I don't have the maintenance budget of a historical site like the ones that maintain old hardware dating back to the 1950s like this IBM 83 card sorter:

This won't be much help, but the number of "bombs" you see on the screen corresponds to the 68000 exception number. A partial list: 2 - bus error 3 - address error 4 - illegal instruction 5 - divide by zero All these would normally indicate that somehow that data or program have been corrupted. This could occur when data is read into memory (something wrong with a peripheral), or could occur if the memory is faulty. This is why some type of diagnostic will be needed in order to isolate the cause.

The Atari ST can read PC formatted floppies (and even PC formatted hard drives if using FAT12 if I recall correctly). I wrote format programs for both PC and Atari ST. Both implemented track skewing (offsetting sector location from track to track) to speed up read / write times (so that after completing a single track step sector 1 would be the next sector rotating into position). For the Atari ST, the program could format a PC compatible single or double sided floppy. For Atari ST usage only, the program could format 9 or 10 sectors per track. 10 sectors per track couldn't be made PC compatible (at least not writable) because the PC floppy controller writes too many bytes after a sector write to allow the shorter gaps needed for 10 sectors per track. I still have an old PC with a floppy drive that I can use to transfer files. The issue with my SF814 isn't the internal floppy drive, since it never does any retries when reading a floppy, but ends up sending garbled data to the Atari ST, so the issue is most likely somewhere in the controller or interface. Most of my backups were source files, documents, text files, ..., not games. I'm a programmer and at the time, my job included writing assembly code for multi-threaded operating systems using the 68000 family of processors that were replacing former custom mini-computers. The company was a Motorola development site, so we got early samples (development kits) of the newer processors like 68030 and 68040. When the Atari ST was released, a lot of the programmers at that company bought them. I moved on to another company before they got to the 68060, which was the end of that line (also the end of that company), and followed by the Power PC. Around 2006, Apple and some others using PowerPC switched to Intel X86 processors, while embedded devices starting using embedded processors like ARM or MicroBlaze. As for the games, there are a few games that I was curious about, but never really got into. Sundog was one of them, and I may look into setting up an emulator soon. I was also interested in a strange programming language called APL, since I had used it during the mid 1970's on an IBM 370 at a local college, and there was a pretty good version at the time for the Atari ST. These days, there's an advanced version from Dyalog for Windows.

It was ST Copy 3.0 (from Dec 1986). It worked on a few dozen or so games released at that time, and yes those early schemes were somewhat primitive and could either be copied or made good enough to pass the copy protection checks. I only tested 2 games, Star Gliders and Sundog, and those worked (ST Copy was able to make runnable copies), despite the originals being nearly 30 years old. Helping here is the fact that these are 720K floppies, with a much longer lifespan than 1.44 HD floppies. However, my goal here is not to restore old games. The reason I want a working double sided floppy drive is to do one more check of some double sided floppies I found in storage to make sure I didn't miss anything when I did backups 20+ years ago. I have a set of zip files I use as an archive of my old stuff, dating back to the 1980's (CP/M, Atari 400, Atari ST, PC, ...) . I'm aware of emulators for the Atari ST, but haven't looked into those yet.

Is this a reference to replacing internal floppy drives or external floppy drives or using some type of external emulation of floppy that uses the same interface as an SF314? An internal floppy drive won't help in my current situation, as the Mega ST4 won't power up. I'm stuck with an original 520ST upgraded to 1MB of ram.

Typo, it's the SF314 I'm looking for. I'm getting scrambled data from it without any attempt to re-read data, so it's not CRC errors, which leads me to believe the internal floppy drive isn't the issue, but instead the circuit board or some other part in the electronics that is scrambling data. For the alternatives to floppy disks, what about all those games that use floppy based protection? Since it's been over 20 years since I messed with this, I don't know if the games have been patched to no longer need floppy based protection. I used ST-Copy 3.0 to make new copies of a couple of game floppies and a couple of regular floppies, and so far, I've been lucky that at least 4 of the old floppies were still readable, and I now have freshly formatted and written floppies. Maybe in the near future I'll take the Mega ST4 apart and see how difficult it would be to replace the power supply.

My Atari computers and related components are nearly 30 years old. I've since found a source for a SF814 for about $125 (US). To set it up, I'd have to store two old desktop computers, an old monitor, buy a computer desk to setup the Atari properly (since I use an old printer stand for the old monitor), with a fairly good chance that yet another component will break down.

Based on what I recall, I think Tangerine Dream used an Atari ST for the songs they did for films like Risky Business. I also recall that Atari had setup multiple ST's at some computer show in the late 1980's, running Midi Maze in multi-player mode.