in8regs

So.. moved to Saipan, constantly approached for bribes, complained about it, the Saipan crooks take offense for being called out for being crooks, make death threats and go after his money claiming taxes. To top it off, one of the largest organized crime organizations in world, J.P. Morgan Chase, is involved in going after him.

Meh timeline, missing the ti-99/4a, influence of other systems, a driving force of the commodore 64, biggest market holder for awhile, while listing less noteworthy systems.. and also no ST? Make that a crap timeline.

The way to go is picking up an XL or XE and installing the AtariMax 32-in-1 OS upgrade. This gives you software compatibility with the entire range of Atari 8-bit machines, without the need for a 'translator' disk. Easy to install, easy to use, the price is right. And if you want to be able to run all the latest current releases, a memory upgrade isn't too hard to do either. You forgot to list your Atari cat in your tagline:) His name is Julius... that's his favorite place to hang out, on top of my collection. So that's the official name, the Atari Julius:)

The way to go is picking up an XL or XE and installing the AtariMax 32-in-1 OS upgrade. This gives you software compatibility with the entire range of Atari 8-bit machines, without the need for a 'translator' disk. Easy to install, easy to use, the price is right. And if you want to be able to run all the latest current releases, a memory upgrade isn't too hard to do either. You forgot to list your Atari cat in your tagline:)

Ah, OK, so if an 800 were upgraded to 64k+, that would get rid of the requirement issue for most games? I found this website: http://www.atarimuseum.com/faqs/HARD_FAQ.HTML that goes over memory upgrades past 48k for the original 800.

How about the 800xl vs 130xe? Are there older games incompatible with newer models?

Were there games that required a 1200xl, 800xl, 130xe, or xegs over the original 800 to run?

K, short on space, what's the cycles situation? With TI graphics being highly compressible, even simple compression like RLE would make a lot of room. If cycles are tight, since you're just short of fitting, compress/process just enough, x line/characters needed to fit everything without sacrificing characters.

Crap, I'm wrong, only variants with h&v scroll.

Maybe with some very smart usage of characters you can come a long way, even perhaps with smooth scolling? In this video you can see how to cheat with the trees: The remake looks pretty smooth. Here's the game on several platforms, some with 9918as:

TMS9918A can't do parallax you say:

Microcontrollers have timers, dac, adcs, room for memory expansion, etc. I was looking at cf7+, it's nice but what I'd want is SD, which lots of the other platforms have had done for them, interfaced via cart & floppy, like this: http://www.c64-wiki.com/index.php/MMC2IEC. I immediately thought of the expansion compartment of the speech adapter for where I'd put it, and would want an SD cartridge(or a cartridge tethered to the uc in the speech synth) as well. The mmc2iec hardware likely could be used as is, just needing the uc code rewritten to emulate ti's disk controller/disk instead of c64, then wire it to the needed pins. That's nice, but in my view, all the sd/cf/etc devices are over priced, wanting $45-150. I got curious, so I looked at microcontrollers and interfacing with sd, which there are many cheap solutions, relatively easy sd hookup, already worked out with howtos. I eventually spied TI's msp430, their new MSP430G2xx go for 0.25c per 1000, and single 430s go for as little as $1.25 at places like mouser, even better, many versions are available as free samples from TI. SD and the 430's require a lot less soldering and space than the FPGA setup the cf7+ uses. Did I forget to mention? The 430 is essentially the microcontroller version of the 9900:) Albeit modified, not compatible. Though a microchip or pic uc might be a better fit, the idea of the 430 being used for interfacing to the 4a is appealing:) Anyway, I even saw a PIC uc comparable to the low end 430's used to playback raw audio at 8bit 8khz off of an interfaced sd. Using a uc could be viewed as cheating/not as hard core, I suppose:) Though I believe there was an external DAC add-on back in the day. A compromise to roll your own are the $20 development boards, like starting with the mmc2iec, but need to add the sd interface.

> EKGs Actually.. http://focus.ti.com/general/docs/litabsmultiplefilelist.tsp?literatureNumber=slaa280a The 430 ucs having evolved from the 9900.

The problem with whtech is they require prepending http:// to an ftp url, which is.. unexpected. digisynt.dsk isn't in the subdirectory anymore, and whtech's search and a google site search come up with no results for it. There's still reconstructing it from peekbot if need be. What's the highest precision timer available?

Hey, so there's enough oomf to do sound affects, not just title screens, after all: http://99er.net/rev4.html. You've discussed this before:) http://tech.groups.yahoo.com/group/ti99-4a/message/61153 ftp.whtech.com is dead, but peekbot lets you look at the files as hex and text: http://peekbot.jamtronix.com/dispatch.fcgi/catalog_image/ftp%3A%2F%2Fftp.whtech.com%2Femulators%2Fpc99%2Futils%2Fdigisynt.dsk

