1050

When you are selecting eproms for Atari OS replacement, I've found out the hard way, that you want one with a speed of 200ns even though this seems quite slow, they seem to like it much better. I have zero experience with getting an eeprom to ever work in that or any other purpose.

Not a problem, I was chunking out several single 3.5 drive ones during those days myself, not so much anymore. I got to where to where I would just count on using JB Weld and pop rivets on the SIO jacks because the real reason they fail is weak rivets to hold them on the board properly which quickly grew into JB Weld for the power jack as well because it gets loose too and then the same problem shows up there. My 800XL has the same SIO sockets but it's a double sided board and the rivets are clearly thicker so they have some actual bite when installed. I'm guessing by the time the XF551 came out cheaper inputs were the norm on how Atari corp would float from then on with the results we have to fix constantly. Those CSS dual drives were very popular, and should command a great price if only you can find someone that is willing to sell them.

I won't take credit for it, but I posted a thread here years ago (2015?) showing how to do it under the ribbon cable jack on the XF551 board. BECAUSE I had 3.5 drives that had no jumpers, they were made to be D1: and this was the only way it was going to work. It involved cutting the trace next to the header of pin 10 underneath the board and jumpering the trace feeding it over to pin 12. Pin 16 (MO) is connected to pin 10 (DS0) on the XF-551 board as is, just need to block pin 10 and shunt that signal to pin 12 (DS1) which is right next door. I was quite pleased with myself and figured somebody might find it useful themselves. I've tried to find some of those old posts of mine to harvest posted pictures, etc., that have become lost as versions of windows crash on me and I loose stuff that way. But I don't have very good luck finding much. It would appear that some one did see it and had the same luck I did? Puff did something similar using a small circuit board IIRC that changed things in that region, mid cables on his dual 5.25/3.5 drive that I got to play with for while. It was a confusion at the time, but it made some sense when I ran into my modern 3.5 drives that also needs pin 3 pulled or broken off or the drive won't work if it's used in a PC. And that boondoggle from the days of IBM PS/2, those floppy drives used pin 3 for something I can't even remember.

Only because I can easily do this, I would install the mech in an old school windows 98 box and go with MS-DOS tools to do the testing of the mech there. So many more tools on that side of the fence for that kind of diagnosis. Sounds like somethings up and you'd be light years ahead to know where the problem really is. The dodgy XF-551 board or the mech alone.

It certainly lacks the polish of a mass produced unit, but I'm suspicious that it's a home rolled short run for fast money unit based on the infamous Rambo in one form or another. See this post for more information keeping in mind whizztronics, and ICD's rambo made their's based on the original Claus Buchholz design which is also found in the post linked below. There are issues with the Rambo design starting with lot's of non-support in memory detectors looking for the lost 4 banks of the Rambo that are now holding the system data, while the original system memory is NOT used at all. AtariAge user ClausB is the original designer and posts a schematic in this post below. You can also see the instruction sheets for both the wizztronic and ICD Rambo if you'll follow links provided in that thread. And a vast number of memory testers here

Personally I never thought the gibberish above the atari part number meant anything before today, but a quick search gets me the datasheet from PCA. https://www.pca.com/datasheets/EP82XX-HL.pdf BUT there oddly isn't an 8212 offered... Somehow I think an Atari contract is involved and I'm calling shenanigans. Clipping away at a non existent chip doesn't work around here, but in these troubled days it just might keep one occupied, out of trouble, and off the evening news. Once I officially retire next month and start gathering ss benefits, I'll order the kit from retro myself - I'm done with waiting on vaporware.

Caution about any Newell offering containing the fast chip code, it might be broken at offset 0x01E0. It should be E9h, instead you might find E5h as found in the OMNIMON XL ROM code. So in the OMNIMON code the offset is different due to the fast chip code being included inside a larger file - it's offset there is 0x19E0 representing +0x1800. I dunno why it's broke or how it got broke, but I do know it might effect things. The proper code does a subtract from 09h and the broken code does a subtract of the value held at BOOT memory variable (0x0009) which is usually set to one. The end result will be different I would think.

Did you modify the ROM code but failed to update the checksum values? It could be failing because the checksum is wrong for a reversed OPTION press mod just for one easily forgotten I did that example. I know all about how humbling it is to do that too. 0xC002 - 0xCFFF 0x5000 - 0x57FF just to be accurate. I can quite easily check your ROM for the proper checksums if you'll post the ROM file.

I received 3 800s one time and out the three, two needed new PIA 6520 in order to boot with the 1050s I had. Can only suggest something with the early PIAs weren't up to snuff, but I had on hand a tube of 68B21 replacement PIA chips and in short order was working fine with all three 800s.

