Nezgar

All Atari & 3rd party disk drives and upgrades that provide double density support are inter-compatible, except for Atari's 815. The biggest additional feature the popular upgrades provide is track buffering, which speeds up successive sector reads & writes from the same track. The Happy and Speedy upgrades provide this. The "Super" speedy has enough RAM to buffer an entire DD disk, but is *ONLY* utilized by it's disk copy program, not for everyday operation. Happy has more software / awareness / popular in North America, and Speedy in Europe. In fact, prior to the creation of Mega Speedy, Speedy firmware was incompatible with NTSC machines, so until the last few years you wouldn't be able to get one to work even if you wanted it to on an NTSC machine. Patches to the Speedy firmware that were made as part of the MegaSpeedy "kitchen sink" upgrade have allowed the individual Speedy spin-off replica products to be viable for North America users now too. Both Speedy & Happy have track buffering and will be "fast" for everyday use with DOSes or modified OS's that support the Ultraspeed protocol. Both can copy protected disks, but I think the Speedy software is mostly in German. Happy upgrades and software are going to be better "supported" by others in North America since many people have used them since the 80's, if not authentic products, there are many clones made over the years. The AtariMax produced product isn't cheap, but AtariMax may still offer free shipping which makes up for it a bit. If one was going purely on recognizable features to resell the drive, the Happy would be an easy win. The Speedy is pretty "New" to North America, so will be less recognizable by buyers of an upgraded drive. For those in the USA, it looks like you can also order many of tf_hh's products from Vintage computer Centre: https://www.vintagecomputercenter.com/?product_cat=tfhh&post_type=product&s= I am a big fan of the US Doubler upgrade. IMHO every 1050 should at leasthave this upgrade as it provides double density and optionally UltraSpeed (with specially formatted disks) with minimal additional hardware, but it doesn't do track buffering or have copy-protection duplication abilities.. A DIY installation simply involves programming a 2732 EPROM and soldering two 6810 SRAM's together. (one additional on top of the one already in a stock drive). I've also made my own patches to the US Doubler ROM to improve it's default sector interleave when formatting ED and DD disks, and speed up the head stepping timing similar to that of a Speedy drive. (For Tandon mech/made in Singapore drives only so far). For WST/made in hong kong drives there is also a ROM that maintains the faster stepping speed from Atari's stock ROM, and adjusted stepper phase encodings to keep the head aligned. (Using firmware from a Tandon 1050 in a WST 1050 or vice-versa will result in a 1/4 track misalignment). Indeed - I always like modifications to be "reversible" so I was happy to release the designs and produce the PCB as mentioned by @E474 for a US Doubler installation using two 6810's together on a socketed PCB with no soldering of the 6810's together required. The thread about them is here: At this moment I have many of those PCB's on hand but none assembled so if you are interested in this route let me know. Work's been so busy a good PCB soldering session might be some good therapy for my brain hehe.

When you turn on the computer with the drive powered on and configured as drive 1, does the computer jump to "READY" or does it produce "BOOT ERROR" ? (This will tell us if the drive is responding to commands, even if they are NAK's). If you receive BOOT ERROR, do they print faster when the drive latch is open vs closed? If you receive BOOT ERROR's, does it change with a disk in the drive? (ie long pauses between each line printed) - is it any different with a disk in the drive, or without a disk in the drive? If you can get booted into DOS from a working drive or from an SIO2PC type solution, then switch over/attach this drive as d1: can you issue a format command to the drive? The normal/expected motions are sequentially advancing from track 0 to 39 (formatting), then retracting track by track from 39 to 0 (verifying). See if it maybe steps from 0-39, but then errors out when the verify phase starts at track 39.

This is a good suggestion, and I just checked it as well.. but the "expansion list" on page 33 (of the Jan 2022 edition) there is a reference of a 1088K upgrade (64K + 1024KB) but no reference example for 1024KB... which 4 banks should mirror the base 64K, or IMHO be blocked from use? I think there was maybe one Petersen type 1024K upgrade for the 800XL, vs 1088K in an XE, since "usually" the base 64K in the first row is untouched... If anything, it should match the behaviour of that upgrade... IIRC Petersen type upgrades would block access banks that would otherwise mirror main RAM.. I'd have to read up on them again. I'm not optimistic about the number of ramdisk programs that would correctly identify that 4 banks are mirroring base RAM.... In regards to 192K mode - it could be simplified to be a 320K "COMPY SHOP" type mode that uses bits 2,3,6,7, preserving ANTIC banking on bit 5. Programs that don't support bit 7 for banking will only detect 128KB of extended RAM (192KB total) Ie SpartaDOS 3.2 RD.COM), but those that do will detect all 256K of extended RAM (320KB total)

I presume it's a 3 position switch? (for 3 different OS ROM's depicted) Does the system fail to boot in any of the three switch positions? It's possible that the 2 EPROMs have failed over the years, but the original Atari OS mask ROM would be less likely to have failed... You may be able to pop out that PCB, and try each of the three chips individually plugged into the OS ROM socket to see if they are good, or if the issue is just with the switching mod. If you have an EPROM programmer, that would be another way to dump the contents of the ROM's - especially the "CUPID Rev 2" - that's interesting, not heard of that name before myself.

