Nezgar

If its a "lazer" it would function as a rev 1 happy 1050 (no corrupted single density ultraspeed writes, unbuffered) and not exhibit those symptoms like the more common rev 2. Its been a while to remember but if you start the genuine happy 7.x diagnostics software, see if the ROM test results in "Pass" or "PASS" - as that differentiates V1 or V2. (Or "FAIL" if the rom has been modified and checksum matches neither). Lazer had a modified utility disk to pass on its own modified rom...

I guess that may toggle the happy ROM's unbuffered mode, which is not the same as "unhappy" mode, and not the same as switching the whole ROM to the Stock 1050 ROM, which the above switch does.

There is a single wire coming off that Happy PCB that supplies +5V/Vcc. The other two wires go to the +5V/Vcc pins of the ROM on the Happy PCB, and a ROM still sitting in U10 on the main board underneath. This is attached to a 3-pin 2-position switch (SPDT on-on) on the faceplate to switch between "Happy" mode and "Stock 1050" mode. Of course this should only be done with the drive off. Nice simple hack mod actually. So centre pin of the switch goes to the +5V/Vcc from happy PCB, then the outer 2 pins of the switch go to Vcc of each ROM.

Rescue on Fractalus (turn up the bass 😁) .. And the engine takeoff uses a pokey 16-bit pitch register for the very smooth high-pitched increasing whine.

At the other end of that arm circled in the pic is where the spring is attached. That end has a bend down that drags against another metal surface. There may be enough drag there that a little push will "encourage" the mechanism to eject. If that works, a little 3-in-1 / sewing machine oil applied with a q-tip along the surface where it touches may help reduce that friction. I've also found sometimes that bending that rear bend a little inwards or outwards can help... will take some fiddling.

Based on this I'd say your CPU/6507 socket is good, and your ROM socket has an issue. The happy board has the ROM onboard along with the CPU. While replacing your ROM socket would be the prudent action, you could try inserting a 24 pin machine-pin socket into the existing socket, and then the ROM into that. This may improve contact if the stock single wipe contacts have been depressed too far, etc. The happy boards also use machine pins, which may help improve contact in your CPU socket. Though inserting machine pins into single/dual wipe sockets may permanently depress the contacts in the sockets where they won't contact regular flat chip legs with enough pressure anymore.

The 810 has no disk change detection method. It does not spin briefly when inserting a disk or closing the latch like the 1050 does. Some upgrades like the Happy use the write protect sensor to detect a disk change, but this is not a feature of the stock Atari ROM. The 810 also doesn't have a track 0 sensor. The powerup sequence moves the head from an assumed track 39 to track 0, then back to 39 before spinning down. If the head wasn't already at track 39 when it was turned on, it will end up "rattling" as it hits the barrier at track 0, which effectively re-aligns the head to track 0, and the firmware can assume it has definitely been positioned on track 0 after 39 backwards step attempts after that point. If the drive was successfully reading some sectors, and then gets some read errors, the failure/retry function of the 810 will seek the head to track 0, and continue to try to step it backwards causing it to again bump into the barrier there, to try to re-align the head at track 0, and then seek back to the track it was trying to read the problem sector from again. This could be due to an actual bad sector on the disk, a dirty read head, or intentional bad sectors /read errors due to copy protection. I would next focus on trying to clean the head.

Ah k, so it sounds like your stepper motor isn't working. If you manually move the head to track 0 (outermost position) see if it powers up without the constant start/stop. This will confirm if your track 0 sensor is still working. If so, you may even be able to boot/read sectors from track 0 of a disk, until it tries to read another track. Can you take a picture of where the wires from from the drive mechanism connect to the 1050 mainboard at the back left side of the drive? They may either be disconnected, or connected incorrectly. A picture would potentially allow us to identify an incorrect connection.

That's the POST failure mode. Something is not right that the firmware detected. First thought is track 0 sensor. I think I've caused this behaviour by disconnecting that. If you move the head all the way towards the centre of the disk and power up, does it step the head all the way back to the outermost track before doing the motor on/off cycling? If the track 0 sensor doesn't see the head "arrive" at track 0 this mode gets triggered. CPU and ROM may be good since that repeating pattern is following ROM code. Next up it could be bad SRAM in the RIOT or 6810, which can be swapped out of another 1050 to test...

