Urchlay

I've always been interested in the idea of semi-random music... say, you come up with a structure for your tune (distinct verse, chorus, bridge, etc), each piece of which has a chord progression, so the overall tune is made of a pretty long set of chord changes. Then you come up with several rhythm/bass patterns for each progression that follow the chords, and all sound OK no matter what order you play them in (so long as the pattern you're playing is for the current chord in the progression)... Each time through the tune, for each measure (or for each group of 4-8 measures?), you pick a random rhythm pattern that matches the chords that belong there... maybe not completely random, or it wouldn't sound like a coherent rhythm, but the idea is that you come up with enough variations on the theme that it sounds improvised instead of being exactly the same each time. Some of the patterns will be almost identical, with different fills/breaks, and some will be radically different... ... then come up with a whole bunch of lead phrases that just stay in the same key as the song, and play them over the rhythm, also in random order. You could maybe group the lead phrases into categories ("fast scales", "arpeggios", "bent half notes", "counterpoint", etc), and play only lead patterns from one category each time through the overall tune structure, so each repetition has a different "feel". I think this would lead to music that sounds less computer-generated... Of course, it'll never come close to a real blues or jazz jam by humans... In case you can't tell, this isn't a fully worked-out idea yet I think this is close to how the A8/5200 Ballblazer music works, though I haven't disassembled the code to find out for sure. If it ever truly repeats, it takes a really long time to do it.

I'm looking for a an NTSC 1200XL (or possibly an 800XL) with: - At least 256K of RAM - Clearpic/Supervideo mod, with working chroma output - 32-in-1 or other switchable multi-OS upgrade - If it's an 800XL, no internal BASIC (or BASIC disabled by default at boot) - Possibly an internal SIO2PC I'm looking for someone who will either sell me such a machine, or who will mod the 1200XL I currently have. I realize this is not going to be cheap at all, but if I ever want to own an "uber Atari" like this, I'll have to spend the money: I can't do the mods myself. I don't even know how much to offer, so anyone interested can basically name their price (I'm not made of money, of course, but I'm not trying to get something for nothing either). Any takers?

Well, I ended doing this mod: http://sog.com/atarimods/1200xl-vm.html ...because Slor recommended it to me, and because I was able to do it with the parts I had on hand. Edit: whining removed. Sorry for subjecting everyone to that.

I'm pretty sure what you're talking about is his attempt to re-image Atari as a "serious" computer company. I've read that when he first got to Atari, the first thing he did was kill all video game development, and fired the developers that only had video game experience (the rest of them were instructed to start working on the ST operating system, or whatever currently computer project was going on). That "black heart" stuff is kind of unfair... I'm not a fan of his business policies, but I can forgive the guy a lot: he grew up in a concentration camp. He lived through 10 years of man-made hell on earth, and survived to make something of his life. The 7800 was first developed in '84. It's possible that in an alternate universe, Warner would have killed the 2600 in favor of the 7800... we would have had hundreds of 7800 titles, and if successful, there could have been a successor to the 7800, which would have been the system the kids all played in the 80s, instead of the NES... and if it had been backwards compatible with the 7800 and the 2600, well, how cool would that be?

The Pitfall II theme does rock... but damn, it gets repetitive. I played with my brother not long ago (him actually playing, me trying to remember where everything is on the map), and after half an hour we're both ready to turn off the sound, but each one of us thinks the other likes it, so we didn't for another half hour. It's too bad there's no in-game option to turn the music off while leaving the rest of the sound effects on. I guess that's sacrilege to some people, but after a while, the opening notes of the slow music (when I get killed) make me want to throw the joystick at the TV.

You guys are making me think about porting Stella's debugger to ProSystem, or porting ProSystem's emulation core to Stella... how cool would that be?

Try "export TERM=ansi" before running lynx. If this works, you can set the term type in /etc/inittab (should be the last parameter to getty/agetty/uugetty). I've got a DEC VT220 terminal, so I use this: s1:12345:respawn:/sbin/agetty -L ttyS0 19200 vt220 For an ANSI terminal, just change the "vt220" to "ansi".

I really wish I could run this on real hardware... the emulator never looks anything like the real thing for stuff like this Yep. Try my color scheme. You can get more colors, but I wanted a pure gray/white. Mine uses GR.0 characters, with quad-width player/missile overlays (one quad P/M pixel = 4 clocks = 1 GR.0 character). It turns out that the GR.0 foreground pixels are displayed with the same hue as *whatever* background is behind them (either color register 2 or a player/missile), so I can only get e.g. pink on dark red, or dark red on pink (inverse video), never red on white or white on red. I had the idea to use GR.8 with 3 fonts (normal, artifacted red, artifacted green) plus P/M overlays, but I never was able to draw artifacted characters that looked good to me (which could just be my own lack of imagination).

Well, pretty soon I'm going to have at least a 256K XL, until then I can only run it in the emulator I can't tell from the screen shot... how are you doing 4 colors per frame? GR.0/GR.8 with artifacting, or GR.15 with 4-pixel-wide fonts? Cool. That might also look good. I'll clean it up and post it here... right now it has some fugly default colors, left over from my experimenting with it. I did a 2-frame version, with red and green only. Was able to get 4 foreground colors this way with almost no visible flicker, but they were white, pink, green, and orange (no way to get blue, and I couldn't find a way to get a proper red without eye-boggling flicker).

How about CAT, or CTTY (for Color Teletype, pronounced "kitty")? Or Cat-Term (Color Ansi Teletype Terminal) if you want to incorporate the word "term". By extended, do you mean it uses the RAM under the OS on an XL, or that it requires a 130XE or greater? Yet another reason I need a bigger Atari... Do you accomplish this by flickering red/green/blue every 3 frames? I wrote a crappy little demo that does this, was planning to turn it into a color ANSI term... guess someone beat me to it

Hey, that's pretty cool... That's a 130XE? What terminal program is that?

Basic XE is an OSS "super" cart, has its own internal bankswitching and can disable itself, if I recall correctly. There might be a way to install it internally, but it'd be a lot more involved than just replacing the ROM chip... you'd have to talk to someone who knows what they're talking about (someone not me) I bet he was wanting to know about extra RAM banks (above 64K), which standard Atari BASIC can't help you with. BTW, I like your new avatar... how much did you have to pay that atarinoob guy for his rare find?

I remember an Insight:Atari column that talked about another bug in Rev. B... Every time you'd SAVE a program, it'd grow by 16 bytes. Next time you LOAD it, and SAVE it again (without even modifying it), it'd grow another 16 bytes... This was never a problem for me (the lockup bug was a lot more annoying), but the extra waste bytes in the tokenized BASIC file could be gotten rid of like so: LOAD "D:PROG.BAS" LIST "D:PROG.LST" NEW ENTER "D:PROG.LST" SAVE "D:PROG.BAS" Unfortunately, the lockup bug could occur during the ENTER: every time you add a line to a program in Rev. B BASIC, whether by typing or by reading it in with ENTER, you run the risk of lockup. Still, if it did happen, you could reboot and ENTER "D:PROG.LST" again and it'd generally work. There's also at least one revision of BASIC that will crash if you type INPUT and press enter (without a variable name). Can't remember whether the Reset key would get you out of that one or not.

Hm, I'll give that a shot. I suppose in that case I don't even have to remove the parts in those positions, just short around them?

Like I said, I don't know whether all 1200XLs are like mine or not... but my 1200XL looks hideous on both monitors I've tried it with, and on a TV. It might be that I'm just too picky about video quality, and that most people would either not notice or not be bothered by the way my 1200 looks.

Apparently so... 4 of them. I'm looking at the Clearpic 2002: http://www.retrobits.net/atari/clearpic.shtml Unfortunately I don't know enough to be able to tell why, or how much it would affect the circuit to replace them with a different value. I have a bunch of small 10 ohm resistors, could twist 3 of them together to get 3.33 ohms... but I have no idea whether it'd work or not.

What ever happened to the X-Wing/Tie Fighter series of PC games? I always thought of those as the descendents of Star Raiders... If Star Raiders were released today, with modern-style 3d graphics, hmm... someone should try it and see?

Hm, upon further reading, I think I'm going with the clearpic instead of the supervideo. The supervideo page says it's more concerned with bright, vivid colors, while allowing some ghosting... and it's the ghosting I'm trying to get rid of. I've located all the parts I need (in my stash, and in Dad's much bigger stash), but the 1 ohm resistors I have are huge ceramic high-wattage packages, over an inch long, which will be a pain to use. Are low-wattage/small-package 1 ohm resistors hard to come by?