Sure - I don't like uploading redundant files, so I found a previous post here: (There's some other discussion in that thread you may find interesting too) https://atariage.com/forums/topic/275134-another-unknown-eprom/?do=findComment&comment=4208141 The open code from the file in that post is 1814, but you can hexedit the first two bytes of the dump to whatever you want. Maybe 9999 (B&C standard) or ABCD (seems to be the 1050 Super Archiver standard - though that would be CDAB in the ROM). Also this post - a dump I made with open code 1595: https://atariage.com/forums/topic/275134-another-unknown-eprom/?do=findComment&comment=4432031

Since you are using SpartaDOS X, check out the HDSC command ("hard disk sector copier") from the SpartaDOS X Toolkit: From the "Remarks" about the commend in the documentation:

I suspect it the annoyance would be more on whomever was tasked with programming the 1050 Super Archiver EPROMs and making a unique code and keeping that matched up with whatever documentation. CSS Instead put more effort into obfuscating the hardware, as well as 'uncopyable' protection on the disks... I wonder if Super Archiver software simply blindly sends an open code of ABCD. (Edit: or because of the contents of sector 720 when the drive is powered up. (I'll have to check the below Super Archiver v3.x2UK ATX) I see "Archiver and Editor, The v1.0 (1983)(Spartan Software)(US).atx" in the Software Preservation collection from at least 2019, has header line "*** THE ARCHIVER V1.0 ***" even older than the V1.2 I've tried so far earlier in the thread. It also appears to have the "magic bytes" in sector 720 since the drive was automatically opened with this ATX mounted in Altirra. There does appear to be simple copy protection on the disk in the form of blank tracks 5 through 38. Track 39 is fully intact - likely just to to host sector 720. The blank tracks could have just been to speed up duplication, maybe not necessarily checked by the software... Next up "Super Archiver v3.x2UK (19xx)(Computerhouse)(GB).atx" - also in the Software Preservation Archive... Attempting to read this disk in with the 810 Archiver v1.0 can read track 0, but fails completely trying to read track 1 with "[[ READ FORMAT ERROR ]]". I'm curious to know what exactly the "uncopyable" protection is, presumably it's been figured out if it's been converted to a working ATX. Has the Spartan Archiver emulator for the Happy 810 disk made it into any archives?

Did you patch & program your own ROM for that sequential open code? Edit: Oh - So you must mean a 1050 Super Archiver then? Did 1050 Super Archivers also have unique factory open codes like the 810? I know less about those...

Here is the post with some very nice documentation for the Archiver software: (Specifically the SCANIT.doc and SCANIT.pdf) - Appears to be the version distributed by B&C Computervisions. https://atariage.com/forums/topic/249750-bitwriter-replica-1050-order-phase-has-started/page/3/?tab=comments#comment-3502155 Page 29 mentions the unlock code is "9999" so I guess all the ROMs from B&C would have that code. One interesting section we touched on earlier @Sugarland was that of making a disk that will automatically "open" the drive. See this excerpt from page 29: Most of my disks seem to have a blank sector 720, or the disks are truncated to 65K... But I found one "The Super Archiver II 3.03.atr" (which is also in that above linked post) DOES contain a sector 720 with what appears to fit the description! 16790: A9 02 8D 92 01 EA EA EA A9 80 8D 95 01 EA EA EA 167A0: A9 01 8D 9D 01 EA EA EA A9 01 8D 91 01 EA EA EA 167B0: A9 00 8D 9C 01 EA EA EA 60 Dissassembles to: 0000 A9 02 LDA #$02 0002 8D 92 01 STA $0192 0005 EA NOP 0006 EA NOP 0007 EA NOP 0008 A9 80 LDA #$80 000A 8D 95 01 STA $0195 000D EA NOP 000E EA NOP 000F EA NOP 0010 A9 01 LDA #$01 0012 8D 9D 01 STA $019D 0015 EA NOP 0016 EA NOP 0017 EA NOP 0018 A9 01 LDA #$01 001A 8D 91 01 STA $0191 001D EA NOP 001E EA NOP 001F EA NOP 0020 A9 00 LDA #$00 0022 8D 9C 01 STA $019C 0025 EA NOP 0026 EA NOP 0027 EA NOP 0028 60 RTS So that LDA #$80 then STA $0195 should in theory 'OPEN' the drive automatically. Looking at all the NOP's spaced out, implies room was intentionally left for adding more code. Some pretty nifty flexibility there for such an early product... Indeed, the last two bytes of sector 720 are 4A 25 in "The Super Archiver II 3.03.atr" - So this may have been a way to "open" the drive before we knew what the code was...

Of course I realize after I hit post that it only wasn't working with Altirra full drive emulation because the file was already open in my hex editor... ?‍♂️ So with some quick testing booting with Archiver 1.2 and 3.02 software I could "open" the drive by pressing "O" then typing 1014,1 (other codes fail as expected) and read in a source disk by pressing C then Start. So indeed this dump works, and maybe the likes of @phaeron can dig into the firmware further, to see if differences found maybe suggest this 810 Chip / Archiver ROM is older than the regular "VERSION 1.0", or just hacked/patched... Edit: Referenced "The Archiver V1.2" disk is here: (although interestingly truncated to 65K, so the software will report some higher tracks as having missing sectors) https://archive.org/details/a8b_Archiver_The_v1.2_198x_Spartan_Software

Well.... Turns out I actually have 4 previous dumps, and all of them ONLY differ in the first two bytes (the open code). There IS actually a twist... All of the previous dumps I've seen have this text string at the beginning of the ROM from byte 2-44 hex: * THE CHIP - VERSION 1.0 * (C) 1983 SPARTAN SOFTWARE OF MINN. INC. But in yours, the first thing that stands out is these bytes have been zeroed out, except oddly the asterisk and carriage return bytes... But there is a smattering of other changes in the binary data too, making me wonder if the dump was good, so I tested it in Altirra under full drive emulation for the 810 Archiver and it fails similar to if it has no ROM at all, so I think that confirms the dump is bad... Could you please try dumping it a few more times? I've personally had issues with my TL866 reading old 2716's and 2732's reliably - I think it reads them "too fast" or the EPROMs really are so old that their programmed data is on the verge of bit-rot... You may have to find a way to dump it by putting the EPROM into a cartridge that supports it, and dump it using a DOS "write memory" command. I was able to get a good read of my PERCOM AT88-S1 2716 this way - but I can't remember which cartridge I used at the moment... If not completely corrupt, one difference interesting to me seems to be the sector interleave table at 08CB, used during format: Sugarland Image: 12 01 03 05 07 09 0B 0D 0F 11 02 04 06 08 0A 0C 0E 10 (hex) 18 01 03 05 07 08 11 13 15 17 02 04 06 08 10 12 14 16 (decimal) This matches the "Atari Standard" 810 Revision C, and 1050 single density interleave. (9:1 interleave, 9.0 revs to read a track) vs "known good" image: 11 0F 0D 0B 09 07 05 03 01 12 10 0E 0C 0A 08 06 04 02 (hex) 17 15 13 11 08 07 05 03 01 18 16 14 12 10 08 06 04 02 (decimal) This is the optimized single density "Chicaco" interleave laid down by the Archiver (Chip) 810, Happy 810, 810 Turbo, 1050 Duplicator, US Doubler, etc. (9:1 interleave, but 8.1 revs to read due to optimizing taking the gap into consideration) So..... at first glance, the blanked out naming at the beginning of the ROM would lead you to believe it might be a "hacked" ROM where the copyright text was removed, but I would consider the format interleave to be a "downgrade" as it's slower... The Tandon mechanism was a "later" 810, which didn't show up until November 1982 according to Atari, but that's still supposedly before the Chip/Archiver was released in 1983. So - it's also possible that this was an early or leaked revision compared to the more common firmware. If we can get a good working dump, then maybe we can dig further into the specific code differences and engage the AA disassembly experts, etc...

Hehe, congrats @Sugarland (and good guess @DjayBee )- yes the interpretation of the bytes would be reversed since 6507 processor is "little endian", so 1014 would be correct. Edit: also thanks for posting the dump - nice to have one more unique specimen from the wild. ?

This will work in a pinch, but this particular hack won't support any faster than 1x SIO (no faster ultraspeed modes) and I think had other issues like not being able to be on a shared SIO chain with other peripherals due to missing signal wires required for that and other reasons I can't remember. Lotharek's SIO2PC-USB thingy I previously recommended supports all of that. You don't want to backup a 16MB hard disk partition to the PC at 19200bps

There's so many fancy devices out there, but I always find myself falling back on a simple lotharek sio2PC-USB adapter along with RespeQt software. Simply copy the file to the virtual SIO drive. From RespeQt you can then drag the file out of the disk image to the pc desktop with carriage return/linefeed translation too. Even fancier if you use the PCLINK driver in spartadosX, and copy files to PCL2: for example, and the file is deposited directly to your PC filesystem in whatever folder you've designated that drive to. This method also preserves date/timestamps, but maybe not text file translation... https://www.lotharek.pl/productdetail.php?id=108

Woohoo! Progress is always good. It's possible that by temporarily detaching the metal band from the stepper you have misaligned the head ever so slightly. If so, it won't be able to read disks formatted in other drives, but if you can get DOS booted from another drive and swap in this one and format a disk / write DOS you may find it can read it's own disks... if so, you will have to tweak the alignment by adjusting the position of the band until maybe it can read a disk from another drive reliably again... there are more complicated ways to do this with an oscilloscope to see which position results in the strongest signal, but the poor mans way would be to loosen the stepper itself from the mech, and marking where when rotating the left/right "edges" where reading fails, and tighten it down between those... edit: you say a format fails - is it failing because the stepper can't reliably move the head do you think? If so, indeed hopefully things loosen up over time with oil etc. To excercise it, try manually advancing the head most of the way, and when you turn on the drive it should advance a few tracks, then step backwards until it reaches track 0.

Hmm. No hints from any of the other photos in the listing. It must be to connect to some 3rd party peripheral that's not included.

I've experienced this with a couple drives.... I took some fat pliers to the knob on the top of the stepper motor and cranked it with some "gentle force" and it "cracked" free... Maybe give it a try. Once it's free it you can work it back and forth and might still be a bit noisy in use/stepping, so you can slowly work in some 3-in-1/sewing machine type lubricant from the bottom side.

I agree it's confusing.. I believe this is indeed the correct differentiation... I did have some difficultly locating a particular software disk to reference in my first post. There are indeed a number of them, and the collection is muddied by the numerous titles targeted to the version that runs from code uploaded code to a Happy 1050's RAM. I do have 1 810 with an archiver, but I don't recall which specific software disk I used with it - or if I even went as far as trying to read/write a copy protected disk... The Happy 1050 version of the archiver is "opened" by default once the drive is "converted" by a boot disk, and does not require entering an open code. The 810 version has to be opened manually (or by special disk with special sector). This may only work if the "open" code bytes in sector $2D0 match that of the particular ROM in your Archiver, and only with the original Archiver 810 disk(s) - the later versions that also support the 1050 probably don't have the right data in sector $2D0... I don't recall. It was a "convenience"... I'd have to read up / test this with some other media. Looking at some of my photos, it appears I was using the disk software that identifies as "*** THE 1050 CHIP V1.1 ***" with an 810... Ideally you dump the 2732 EPROM to see what the first two bytes are. Two recently dumped ROM's I've come across had open codes of 1595 and 1814. Otherwise there's 65,536 combinations to try... ? It's possible you DID get the drive to OPEN successfully. If so, it will cause grief with any programs that attempt to use US Doubler type Ultraspeed, as the Get High Speed Index ($3F) command is used by an opened archiver for some other purpose and causes a timeout. Argh... yeah, Sorry to hear... I've had my own experiences with this... it's heartbreaking! I spent an entire evening using plastic cement trying to puzzle one all back together before I said f*** it. At least the drive and all electronics checks out OK! It is targeted as my "project" drive slated for some sort of future upgrade... probably an archiver since it's the easiest heh. I believe I posted pics with a rant on facebook at the time.. Got a full refund, but still disheartening to see irreplaceable items destroyed.

It's "The Chip" for use with the "Archiver" software. The modification as pictured matches that in the installation guide here: https://archive.org/details/rearc_the-chip-for-atari-810-ch-9-installation-198x/mode/2up Users Manual: https://archive.org/details/ArchiverEditor/ The software is here: https://archive.org/details/a8b_Happy_1050_Chip_Archiver_Editor_The_v1.1_19xx_Fox You'll need to dump the EPROM to determine the two-byte "open" code to enable the archiver features - until then they are disabled for normal use to avoid detection by programs. Originally, each ROM had a unique code programmed, which was also a form of protection that could allow a pirated copy to be traced back to the original purchaser. Some pirated ROM's may have replaced the open code with something simple like "0000" or "1234" so you could try those first... The other wires most likely are for write protect defeat. Either always write/never write, or normal behaviour / allow write. Sometimes switches were installed to lower the RPM as well. Edit: yes, checking the schematics, J101 pin 1 & 2 are normally directly connected to the write protect photodiode, pin 3 n/c, pin 4,5 power the infrared LED opposite of the photodiode.

Try swapping in a POKEY from another computer if possible...

Synced drives like Google Drive, MS OneDrive, Box, DropBox work by constantly scanning for changes in the files on the local drive. This often creates conflicts with applications with locks on files as they may be "in use" by the sync application, and can't handle that condition... probably something to do with Altirra being unable to write to a file if it's locked by the sync agent.... Try temporarily pausing sync in google drive..

Right... PortB bit 5 on a 130XE would allow Antic to display extended banked RAM independent of CPU selection on bit 4... but of course I see what you mean this doesn't apply for RAM under ROM. But.. My thought was to use a DLI to switch the ROM off when drawing the screen, and back on at the end of the frame... maybe impossible since too many other OS dependancies/interrupts would interfere....

Ah yes you're right, thanks. ?‍♂️ Edited previous post. Rusty holiday brain.

Edit: Yes mechanisms can be swapped, with respective ROM swap if swapping between Tandon/WST. Mix & matching 1050 motherboards & drive mechanisms is generally not recommended, as there is factory calibrations done on each motherboard for the WDC controller specific to the mechanism that was originally paired with it. If you need to, the calibrations necessary require an oscilloscope to complete. See this thread for the process: Otherwise, the electronics are similar, but the ROM for the WST drives has different stepper encoding specific to the WST mech for proper alignment (ie a tandon drive with a WST ROM would result in a 1/4 track mis-alignment, and probably too-fast a stepper speed to work with it's stepper motor). I think there may also be a variance in pinout of the headers that the drive mech attaches to at the back of the drive... (ie write protect) Some drives also have the newer 2797 WDC controller, which is incompatible with the WST ROM, and requires Revision L for Tandon drives only. I'm also not sure if the actual motherboard layout is slightly different to prevent it from fitting into a Tandon/Made in Singapore case...

For the Happy specifically, it's ROM includes a reinitialize drive command (Command $48, AUX1 = $03). The custom code uploaded to a happy drive from the happy backup utility also monitors the SIO ready signal from the computer, and if this signal ceases to be high, ie from the computer being switched off or SIO cable being unplugged, this also triggers a reinitialize of a happy drive reverting it back to "normal" happy mode -- disabling the uploaded code.