Jump to content


  • Content Count

  • Joined

  • Last visited

Community Reputation

358 Excellent

About 1050

  • Rank

Recent Profile Visitors

9,837 profile views
  1. My bad, I jumped the gun and skipped a step in proper diagnosing. I should have told to you to double check the ohms of each winding on the stepper motor before sending you to the market to buy the wrong parts to fix it with. Those 5317s must be pretty tough. From pins 5 an 6 on the disconnected motor jack they should have 33 ohms to pins 1, 2, 3, and 4. A short should exist between pins 5 and 6.
  2. Excellent digging, kudos. In the distant past someone installed J15 cable backwards and blew one or both udn5713 chips (U2,U3) into now having a dead short internally. It's probably U2 by the schematic as I read it. 14$ gets you ten of them here: https://www.ebay.com/itm/QTY-10-udn5713M-ALLEGRO-8-PIN-DIP-PERIPHERAL-DRIVER-NOS/121279928551 Tried the usual suspects, jameco, mouser, digikey with no matches so it could get difficult to locate these all too soon.
  3. Check voltage at the 7812 pins both input and output, loaded and unloaded. Post 4 results. Sounds kinda like a poor job of soldering maybe? Not meant as a slam but using flux will help a lot, perhaps just reflow the regulator connections with flux? Poor supply voltage could very well be the big legs on the big caps has pulled the solder joints and those then need reflowed with flux.
  4. Like Nezgar, I haven't done it myself, but I always wanted to make the original Nick Kennedy's SIO2PC and 10502PC cables to do the same thing, write stored ATRs on the PC to an Atari computer or a 1050 drive for use on a standalone Atari. This project is circa Windows 95 or thereabouts and is using a standard COM port on the PC which limits it somewhat. http://pages.suddenlink.net/wa5bdu/sio2pc.htm
  5. 1050


    Changing it is likely to result in no joy oddly enough. The problem is that it's dirty and needs a proper cleaning with deoxit or other contact cleaner. Part of that process is to wet the wiper and carbon arc, then move the wiper via screwdriver slot full range back and forth a dozen times. Let it dry, move it 12 more times dry and clean it again wet. It should become very stable in setting the color at that point and the new one you replace this one with will need the same treatment anyway. It's the nature of some potentiometers to behave like this and it's not really bad in the first place. You can try it with some WD-40, but eventually most will want a genuine name brand contact cleaner for that kind of work.
  6. I'm your huckleberry. It could be anything memory related at this point and reminding me of boarderline timing issue since the machine does work to some extent while reporting ram that doesn't - and that just doesn't compute. I'd suggest a change of U18 from 74LS08 to 74HCT08 for a stronger phase 2 clock signal as I always do for these boarderline timing cases. But after that and if there are still issues, anybodies guess is as valid. In other words I have not a clue at the moment outside of the weak phase 2 clock that often plagues some machines. I also haven't done EMMU either, but did have a timing issue with a home rolled MMU and only concerning the timing when printing. On a hunch dropped back in the PAL MMU that came out and I was back to printing. Odd, but that happened here. Otherwise the GAL MMU worked fine. I only did the GAL because I could and it worked fine half a year or so and then I needed to do printing. Did get some faster and slower GALs in but didn't burn them so no results if that was a fix or not.
  7. It's a well advised, late production run factory mod that will prevent burning the board under those two diodes if the load on the 12 volt supply side goes out of bounds for some nefarious reason we can't predict. I have a board burnt in two right there so my vote is to retrofit them long legged style while you still have something to solder the ends of the leads too. They run about 10% with the long leads here, of course YMMV. And only one with horrible results IIRC.
  8. True and true, my observation is explained by noting that 1772 is positive out for MO but needs to be inverted for even 5.25 and of course 3.5 drives. And then my not understanding that part clearly before I posted last. This is where I learn something new to me and I thank you all for that. But: I would always assume the opposite, that any and all 3.5 drives were set to be DS1 and eventually they were all hardwired to be DS1 to save OEM assembly time. 4 drive floppy computers never were a major portion of the market and two floppy drives weren't popular either. Your connection needs to be at the 34 pin cable shown in post 6 as a jumper from 16 to 12. Disconnect pin 10 there. I do believe so, yes. I've done exactly that under the board of the XF551 for use with DS1 set 3.5 drives and it worked a treat. Posted a photo of the work done in the group but have lost the link to it. Feeling pretty useless about that but it is what it is. My opinion is sort of. The combined /DRVS signal is now busy light on, which also turns on head read/write and index hole circuits. Suitable for ONLY one floppy drive computers is the change employed. Should have worked if 34 pin connector is the XF551 board connector. And it hasn't already been modified for SD1 use under the board (maybe?). It does get confusing, best of luck in any case.
  9. Coming out of the 1772 on the XF551, MO is inverted by a NAND gate and then split off to the DS0 pin as well. kheller2's link shows both /MOTE and /DRVS as negative logic by that forward slash, but the XF551 is positive to turn on the busy light and the motor. This "new" type of drive requires inverted logic on those pins?
  10. Faster key repeat and other toys such as green screen, but mainly launching of omnimon at 0xC000 which isn't the normal for an 800 with special keypress during a RESET. Or by fiddling with DIP switch having RAM at 0xC000 instead, etc. It seems all of Newells FP package has the bug at offset 0xE0 of E5h instead of Tebe and Puff's E9h. So how or where Steinman got his FP code might be obvious. I'll guess it's just copy and paste with no source just like the rest of us, 1984 is the ascii date Marslett put in the actual code. So Draco reports that this FastChip code breaks TurboBasic and it makes me wonder if his experience was with the buggy Newell version or not, if the working (good) FastChip code does the same trick anyway with TurboBasic? It would be a pity if it does not work with TurboBasic.
  11. To the best of my knowledge, Marslett is the author of Newell's FastChip code. Not sure about the financial arrangements if any and what ever source I can find for Marslett's FP code is a wild, not ready for prime time, first try gathering of nonsense that can't possibly render the final product. Tebe of MADS fame did a break down of the code though and it's well commented too. It is to be found in his MADS distribution in a folder off the beaten track there. But original Marslett source code commented is nonexistent, IIRC. His FastChip code carries his name and copyright date readable in ascii within it. Bob Puff offered the same FastChip code in some of his alternate OS roms as well. Newell has minimal comments in his source code which isn't source code per se. Only thing offered is a PDF of an assembly report of sorts that needs converting into actual usable source code. Newell E rom is the 0xE000 to 0xEFFF region code minus the character set from 0xE000 thru 0xE3FF, so it's only 0xE400 thru 0xEFFF instead. For the 800 since the 800 had two separate ROMs for those E000 and F000 regions too. OSNv601.zip
  12. It's like Disk Communicator producing a .DCM with ARCing the disc information. Just Sparta's version of that. scopy.zip
  13. The solution is in the converter, the equivalent that is printable would look like this: 4150 .BYTE +$80," MYDOS double density ATARI OS ",$1B except we still need a non-inverted space preceding that so writing the converter code that would do this automatically for us is fraught will all sorts of problems that were understandably dismissed as good enough for government work. Leaving it to us as a manual exercise.
  14. You sure are a persistent cuss. Not that this alone is a bad thing, it's actually a very good thing. So no, I don't have a 100% working rom file. I have only emulator and I can't confirm the work done on a real machine which is where this altered XE OS rev. 3, CRC-32 of 29F133F7 originally should work fine. I start with that version and apply the hi-speed SIO patch to it with no switches used. It should have every toy Hias put in his patchrom.exe process. Then manually I do; offset 0x0000 new checksum for 0x0002 thru 0x1fff region in little endian order - new checksum-16bit is actually 0x841e but in rom has the reversed order 1e, 84 as first and second byte of the rom file. This is the last thing done along with verifying that the last half of the rom file has it's correct checksum too. offset 0x049f D0 for F0 to reverse the function "Press Option at Boot up for DOS" - DOS is now the non optional option if you get what I mean there... This will effect the behavior of a real machine when a boot is attempted and you have no drives turned on. I disremember exactly how it's different but it can spin you around when you don't remember such applicable things in the midst of confusing behavior of what used to be a solid working Atari system now showing the auto self-test instead of BASIC ready prompt, if I guessed right. The auto self-test of course leads one to conclude it found something broken and nothing is actually broken. offset 0x0fff Hias signature for hi speed SIO patch applied offset 0x13a8 altered banking byte bit table to 0, 4, 8, c to fix four full banks of extended memory test offset 0x1939 starts Marslett copyright text string denoting the fastchip math pack The fastchip math pack is not working right with TurboBasic - this can be tragic for some, but it resides at; offset 0x1800 thru 0x1fff in case one would care to use a hex editor and correct that code with the original and re-compute and store the front half checksum. selftest code resides; offset 0x1000 thru 0x17ff SIO hi-speed patch resides; offset 0x0c00 thru 0x0cff with hooks into code; offset 0x02b3 thru 0x2b5 and offset 0x2971 thru 0x2974 and offset 0x3c20 thru 0x3c22 Things I've learned this time thru is that it must have been Newell alone that offered the broken version of the Marslett math pack. Perhaps he even 'tweaked' it not understanding Marslett's use of way non-standard means to extract the data he wants, he was masterful at doing that too. Marslett's source code is so far away from the published rom code as to not be applicable at all in my hurried opinion. Tebe's mads release has his version of commented source code for the Marslett math pack and it's brilliant work. Hias's hi-speed code is also brilliant, correcting both checksums in the rom effortlessly. The above Option change and fix for banking bits in the self test would be applicable to XEGS code. Mathy's 1 meg XEGS would need some further adjusting of values to test four of his banks however since his uses a non-standard banking byte table. Even instead of odd, IIRC. More than four banks for everybody would require a different display screen and a different test, this self-test 'toy' is not well suited for expansion and not very useful either. I haven't tested it on an emulator since it's so full of patches that the emulator will step on it and break it, this makes that use not so very smart to begin with. It is then 100% untested. There are already reports that the fixed extended ram test fails on some selected emulator memory expansions. And that this aspect does not apply to real Atari machines anyway. v3_85_hi_op_ma.rom - does contain fixed extended memory self-test CRC-32 9DA106D3 v3_85_hi_op_ma.rom
  15. That would be the fault of the poster of the text you have to not mention it comes from addmema.arc over at UMich archive where inside the arc are the instructions along with .PIC files which are the diagrams referred to. http://www.newbreedsoftware.com/xlsearch/ enter addmema into the search box and download it directly. And then open in a new window the UMich link for more. And more info here,
  • Create New...