Urchlay
-
Content Count
1,213 -
Joined
-
Last visited
Posts posted by Urchlay
-
-
I must agree that this sounds like a RAM problem. Selective cartridge failure can be attributed to how that cart program operates when there is an absence of RAM after $3FFF.You mean Martin72's problem, not mine? 'Cause in my case, if the game's using the extra RAM, it wouldn't keep playing (with minor graphics glitches), it would die...
My first Atari was a 600XL with the memory expander module (back in 1985). After a number of years of use and transporting I would occasionally encounter a bad connection between the computer and module. This resulted in the absence of the extra RAM.Regardless of the type of memory upgrade you have, suggest using the in-built self test function
With the internal memory upgrade, you actually remove the original pair of 16Kx4 chips and replace them with 64Kx4s. So they're "all or nothing", you won't encounter a failure condition where the new/extra RAM disappears but the old remains... I suppose a cold solder joint could intermittently cause part of the address space to not be decoded correctly, but I've left it in self-test before and let it run for a couple of hours, never saw a red block appear. Also, disk software that requires 48K or 64K never fails... for that matter, I've done a bit of tinkering with BASIC on this machine. If the upper RAM disappeared while in standard GR.0, the display would go haywire (since the display list and screen RAM are located just below $A000). This hasn't ever happened... I'd assume a bad solder joint wouldn't only cause problems with one cart, and in fact the same version of Millipede plays fine when loaded from disk. (Actually it's not *exactly* the same: it needed 3 or 4 STA's that write to the cart address space switched to LDA's, to keep it from self-destructing when loaded into RAM. I doubt these are the source of my problem, though: Pac-Man contains similar self-destruct code, but my Pac-Man cart works fine).
Instead of loading the register and then manipulating the appropriate bit(s), the author loaded the accumulator with a specific byte and stored it into $D301. From memory there was one or two bits set to zero that should have been set to on.Ouch! So it did something like enable the Missile Command ROM? I'd never even thought of that as a source of incompatibility for the XEGS, it'd probably drive me insane too...
-
600XLs have 16K ram by default and can be updated internally or externally to have more.We both have internal 64K upgrades... I did mine with a pair of 64Kx4 RAM chips from an old ISA video card.
In the Atari 600XL (internally updated to 64k) the beginscreen of the "Donkey Kong Junior" game starts up normally but when i start the game the screen seems to be freezed and nothing happens anymore.The same happens at both of cartridges, but in the 65XE or 130XE they work fine. So i think there is a small difference in the layout of the pcb of the grey cartridges with grey label or something else (or there's a little difference in the 600XL).
But i understand you have a comparable problem with the grey Millipede cartridge.
By the way it is not at all grey cartridges: my grey moonpatrol cartridge works fine in the 600XL also the XE-blue-label grey 64 k cartridges (like Mario Bros).
Wait, the same thing happens with both carts (brown and grey Donkey Kong Jr), or just the grey one?
When the problem with the Millipede cart first came up, someone suggested it might be a bad capacitor inside the cart... and someone else suggested it might be that the replacement RAM chips have different timing than the originals (too bad I never tried Millipede on the 600XL before upgrading it). I packed up everything I own and moved not long after that, and the 600XL was in storage until 2 weeks ago... and now I can't find the Millipede cart. When/if I do find it again, I was going to see if I could either replace the cap inside the cart, or swap ROMs with a working cart (assuming the ROMs are socketed in the grey carts like they were in the brown ones).
Also I've got 6 more 64Kx4 RAMs if I can find them, was going to try swapping those into the 600XL... though I doubt it'll change anything: all 8 chips came from the same ISA super VGA card, they should be identical. Also everything else I've tried works great on that 600XL, including a BASIC XL cart (if something were wrong with the cart port, I'd expect a bankswitching cart to fail).
Another thing I might try: burn an EPROM of the Millipede code and see if that works in the cart.
Do you (or anyone) know whether the grey Atari carts are socketed?
-
Press Escape, then shift and the Clear key (the shifted version of the less-than symbol). It'll print kind of an inverse video bent arrow that points up and to the left. If you don't press Escape first, it'll clear the screen when you type it.
You could also print CHR$(125) in a BASIC program.
-
What exactly happens with the grey cart in the 600XL? Black screen, or the game plays with garbage on the screen, or what?
I've got a 64K upgraded 600XL and a grey Millipede cart... the cart works fine on my XEGS and 800, but not on the 64K 600XL. I get extra pixels on the screen, the same color as the mushrooms. The game is actually playable (the extra pixels don't seem to trigger collision detection). All my other carts work fine on the 600XL... and Millipede plays fine when loaded from disk. So, like you, I think something weird is going on inside the cartridge.
-
Most of the other home computers of the time (like the Apple) use Microsoft BASIC, which IIRC always adds a space when there's a semicolon in a PRINT statement... the Atari's BASIC doesn't do that, so probably you should edit the line where you removed the semicolon, and add ;" "; (semicolon, quote, space, quote, semicolon) to get the Atari to behave more like an Apple. The BASIC revision (A, B, C) doesn't matter: The language didn't change between the different versions, they just fixed bugs. If you're using revision A there's a small chance of BASIC crashing for no apparent reason, if you're using B there's a much larger chance, and if you're using C it should never crash for no reason (you can still crash it by e.g. POKE to the wrong place, but that'd be your fault, not BASIC's)
Alternatively, you could run the programs in Atari Microsoft BASIC (available as disk [image] or cartridge). Most likely they'd run correctly as listed in the book.
I've actually never heard of the Micro-Adventure book series... if they're books full of type-in programs, would you consider posting your typed-in versions here (on an ATR image or single SAVEd BASIC files), once you've got them debugged?
-
AFAIK, all programs [*] that use the Rtime8 do so via the Z: device driver... so you ought to be able to use whatever chip you want, provided you write a Z: handler for it that does the same stuff (presents the same API) as the Rtime8 one does.
[*] All programs except the Z: driver itself!
-
The keyboards have the extra switches because they are identical to the 65/130/800 XE. As the XE was released in '85 it is not a surprise that Atari may have used older keyboards, or, they have been replaced with other keyboards over the last 20 odd years.Hmmm, do all XEGS keyboards have contact points for Start/Select/etc keys? And do they actually work, if you short them? Seems like adding buttons for the console keys would be a good mod for the XEGS keyboard... I might have to disassemble mine and see if it's possible.
-
Clearly some quality woodwork... but did you have to crown it with a commiedor monitor?
What else was he supposed to do? Atari never made us a monitor for the 8-bits...
-
I'd really be impressed by a software solution. I agree that would be an ideal approach except for maybe the hastle of having to load a program everytime you switch back and forth. Once I isolate the interference problem I hope to eliminate the need for a switch altogether.Hmm. With software, you can map the keys how you want... so what'd be the ideal key layout for using an Atari as a PC keyboard? You'd want to be able to send every keystroke the PC keyboard can... I suppose you'd use the console keys, one for Alt, and one for a modifier (e.g. pressing Select + numbers sends F-keys, Select + brackets sends curly braces). The 1200XL's F-keys should map to the PC's F1 through F4... the Atari Break key should map to the PC Pause/Break... if running on a 1200XL, the LEDs could be indicators for caps/scroll lock...
Something like Select + left/right/up/down (aka + * - =) could be Home/End/PageUp/PageDown. The CX-85 keys could be either arrows or numbers, with some key mapped as Numlock. The joystick could be used as a simulated PC mouse, or send arrow keys + return.
The coolest way to interface it would be to use an SIO2PC-like device that connects to the PC's PS/2 keyboard port (or to a PS/2 => USB adaptor), and just have the Atari speak PC keyboard protocol (which is serial, similar to RS232, but using 0 and +5V). You wouldn't even need a driver on the PC side, and it'd work with any OS (even in the BIOS menu). I'm not a hardware designer really, not entirely sure what'd be necessary... AFAIK the only reason an SIO2PC needs a max232 or 1489 chip is to convert from the Atari's 0/5V logic levels to the RS232 positive & negative voltages... does this mean you just need a cable with an SIO plug on one end and a PS/2 mini-DIN on the other end?
I'd say the Atari key layout should be kept (e.g. shift-2 for double-quote)...
Hm, it wouldn't be hard to write the Atari code for this, if I knew what'd be needed for the hardware interface. Anyone know?
-
I did the following and it turned out great on my 1200XL:Remove L15 and replace with a wire.
Remove C60 and replace with *nothing*.
I also connected the missing chroma line at R45.
This mod gave me excellent Chroma/Luma; and pretty good composite. I would say that this mod produces video that is at least as good as a stock XE -- maybe a little better. (IMO) It is not quite as good to my eye as Clearpic 2002, but close, and at least by comparison to other video mods, is very easy.
We need a name to differentiate this -- what should we call it (anyone)?
Easyvideo 1.0 (or 2008)?
I wish I'd known about this before doing a clearpic mod on my 1200XL... Eventually I got it working, but it took 2-3 days of soldering, sweating, and cursing.
BTW, the reason my clearpic was so difficult to do was that I found out (after I started) that my 1200XL motherboard didn't match the description in the clearpic article. Apparently there are at least 2 1200XL motherboard revisions with slightly different video. I can't remember specifics now, but it seems like the directions said to replace a cap with a resistor... but on my board there was no part at the marked location. A couple of other parts were different from what was expected, too...
So we should try to find out whether your new mod is universal, or only applies to one or the other revision... and how to tell the difference between the two revs.
-
I recall using the 'freezer' for making those bandit boulderdash files and a few other things, quite a useful program that was/is! Speaking of boulderdash, I only noticed the other week that only half of my boulderdash screens were ever uploaded into bandit boulderdash files, I wouldn't mind getting hold of all my screens again, but the only person I know who has them is john e., and his atari is up the attic! Shame.You're the Bandit Boulderdash guy? I owe you one... I know a girl who's a huge Boulderdash fan. Last christmas, I gave her a CD with an emulator and all the boulderdash variants I could find, including the Bandits ones. Her eyes lit up like, well, a christmas tree... said it was the best gift she's ever gotten.
-
Nice-looking icons.
A couple of thoughts...
It might be nice if the icons were done in 64x64, using the color palette from one of the Atari emulators. They can always be scaled down and/or converted to the 16-color windows palette later. You could offer zip files of the large, hi-color ones or the small 16-color ones (which would be automatically generated from the full size/color ones. I'd probably use a perl script, but any language would do).
What's really needed is a database of games, with md5 or whatever kind of checksums, and a script/program that reads all your emulator files and automatically assigns the icons based on the checksums. Not being a windows programmer (or even user), I don't know what you'd use for this (presumably icon assignments are stored in the windows registry, but then vista has done away with the registry or something). The database would need all the variants of each game floating around out there on the net (xex/atr/rom file versions, plus the various cracked copies).
Out of curiosity... how are you making these? Drawing them by hand, or taking screenshots of an emulator and copying a 32x32 area out, then doing palette conversions and rounded corners?
-
And I can't remember the name of the monitor that I got. For some reason, the brand name "Texas Citrus" sticks in my mind, but I don't know if that is correct. Texas was definitely in the name, which I know doesn't narrow down the name much.Texas Instruments? (Did they make monitors?)
-
Ugh. Who wants to pay long distance charges to call a BBS?
Maybe there's a way to allow both telnet and real modems? Is there any A8 BBS software that supports multiple lines, so you could e.g. use an 850 (4 serial ports), with a modem on one port and a terminal server box (or PC + SIO2PC) on one or more of the other ports? Metalguy is right, if you limit yourself to modem users only, you won't get much traffic.
-
Control is where Capslock should be.Debatable. Until IBM came out with the AT keyboard in the late 1980s, pretty much all computers and terminals had the control key next to the A key. To my way of thinking, the modern PC and Mac keyboards have capslock where control should be (but I remap them in software, so no problem).
In conclusion, I don't look forward to doing BASIC type-ins.Actually the key layout you'll get used to pretty quick... but the XE and XEGS keyboards have almost no tactile feedback (they have a spongy feel, like typing on overcooked noodles). If you're going to do a lot of typing on an Atari, I recommend getting an 800, 1200XL, or 800XL (in order of best keyboard feel). Of course "best keyboard" is a completely subjective thing, others will disagree, and there's no right or wrong...
-
I'm somewhere between mad and laughing right now!!!!!! .......and I'm really mad that I threw it away!! Grrrrr....I was in a bad mood that night! I really did hook it up to my XEGS and tried to start a tape, but I wasn't real persistent! I probably should've given myself a few days to chill out!The annoying thing is, most people selling Atari tape drives don't know that either, so they don't test them properly...
Odds are any 410 you buy won't work, unless it's from a seller who really knows what they're doing. The 410's drive belt goes around a tiny pulley, and if the drive sits unused for a few years, the belt develops a kink at that pulley. You can replace the belt (search this forum for "410 drive belt" for details), but any random 1010 probably has a better chance of working as-is, and an XC11 or XC12 might be a safer bet (just because they're newer).
-
ok, so Bob is referring to the cable? If I want to use s-video I just do the mod and use my s-vid cable?I don't know what kind of cable you have.
If your cable has separate chroma, luma, and composite outputs, then you can use it. If it doesn't (if it has only chroma and luma), you'll have to rewire it so the chroma on the monitor end connects to the composite on the Atari end.
If none of this makes any sense at all, I suggest you get someone else to do the mod and wire up the cable... I don't mean to sound rude, but you'd stand a good chance of breaking something.
-
Use Composite for Chroma and Luma for LumaCould you explain this for idiots please
Normally, for s-video, you connect the Atari's chroma output to the monitor's chroma input, and the Atari's luma output to the monitor's luma input.
He's saying, connect the luma normally, and connect the Atari's composite output to the monitor's chroma input (you do this by making a custom cable).
Make sense now?
-
Ugh. If I'd known it would start such a $#!+storm, I'd never have suggested torrents...
As far as the potential virus thing goes... what is it, a DOS keygen for an ancient piece of software? Probably should just remove it. Likely it wouldn't be useful to anyone in 2008 even if it weren't infected.
-
I was one of the people who loathed typing in programs... Anything longer than a page or so, or anything all in hex or DATA statements, I wouldn't even try. I missed out on some good stuff due to that, but it wasn't a total loss: it meant I had more time to spend working on my own programs. Also, later on when I had a modem, found a couple BBSes that had a lot of the type-ins for download.
Back then I always wondered why magazines couldn't print the programs in machine-readable form, and sell a device like a barcode reader to read them with. I guess it would have been a short-lived thing, obsoleted when the mags started offering floppy disks with all the programs on them.
-
Mine was an Atari 400, xmas morning, either 1980 or 81. It wasn't really a computer yet though, didn't come with BASIC or any other language, or any storage. Can't remember how long I had to wait before Dad sprung for the BASIC cart and 410. At least I got to play Pac-man and Star Raiders while I waited
-
so which file format is best for this? The standard zip or a rar? I've never created a torrent before, but I have the .zip of 1 and 3. 2 says it will be ready by tomorrow morning according to my download manager.If I were making the torrent, I'd use the zip files, exactly as downloaded from langesite. That way, people who have already downloaded them can help seed the torrent right away, instead of waiting for their torrent client to (re)download the same files packed in a different format.
-
So... the torrent is still up? Am trying to seed, but no peers are downloading from me.
-
Hm, what about Hard Hat Willy?
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
Atari cartridges differences
in Atari 8-Bit Computers
Posted
Yah, I know just enough to know there are lots of things that can go wrong. Nonstandard cart works in standard machines, standard carts work in nonstandard machines... but the weirdness in the cart and the weirdness in the 600XL happen to interact in a way that's noticeable.
Sadly, I am my own local tech. I can just about follow a set of directions... I can troubleshoot simple things, but I don't even know where to start with this.
Well, I do know where to start with the cart (replace the ROM with an EPROM, and/or get another Millipede cart, see what it does), but not the 600XL. I can usually fix the ones that don't work at all, but this is much more subtle.