Hey All, I still have Kay's 810T PCB which he graciously lent me, and we've been in touch about it recently as well -- I apologize to all on the lack of timeliness on my intended plans of getting this thing installed to witness a real-world working double-density 810. The effects of Covid-19 and my job moving to primarily work-from-home the last few years has taken a toll on the organization of my home office and space allocated to Atari projects... but this post gives me renewed impetuous to get that corner of the world back into order! I absolutely would also like to see this board reverse-engineered and replicas made. I had emailed tf_hh in the past and he expressed interest in receiving it after I am done with it for exactly this intention. Previously I was able to identify 1 of the two LS logic chips that weren't soldered directly to the PCB using the LS test options in my miniPro programmer, but the others will likely require probing once it's in operation, and/or careful desoldering from the PCB (& socketing of course) to test separately. (The loose chip with the white wire attached is a 74LS04) So, I hope to have more to say in the near future with more updates, and hopefully this thing actually works!

Can you confirm you used the "P. Format Single" option in DOS 2.5? otherwise the regular format option "I." will format the disk in Dual/Enhanced density, which is unreadable by an 810. OK, we can see in your video that it indeed goes through the motions of formatting tracks from 0-39, but then gets stuck when it tries to verify on track 39, supporting the evidence that it can not read anything back. Can you try cleaning the head? Use a little isopropyl alcohol / rubbing alcohol on a q-tip or fine/microfibre cloth to clean the ceramic head underneath the pressure pad and wipe it clean with a microfibre cloth. Then repeat the tests again. OK this at least indicates the erase component of head is at least partially functioning, if the pre-existing content was trashed by the 810 format. One other thing to try when trying to read a disk, or even at the phase of the format when it reaches track 39, try applying a tiny bit of downward pressure on the pressure pad with your finger to see if it helps get a sector read, or if the format progresses any number of tracks backwards from track 39 with that pressure applied... If so, you might need to adjust the pressure spring to another one of the three "slots" , or some other adjustments to tighten the spring (ie inserting something in between the spring and the pressure pad arm like a small piece of eraser, etc)

Your observed POST sequence doesn't include any movement of the head? The drive normally moves the head to the "innermost" track 39 when spinning down. When powering up, the head should move to track 0 (outermost track) and then move back to track 39 before spinning down. If you don't see any head movement, see if you can manually move the head forward/back at all with a light push. if not, the stepper motor may have seized up and you might have to give it a turn with some pliers to break it free. Here is a video of what an 810 with a stock ROM looks like when formatting a disk: Spin up Move from track 39 to track 0 format track by track from 0 to 39 verify (read) track by track from 39 to 0 Lastly, DOS will then write boot sectors, VTOC, and directory sectors - if SpartaDOS, this is only on track 0. If DOS 2.X, this will be on track 0 and ~19. Move to track 39 and spin down on idle. This example video shows a format using SpartaDOS, so the boot/bitmap/directory is only written to sectors on track 0 after the drive returns control to DOS. If you have another working drive, it could be good to know if a disk that was attempted to be formatted in this 810 is readable in another drive, or if the disk is prepared beforehand in the other drive with readable data on it (ie create a test file) if the disk is actually erased, or if the original data is still readable in another drive after an attempted format in this 810. If you've messed with the RPM somewhat, a known good disk formatted in another known good drive (ensure it's single density if formatting in a 1050) you should be able to still read sectors if the RPM is +/- quite a bit maybe even 30+ RPM off? - it's usually the writes that are a concern when the speed is off, as too fast and you risk overwriting the next sector, and too slow you risk read reliability due to increased density. If you can take this "known good" disk and attempt using some RPM test utilities and adjust RPM until mayne you can start getting ANY successful sector reads.

The sector copier on the happy 7.1 utilities disk I recall will work in a pinch with non-happy 1050's, it will just drop to standard speed SIO for non happy drives, and was pretty reliable with detecting all three densities. It will use extended RAM in a 52K 800, 128K 130XE and some variants above that for single pass single drive copies too.

I recall running the MIOCACHE utility with my ICD MIO. You would leave 32KB of MIORAM unallocated (not used for printer spooler or RAM disk) and this would significantly speed up random IO & directory access to hard disks. Here are a few mentions: I never did have any documentation along with the utility, so I only learned the author from the 1st linked post. Would be great to find any supporting text. These diag tools seem to be a great compliment to go with it though since they sure seem they should have... Maybe by different authors.

I'd also test the picture on a real CRT that supports S-Video... Some LCD monitors don't support S-Video properly, and may only do weird things like process it as composite, etc.

Well, there was some compression with SCOPY in the form of zero-filled sectors would not be stored in the SCP file, but I guess sectors with any non-zero data would have no further compression.