My bad, never mind about the pin advice as they completely repurposed the pin's use at the chip level which means they also included a pull down resistor on the chip to ensure a non-floating pin even when it is cut off which is the new "purpose" for single sided drives only. But the above advice is still sound for most other pins, never leave one floating or you can expect random results.

Not cut at the factory. One NEVER does that with a working brain stem, it needs to be told what to do and may be your entire problem. I would attempt to use a bit of thin wire stuck into the the socket and soldered onto what ever is left of the cut off pin right away. You don't leave pins to float since their logic state can change from internal chip leakage and that gets you random results any way you can slice that cake. I'm pretty sure it's not the stepper because it's not passing the RAM test or other section of Power On Self Test code written into the ROM. Stepper code isn't able to even be run because it keeps looping thru the failed POST test to start over and that is what is flashing the light as a clue and spinning up the main motor. 6810 isn't prohibitive in cost and you could use some extras to make a US Doubler out of it as well - why not get some and swap it just to be sure? The good news is it appears that the CPU and ROM are working, but something else isn't quite right. And the RAM test is quite extensive here reading mirrored data images in banks showing up at different addresses that another test might not be testing for.

Spray the table you are using and then transfer it with a toothpick or any other device that suites you.

When I had a real atari system, I would run it with a four drive stack with two D1: and two D2:, using the power switch on each drive to activate which pair I wanted. I found the only way to reliably allow this kind of swap to occur was to do the power down of drive to be abandoned, power up the drive to use and then most importantly do a RUN at 0x07E0 to effect a proper SIO init on all the disk drives and slap DOS up side the head while I'm at at. That might be what you are missing? Until I got into that habit I would often have the most confusing array of issues trying to use the newly powered up drives. At the top of that list was a drive that failed to do anything like it wasn't there at all.

Eventually I find the ar0 file on the disks is NOT an autorun file as depicted in post #4 as I first suspected and suggested. You were supposed to hop right up and fix that right away... David wrote a broken MyDOS that loads and runs anything for autorun files and is the only type 2 AtariDOS that will do that. I see no reason to change anything. You just need to fix your files to the standard. Here is the fixed ar0 file. NDEV.AR0 And here is the original NDEV.BAK See if you can spot the difference and then realize why a good hex editor is handy. The reason one doesn't want that behavior is due to the fact that the RUN vector is only run when the IOCB block is finally closed if that mode is allowed and the INIT addresses are run during the load process at each sector of the incoming file. This will lead to out of order code running and would make this mess look like a piece of cake - which is it is in fact. In the old days, they built their single autorun files like a swiss clock and with care and things worked out fine. But it takes detailed work fraught with additional problems of sector lengths and file endings needing to be whole sectors or the last half of the sector of the next autorun function wanted could be trashed by the INIT run. David's brilliant cure to that insane nightmare is the ar0 method with incrementing file names, but then he does the load in the wrong mode. One of the many reasons I just stole his some of his ideas and not his code.

Looking around to see where and how I might fix this, I come to a conclusion. I'm all wet about my suggestions so far. The first thing David does is reset the ar0 count to zero before he ever runs the autorun file load during the DOSINI run. So it doesn't matter what the number is as stored on the boot disk - it's getting set to zero anyway. Which leaves the only possibility of being that something tschak909 is doing has affected the STATE equate at 0x07BE to the effect of doing a warmstart bypass to DUP.SYS screen and it doesn't run the load autorun file because it thinks it already has done that even on an actual cold start. Which is the weird part, STATE on his disk is the same as a "normal" disk and I can't fathom how it's getting changed around on the fly. Especially before he gets to even run his autorun file... Somewhere DOS.SYS has been corrupted somehow??? It's looking like my short term solution would be to build a 2nd work disk but not from/with this DOS.SYS - DUP.SYS pair. Get those files from a "clean" new source and copy only the other files over to the new disk. This is a deep mystery to me at this time.

Well, I've never had the problem either, but tschak909's disk is quite large and stuffed to the gills with many items. Somewhere along the line, he wrote DOS files back to the boot disk after it found and ran a proper autorun file. I'm thinking it's just this one disk, this rare time that the issue has finally come up. But it's a very real issue. So doing M. Run at Address 7e0 is the same as doing a DOSINI run and in that string of code is where David reset the number for the ar0 series back to zero. I did the same, it should instead be upon failing to find the next ar0 series or completion of loading the last one possible ar9. Never thought about it to be honest but without doing it right, it's kinda dirty code in need of a fix.

