1050

Clever. With the metal tab installed the step motor hits an OBstackle and reverts to the opposite direction of it's own accord. I would have thought it would be done with software instead myself, but what do I really know or even paid attention too. Nice catch, next time I'm close to one of those I'll see it again for the first time correctly.

I never said that. Up until you mentioned a size range, we were talking about a 576K Peterson as is Peterson. You don't get to count those banks accessible by ANTIC only as a valid CPU bank when you are using it as a ramdisk (CPU driven), UNLESS you forgo the ANTIC access feature in your claims for the upgrade at least to some extent. The 576 Peterson breaks the rules on both sides of the issue. It's only a half assed confusion of either one or the other while in reality being both at the same time. Just adds to the confusion certainly for the new guys. End of the day, Peterson is bragging about the size of his chips used while he does have some ANTIC access but those banks stop at 320K just like the Compy Shop does - but it's still a 576? NO it is not, it's more of a confusion than anything else. No complaints just means that there are no programs that use it as a full ramdisk and an ANTIC only access graphically intensive demo at the same time. Mind you I don't have one, especially the one with the fancy switch you posted above to dig further into the issue that I'm never really worried about in the first place (hi, Mathy:) ). Mathy and I go round and round on this issue since forever it seems (late 90s?), he has his rules and I have mine and we are both very stubborn. Without that program and certainly without the upgrade, I can't flesh it out - this cat doesn't get skinned here - but I have my doubts about it's ANTIC access in the ANTIC access only modes certainly. It seems to me that banks just might be used twice which would result in disaster for the data contained in the expanded memory. Unless you use simple software that never attempts such a thing. That just happens to be the case today, so I would expect no complaints. Just in case anybody didn't hear that, my reservations are based only on the theory of how ANTIC access is supposed to work as is used in the 130XE, and as I and I alone interpret that. So it's just one opinion and not an opinion I'm heavily invested in. When I see the Puff US+ 130XE (320K) with a solder bridge on bit5 to bit4, I tend to wonder how this is a fix for ANTIC access issues in the first place, yet that's the claim. It leaves me wondering what kind of beast he created there and I'm not so sure that's a good fix. I'm also not so sure Peterson can take an XL 576 upgrade, drop it into a 130XE and make the same claim either. I will easily admit it's some kind of mixture, but exactly what to do with that is a dunno for me. I've saved your link to discussion with the extra fancy switch offered up by Peterson. I hope to make one someday but I have zero faith it will be any day soon. Thanks for the link just the same - it's very intriguing.

I feel your pain with real hardware struggles, gianlucarenzi. Best of luck with that issue. I've been to your github posts, but I don't understand C and do my code writing in assembler. BUT I did find out that emulators don't work like they often say they do when counting on the various expanded memory choices we have there. And I haven't tried all emulators either, just Atari800win. Starting at this thread: In the beginning there in that thread, I wasn't aware of the issues of Rambo type extended memory upgrades. First thing I learned is that my emulator was lying to me and I had to "pretend" the code I was writing did what I wanted it too. It often didn't which is why I call for so many screenshots running on real hardware. All I had to work with WAS an emulator, but eventually the code was approved by those running real Rambo upgrades. I have issues with using this upgrade on a 130XE as it has bit 5 use firmly reserved for ANTIC access modes and I have zero confidence one can take an upgrade for a XL and slap it into a XE without issues. I'm thinking there are issues and I have NOT approved the peterson for XE use, even though I've seen some 320K versions that also had the same issues. None of those issues have been cleared up for me, so I fear I'm not going to be able to work up a fix in any case. Much less guide you with pointers in a language I don't understand (C). I don't see how one can use bit5 as a banking byte and have it count as "one more valid" bank, it should be discounted as it's an ANTIC access bank. Yet it's still used for "one more valid bank" counts. I don't understand using both systems and still have both systems work at all. I have no code written to test for these anomalies either. On the XL we don't have ANTIC access MMU (U34), it would seem best to limit the work to that platform. But only sometimes does this seem to be clear path to me. Simply put, I have not resolved my issues in order to voice a clear opinion on the matter. I clearly don't know what to think about it. I'm doing good to detect a genuine Rambo with my code. So such as it is, welcome gianlucarenzi to all you can feast on, glad to have you on board too.

Philsan, Have your friend give these memory testers a try, especially EXTEST.COM inside MEMRAMCHECKTEST.ATR. https://atariage.com/forums/topic/189604-small-thing-memtest-10-1996-jaku-b/?do=findComment&comment=3815398 I was thinking the Peterson was a Rambo knockoff, am I wrong? Again? At any rate EXTEST.COM should exclude the rambo system banks from the list of usable banks and thus be 4 less banks than most other testers, IF that Peterson is a rambo type memory expansion.

