Nezgar

Nice deduction there @kheller2 and @JGRAHAM2! (Maybe I should become Nezgar2? ) I still think something is up there... we should see one more column in column 3, and row $8x should not show. Maybe check that wiring again. Because SI2 thinks $8x has a full 4 banks, it probably thinks you have 256K of extended RAM. Some memory testers mistake that row as extended RAM, when it's really a mirror of the base 64K. Checking a real 1980's RAMBO'd 800XL I have, SDX 4.49c detects 12 banks, not 8, and XRAM 0.22 should look like this:

Check out the E80 driver from this post: https://atariage.com/forums/topic/315818-software-80-columns/?do=findComment&comment=4726615 It's an early disk version of ACE-80, supposedly scrolls faster than 40 columns.

Interesting PIA bits 2 & 3 are inpoerative.... In the 1200XL those are shared by the L1/L2 LED's, so maybe that switch on the back selectively blocks those bits from being used the memory upgrade. Try flipping the switch with the blue/yellow wires leading to it, and run the test again.

Hehe..... and to add to the fun - the ill-fated 815 wrote double density disks NOT inverted, yet all 3rd party implementations of true double density assumed inverting double density sectors in the spirit of the 810... so the few disks out there that are intended for the 815 can indeed be read on any other true double density drive (US Doubler, Happy, Percom etc) but you have to invert the data of every sector manually to recover a usable disk image. Case in point: My suggestion of XORing every sector with FF was used to archive the original "Atari Accountant" disks without having an actual 815 drive: ? https://www.atariwiki.org/wiki/Wiki.jsp?page=Read%2C write or convert from an Atari 815 Double Disk Drive I guess since we now know that Charles Marslett wrote the PERCOM firmware after which all future double-density capable drives were modeled after, he must not have had an 815, or a disk formatted in an 815 to know that Atari didn't invert double density. Not a big deal though since so few 815's ever actually made it into the world, and even if it had higher production, the fact the 815 couldn't read single density would have killed interest in it quickly anyway...

