pixelpedant

Yeah, when you live in a downtown core condo, you work with vertical space. So a 42u rack is the order of the day. But the 16u rack on my desk is also very helpful, in its allowing me to position my PVM directly over top of my TI 99/4A, while still giving me space to work with it.

I've recently made some additions/revisions to my setup. Added some wall-mounted clear acrylic shelves and LED lighting (since my rack shelves are pretty tightly packed, they're pretty dark and cavernous without). Obviously, there's a whole lot else going on there, but the TI 99/4A is at the centre of it all (and is the only device directly connected to the PVM, rather than run through an elaborate RGB signal detection/selection/amplification solution).

Well, I certainly wouldn't say it never gets recognition. But I've always been surprised by the way Demon Attack isn't more widely celebrated, and frequently mentioned. It's just so damn well put together. Fast, frenetic action. And cool enemy patterns. I feel like it stands the test of time really well.

75ohm sync is what you generally want presuming your cable itself doesn't contain a resistor included to attenuate TTL sync. It's nice to have an oscilloscope to test sync levels at the output jack, just in case there's something funny going on. You can get oscilloscope kits super cheap these days.

Cool. I'll be interested to try Warlords for myself, tomorrow. On the bright side, in further testing (well, gaming, really), I've found no additional cases which the Framemeister chokes on, in the past 24 hours. Problem cases are still limited to Buck Rogers (sync lost on title screen; all gameplay is normal), Battlezone (generally unstable, but death screen in particular) and Congo Bongo (displays, but with some minor and persistent hsync issues). I also tried loading FirebrandX's 2600RGB Framemeister profiles in case I'd missed anything settings-wise, but this didn't really change anything. Every other game I've played has displayed as expected (i.e., same as on the PVM).

> Are there any 2600 games that output a 240 image? I could have sworn it out out an oddball image. Kind of like how the bg is only 40 pixels wide stretched to 160, giving it a funky chunky look all it's own. Oh, there's a reason I put "240p" in quotes. The use of the term "240p" with respect to a system or game seldom if ever implies that an image produced by it will necessarily contain 240 visible scanlines, and, most importantly, does not imply a standard of any kind. It's just (awkward) shorthand used these days for the strategy of omitting alternating scanlines in a 15KHz broadcast video signal in order to achieve double the intended per-scanline refresh rate. > I've never used any of those converter boxes before so I know nothing about them, but have used recorders before, and unless your using a high resolution signal, most lock the image to 30hz. Most Atari games won't be noticeably effected, but some (like pacman) won't work properly. Yes, cheap capture devices and general-purpose capture devices are usually not designed to handle the 60Hz scanline refresh strategy I mention. However, there do exist purpose-built gaming upscaler and capture solutions which do. Micomsoft, in Japan (of Framemeister fame) almost completely monopolised the market, for quite a while there (with DVDO also making a few products of more limited utility). And solutions weren't cheap, generally starting in the $300USD range, for either their capture or transcoding solutions. But a couple others more community-driven solutions have become available in recent years, with the OSSC and RetroTINK foremost at present. Those aren't as comprehensive a solution as the Framemeister. But they can at least get you from a hacked version of 15KHz broadcast video (i.e., "240p") to something usable in the modern world.

> I figure your device is likely trying to combine images to run at 30Hz Quite to the contrary, both of these devices (OSSC, Framemeister) are purpose-built to handle 15KHz 60 frame per second (i.e., "240p") game system/arcade video. It's actually the opposite (480i) that can give the Framemeister conniptions - it especially doesn't like games/systems which switch between interlaced and uninterlaced signals on the fly (PS1 does this the most, of popular systems up to the 5th generation). The OSSC doesn't have issues switching between 240p and 480i on the fly, by comparison. Though in this case, it's clearly getting hugely confused about the nature of the signal during certain 2600 game contexts. Its LCD shows a rapidly and erratically changing scanline count, during the Battlezone death animation, for example. As I say, I use these devices with 11 different systems. Those being TI 99/4A, Master System, (RGB mod) NES, (RGB mod) SNES Mini, Genesis, (RGB mod) N64, Saturn, PS1, (RGB mod) PC Engine, (RGB mod) PC Engine Duo, and (McWill mod+sync combiner+downscaler) Game Gear. All with good results. All of those systems produce (well, with a lot of help, in Game Gear's case) 240p video either all or greater than 95% of the time. Given how much sketchier I'm finding results on the 2600RGB I'm inclined to suspect that indeed the TIA's and the Atari library's comparative hands-on approach to broadcast video is having some odd impacts on the transcoding process. Even if other systems at times do some similarly gnarly things, the Framemeister and OSSC were built around and tested around systems like the Famicom AV and Genesis. They were not built nor tested with RGB modded Atari 2600s in mind. At the same time, as I say, the OSSC in particular has a really rich set of signal processing options available to it. Lots of options are available for accommodating way out of spec sync timings. So I'll probably find myself hammering away at the problem some more. The Framemeister is more of an "it just works" solution. Still has a good selection of signal processing options, but it's far less often necessary to use them, and (being a Japanese commercial product) they are less well documented in any case.

Further testing (taking up pretty much the whole of my day) seems to suggest that there are actually plenty of cases in which the OSSC can't deal with what the RGB-modded 2600 sends at it. I can find very little at all written on the subject of optimal upscaler settings for the 2600RGB, from various web searches. Which is too bad, as the OSSC has a really very rich collection of signal processing setting options available. I guess there just aren't all that many people with this relatively uncommon mod and relatively uncommon upscaler. Increasing H-PLL Pre-Coast and H-PLL Post-Coast to the maximum of 5 helped moderately, in some contexts (got Buck Rogers - another problem case - half working). Not much else made a significant difference. The Framemeister did better. Most games have no issues. Buck Rogers (which had severe issues on the OSSC) only fails to display the title screen and level number scroll, and all gameplay itself is without issues. Demon Attack (which has moderate issues on the OSSC) is completely without issues. Congo Bongo does seem to have sync issues. And Battlezone is as unplayable on the Framemeister as it is on the OSSC. Again, none of these games have issues as displayed on my PVM, which is my main display. This just addresses how the upscaler handles the same signal.

I'm pretty new to the 2600 (grew up with a TI 99/4A - was jealous of my friend's 5200), but I've finally put together a 2600 setup (involving the 2600RGB mod) which works with my hugely gratuitous signal routing, display, upscaling and capture solution for other contexts (including 11 other systems), and I've been happily screwing around, to a large extent with games I know through their Atarisoft-developed TI 99 versions, which I'd like to get familiar with on 2600. I've noticed something odd about one specific game context and one alone, when upscaling or capturing 2600 games - the Battlezone death animation (chaotic series of colours and patterns which rapidly cycle for a couple seconds) drives *both* my OSSC and Framemeister nuts, but (as you'd expect) displays normally on my PVM. Normally, on the digital end (it's split by a BNC RGB distribution amp), the signal would run through my OSSC for digitisation, and Framemeister for digital upscaling/zoom/overscan/whatever, but I've also tried them both independently, with the same failure. I get the impression the TIA permits the developer to go pretty much as out of spec as they please in a lot of ways, so something screwy happening here is hardly difficult to fathom. But I'm far too curious about legacy a/v to simply let this one go as a minor (and largely irrelevant) corner case. I'm curious if anyone with some knowledge of the 2600's idiosyncrasies could take a guess. It's also possible the 2600RGB board is playing a part in this issue, but since analogue RGBS display is flawless throughout, it clearly isn't failing to handle this corner case outright.

Laughing out loud. Honestly. Well said.

Wow. Hats off to you for finding a solution to this sticky problem on the TI end of things. I thought it might come down to disassembly. But I was kind of hoping otherwise. Thanks for the detailed explanation!