The files beyond sector 720 use a second VTOC bit map sector above sector 1023 which DOS 2.0 is completely unaware of. DOS 2.5 shows them with the brackets < > . 1023 sectors was the limit for sector counting as the three end bytes also needed bits for file number merged within the first two bytes of the last three bytes. This left 0x3FF (1023) as the last usable sector. The second VTOC of DOS 2.5 was I believe at sector 1024 and 1025 thru 1040 were wasted space. So many ways it's not so very compatible with any other DOS. But I used the devil out of it in the years before I had a ramdisk.

That was about I had to report to you as well, the identical first page in both files. I wouldn't call it non 6502 code since rarely some is about, but it's not typical of Atari 6502 I'm used to seeing at all. Very little of it would work and that just doesn't seem like memory space compromised op code then. Dunno what to think of it.

Hi Larry, I don't recall where they were going up for sale, when and IF they go up for sale. I'd hate to miss out on my rare chance. Please inform us of exactly where again for some of us with the foggy brain cells again. TIA. Good stuff, dang good stuff.

Please do, I'm all ears. In fact, I'm stuck right here writing the easy to use MyDOS floppy format tool Andreas (CharlieChaplin) is looking for. I don't have a 1.4 meg system set up to read a percom block from but need that data to fold into the oddly used DRVDEF table at 0x07CC which is done by O Change Config menu selection normally. If the DRVDEF table contains the correct information for the drive doing the format, MyDOS will in fact format it and build the proper matching VTOC for it. Currently the only way to do that is via the O Change Config menu. Reading a Percom block from the drive won't do it with MyDOS because of the format bug where the DRVDEF values are written out as a Percom block to the drive FIRST, and even if that fails, a format is attempted without ever correcting the DRVDEF table. As if error checking isn't an option that should exist? Thus writing a percom block to a drive will never work for a subsequent format done on that drive. And this is supposed to be the way it is supposed to work in the land of Atari as I understand it. But it doesn't work at all with MyDOS unless you go manual and use O Change Config first. I'm thinking there is no need to bother with 2,880 k since there are no floppies nor drives available? Even brand new way back when, they didn't work but a couple of times and the drive got returned for defective. Which quickly ran stores out of stock and had angry customers demanding their full money back. Some got their money, most didn't because it was an industry wide hemorrhage of zero drives that could be made to work even for a dozen floppies. They are listed as existing, but today none actually do. AND we don't have a current floppy controller that is capable anyway. Unless I'm wrong in my research, please correct me. Anyone? And TIA for everything.

There is support for 77 track drives which I tend to think might be some flavor of original 8 inch drives, but have nothing other than a hunch about that. And then one can specify huge sector counts in a drive table that lends itself to mounting 16 meg ATR files as one of those drives quite nicely. Perhaps this method of putting in obscene values into the standard configure drive method was meant for "hard drives"? The code for 4.1 (1985) still contained bugs that would not allow full function of a 16 meg drive properly. In 1988 and with 4.50 those bugs were addressed and fixed by Puff. The odd hard drive table above is still in play as well. Larry, you can also press * to get a directory of the default directory, which if it's pointing at some subdirectory can be handy too.

De-labeling is not an obstacle these days with any modern USB eprom programmer of the $40 eBay variety. They have an option of "guess which logic chip this is" and with the help of that testing facility, the number they used to carry can found very easily.