Some digging and dissasembling this evening.... First up we have three 810's with MPI mechs. Apparently 51 was the single sided model, 52 was the double sided model: https://archive.org/details/bitsavers_mpibrochurre_816309/page/n1/mode/1up #1 is an early 1980 unit, pre-analog/grass valley board set. Model # "B51", low serial number (especially compared to the 1983-84 model in my Percom at almost 900000), sticker on back: #2 has a July 81 Mfg date model "51M", sticker underneath so a bit of disassembly required to see: #3 Nov 1982, "51A" (wonder what the letters mean) Now onto my Percom AT88-S1. Also has a similar "51S", but the percom mechs have all the standard PC supporting hardware still attached, unlike the 810 mechs. I believe thats Oct 83, since there's a sticker elsewhere on the same mech that says Feb 20, 1984 - maybe when it was QC checked. Most of the PCB's have 83 dates. According to the following post by @JR>, 2 AT88 S1PD's had a World Storage Technology (WST) FDD 112-5 03 Mech (Like the made in Hong Kong 1050's) the other had a Micro Peripherials Inc. (MPI) 501c (like the RANA): https://atariage.com/forums/topic/283450-percom-rfd40-s1/?do=findComment&comment=4127830 One of my "Made in Hong Kong" 1050's with a World Storage Technologies mech. Model FDD 112-5. Looks like the double-sided variant is FDD 212-5, as pictured on this electronics recycling site:https://www.recycledgoods.com/world-storage-technology-fdd-212-5-5-25-floppy-disk-drive/ Lastly, my Rana 1000 - an MPI 501C, Mfg date Jan 1984. This particular RANA has a 6502 CPU, a 2732 EPROM (so 4KB ROM) and 2xMCM2114 SRAM chips. 4096 bits x 4 each, together these provide 1024x8 (1KB) of RAM. I also have a TRAK AT-D1 ... are you interested in that? I need to pull it out at some point to dump the ROM there too... Maybe it has the same mech as the RANA.

I had a 130XE that was from a former heavy smoker... Dark yellow, and they keys were dirty to the point where you could barely see the letters... the top case and keyboard (once detached from the mylar cleaned to almost brand new looking condition after a run through the dishwasher, and the remainder of the case cleaned up with Isopropyl alcohol wiping... All that nicotine coating basically coated and protected the original plastic from yellowing.. Now it's one of the best looking XE's I have. Wish I could find before/after pictures... Anyway... just saying see how it looks after a good wash!

I wonder if there was some (popular?) copy protected software at the time that might have failed due to this... I know most (older) Percom ROM's had this behaviour, can you think of any other specific drive brands/types that format with other than $00? (Maybe ATR8000?) Good investigative theories on @ijor's part! I have confirmed this myself as well... I have formatted a disk in both SD and ED, but prevented DOS from writing boot sectors, VTOC etc. Then, using DiskRx, we can see here that every byte of every sector is $E5 (inverted to $1A on disk). Including the VTOC/Direcotry sectors like 362 that @cx2k pictured above, which are normally overwrtitten when the drive returns control to DOS after the physical format completes. I formatted and checked both a single and enhanced density disk, the fill bytes are the same: While patching firmware for my AT88-S1, I found that the v1.2 ROM formatted SD with a $1A fill byte (which would invert to $E5 on disk) and DD with fill bytes $9249 ($6DB6 on disk). This suggests that $E5 was the recommended fill byte for FM, but they still forgot to invert it, and didn't use a different one for enhanced/medium/dual density's MFM. https://atariage.com/forums/topic/304384-percom-at-88-doubler-rom/page/2/?tab=comments#comment-4503979 I wonder if the firmware was initially written by Tandon, they would have more likely used a "standard" fill byte that all other OEM's were using, without previous knowledge of 810 operations. Could also have also just been an uninformed "new" programmer I guess. It's a significant enough and interesting quirk, vs the only officially documented reason of a "different error status than the 810"... I wonder what was incrementally fixed in revision "F". Attached are the two ATR's for anyone interested... 1050-revE-ED.atr 1050-revE-SD.atr

Here's an option at Canadian Tire: https://www.canadiantire.ca/en/pdp/permatex-multi-purpose-synthetic-grease-85-g-0280813p.html#srp

Make sure youre using the latest version of XRAM (0.22) - it was updated in the last few years specifically to handle Rambo's ability to mirror the main 64K as extra banks, and not count them as actual extended RAM: http://atari.sk/extended-ram-test-0-22-0-xram0220-xex/ Maybe post a screenshot too - the usable banks shown may provide a hint. What do other tests show? Ie: MEM /X in SpartaDOS X

Good alternatives are probably sewing machine oil aka 3-in-1 - though that may dry up quickly too like WD40. Or a bit of dielectric grease. Longer lasting. (synthetic, not petroleum based) These are what I use in 1050's. I hate white lithium grease. It is messy (and ugly) and seems to attract dirt.

I've had a chance to give @cx2k's ROM dump a once-over. I've confirmed it indeed identifies itself as revision "E" at offset 0xFF9 and confirmed it runs under Altirra full drive emulation. Rev "E" CRC32 is F9A7AFB2. File is attached. Comparing against the rev H binary, there appears to be 32 bytes less total code in E compared to H. Starting at 0x1BC there appears to be an extra 9 bytes in E that show up earlier in H, and then more significantly after about 0x260... F3E4-F3E5 are 2 NOP's like Rev H. (4 cycles) vs 5-6 in rev J-L. Details described by dhinson919: https://atariage.com/forums/topic/156462-1050-roms/?do=findComment&comment=4137223 Also according to dhinson919, only Rev K and L actually do a working ROM checksum test, so like H & J I suspect this one doesn't either, but need to confirm. https://atariage.com/forums/topic/156462-1050-roms/?do=findComment&comment=4131965 Checksum salt at $0004 is 0x63 in E vs 0xF6 in both H & J, so maybe there was intent for it to work in E... https://atariage.com/forums/topic/156462-1050-roms/?do=findComment&comment=4132976 Lastly is the matter of the "different error status than the 810 disk drive when certain types of protection schemes are used" according to the FSM Tech Tip Would be interesting to know what the actual change was, and which software it might have negatively affected. Would love to hear some further expert analysis from the likes of @dhinson919 and @phaeron! 1050-revE F9A7AFB2.BIN

Atari 810: I think of these in three "generations": (lots of good details in the Atari 8-bit FAQ on the 810's) "810M Pre-analog" Earliest drives Winter 80-Sep 81 - MPI mech, no external data separator, no separate analog board, weak PSU prone to failure and RPM instability, and Rev B ROM that formatted with slow 13:1 best for DOS 1.0's lack of burst I/O. "810M Analog" "Grass Valley" upgraded drives - Sep 81 - Nov 82 - Upgraded PSU based on 7805/7812 voltage regulators, Rev C ROM, data separator, separate analog board. "810T" Tandon drives - Nov 82 - May 1983 810 Tandon mech is a bare TM-100 with a lot of the standard electronics removed. Atari 1050 - 2 revisions: May 1983 to December 1984: bare Tandon TM-50 Mech, Made in Singapore, ROMs with Revs E, F, H, J, K L known, November 1984 to February 1985: WST (World (not Western) Storage Technologies mech, Made in Hong Kong. Modified rev K ROM on EPROM with adjusted stepper phase positions and step timing I'll inspect my drives above for specific more mech part #'s and lookup what info I can find on the Rana, Percom, Amdek.

Indeed it is "a now-defunct web site" according to an upload to Archive.org by @Savetz last year: https://archive.org/details/cyberroach-digital-analog-archive

Looks like another prototype 1050 PCB pictured in an earlier thread from @DavidMil which also contained revision "H": https://atariage.com/forums/topic/275166-one-last-eprom/?do=findComment&comment=3959877 The exciting thing about this to me is the revision "E" ROM that I've been on the lookout for a few years now! I previously wrote about this here after we found revision "H": https://atariage.com/forums/topic/275166-one-last-eprom/?do=findComment&comment=4118950 Specifically: "We're getting closer to the Rev. "E" or "F" ROM's mentioned in Tech Tip 21 in AtariMania's 1050 FSM: http://www.atarimania.com/documents/atari-1050-field-service-manual.pdf#page=40 "The first 1700 units released to the field have a revision "E" or "F" EPROM installed. This revision of the firmware returns a different error status than the 810 disk drive when certain types of protection schemes are used..." I believe most of the changes found in the other known revisions H, J, K were minor SIO timing adjustments. Revision L added support for the 2797 WDC controller, and lastly the WDC mech firmware was a modified rev K with changes to stepper phases and timing (and ROM checksum disabled). Even better that this is revision "E" instead of "F" described in the Tech Tip, as we will now have the earliest known/documented revision, including the supposed "different error status". Edit: Previous thread with details about the revision "H" ROM. This thread has lots of other information regarding disassembly and reverse engineering efforts of the various revisions as well: https://atariage.com/forums/topic/156462-1050-roms/?do=findComment&comment=4137039

Maybe due to some unicode support limitation in windows XP... I bet it will work in Windows 10. Edit: NVM you said you tried on Win10 . Maybe Jac! will comment at some point since I tagged him.

Maybe a screenshot would help describe what you're seeing? Which OS and Java Runtime version are you using? Your OSB ROM (Combined 4K LO, 4K HI, and 2K FP ROM) should match CRC32 0x0E86D61D. The author is @JAC! is here on AtariAge.

Well, I guess just check the CRC32/SHA1 against this list: https://www.wudsn.com/productions/atari800/atariromchecker/help/AtariROMChecker.html (Rev 1 CRC32 = 0x643BCC98)

I also believe that's false. Probably some confusion with the 1200XL OS, which predated the v1 in the 600XL and later.

Well, there's two ways to confirm: 1. Extract the EPROMs and read out the contents using an EPROM programmer. Compare the resulting dump to known OS's, CRC32 checksum etc. 2. Run an OS dumping utility from the Atari under each OS, save the data to a file. There is such a tool inlcuded with RealDOS, as well as one included with WUDSN ROM checker: http://www.wudsn.com/index.php/productions-atari800/tools/atariromchecker Either way then use some method such as SIO2PC-USB or an SD card card solution to get the resulting files to a PC for analysis / upload (ie to here )

Since one is likely "onmimon" the "80C" is likely Omniview.

I recall @Kyle22 pointing out that the instructions on the RealDos site are incorrect. At least, it's not how I've ever wired mine. It looks like the one in the OP's 3rd picture. http://www.realdos.net/US Doubler.html

Fair enough, thanks for summarizing for me. In windows/msdos: (2 files combined to a new 3rd file) copy /b file1.bin + file2.bin outfile.bin In Atari DOS 2.5: (appends file1.bin to existing outfile.bin, so good to make a copy first) C D:FILE1.BIN,D:OUTFILE.BIN/A SpartaDOS: COPY D:FILE1.BIN D:OUTFILE.BIN/A This "hack" results in the standard 2-byte "FFFF" header for executable showing up mid-file, which is supported, but utilities like StreamLiner can remove them extra bytes. Or use a hex editor of your choice to do it. There might be some other quirks like making sure the first segment has an init address not just run, etc... Yeah there's another thread recently about potential to replace the AW XEP driver - I had just never seen it in live operation... It looked faster than I expected from the stories, so Avery's driver must really fly!

I tried reading some TRS-80 disks a year or so ago and I recall the disks would read in DD - but of course the first 3 sectors would be truncated to 128 bytes, and all data was inverted. The EDDY sector editor had an invert option, which revealed readable text / filenames in some cases. In the early days of Atari, many developers/distributors used TRS-80's for disk duplication, and creating non-standard formats as copy protection, since stock Atari drives couldn't reproduce them.

Very cool, thanks for the video -- I love the two input/one output switcher model. Does this function also work for CVBS without the AV-to-HDMI converter? There's also a button to toggle it manually right? (Sorry if these questions have already been asked/answered...) Instead of modifying the DOS, could you have just chained/appended the existing AtariWriter executable to the toggle program for a single AUTORUN.SYS? As someone not familiar with XEP operation since I've never used one before, is the speed that AtariWriter fills text to the XEP80 in your video using the slower speed of Atari's original, or Avery's faster driver?

You can do it this "optimized" way: Or even better, use the PCB in this thread that doesn't involve irreversibly modifying the 6810 chips at all: