Dr Memory
-
Content Count
103 -
Joined
-
Last visited
Posts posted by Dr Memory
-
-
The embedded video shows what I was trying to describe in words. I dearly hope it isn't too large to post - I don't really know the limitations of the board. I looked around for a "rules" post and didn't find it. Hopefully it will either work or TELL me that it's too big and not post! When it came out of my camera, it was 127 MB and I reduced the resolution by 75%, so maybe that's good enough...
Anyway, enough meta. What it shows is me navigating the menu on SIDE 3, with the screen from my 800XL displayed on my Toshiba monitor. The image is really crisp and the colors good (though this screen is black and white), so I'm pretty confident that the video upgrades I described previously largely worked.
But, I've got this weird issue with bulges. Whatever line the SIDE 3 cursor is on bulges inward from the left and outward on the right.
To be clear, I am quite sure this is NOT a SIDE 3 problem, I just used it for the example because it makes it really easy to see what's going on. Also, the FJC SIDE 3 videos don't show this happening, so that's evidence that its my system somehow. It is reproducible on a different monitor with a different video cable and power supply, and on that monitor it happens in both composite and S-Video modes. It's a little less pronounced on the JVC but still there.
The video will make it obvious why I don't have a podcast.
I don't really like the way I sound, and I can't go back and fix verbal typos and the like. I'm sure it is understandable, but definitely not suave.
Any suggestions on what I might do to cure this would be appreciated. I'm out of ideas.
-
1
-
-
I've gotten a bit obsessed with the various video improvement projects out there. I've implemented a couple of them with pretty good success. As a part of this, I had to run down info that had moved. This is where the Super Video info resides currently:
-----
All the links to Super Video on AtariAge.com seem dead. If there are any working links, I certainly failed to find them! So here is where I found the info, as of March 1, 2021:
All of the things:
http://ftp.pigwa.net/stuff/collections/atari_forever/Extension/Super%20Video%202.1XL/
Info is scattered throughout this directory tree. The pics are useful, as are the files, but the file names are not particularly helpful.
Overview: This page links to most of the other files.
http://ftp.pigwa.net/stuff/collections/atari_forever/Extension/Super%20Video%202.1XL/supervid.html
Several of the files have headers claiming that they are about “Super Video 2.1XL". Some of them lie. Most of them are for 2.0 or 2.1 for different platforms. I think the overview link above is the best way to navigate through this.
This is a link to the article from which most of the other info came.
https://atarionline.pl/biblioteka/materialy_ksiazkowe/SuperVideo%2021XL%20oraz%20errata.pdf
If you read that pdf, you will see that most of the other info is excerpted from this article, though I think the smaller pages may have some of the errata incorporated. Also, the article doesn’t cover all the platforms. So why should you care about the article? Mainly because it has the promised images embedded. So when you read “Study Figures 5-7” you can page down and look at them rather than try to puzzle things out. Some of the figures are present in the ftp folder, such as fig5a.gif (which matches Figure 5 from the article). Others are not, such as Figure 6.
Actually I’m fibbing. I think most or all of the pics are there, but some are mislabeled. For example, fig7.jpg is Figure 6 from the article and fig7a.jpg is Figure 7 from the article. So I think all of the info is there, you just have to poke around a bit. The article provides really nice clues, like the picture on the box of a jigsaw puzzle.
-----
To be clear, I'm not taking credit for any of this work, just sharing current locations. I'm sure links will die or move again eventually, and someone will need to do this again.
This table is an attempt to gather up the info from the SV files and the various AtariAge threads, as well as Bryan's "Quick & Easy" mod. Again, I'm not the creator of any of this, I'm just trying to organize it a bit. I did it mainly for myself but figured it could be useful to others.
The color coding is an attempt to make it easy to show where the various mod steps occur in multiple mods. The specific colors chosen mean nothing - I just needed them to look different. No guarantees that I didn't make mistakes! Steps with no "Remove or Mod" entry mean that step is purely an addition.
What I call the "tf_hh version" is based on a message he posted in a longer thread, describing what he usually does now after modding like 50 systems. He left out the chroma pin jumper and resistor but I'm sure he just assumed it was obvious.
"FJC minimal change" is the two items that FlashJazzCat once mentioned doing and getting good results with deep in some video thread. So I tried just those first. I agree - it looked a lot better after just those two changes.
Results:
I did just steps 1, 3, 6, and 7 of the tf_hh version on my PAL 800XL and got really, really good results. Beautiful picture quality on both composite and S-Video. Really, that's pretty much just the two things that FJC liked + the auto-switch diode mod + the enable chroma pin mod.
I repeated those steps on an NTSC 800XL and got pretty good results, but not as good as the PAL system. There was no C56 to remove though. I then did the rest of the steps from that version and it improved things a little but it's still not awesome.
The symptoms are that some parts of the screen are mildly warped. For example, on the SIDE 3 menu, when navigating a directory, the line the cursor (white bar) is on is sort of offset to the right, on both sides. So the left side is pulled in a little and the right side is pushed out a little. So like a little indentation on the left border and a little bump on the right border. The distortion follows the cursor - whichever line is selected shows the bump and indentation. This is all seen using either composite or Y/C, and is seen on two different monitors. I'd say it's a bit more pronounced on the Toshiba than the JVC.
All I can think to try is the two mods I didn't install - the 10 uF cap in SV 2.0 and the 1K resistor in SV 2.1 and Bryan's mod. No idea if those will help. Comments?
Oh, and tf_hh's suggestion to put a shottky diode in series with R56 works great - no switch needed! In fact, on the JVC I can have both sources wired up at the same time and switch back and forth on the monitor.
Hope this is of some use to somebody someday.
-
As mentioned previously, I ordered in February this year and got my stuff in 2 week. Really not bad, especially compared to the horror stories of some others! Also, very happy with the products.
It wouldn't surprise me if things ordered in December got mixed in with the Christmas shipping mess and are still in purgatory somewhere.
-
1
-
-
Breakthrough! I finally worked up the courage to desolder the Delay Line from a working Atari 800XL. I replaced it with a socket and plugged it back in, and my system still worked. Phew! I know this is old hat to many of you but the last time I did something similar, which would have been something like 35 years ago, I killed the computer I was working on. If I remember right I was trying to install an Omnimon upgrade in a brand new 130XE, one of the first to hit the local store, and it did not survive. So I've always been worried this sort of thing. But this time it went well.
I then swapped the Delay Line chip from the sick 800XL to the working one, and the working one stopped working. Black screen 90% of the time, red screen the rest. So that's proven. I swapped the known good chip into the sick 800XL and for the first time since it arrived from Moldavia (via ebay), it worked and gave me video.
I know a couple of you had pointed out this as a possible cause, but I didn't have any 800XLs with it socketed except for the one I was trying to repair. Well, now I do, and that was a good suggestion.
Many thanks to those that helped. I don't entirely get how that little chip with only a few pins and capacitors can be so critical to the system, but here we are. Time to buy a another, or maybe one of the replacement projects.
Success!
-
4
-
-
I've been studying the PAL section of the video circuitry. I managed to find a set of redrawn schematics on the Internet, that included the things changed for PAL systems (which aren't covered by the Service Manual nor the Sams book).
One interesting this is that there is an extra IC! U21 is listed as "not used" in the other books but on a PAL system it is indeed present. It is a 74LS74, which is a "Dual Positive-Edge-Triggered D Flip-Flops with Preset, Clear and Complementary Outputs". I've been looking at the pins of this with the scope.
I don't have a nice chart yet, but to summarize:
On the A half of the thingie, CLK 1 has 3.55 MHz, D1 has 1.77 MHz, and the outputs are 1.77 MHz. Interestingly the inverted output loops back to become D, one of the inputs. So I'm thinking this thing is dividing the frequency on the CLK pin by 2 and outputting a signal at that frequency.
On the B half of the thingie, CLK 2 has 1.77 MHz, D2 has 886 KHz, and the outputs are 886 KHz. CLK 2 comes from the non-inverted output from the A side, Q.
So the overall effect is to take in a 3.55 MHz signal and put out a 886 KHz signal (by dividing by 4). The 355 MHz signal comes from the NTSC circuit, which makes sense as it is the frequency of the other crystal.
This was probably a rabbit hole, as the numbers seem pretty good, but I had a lot of fun figuring it out. I still don't get why they went to the trouble of generating that 886 KHz signal. I see 1.77 MHz all over the place on the board but not that. I also still don't get why Y2 shows 1.77 on one pin and 886 on the other - really didn't think crystal oscillators worked that way - but at least now I can see where the 886 originates!
Oh well, back to the drawing board.
-
4 hours ago, Faicuai said:Check first for any signs of prior desoldering work, if any, and individually test THERE first.
Then, assuming there is a contact failure somewhere, start by pressing (firmly but not crazy, with uniform pressure) with your thumb ALL active components, one by one, in sequence. Press, turn on, wait, then turn off and repeat for the next component. If there is ONE socket where contacts are failing (especially in MoBo) chances are you will find the culprit. If it os more than one, well, that would be a daunting task.
Sadly, no sign of previous work. At first I thought there might have been a couple of jumper wires added but I've since found several pics of PAL 800XL mother boards showing the same jumper wires, so I think they are stock. No puddles of solder, no flux mess...
All chips have been reseated many times. In fact everything socketed has been removed and reinserted, and most of them have been tried in other machines (where they worked fine). This morning I replaced all the RAM chips with some newer RAM chips that I had bought off of ebay and tested. No change. Which makes sense, as I had previously run the original RAM chips through my Arduino-based DRAM tester.
Still black screen, rarely red screen instead.
-
9 hours ago, Mazzspeed said:What sort of scope are you using, is it fast enough to catch the state of reset on boot? The fact it goes high indicates to me that it's not the problem, if it stayed low that would be a problem.
Rigol DS1054Z. It's more a question of operator skill than scope speed here.
-
1
-
-
9 hours ago, Rybags said:Might be normal - you could test by pressing the RESET key after power on (not sure about 1200XL but all other XL/XE OS variants have a software generated delay of a fraction of a second)
I've been off trying people's suggestions, so I'll have a couple of small posts here. Sorry, I couldn't figure out how to put more than one quote in a single post.
For this one, I plugged in a KEYCON, one of the cool toys I bought from tf_hh recently. This allowed me to hit the XL reset key without the keyboard assembly flopping around. I then watched Pin 40 on Sally with a multimeter and powered up. Sure enough, it starts at ground and quickly goes to 5V. It does the same when I hit the KEYCON Reset instead of power cycling. Not sure why I didn't see it on the scope before - operator error I'm sure.
-
4 hours ago, bob1200xl said:Make sure that RESET is working properly. It should go inactive about 1 second or so after power on.
sequence:
Power ON
RESET is active (at ground) and goes inactive (plus)
6502 wakes up and clears all of memory, including the hardware chips (POKEY and such)
Speaker 'pops' meaning init was successful. Video should also reset to nada. Screen should be black.
Bob
I'm not 100% sure what you mean by this. I monitored pin 40 on Sally during boot and it immediately goes to 5V, does not hang out at ground at all. Or is that not what you meant?
-
We have verified that Vcc and GND are at reasonable levels, and that it is getting Phi 2 from Sally as expected. I'm not sure what else to check on it. I probed each of the signal pins (4, 6, 8, 10, 12) and they all have signals but I couldn't tell you if they are correct.
-
Sure. The phi signals look plausible to me but I'm obviously no expert. I saw no big differences between the source and sinks of the various phi signals, just some voltage drop. No open circuits and no frequency changes. But, I can't rule out the voltage drops being too high or the freqs being wrong or whatever, so I logged it all.
Phi 2 source (Sally) 1.77 MHz 2.19V
Phi 2 destinations (ANTIC, GTIA, POKEY, PIA, Delay Line) 1.77 MHz 1.75V on all except Delay Line, which measured 2.19V
Phi 0 source (ANTIC) 1.77 MHz 2.48V
Phi 0 destination (Sally) 1.77 MHz 1.99V
Fast Phi 0 source (GTIA) 3.55 MHz 2.46V
Fast Phi 0 destination (ANTIC) 3.55 MHz 2.42V
Phi 1 source (Sally) 1.77 MHz 1.73V
I'm pulling the frequencies and the voltages from the scope. The voltages are "Avg" after I let is settle for a bit. Obviously Avg isn't all that meaningful when you have signals with a large voltage swing, but it was the best summary number I could find for voltage.
I'm a little surprised to see that GTIA and ANTIC are the sources of two of the clock signals - would not have guessed that. I guess GTIA is actually driving things with "Fast Phi 0" and ANTIC divides it by two and passes that along to Sally? Huh.
I do not know if the frequencies are correct for a PAL 800XL as I haven't been able to find anything like the Sams book for PAL systems. I did find a nice set of reverse engineered schematics that include the PAL circuitry though, so at least I can trace things out. I just don't have example voltages and waveforms. That would be cool.
I'm hoping that posting all this detail will help the next person that needs to debug the same sort of problem. If I had been able to find a thread with this info in it, I'd be reading that and comparing it to my machine rather than doing all this work!
-
1
-
-
The OP is remaining calm and taking it all in. I tested all the voltages and grounds and they seem reasonable. All but two chips were at 5.00-5.04V. Those two were the LM358 and the Hex Buffer CMOS, both of which were at 4.74V. That doesn't seem far off enough to be problematic but I'm still taking it as a possible clue and will revisit if nothing else is found.
The other interesting voltage thing is that very few of the grounds are actually at 0.0 volts. The ground plane is, but most of the chips have mV or 10s of mV on GND. I'm guessing this is because of the discrete components and the traces but am not 100% sure of that.
So now I'm about to dig into the Phi signals as suggested earlier. I ended up making this little chart of chips and pins to use a checklist for the voltage check and updated it to add the Phi stuff. Perhaps someone will find it interesting. All the info is from known sources but I didn't find anywhere it was organized the way I wanted it.
Still having fun!
-
Thanks DrVenkman! That is very helpful. I'll probably spend most of the day doing that after I get some caffeine in me.
That's just the sort of advice I was hoping for - something concrete to try that could help me understand stuff.
I share your views on replacing all of the sockets, and I can assure you that it would be risky. I MIGHT be able to do it but it would be ultra-stressful and it is likely I'd make mistakes. Similar views on things like "replace all the caps" and such.
Rybags, the 74LS138 at U2 got the chip swap test too and seemed fine - didn't break other machine and good one from other machine didn't cause me to start getting video. I'll focus in on the delay line chip - even if I can't swap one in I can certainly measure things.
I've attached a couple of the scope pics I've managed to collect. The procedure isn't great - I'm not all that pleased with Ultra Sigma and UltraScope - but with effort you can get pretty good images.
This is what the signal looks like on the nice side of Y2. It looks pretty clean to me. I haven't been able to coax UltraScope into capturing the Measurement region along with the data area, but this shows a nice clean 225.4 ns sine wave with a mean p2p of 770.8 mV. So that's 4.386 MHz, which seems plausible.
This is what the signal looks like on the other side of Y2. I'm really not sure what I'm seeing here. The other crystal doesn't have a side that looks like this. Measurement indicates that it's a 1.28 us (886.8 KHz) signal at 3.504V. I'm not experienced enough with electronics to understand what this means.
-
The MMU and PIA were two of the many chips I swapped. Both ways - I tried them in a working machine and it still worked, and tried the ones from that machine in this one and it still didn't. The only one I haven't been able to try is the wierd delay line thing because I don't seem to have a machine with that socketed. I've been using a good 800XL for the secondary guinea pig, so no worries on the 1200XL/XEGS front.
I agree that it could be some sort of physical damage but I haven't spotted it any issues with a jeweler's loupe. As for a bad component, maybe? But my life would be better if I had a clue on where to look.
The Y2 crystal still looks suspicious to me. I'm hoping someone will know what it means to have the frequency so far off as sell as different when measured on the individual pins, or at least tell me if these measurements are normal. I have no other PAL systems to compare.
-
I'm trying to fix a PAL 800XL with the black screen of death. Sometimes the red screen instead. I've done the vast majority of things I've seen described in the various threads and youtube videos:
1. Tried all of the chips in other machines - all worked
2. Tested all the memory in my little Arduino DRAM tester - all good
3. Swapped in chips from other machines to see if it would change anything - no effect, aside from some wierdness with putting NTSC/PAL GTIA/ANTIC in the opposite kind of machine
4. Tried different power supplies and monitor cables, that are known good because they work on other 800XLs - no effect
So I've been using various test instruments to dig in deeper. The problem is, I fear my skills and knowledge just aren't at the level required, and the documentation I'm using is aimed more at NTSC systems than PAL. For example, the Sams book describes an NTSC system only.
I picked up a real Frequency Counter on ebay. Low-end and used but not one of the Chinese kits. I've got one of those too but it has limitations that annoyed me, so I sprung for a Simpson 710, which is actually one recommended by Sams (coincidence). When I use it on the Y1 crystal, I get 3.546 MHz, which matches what it says on the can. When I use it on the Y2 crystal, I get 886 KHz, which isn't right. I don't get how that can be - never heard of that kind of failure mode for a crystal, but then again, I'm no expert, that's for sure.
So I dug in deeper. With an oscilloscope I poked around and checked out the various test points in the Sams book. Generally I see frequencies of 1.773 MHz or so, which doesn't match either crystal. The Sams schematics give this in terms of delay. I see delays around 564 nanosec, where I think I should be seeing delays of 0.2 microsec. So .564 instead of .2, which is wrong. The waveforms look plausible but the frequency isn't right. Something seems wrong with time, so I went back to the crystals.
This is the really weird part and what finally drove me to post. When I look at what's going on with Y1, I see ~3.546 MHz on either pin, measured against the ground plane. When I look at what's on Y2, I see ~886 KHz on one pin and 4.386 MHz on the other.
Any of you experts have any insight into what's going on here? I don't understand why or even how a crystal oscillator can have different frequency measurements on the two pins. I've been reading up on them but don't get it yet.
Also, why would my delays and frequencies be so far off of what is shown on the schematic in the Atari 800XL Sams Computerfacts Technical Service book? That's the only place I've found that shows expected voltages and waveforms so I've been leaning on it heavily. But it assumes someone a lot more knowledgeable/experienced than me really.
Any help or advice would be welcome. I just don't seem to have the usual problems with the RAM or OS or BASIC or one of the co-processor chips going bad. Something odd here and I'd like to understand it, and perhaps eventually fix it. I've seen several of the elder statesmen mention that if they had a scope they'd go deeper and do things differently, so I'm hoping for some info on just what that means.
-
My Sys-Check v2.2 XL has arrived! Along with the KEYCONs I ordered. Yay! So they shipped on 2/6/21 and got here on 2/22/21. Not the fastest trip ever, but it could have been a lot worse, given COVID and the current issues with weather in the US.
Oh yes, it works.
Thanks, tf_hh! I have no complaints. Happy customer.
-
1
-
-
I find it interesting that they both got sent to big USPS hubs in NY. So yes, they both have to get past the storms to get to me.
-
Signs of movement! The USPS admits to having taken possession of my shipment. It appears to currently be sitting in "ISC NEW YORK NY(USPS) " in New York, NY. Amusingly, I ordered a couple video cables from Canada a couple days before my order with Jurgen, and they too just arrived at a different USPS regional facility, also in NY: "JAMAICA NY INTERNATIONAL DISTRIBUTION CENTER ".
The race is on! I'm really looking forward to the Sys-Check XL in particular, as I've got a couple of dead A8s I've been working on.
Oh, perhaps more relevant to this thread, I mainly wanted to confirm that the tracking method I mentioned earlier seems legit - my stuff started with Deutsche Post, went to DHL Paket for a little siesta, then was handed off to USPS, just as DHL claimed. So the thing where it was supposed to go to USPS but no useful info showed on their site yet was... fine, and correct.
FYI I'm in SoCal, so I expect this will still take a couple days, due the weather issues in the US. Depends on how they route it I guess.
-
I built one (well actually two) of the DRAM Arduino testers xrbrevin posted about above. I thought others might enjoy my little adventure, so I took a few pictures and here we are. I don't have a youtube channel or anything but I've been trying to fix a number of sick A8s recently, and bad memory is apparently the number one cause of various ailments. So I thought it was worth the effort to gain the capability to test DRAMs in the comfort of my home, and that others might be interested in the results.
The first build used an Arduino UNO and a breadboard. It works fine and I still have it set up for now, but will at some point tear it down to reclaim the ZIF socket.
Both images show a test of a bad 41256 chip. It was identified as being bad using this very tester. This came out because I bought a used 800XL with a RAMBO 256K upgrade that was reporting errors, and I kind of got obsessed. Anyway, you get a green light blinking while testing. If the test passes without errors, it turns solid green. If any errors are found, it turns solid red. The wire I'm holding is what I'm using to switch between 4164 and 41256 mode - I have to close a circuit to put it in 4164 mode. I didn't have an appropriate switch when I started this project.
Also you can see that my fingers are about the size and shape of moderate-sized sausages. This made the second build far more challenging than originally expected. Now I know better, and hope to never attempt such a thing again.
The second build used an Arduino UNO and a Gikfun prototype board. So now I have an Arduino shield that tests Atari RAM. Woo hoo!
This image shows the shield version testing the same chip. Note that it is lying! This chip is known bad! What happened is that I wired in a switch to select 4164 or 41256 mode, as selected by the original creator of the tester. Up is 4164, down is 41256. If you test a 256K chip using 64K mode, it only checks the first 64K... So here is truth:
Note that switch is properly set now.
The other thing I wanted to show, in case you may be thinking of making one of these, is this:
Oh My God it was painful to make this! I'm sure at least part of that is due to my inexperience at soldering in close quarters like this, and part of it is certainly due to my fat fingers, but still, you have to get a lot of wires and a few components just right. This is not the most elegant proto board job ever, I'm sure. You can zoom in on the other pics to see the other side of the board. I imagine some of the pros are laughing at me right now.
It probably took a half hour or so to wire up the breadboard version. It's really not bad at all if you have the parts. I got it working without the ZIF socket initially because mine were on order, and it worked fine that way, but I hate socketing/removing chips like that - too risky.
Making the shield version took hours. I found it quite stressful. If you are a lot more experienced with this, maybe it won't be so bad for you? I've done a lot of casual soldering and built some kits and such, but there is a vast difference between sticking components in clearly labeled holes with the appropriate ground and power buses already set up and all the vias already in the right places and no extra stuff in the way, and this. I bet I spent over an hour just agonizing over how I wanted to handle the switch!
Still, it was worth it. The shield version should be a lot more robust, and I expect it will get plenty of use over time.
The pictures were resized to 10% because my phone produces these beautiful 6MB pictures and I didn't want to blow up the forum. Hopefully this was an okay balance between size and visibility of detail. I'm sure someone will tell me if they were too big, or I did something wrong with forum etiquette, or whatever.
-
2
-
-
Jurgen, sorry to hear you are having issues with a customer. My stuff isn't here yet but I'm prepared to wait patiently - I know your stuff is very high quality and all of my interactions with you have been great. You are not responsible for COVID and the various shipping companies, obviously!
I'm actually writing this because I learned something about tracking today, and I only went looking because of this thread. Like others, I started getting the status from Deutsche Post that it had been handed off to someone not named and I might be able to get status from them. This thread made me think that might not be a dead end. Sure enough, I put my tracking number in on this site:
https://www.parcelmonitor.com/track-it-online/
and they were able to show that my parcel has been handed off to DHL. DHL Paket says it's in an "Export Parcel Center" in Hamburg.
Alles Gut! Haben einen schönen Tag!
I also put my tracking number in on the USPS site, and got about the same results as Krenath, even though I already know (or at least believe) that DHL has my package. I do not know how to interpret that, but I'm just happy knowing where my stuff is at the moment (in Frankfurt, soon to be handed over to the carrier for the next stage of its journey).
-
2
-
-
I was trying to disassemble a file I found on a disk I was exploring, and got some weird behavior in dis6502. I'm using the official release of 3.6, as far as I can tell. It's 884,224 bytes long and I've been using it for a while now.
The target file I'm looking at contains a bunch of small segments. I don't know why the author did it this way - suspect intentional obfuscation aimed at reverse engineers. It looks like a valid file though. It isn't large so I attached it (AUTORUN.SYS).
When I drag it into dis6502, it generates many tiny segments, which I believe to be correct. Len of a segment is typically $18 or $17. The reason I'm writing this is that when I right click a segment and select "Merge contiguous segments", I get a dialog box "Exception occurred in MainWndProc" with text "Segment index out of range". It doesn't matter which segment I select. Also, once this happens, selection of ANY segment, including the innocuous one at the end that just sets INITAD, yields the same dialog box and error message. So this bug leaves dis6502 in an unhappy state.
Looking at the file with a hex editor, it really seemed fine, so I wrote a small python script to combine the mini-segments. It worked, which both
proves the validity of the file and let me load it into dis6502 in usable form. I attached the output of my script as well - two segment files that add up to content equivalent to AUTORUN.SYS (seg.1 and seg.2). Those load fine, but I seem to remember older versions of dis6502 being able to do the merging without an external tool. If you load them both into a single dis6502 instance, what you get is logically equivalent to what you get if AUTORUN.SYS is loaded but without the cruft, which allows for a much nicer disassembly.
So I'm not stuck, I just wanted to report the bug. I don't see it on the list in dis6502.txt.
I spent some time getting 3.6 to build under VS2019, and made a version that doesn't need the XP junk, but feel like that's not useful to the community as the actual authors are already working on a beta of 4.0. So I will spare you my adventures with visual studio and just stick to the little bug report.
If I'm doing something wrong or violated some sort of atariage.com norm, I'm sure I will be duly informed.
-
1
-
-
Decided to add a working example SD card image. Chances are, if you have SIDE 3 you are into the A8 enough to not NEED this because you already have an Sdrive-MAX or a SIO2USB or something like that, but this provides an example of a working image and a way to get things from a PC or whatever to an APT partition without having to hook up additional hardware. The files on the FAT partition provide a little more info.
It was created using Win32DiskImager on a 2GB SD card, then zipped because I didn't think anyone would want me to upload a 2GB file.
More info in the README.txt.
-
1
-
-
drac030, that all makes sense. Thanks.
-
Entry - 750000. The 800XL shown is a recent addition to my collection, which includes multiple 800s, a 130XE, and a XEGS. I regret getting rid of my 1200XL and ATR8000 during a financial crisis something like 20 years ago but here we are.
-
1
-
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
800XL video March 2021
in Atari 8-Bit Computers
Posted
I've been messing with the settings on the JVC all along. I don't think that one is going to get any better. I managed to find the remote for the Toshiba so I could check the settings on that - sure enough, contrast was way up so I put it back to neutral. Not sure how that happened - no external picture controls exist on that monitor and it sat unused for a couple years. /shrug
So that mitigated the problem but did not make it go away entirely. I also installed the nasty resistor mod, where you have to drape a 1K resistor between two components over several others, and managed to do it without making any shorts. Really not fond of that one. The SV article says "This resistor provides negative feedback around the color amplifier Q2-Q4-Q5. The effect is subtle, but it improves saturation a little and reduces color shadows somewhat.", which sounds about right. Subtle effect at best. It didn't seem to do a lot. I also did the capacitor C50 value upgrade earlier (10 uF -> 100 uF), to no visible effect. That one was supposed to "restore AC filtration lost by removal of L5". Maybe it did but I don't think I had that particular problem. I'll almost certainly skip those two in the future.
Thanks for the suggestions, I tried all.
I also tried the SIDE 3 cart on a 130XE with stock video, and got basically the same effect. I'm thinking this is just the way it is. Most things look really good, I just get weird effects with that selection bar - it warps the selected line just a little for some reason. Looking really closely I can see it's actually shifting the whole line a little - I just noticed the edges first because they are normally straight and it adds bends. I used the color option in the cart to try some of the other palettes and still got the same effect.
As I was working on this post I thought to see if there is a similar effect on an Ultimate cart. There is! It's not as obvious because there is no right hand border on the menus, but if you look closely the whole line that is selected shifts right a little. On the very bottom line, the one with the down arrow on the right, that arrow also shifts. So it isn't just SIDE 3. Even if it was, this isn't a bug report, just an exploration of a bit of weirdness. That was the only other program I could think of with a long cursor like that, and sure enough... It's like that entry in the display list is shifted a couple of pixel clocks or something.
I'll probably just go ahead and install my Ultimate 1MB. This is the 800XL I wanted to put it in to start with.
In summary, I'm pretty convinced this isn't actually a video problem, which is good as I have nothing left to try.