Ok, it is genuinely broke. This beta 4 wants .ar1 because it did load ar0 at one time before, incremented and tried again but didn't find that file and then got H. Write DOS files to the boot disk preset to start looking for .ar1. I was not aware this could be an issue but it does need some correction somewhere so this doesn't happen again. Strange cure is to do M. Run at Address 07E0 and then H. Write DOS files to D1: and you should be good to go. I still don't have a good clue how this happened, but clearly resetting the extension to zero needs to also be done when H. Write DOS files to disk is done. Next version release will have it. A genuine bug - well done. As to blocking the autorun with a keypress, it will take some cogitation with MyRD in mind and how to keep one from messing with the other since there are already bootup keypresses at work with MyRD.ar0. But I'll keep it in mind for the next version release as well.

So that's interesting. Have you tried autorun.sys as the file name? Please do. If it loads then that means somehow you have the wrong DOS.SYS while beta 4 DUP.SYS is giving you a fake news menu screen. It can occur rarely that DOS.SYS from one version is hooked up with DUP.SYS of another version. This is usually avoided with the ATR distribution method, but it's not perfect by far. And mistakes can still be made. Especially when H. Write DOS files to the boot device isn't done at that appropriate time needed. The code from 4.53 in this area of DOS.SYS is the same and is the source for 4.55 beta 4 so I'm at a loss to explain it so far. And first instance of this complaint so thanks for the bug report.

Autorun files only ever did work if you call the INIT vectors at 0x02e2-0x02e3 at the end of the autorun file itself. It's not an autorun file if it's using the RUN vectors at 0x02e0-0x02e1 which are not allowed and just won't ever be processed. It's on you to make sure your autorun files comply with both these autorun rules. Not a MyDOS thing BTW. But it does comply to those strict pre-existing rules. So it's likely most have never even heard about those rules mainly because they don't use autorun files much. It's no big thing either way. Anyfile.ar0, anyfile.ar1, anyfile.ar2 work fine if the files are correctly vectored as actual autorun files. I guess we could have broke the mold and called them autoinit files instead?

A quick look tells me this is an 800 rom layout with typical values for same at the last three vectors of the file. Which is a quandary due to ram disk involvement which typically works port b on XL/XE only, unless everything here is using an axlon ramdisk? At any rate, the dump is highly appreciated here as it can serve as an interesting disassembly with unique treatments of ramdisk operations - and I just LOVE that stuff. Thanks so much. So the self test data section is all zeros, it might be that they are actually written into the ROM as zeros. Which means it could be a toss up to burn this, pop it into an XL/XE and have it work right. Also unknown is if special disks bring in other code that needs this code to work, there seems to be an error message in atascii that complains of bad data on a disk - so there could be missing code for this toy on a disk somewhere. All I have at the moment and it was a hurried look thru it.

Please keep us appraised of marketing plans for the boards, if when how much. I would like more than a few, less than a dozen, but six would be nice for starters.

Just a wild guess, but one tenth of an inch? 2.54 millimeters. Hold up the legs of an IC to the holes and does it match? That's it then. So that's not diagonally of course, you'll need some math there.

I'll always vote for the incompatibility reason. SD in FM and 26 sector per track MFM were "lifted" from 8 inch discs. Put 8 inch topology on a 5 1/4" and you have instant incompatibility with all other players. This is too perfect of a fit to ignore.

It's a mess, but it has the same first sector pretty much as the Happy 7 disk. Then sector 2 is blank and that won't work for a boot sector at ALL. Hyper does replace text in often repeated similar patterns all the way to the end for both discs that make it look like a purposely made to be shit disc. No VTOC, No directory, how does it get this sideways without help? The 1st sector similarity has me thinking do you have the Happy 7 disks and have you tried to boot them? Until we get sector two with something in it and correct the "errors" in sector one which by rough guess would be about 20 bytes, we are not getting very far with this rocket. And then there's this feeling that if you booted Happy 7 you would find it says it's a Happy. So just an outright ripoff that somehow is not qualified for a full copyright infringement effort across the pond due to non working software supplied and on the phone the voice says to use the Happy software and don't bother me again.

Known as bypass capacitors and/or decoupling capacitors, their use is common. One for every chip is the generic rule with some high performance people up sizing the capacity at the same time. Your 104 examples would then be 204 or 304 if you cared to double or triple that actual capacity shunting the noise spikes to ground plane locally. Atari commonly used a chip capacitor inside a glass case with axial leads mounted to the captured chip capacitor inside = insanity on some level. http://docs.eao.hawaii.edu/JCMT/i/012_HARPB/localOscillator/Manufacturers/Phytec/AppNote/Atmel/PLD/doc0484.pdf This note primarily aimed at PLD devices like PAL or GAL, but please note - EVERY chip deserves the upgrades suggested in this application note. This one a little newer, is on about static ram chips. http://ww1.microchip.com/downloads/en/AppNotes/Atmel-8580-TPM-Power-Supply-Decoupling-ApplicationNote.pdf