Early Happy mod. Additional SRAM, replacement ROM, and the switch is likely a "slowdown" mod to be able to write more than 18/19 sectors on a track. Good that the drive appears to pass POST, as it suggests the powers/controller boards are all OK. It has the "grass valley" board set, which means improved power board, separate analog board (on top of the mech) and data separator (daughtercard hanging off the side board). It could just be an issue with the mech.. Test formatting a disk to see if the blank sectors are readable on another drive / if it actually erased a disk if data is written to it prior. If you have another 810, you could try swapping in another mech. There's a collection of old happy 810 utility disk ATR's, you could run those to run some diagnostics to test the RAM/ROM, which might also help match up the right version of happy software to your particular drive..

This is a good PSU, like the ones that came with the XE's. They will be less than 5.24v under load. Because they are likely to output a much smoother DC than unpredictable modern switching supplies. The Meanwell may be good, but any high frequency ripple on the DC output will be apparent in the video output of the atari, so it may be good or may not depending on the modern PSU / YMMV. But id leave the original PSU as is, and do up the meanwell separately if you want to try it.

I haven't used Monkey Wrench II myself, but here is the manual which might help: https://archive.org/details/the-monkey-wrench-ii

The 810's aren't clones, but just surplus 810's that Atari sold to some resellers without cases, which they created cases for themselves before reselling. IMHO, these often look better than the original plastic cases. You can see some references to these incarnations in the Atari 8-Bit FAQ: B&C 810 SS SD (B&C ComputerVisions house version of Atari 810) Best Electronics 910 SS SD (Best Electronics house version of Atari 810) Computer Palace RCP 810 SS SD (Computer Palace house version of Atari 810) San Jose Computer Special Edition SS SD (San Jose Computer house version of Atari 810) But ooh, it has a happy mod! You might have to go through a bit of trial and error to see which "version" it is, though with a 1983 sticker it might be a Rev 7. The switch at the front is commonly a write-protect/write allow switch, but with a happy in there it could be a fast/slow switch, which disables or enables the track buffer. I guess the "Special Edition" designation was San Jose Computer's way of designating the Happy Enhancement. Various revisions of the happy software are here if you ever get the drive to a working state: https://forums.atariage.com/topic/283666-archive-of-happy-backup-software/?do=findComment&comment=4127979

Did you test swapping all the main IC's into a known good machine? To at least eliminate those as a possible fault, or that they have been damaged. Especially CPU, ANTIC as mentioned, and possibly OS ROM. See if the screen colour changes with OS ROM removed -- usually that results in a dark brown/red screen I think.

No, but with full emulation of drives and other peripherals you can emulate their function very faithfully.

A very similar cartridge is the "Uno" cart - main difference is 128KB of RAM instead of 1MB like the Ultimate, so it can do 64KB carts just like the Ultimate, but not 1MB biggies like Bad Apple or Atariblast.

I've definitely corrupted disks in drives attached to an ATR-8000 by powering it up with a disk in and latched. I've personally never corrupted a disk in a 1050 or 810, but I believe I saw there are design enhancements in the 1050 schematic that protect the write head from surges during poweron/poweroff. There are issues with the original power board 810's that could corrupt data if a disk was in & latched as there is also no write circuit protection there, but I believe was later improved with the Grass-valley set of upgrade boards that present in "most" but the earliest of 810's, as many people back then would have upgraded them if they didn't have it already for the reliability improvements. Since the 810's always relocate the head to track 39 when spinning down, it was most likely that you would corrupt a sector on track 39 - which I guess was a design decision to protect against otherwise corrupting important boot/VTOC sectors on track 0...

That ROM is 2048 bytes with a 6-byte DOS 2 style binary save header... (FF FF 00 A0 FF A7, meaning load at memory location A000-A7FF (2048 bytes). I believe EPROM programmers like the Bob-Burner saved files with this header format... Without those 6 header bytes, the remaining 2048 bytes that produce a CRC32 of aad220f4. This matches the CRC32 for Rev. E noted in the Altirra Hardware Reference Manual (2022-01-03 Edition). Here is what Avery reverse engineered for the additional commands in Rev. E... These commands could have allowed some nifty tricks if Atari had originally included them in Rev B or C... Now need to look more into where "Dave Staugas" comes in... Googling shows he was a prolific Atari Programmer that wrote NEOchrome for the ST, Hover Strike for the Jaguar, Millipede for the 2600, and Rampage for the 7800. Methinks he may have "patched" the 810 ROM to add those features that would be useful to an programmer like himself? It was probably only meant for internal use, and only "leaked" similar to many other things that were leaked / cleared out of Atari...