This would be valid for the sound chip, too, which is subject to the same issues with the wait states and multiplexer. Of course, that instruction as it stands is not very practical, you'd need a way to get different data into R1. It's more likely you'd use MOVB *R1,*R13 as the fastest useful instruction, and that would still need external hardware (likely) to put different data at R1's pointer. But if you did that, the indirection adds another 4 cycles, IIRC, and another memory access. If that's to cartridge memory, then add another 4 cycles for wait states, and we're up to 34 cycles per sample. In most useful scenarios, though, the audio data is going to be packed, either 4 bits or 1 bit, meaning you will need to split the byte and merge in the sound chip control bits. IMO theorhetical maximum is not very useful in this instance. Practical maximum (ie: an actual application which we can group optimize, maybe) is probably more useful. Disk access is pretty tough.. I would be surprised if anyone could do a system streaming audio from the floppy. I would be very sure that such an action would require direct control of the FDC. The z80 stuff was being ignored. I assumed I didn't need to clarify, that people would recognize what's pertinent. What I'm curious about is what's possible, started with looking at the bandwidth to see if the prospect would be killed there. The floppy is the slowest that I've found, yet its 31.5KB/s is more than the 12K needed for 12bit @ 8KHz, so bandwidth doesn't appear to be the limiting factor. The story isn't over of course, you had said the CPU was already at 100%, so the possible playback rate is going to be less from adding steaming handling. The question comes up again of whether the prospect is killed, but if not, back to what's the best possible playback rate that can be achieved. 3.3MHz/34 cycles per byte~=95KB/s tr for preformatted streaming from cartridge, yes? Next up would be estimated cycles for parsing packed. Direct FDC control would mean yet more processing to account for, you figure the CPU load is approaching unfeasible?

Uh, yeah, I don't think anyone is under the impression the NES PPU is a 9918:) Based on the information, the rumors were true.

More bandwidth estimates: http://www.atariage.com/forums/topic/135588-dragons-lair-full-motion-video-for-the-colecovision/

Yes, they had Ricoh do the implementation.. cribbing off of the Coleco Vision, aka 9918. As you can read from the NES history article, they intended to use a z80 for the NES, but went with the 6502 because it used much less die space.

http://nesdev.parodius.com/bbs/viewtopic.php?p=45388&sid=37aecf831bd7c56f523461b58957b7be The article being referenced being in Japanese, on the making of the NES. http://translate.googleusercontent.com/translate_c?hl=en&ie=UTF-8&sl=ja&tl=en&u=http://trendy.nikkeibp.co.jp/article/special/20081002/1019378/&rurl=translate.google.com&usg=ALkJrhgRSZEZqqm_kX6SCn-gPnTpfod1gA

From http://spatula-city.org/~im14u2c/vdp-99xx/, http://spatula-city.org/~im14u2c/vdp-99xx/e1/99-4_History_By_KG_in_answers_to_Matthews_Questions.doc Q&A of one of the TI designers. News to me:)

OK, I did the math here... without unrolling the loops, it was 675 bytes per frame that could be written on an NTSC machine. This would be 675 * 60 = 40500 bytes per second. Even at that low estimate, that would leave 12k for sample input from floppy/cart, 12k for playback, 16.5k for code and video, assuming working out of vdp memory.

Oh, I would guess simultaneous playback and floppy/cart streaming would half the bandwidth again, so 412.5 KB/s, well above the rates we're discussing. I would think floppy and cart would do better than 12KB/s of the 12bit(this would be impressive:) 8khz sampling. With CPU already at 100%, I would expect adding the handling for streaming from floppy/cart would drop the playback limits. Does read before write, so half again? 206.25 KB/s, still plenty of head room. Ah, found something akin to this topic that you(Tursi) looked into awhile back: http://www.99er.net/cgi-bin/ikonboard/ikonboard.cgi?act=ST;f=3;t=23 You ramped it up to 1536k per frame(I didn't catch whether you're referring to 50 or 60 Hz,) for 8 bit memory, then doubling that when you went with MOV *R13,*R12, so 150 to 180 KB/s. Still the question of floppy and cart performance, or I guess 8 bit memory is cart. Info I'm finding for floppy drives is a double density 5.25 does 250 Kb/s or 31.25 KB/s. A 360K floppy would hold 30 seconds of 12bit 8khz audio.

Would need to stream from a floppy/cart, with memory use only enough for playback and small if any buffer. I don't know the bandwidth from floppy/cart. 3.3 MHz 16bit 9900 would be 6.6MB/s, cut in half from the multiplexing, divided by 4 from the wait states, .. other bandwidth eaters? Any rate, that's 0.825MB/s, which even if the case, the TI floppy drives are likely slower, don't about about the cart speed either. Anyone know? Finding those out would tell us what the max bit depth and sampling rate that could theoretically be achieved streaming from floppy or cart.

I don't know that there is much in the way of support needed other than making the emulator behave like a real sound chip. It's just a matter of turning the volume on full blast and then shutting it off instantly. It creates a pop that the software modulates. IE more pops per second = higher frequency. If you can't find the object code on WHT let me know and I'll send you a copy tomorrow. BTW there are about a hundred or so files on WHT for SFX. (Can't recall where they are and navigating that mess is a pain I well know so good luck As far as games go, I have seen very few examples of truly integrated digital sound on the old boxes. Seems very CPU intensive. Although Eyeball for the C64 has it masterfully done. If too heavy for FX, there are title, boss, high score, etc. screens.