Jump to content

Nezgar

+AtariAge Subscriber
  • Content Count

    2,548
  • Joined

  • Last visited

Community Reputation

2,026 Excellent

About Nezgar

  • Rank
    River Patroller

Contact / Social Media

Profile Information

  • Gender
    Male
  • Location
    Saskatchewan Canada

Recent Profile Visitors

5,995 profile views
  1. I'm also curious if such a beast exists - since most of the "800" compatible OS's for the XL/XE are derivatives of the original 400/800 OS that did not have PBI support in the first place. Most of them like BOSS XL, Omniview, Omnimon, OSN-XL, all used one, more, or all of the extra 6K from the selftest, International Char Set, PBI code, etc...
  2. hehe, for sure it was a longshot, heavy speculation while trying to think what else could be wrong. Thanks for the dump. I agree unlikely if those are the only changes. Excellent you've narrowed it down to the analog board! Maybe the Rev 2 810 Field Service Manual? http://www.atarimania.com/documents/Atari_810_Disk_Drive_Service_Manual_Rev_2.pdf There is a troubleshooting flow chart for the 810 Analog drive on PDF page 138 - indicates for a write fail go to 8B-22 (PDF page 144) which has some suggestions: - "Is there 0.8V on pin 12 of A106?" No: replace phototransistor (you previously indicated write protect sensor seems OK), Yes: replace in order: A106, Z103, A105 Cheers-N
  3. Thanks for the definitive explanation "why". I now know since using a real 810 Archiver that the command becomes only available when the archiver is "Open" so a "Closed" archiver 810 works perfectly fine with SDX... The "Archiver Emulator" code upload for the 1050 Happy is always open, so that one is not really usable with SDX.
  4. My daily driver 800XL has a UAV rev D connected to a 1702 with Luma/Chroma, is a very crisp clean picture. I have a 2nd 800XL I've cleaned up, but still has the stock output with no discrete chroma out, connected to another 1702. I tried using the Luma+Composite input combo to the monitor, and it worked, kind of. It behaved a little odd with the colour saturation changing, or colour completely dissapearing depending on the picture, seemingly more prevalent on primarily bright screens... so I reverted it to composite only as it consistently works, at least until a UAV goes in. I honestly have not tried this combo on the other 1702 to compare if this behaviour is consistent.
  5. Good find on the Archiver mod. Have you tried swapping the mech into another working 810? Also, try swapping the side board from a working 810 into this drive, since the side board has to be modified to support a 4KB EPROM for an Archiver... That would reduce the problem areas to the rear power board or the top analog board. The fact you mention the Archiver ROM has been modified as you found (open code 1234, copyright replaced with $FF's) it's possible something else has been broken by whomever edited it, or 'write protect' function has been altered to work differently. You could try installing an EPROM with a known-good image, ie this one I posted: https://atariage.com/forums/topic/275134-another-unknown-eprom/?tab=comments#comment-4432031 Could you post a dump of your EPROM? It would be interesting to try running with full drive emulation in Altirra to see if by chance the problem can be replicated there.
  6. The 800XL most likely contains a Revision "B" BASIC ROM. Most brown-shell brown-label Atari BASIC cartridges were produced for the 400/800, and had revision "A". If your BASIC cartridge has a silver label, it is likely revision "C" - which is also included on all XE computers. (both versions are designated CXL4002) Both revision A and B had some serious bugs, which were finally fixed in C.
  7. I recall @MacRorie was working on a very detailed install manual to include with the UAV's he's producing. I don't think it was released publicly.
  8. What kind of display are you trying to use it with? It's designed to be used with monochrome monitors that do not try to derive a colour picture from the signal. The XEP 80 is "compatible with a "composite" video monitor and will show a picture, but the signal is high enough resolution that using a composite input in a colour monitor will probably be blurry with lots of colour artifacting. The closest you could get is by connecting the XEP-80's output to the Luma input of a colour monitor with an S-Video input (with no Chroma input)
  9. I was able to keep RF functional as well as the UAV by soldering a socket on top of the 4050 (which was also originally socketed), and plugging the UAV into that. It made for a pretty high stack, but it works... (definitely does not fit inside the shield, unless you cut a hole) It might be compromising the video quality a bit, but it's still better than 130XE S-Video. @Jx Canal you mentioned you saw no difference in behaviour with the OS ROM removed? Do you by chance have another 600XL or 800XL that you could test by swapping IC's to? It's possible a static discharge has damaged an IC. What type of power supply are you using? One type the "ingot" is known to fail with voltage high enough to damage components. If you were soldering, make sure any flux residue is cleaned up.
  10. Try the RPM.COM included with SpartaDOS 3.2d - (I checked it's not included with 3.2f) https://archive.org/details/a8b_SpartaDOS_v3.2d_1986_02_17_ICD_a Direct link to ATR: https://archive.org/download/a8b_SpartaDOS_v3.2d_1986_02_17_ICD_a/SpartaDOS_v3.2d_1986_02_17_ICD_a.atr There are others out there, that I can't recall at the moment.
  11. Thanks for commenting @mikey! Curious if your testing included both PAL and NTSC computers? I remember the original Speedy firmware highspeed timing would not work with NTSC computers, until it was patched around the time of MegaSpeedy development and testing. I will not be able to install and test my new 1050E with an NTSC machine for a couple weeks myself. @MADRAFi are you using a PAL or NTSC system?
  12. I remembered this being mentioned previously. There's probably other threads too.
  13. The Stock 1050 ROM, and happy 1050 is nice, because they will actually format all the tracks first, before verifying. With SpartaDOS at least, you can then go and write the directories afterwards, if you beware of the bad sector landmines On a couple disks I use for general mucking about with, I used DiskRX or EDDY to find the bad sectors and map them as 'in-use' in the bitmap. Then you can still use 99% of the disk for daily use, as it will skip the bad sectors. I remember there used to be a utility for SpartaDOS that would automatically do this, and collect them all to an official file in the directory to ensure disk checkers didn't get confused by sectors marked in-use, but no file allocated to them... Anyone remember/have that progtam? US Doubler 1050, and other mods format and verify each track before moving to the next, so for disks with bad sectors, it will only ever format as far as the first track with a bad sector...
  14. Much appreciated @moonlight_mile! Your v1.10 dump CRC32 E2D4A05C matches the v1.10 ROM previously dumped from an RFD40-S2 by @ballyalley Great to have v1.10 verified from 2nd source.
  15. Random idea for the hardware gurus... A simple PBI or Cart+ECI PCB that's ONLY function is to override the on-board OS. It could be a cheaper alternative option for diagnostic with shoestrings RAM tester, without having to open the machine. Next step feature would be switch(es) to select between 2 or 4 OS's on the external EPROM.
×
×
  • Create New...