Basically the extended memory as used in the Atari scheme is to send the active memory bank the /CAS signal and that allows each memory chip in that bank array to decode for it's desired address for read or write on the data buss at the appropriate time. Without the /CAS signal, the memory chips then enter what's called /RAS only refresh mode where the data in/out buffers are tri-stated (unaccessable/disconnected from data buss) while address is decoded internally but is only used to refresh an entire row of memory cells. Each memory chip has the smarts to know which it should be doing by the /CAS signal going low. The / forward slash used on /CAS as I type it is supposed to be a bar across the top of it to notify those interested that it is a negative active logic state. So keep the /CAS line high all the time and that memory bank of chips is asleep and undergoing memory refresh on it's own internal counters. Turning on a bank of memory chips then requires the one and only /CAS signal to reach that set of particular memory chips. So how to do it is where I can't help since I don't have knowledge of just how 1UMB works in the details. 1) Newell misspoke about the switch and was referring to another issue while using compatible talk to avoid the actual question about Antic access. It's not a thing with a Newell upgrade and never will be without the 2nd MMU of the 130XE wired into the circuit so that actual emulation of that talent occurs. 2) Same for 2nd switch advice then too, neither writer understands the complexity of Antic access nor how to bring it to a memory upgrade properly. 1UMB has it and it works fine, Newell will never have it and never did. And what you want is something else entirely. There is nothing great or wonderful about the Newell, I have a one (four) meg FYI, I can not shut mine off with or without software. So I would have to install a switch to keep /CAS away from the input of the Newell and to also then shunt it to the 1UMB instead for it's use alone. Something like that might work, but I see no reason to keep the Newell since the 1UMB will give you one if you select for it. The off /CAS input then should be held high with a 4.7K resistor to insure that two memory banks are not trying to access the data buss at the same time. So PIA pin 15 is bit 5 of PORTB 0xD301. In an Antic access upgrade, is it used to determine if Antic has access to the ram window at 0x4000 - 0x7FFF or the CPU has that access or neither/both do. It can not then be used as a banking byte to select the number of which bank of memory is in that window in Antic access upgrades. This requires a separate MMU in the 130XE since the /CAS shifting must occur during the /HALT event if it is to occur. Antic can then use the extended memory window while regular CPU Base memory for the window is refreshing. And vica versa as the case may be. PIA pin 14 is bit 4 of PORTB 0xD301. It selects the CPU access to the extended memory bank for the ram window at 0x4000 - 0x7FFF, just like bit 5 does for Antic in Antic access upgrades. Bit 4 (and 5 in Antic access upgrades) are low active signal(s) so both high mean that the window data is coming from Base memory and extended memory is in /RAS only refresh mode. Clear as mud even for me, I hold no opinion that Antic access is even desirable, but without it some Demos won't display/work right. You can't make a Newell into one of those by any simple switch or solder bridge. For Antic access you need both /CAS and /HALT signals decoded by logic chips before they happen so to speak in order before the switch of the proper window at 0x4000 - 0x7FFF occurs properly. This is the rub, apparently /HALT occurs before /CAS and this then requires the effect of a latch to hold its value such that straight glue logic fails to provide a working solution. We need a properly programmed GAL or PAL which is what Atari used in the 2nd MMU of the 130XE to pull off the magic of Antic access. 1UMB has the GAL which is also selecting an array of Antic access and other memory types/sizes including Newell. ATB, stay safe out there people.

In meantime of saving for the next buy, there are workarounds for free. Borrowing from atariage user russg and his saved zip file for ASMED.ZIP where he converts the cartridge code for the assembler/editor into an executable to run from DOS, I've done the same for BASIC_C in this updated zip file containing both cartridge code and executables of each. ASMED_BASC.zip Now the only problem is getting the contents of it to a real floppy.

Yes, erase is a function of the write cycle. U21 a 3086 transistor array is called the write amp in the Sams Photofact. On signal comes out at pin 8 to be amplified further by Q1 2N4404 while the signal is actually supplied by U17 a 7406 hex inverter using two gates for more drive. But the problem isn't erasing, it does that. The problem is writing understandable data back to the disk. Those list of chips is then more than the above. For the moment changing the 3086 at U21 has fixed some write issues in the past as well as U17 the hex inverter. 3086 are known weaklings at both the write amp and the SIO input uses (U1) in the 1050. Bad silicon in the early days is my guess, new ones don't have the problem. Both these chips do double duty in erase drive and data writing. Sams Photofact 1050 http://www.atarimania.com/documents/Atari_1050_Disk_Drive_Sams_Computerfacts_Technical_Service.pdf I would change those two chips just for the heck of it. Then see if symptoms are different at that point.

On an 800XL the ROMs go in the top slot facing away from you, 130XE the ROMs would go face down against the table or desk. Yes both sockets need a 64K ROM since slot 14 (RD5) can be seen to be jumpered to slot 13 which is +5 volts in and that tells us it will use the lower address range of 0x8000 thru 0x9FFF in addition to the normal 8K cart range of 0xA000 thru 0xBFFF. Trouble is the common 2764 eprom which is the correct data size for 8K (each) comes with 28 pins and not the 24 you have here. Special eproms are required then and they are hard to find and pricey as well. So I propose you save these for use with Atari game/utility ROMs and get some other boards that do support bog standard 2764 eproms. Bruce at B&C used to sell them as: PRA062 PCB CART board 16K for EPROMs W/SOCK 2-2764s - $8.00 B&C But since he has pulled his catalog down for revamping, I'm not sure he has any. He does business on eBay as https://www.ebay.com/str/atarisalesandservice I would contact him by selecting an item from his store and on that page look for "contact seller" to send him a message via eBays internal email system - he doesn't seem to respond to direct email to his actual website. With one post I assumed incorrectly that you would need a lot of help. All you need to do now is cut the jumper between slot 14 and slot 13 and that will make it an 8K cart. Put the ROM in the right slot and best of luck. Try the left too if right doesn't go to BASIC.

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.

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.

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.

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

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.

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.

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.

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.

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?

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.