Nezgar

Thanks for the detailed clarification @reifsnyderb, much appreciated and much more coherent than my previous thoughts. With 32K provided by the 128k AS6C1008 SRAM chip ($0000-$3FFF & $8000-$BFFF) I guess technically 96KB of that chip goes unused. Then the 1024KB from the AS6C8008 SRAM provides 64 16KB banks at $4000-$7FFF, of which 1 would be considered the "base" RAM, plus 63 "extended" banks. so 32KB + 1024KB technically in hardware, or from the software perspective seen as 48KB of "base memory" plus 1008KB from 63 additional 16 KB banks, for 1056KB total. Got it! So I guess future ideas for consideration would be: a 52K mode, but this would have to disable Axlon banking. The $CFFF register supports up to 256 banks, so you could technically add 3 more MB for a 4MB max -- SpartaDOS X does support this.

Neato. Simcheck shows 32KB base memory, is it actually 48K, but 16KB occupied by a cartridge or maybe a hardware bug? Do you still need one more RAM module to fill $8000 through $BFFF? Or even up to 52K CFFF, but then that introduces potential for conflict with the axlon banking register... MEM /X also showing TOP $7FFF (32767) in your screenshots. Edit: I see now rereading you indicated the board only handles 32K of the memory map so that makes sense. I hope the last 16KB can still be made up with a module in the remaining empty slots. Also you mentioned 62 banks, but sparta indicates 63 banks. Sparta consumes one bank for disk i/o buffers and such, so that's why it says 63 banks/62 free. But help me understand as I think through this. If the board really has a total of 1024KB, that means that 16KB would need to be fixed mapped to $0000 through $3FFF, and $4000 through 7FFF base RAM would be "bank 0" but indeed there would only really be 62 more banks available. If SpartaDOS X or other ramdisks think there are 63, then there must be 1 unusable bank or shadowed due to the base 16K from $0000 to $3FFF?

I agree, but I imagine all it took was a customer to complain about data loss when removing a disk prematurely if this applied to buffered writes... maybe 3.1 was only offered to "those" customers. ?

Yes.... that is also my prime desired bug to fix.