Did you compare them side-by-side? Did you compare using the same TV/monitor and cables? Were you using TVs, composite, or S-video? There are a lot of variables that can affect the video quality... if you were using a crappy TV, the quality would be crappy on both machines... Also, I have no idea if the ghosting problem shows up on all 1200XLs, or just some of them, or whether it's worse on mine than other 1200XLs... I've only got one 1200XL, and I've only ever seen one other one in my life (and that was 15+ years ago, can't remember how it looked). Thats is usually caused by either the switch box or the TV but in your case you are using a monitor so I am not sure what the problem might be unless your monitor is on its way out If the monitor were dying, it would have the same problem with the 800... but it doesn't: the 800 picture is beautiful, no ghosting, no smearing. I'm using the same monitor cables for both, and the same monitor, so the difference has to be in the computers themselves. If you follow the Super Pic link Steve posted ( http://sog.com/atarimods/supervid5.html ), it has some information on the ghosting effect, and an explanation of the differences between the 800 and 1200XL video circuitry...

Actually it doesn't look like it'd be any harder than the clearpic... maybe a couple more components, but the directions are step-by-step instead of just a list of parts and board locations. I suck at soldering, but assuming I'm going to do it anyway, I might as well pick the mod with the best output... so this one's better than the clearpic, then? ...wonder why Atari screwed up so bad with the 1200XL video? The 800 is gorgeous... and the whole selling point of the Atari machines was how great the graphics are. You'd think they'd have given a little more thought to the design...

Ehhh... guess I wasn't being clear in my post. I'm using a monitor cable I've made. Actually, I've made two of them (one composite-only and one s-video only). Both work great on my 800, with no image ghosting or interference. The 1200XL, using either of the same cables with the same monitor, has horrible ghosting. Until I did the one-wire chroma mod on the 1200XL (about an hour ago), I couldn't use the 1200XL with s-video (no chroma signal)... but the s-video output has the same ghosting as the composite. At least I didn't break anything: the image looks the same through composite now as it did before I soldered the chroma wire (just as bad, but no worse). I just don't want to do the full clearpic mod (ordering parts, checking the mail compulsively for a week, spending an afternoon burning myself on a soldering iron, then the evening finding which of my crappy solder joints are bad), only to find out that it doesn't fix the ghosting problem. Was hoping someone could tell me for sure.

I have a 1200XL I haven't messed with in a while due to its horrible video quality. Hooked it up for the first time in a month or so today, to play Flowers Mania (good game, BTW, won't run on my 800 though). The video is just as awful as I remember it... I noticed a ghost/shadow image to the right of the real image, offset by 4 color clocks. I can see this with the BASIC cart in: white on blue READY prompt, with white cursor. Each of the letters and the cursor has a black "drop-shadow" to the right, in very dark blue. It's especially noticeable next to the Y and the cursor. Also, at the place where the left-hand black border meets the blue background, I see a greyish vertical stripe, the height of the screen, 4 clocks wide, like a shadow of the black border on the right of it (overlaying the blue). I played a few different games on the 1200XL today, and they all exhibit the same problem. Is this a common problem on the 1200XL, and can it be fixed easily? By "easily" I mean something that doesn't require ordering parts and waiting for them to get here (e.g. can I do it by removing some parts, or shorting around them, or something?) I know about the clearpic mod, but I don't know if it will fix this particular problem or not... I tried soldering a wire from R44 to the chroma pin on the monitor jack, as someone recommended in this forum, and it does indeed give me S-video output... but it still has the annoying shadows, and doesn't look much better than composite. Anyone have any experience with this?

Of course not, silly, there's no PAL dump there... OK, what I've found out is that the PAL version of Ms. Pac-Man really is a 32K ROM, but most of the first bank is unused (set to $FF). The first half of the ROM dump (after the 128 byte A78 header) contains 512 bytes of non-$FF data, half of which are $00, then 15.5K worth of $FF bytes. The second half of the ROM dump is very similar (but not identical) to the NTSC 16K ROM. The differences between the NTSC dump and the 2nd half of the PAL dump start at byte 2597. It looks like someone converted the 16K NTSC version, but ran out of space in the 16K ROM (perhaps due to inexperience, or perhaps there's more to 7800 PAL/NTSC conversions that I think there is). Rather than tighten it up, they just released it as a 32K cart... with 49% of the space blank/unused. Maybe they were trying to meet a tight deadline or something.

Try splitting each ROM into 16K or 8K chunks (UNIX 'split' or 'dd' commands), then 'cmp' or 'md5sum' to compare the chunks. Sometimes incorrectly dumped ROMs have doubled banks. Could be the first 16K of the dump is identical to the second half, or it could be weirder than that. Were you using the dumps from the Atariage database?

Happy new beer... ...er, year... Close enough...