I've been playing around with speech a lot lately. Not attempting to do anything in particular, necessarily. I wrote a Python app for editing speech patterns (analogous to Speecoder, but with more user-friendly/modern editing). Then I got to mapping musical note frequencies to LPC pitch values for the sake of messing around with sung speech. TEII and the Text-to-Speech disk are powerful tools for generating pattern data (and even messing around with pitch and energy a bit). And heck, the Text-to-Speech disk subroutines can even be used in an XB program! But what would make these tools really useful to me is if their generated LPC patterns could be dumped for subsequent editing and reuse. Especially because the phonemic/syllabic inventory of the default vocabulary is incomplete.

CALL SPGET serves as a simple, handy way to fetch LPC patterns in XB and the Speech Editor (which can then be saved, stored, modified, etc.). But while TEII and the Text-to-Speech disk offer much richer speech composition options, it doesn't seem like there's a trivial way to dump patterns for subsequent use, or generate patterns ahead of time for performance reasons. Or at least I can't see one. Is there a method I'm missing here?

I have what I think is likely a fairly basic (pun...I'm not sure...intended?) question regarding the VREAD and VWRITE subroutines. When I CALL LINK ("VWRITE",[address],[string]), I notice that the character written to screen appears to be of an ASCII value 32 greater than that of the character contained in [string]. That is to say, CALL LINK("VWRITE",[address],"!") results in "A" being written to screen at the location associated with [address] and CALL LINK ("VWRITE",[address],"`") results in non-character data being written to screen at the location associated with [address]. Meanwhile, when I CALL LINK ("VREAD",[address],[bytes],var$), the character contained in var$ (if a single byte read) appears to have a value 96 greater than that of the ASCII value of the character originally written to the screen. Would anyone be able to illuminate why this is the case? Though I've had a TI 99/4A my whole life, I'm very new to the development side of things. But these subroutines seem like pretty powerful tools which I'd like to be able to utilise. Edit: I'm guessing this must just be a function of fundamental discord between the vanilla XB pattern table and the XB256 Screen 1 and Screen 2 pattern tables? But this seems to raise the question - why does VWRITE accept a string (rather than, say, an integer) as an argument, if that string is merely being treated as representative of a location on a (vanilla XB) pattern table which isn't being used? Seems confusing. Or maybe I'm just not understanding what's going on here. I'll have to experiment some more.

Mounting a fan on the back does seem like the way to go. Or at least, taking my system apart and having a look and a think, that's where I ended up, as far as ideas for solutions. The rear grill seems to be the best position from which to ventilate the system board area, from what I'm seeing. I'm thinking what I may do is rear mount a couple of these while simply removing the slats in the area. Though the real goal is of course to make my TI look like a fan-driven HoverComputer that flies around the household making obnoxious suggestions regarding Household Budget Management, Home Financial Decisions and Physical Fitness in a conspicuously synthesized voice.

I tended to find in my youth that my TI 99/4A would overheat and start misbehaving, after really, really long play sessions (or at least, I can only assume that correlation is a valid one - the bed of the cartridge slot could get really frickin toasty). And I've noticed this a couple times recently again. Though I don't have as much time for multi-hour play sessions these days, the sheer abundance of games furnished by flashcarts means there's more justification for them, and when I stream my play sessions, they sometimes go on for hours. So I'm wondering if folks have advice regarding the best way to cool an original model TI 99/4A. Will running a fan off the vents near the cartridge slot accomplish anything? Has anyone done anything hackier?

Yeah, makes sense. I mean, I've never had much trouble with the dumps I've used for FlashROM99 or FinalGROM. Though I was having some trouble with a tape dump recently. Which makes sense. I mean, magnetic storage being what it is.

I do have the cartridge expander (for the purpose of a trick involving Speecoder and reading speech synth from GROMs). I assume the ROM dump procedure is similar? If I have anything folks would have a use for a dump of, I'm happy to do it. I'd just need instructions. I've got a NanoPEB, RS232 to my desktop, FinalGROM and XB2.7 Suite cart, so any requirements for such a process should be satisfied. I just figured most things had been dumped satisfactorily well already. Are bad dumps an issue in some cases?

It's true, adult me finds it kind of neat that I've got a bunch of oddball late 80s mail-order Databiotics cartridges, instead of the more common early 80s ones. But for the sake of childhood me who just wanted to play some fun games, I'd still have preferred them to be the classics Another thing about these cartridges, though - gosh, they sure went cheap on the labels, late in the game:

My childhood TI cart collection (which is still with me) is a bit lackluster, in a somewhat odd way. I got into the TI game a bit late, so instead of Atari's or Sega's 82/83 classics, I've mostly got a bunch of 87/88 Databiotics carts (e.g., Barrage, Black Hole, Midnight Mason, QMaze). No Tunnels of Doom or Centipede or Jungle Hunt or Star Trek: SOS or Buck Rogers or Burgertime for me. Anyway, this week, I think I finally righted that long-term wrong with this acquisition. The highlight here for me is a near-mint Star Trek: SOS and near-mint Return to Pirate Isle. Both were opened non-destructively, and (curiously) there is no evidence at all that the cart or manual were ever handled or used. And since they were apparently left inside the package, there's little to no yellowing/discolouration. I'm not normally one for game collecting for the sake of game collecting. Flashcarts are fantastic, as far as I'm concerned. And I own hitherto almost no CIB games (out of hundreds) and zero Sealed games. But even I got giddy opening up (carefully) the pages of a brand-new-looking Star Trek: SOS manual and picking up a brand-new-looking Return to Pirate Isle cart. Felt like Christmas '83. Or in my case, a somewhat less lackluster Christmas 88

Only if it were a well-documented FPGA-based perfect or near-perfect workalike, I'd say. Analogue NT Mini sort of thing. And even then, maybe only if it provided native analogue output. And even then, it wouldn't replace my main setup, only function as a supplement to it. What can I say - I'm a purist. And my whole damn (11 system) setup is based around analogue signal routing. If it were really just basically a software emulator, I'd surely elect to keep on using real iron 90% of the time, and Classic99 for the other 10%. And if a need for a compact, portable, standalone TI 99 box ever arose (which is difficult to fathom, given I've already got my tiny laptop, which I carry with me 100% of the time, loaded up with TI 99 stuff), I guess I'd just grab a spare Pi out of storage, and throw the requisite stuff on that.

At least in my case, I would say that because the TI99 is also its keyboard, I tend to pull it forward and backward on the rack on which it sits constantly, depending on whether I'm using it at the moment (it's in the middle of my computer desk, which is my computer desk for all other purposes as well), and its feet tend to hit the surface of the rack constantly, as a consequence. I can see this resulting in wear which would cause them to be displaced, but I can also see someone pulling them off simply to prevent this, as they move it around.

Ooh, that would be a tempting choice!

I would very much enjoy seeing that!

Indeed, the Compute! article linked describes the (simpler) approach to producing pitch-adjusted speech in this manner in TE2. However, it's also more limited. Mainly, as without the ability to freely adjust the duration of syllables and their constituent structure, it's difficult to sing a song. The best one can do is reduplicate allophones in some cases (which wouldn't work for diphthongs). What's more - the built-in vocabulary and syllables constructed from TE2 allophones are themselves necessarily not of equal duration to one another, so what you get is more like just notes/syllables of arbitrary duration. So in the opening passage of You Are My Sunshine, syllables/notes should be of these relative durations: You(1) Are(1) My(1) Sun(2)shine(3) And that's what we'd want to achieve. Which we can. But really only by editing the speech itself. This is a challenge faced as well to an extent in editing the speech directly, in that, because English syllables are of radically varying phonotactic complexity (compare: "he", "strengths"), and the "time-resolution" if you will of the synthesizer's speech is not particularly great (20 frames was the target duration I used for quarter notes), more complex sounds will tend to be inherently longer. Where there is no real correlation between phonotactic complexity and note duration in music at all (i.e., "strengths", as a word composed of 7-8 phones depending on dialect, is not customarily sung for four times the duration of "he", usually consisting of 2 phones). However, in my case though, I also wanted to do this in Extended BASIC to a large extent just because I wanted a solution I could expand upon in Extended BASIC.