Great work @manterola! Big surprise to me as I have been working with a friend to make a new replica Duplicator 1050 PCB design as well -- I'm currently waiting on the prototypes to arrive. We reworked the layout to shrink the footprint as much possible while keeping the original IC's, and added a ROM bank select to hopefully allow for a switch between 2 revs of Duplicator firmware, or the original 1050 OS (if programmed in half of a half of a 27128). I have been in communication with @E474 who inspired me with the idea to start this in the first place (it was a big jump in complexity from my 6810 doubler PCB's!), and have been brainstorming with him many potential future enhancements (like maybe integrated happy/cheerup support) and of course the potential of improving the firmware starting with being able to compile from original source, but figured I better make sure Rev 1 works first. Anyhow, I was going to wait until I confirmed if it works before posting anything, but without further adieu here's a sneak preview: ?

Excellent! Always great to get to the bottom of an issue, good work. To start out, you can definitely do the ol' hacked SIO cable and connect 3 lines to a serial TTL USB adapter for cheap: Though since not many of the signals are connected, you won't be able to use the faster ultraspeed protocols or share it on the bus with other peripherals, but I highly recommend Lotharek's self contained SIO2PC-USB device to start out,,, There's a million disk drive emulating things out there (FujiNet is the most exciting as of late), but I often end up falling back to this for basic file transfer and drive emulation to/from PC: https://lotharek.pl/productdetail.php?id=108 Yes an old DOS PC can work, but will require older DOS software and a serial SIO2PC with RS232-to-TTL level converter (max232) in between - here is a post I found that documents the "old fashion" serial-only SIO2PC cable: https://atariage.com/forums/topic/102152-making-an-sio2pc-cable/?do=findComment&comment=1240410 The 410 doesn't rewind because one (of many) belts is probably worn after 40 years. The belt will have to be replaced, which can be a chore. Replacement belt kit is available here: https://console5.com/store/atari-410-program-recorder-cassette-player-4-piece-belt-kit.html Cheers!

All that matters is the loaded voltage when it arrives at the atari power port. Measure them all with a multimeter to know the actual voltages to compare. Edit: Multi-voltage quick chargers will always "default" to the standard 5.0V. They require extra negotiation protocols to supply their higher voltages, so should be just fine otherwise...

After doing the resistor-cross, any bad memory identified by sys-check, can potentially be narrowed down to specific chip(s). I had bad memory in the extended ram of a 130XE and got it functional with only having to desolder/socket/replace three of the chips by hand since I didn't have a desoldering gun... I really should do all of them, but it's good enough "for now". I'm fully aware more could fail at anytime so it's definitely not a candidate for resale unless I finish the job.

The colour change is due to the replacement PSU providing a slightly lower voltage to the Atari than the original PSU. You could in theory correct this by adjusting the tint on the monitor or the colour pot on the motherboard but... I found in my own re-purposing of various modern/USB +5VDC PSU's that the final output voltage varies quite a bit across them all. The lowest voltages seemed to be moslty on PSU's with ratings of 1.0A or less and those long wires with very small guage wire. Note the fat 18AWG cord atari PSU's use on the DC leg. The PSU may very well be putting out 5.0V, but with the impedance of a long small guage wire the voltage when it arrives at the Atari may be as low as 4.5V. Around there the colours are usually way off tint, and my SIDE2 cart won't even function. So in conclusion, it would be interesting if you can measure the voltage at the Atari with the power on with a multimeter to see how much below (or over) 5.0V it is.

I would use Syscheck or shoestrings RAM tester replacement OS ROM to also ensure your base 64K is OK. Next, you can swap the base and extended 64K by cris-crossing one end or R110/R111, which swaps U26-U33 to become your base 64K, and U9-U16 becomes your extended 64K: If the system still boots afterwards, then the extended (U26-U33) 64K of ram may actually be OK, and your suspicion about an MMU issue may be true... Also test this 64K with syscheck and/or shoestrings RAM tester, as they do not test extended memory, only base memory. If the system doesn't boot, then the extended 64K is actually bad and you might as well desolder and socket U26-U33 to permit further troubleshooting by replacing some or all of the DRAM chips...

Bingo, I think that matches the PCB! Image I found from the following thread:

This seems to be my issue. OK Excellent if you were able to get it to read some sectors!!! So just so I'm clear, if the drive head is manually placed at track 0 and powered up, it no longer enters the the continuous on/off cycle? and by extension, if you power up the drive with the head NOT at track 0, you end up with the continuous on/off cycling? If so that means your T0 sensor is actually WORKING, and it may be your stepper. Furthermore - The track 0 sensor is connected at J10 - if this is disconnected, the drive will also believe the head is always at track 0. If you test with this disconnected, it should result in the drive NOT ending up with on/off cycling no matter where you place the head, but may only get actual good sector reads if it's physically placed at track 0. To confirm if your stepper is receiving power: With the drive off, the head should be able be manually moved freely forward/backward. When the drive is powered on and motor is spinning, the stepper motor should prevent free movement of the head if you try to gently push forward or back - check if yours matches this. If it continues to allow free movement while the motor is running, it may be an issue with the stepper. The stepper is connected to J15 at the back of the drive - ensure it's connected, and not connected backwards

The power-on behaviour you are describing suggests at least the 6507 CPU, 6810 RAM, and 2332 mask ROM are all good, as those are indications of it taking actions according to the startup procedure. With the drive off, try manually moving the read/write head away from track 0 closer towards the centre of the disk, then turn the drive on and see if the head moves toward track 0. If the drive is already not positioned at track 0 (furthest away from the centre of the disk) then manually move it there, and see if the power up behaviour changes. If the track 0 sensor has failed, and the drive thinks the head is "always" at track 0, it should pass POST and be able to read sectors from at least track 0. If the track 0 sensor has failed and the drive thinks the head is "never" at track 0, it should then try to step the head outwards toward track 0. 810's are not more reliable by a long stretch....

Did you reprogram the PLCC EEPROM? Is the EEPROM that is now in the AtariMax flash card a new/blank one? If so, I believe the process to program it is to boot the disk with the AtariMax flash utility without the Cart inserted, THEN plug in the cart for programming? Or program the EEPROM with an external programmer then plug it back into the cart...

Looks like a 256K memory upgrade. Notice the base 8xDRAM chips have *256 designation, vs the originals ending in *64. It's not wizztronics or ICD RAMBO, those appear to have a more rectangular PCB. Can you expose more of that PCB with the tape removed to see if there is any identifying branding? Looks too professional to be a homebrew PCB...

POKE 65,0 ? or, enable SIO device patches and/or sio accelleration.

That is the later, slightly less common made in hong kong 1050 variant that contains a World Storage Technologies drive mechanism. (vs made in Singapore / Tandon Mech) You are unlikely to get a response. It took one of the best years to secure an interview via phone call. https://archive.org/details/bob-puff-atari As to the upgrade itself, most of it's "cool" factor is from it's ability to duplicate copy protected software. The every-day utility is close in function to the ICD US Doubler upgrade. A firmware +RAM upgrade that enabled approximately 3x faster SIO transfer rate, but no track buffer so maximum sequential sector transfer speed required formatting disks with an optimized interleave. The built in Atari OS did not support the faster "ultraspeed" protocol, so you either had to boot a DOS (ie SpartaDOS, Top DOS) with a handler to support it, or install a repalcement OS ROM in your machine with it built in. CSS also produced such an upgrade called the "UltraSpeedOS+" Nowadays there are many more.

The Computer History Museum published a blog post todat about a trove of CompuServe documents, brochures, software, and hardware of material they narrowly rescued. Looking forward to learn more about what they acquired! https://computerhistory.org/blog/mission-impossible-chm-edition/

You don't need to use the open command with the chip converter (for happy drives). Just proceed straight to the copy disk commands.

First confirm if the original stock Atari ROM can format/read/write ED before going down this path. It's possible formatting ED/DD code may never have actually been implemented in the 1050E ROM, if it wasn't completed. After confirming the above, then you might consider the below, only if it is failing when operating in ultraspeed SIO modes... In the 1050 cut out C56, C57, C58 and C61. There is a picture on page 5 of the Mini Speedy installation manual here: https://www.vintagecomputercenter.com/wp-content/uploads/2021/04/MiniSpeedy1050.pdf In the 800XL, cut, lift, or remove C77 and C78: Optionally, solder a 4700ohm resister between Pin 10 and Pin 5 of the SIO socket, which I did as pictured below by connecting the right side of C78 to the top side of C80. This is slightly different in other 800XL motherboards...

Excellent - the more memory checkers the better! Tried it out this evening on two machines, and I may have found some bugs / nuances with different hardware... With my NTSC 800XL with tf_hh 512KB SRAM memory expansion (the one that sits under ANTIC) Running the .CAR from Ultimate Cart, SimCheck initially detects this system as 576KB Rambo with 32 banks using bits 7 6 5 3 2, but after pressing reset, it then shows 560KB/31 banks, with bank $2D missing. On the same system running the XEX from SpartaDOS X 4.49c on SIDE2 cart also I get 560KB/31 banks also showing $2D as the missing bank. Mucking with CONFIG.SYS to USE=OSRAM, disabling RAMDISK, etc, it intermittently reports the correct 32 banks. Running disk based spartados or Realdos while SIDE2 cart is present (booting via COLD /N) shows similar results, unless the SIDE2 cart is removed completely. Only if there is no SIDE2 or Ultimate cart in the system does it reliably show 32 banks. Lastly I tested it in a 256K XL with ICD RAMBO upgrade, and it correctly detects 256KB/12 banks using bits 6 5 3 2. If run in SDX without X command, screen is not restored to SDX command prompt when exiting: typing SDX CLI commands work, but I cannot see anything until pressing reset.. Using X to run SimCheck restores screen properly on exit. This is true for both the 576K 800XL, and the 256K 800XL.

There is a diagnostic function already in the stock ROM for 1/2 track stepping, and someone had posted some test/proof of concept code that would try to write /read "between" tracks... doesn't work so well for the sake of "hiding data" or any potential of gaining any extra capacity.

Another thought -- I can't remember if it's possible to move the motor slightly after loosening its screws. If so, maybe pulling it back a little it will tighten up the belt tension?

With the exception of the firmware in made in Hong Kong / World Storage mech 1050's, which uses phase encoding with 2 phases engaged at a time. (EPROM labelled WST AMC R5) As a result, mismatching Tandon/WST firmware/mech will result in a 1/4 track misalignment if the mech is not re-aligned.

Based on the "AWC / REV. 5" EPROM, this is a slightly less common made in Hong Kong 1050 with a World storage mechanism. If you replaced the drive belt, be aware that it doesn't use the same belt as the more common made in Singapore drive with a Tandon Mech. Tandon belts are easier to obtain including from places like Console5, but the WST belts are a different measurement. The only place to get them I know off the top of my head is Best Electronics, but they have other minimum+maximum order limitations...