Jump to content
IGNORED

TI's DAC/ADC


in8regs

Recommended Posts

What? Why the cassette port of course, included in every 4a. What I don't know is how functional it is. What I do know, is this is an old idea, done on other old systems of the day: http://www.atarimagazines.com/compute/issue88/Audio_Recorder_For_Apple_II.php If the TI's cassette port can be used like the Apple II's, all these homebrew TI games could possibly be using sampled output.

Link to comment
Share on other sites

What? Why the cassette port of course, included in every 4a. What I don't know is how functional it is. What I do know, is this is an old idea, done on other old systems of the day: http://www.atarimagazines.com/compute/issue88/Audio_Recorder_For_Apple_II.php If the TI's cassette port can be used like the Apple II's, all these homebrew TI games could possibly be using sampled output.

 

It's very possible, in fact it's been done on a limited basis. If you are in to digitized sound, see Barry Boone's SoundFX. It also has a converter to port PeeCee sound files to the TI.

Link to comment
Share on other sites

Quick search shows he released the source back in 2000, but haven't found the source yet. http://tech.groups.yahoo.com/group/ti99-4a/message/3625

 

And Tursi has support for it, and something called TMNT, in classic99, showing up in the whatsnew.txt.

 

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.

Link to comment
Share on other sites

Quick search shows he released the source back in 2000, but haven't found the source yet. http://tech.groups.yahoo.com/group/ti99-4a/message/3625

 

And Tursi has support for it, and something called TMNT, in classic99, showing up in the whatsnew.txt.

 

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.

Edited by in8regs
Link to comment
Share on other sites

TMNT exactly used the cassette port to sample it's audio, and a small assembly routine to play it back. As such, it's 1 bit audio and takes 100% CPU. I didn't measure the bit rate at the time, but playing with it in the last couple of years suggested around 9kHz. Sound F/X, Barry was saying he got around 11kHz, and he plays 4-bit audio. Both use the same technique - set the sound generator to the highest frequency, and then toggle the volume level.

 

Emulators may need support, because for the most part, they can't accurately emulate the 40kHz-or-so output at the top of the sound chip's range, causing aliasing and other issues (to do so, they would have to be sampling at 80kHz or better, which most sound cards won't do). By default, Windows itself only mixes at 22kHz, meaning anything over 11kHz will be screwed up. There are ways around this if the emulator is clever, of course. I don't know if MESS manages to work with these programs, but I believe in the past at least, it did not.

 

Classic99 used to work around this by emulating a DAC mode... if the frequency on the sound chip was set above a certain threshold (I think it was 22kHz), then audio changes were put into a DAC stream instead of trying to manipulate the frequency that high. This worked. However, all that code has been ripped out in favor of the new sound engine. The new sound engine should be able to reproduce the sampled sound, but it doesn't have a high enough accuracy right now, as it processes only on the vertical blank. So Classic99 can not play any sampled sound right now, pending my replacement of the timing system.

 

Note that all this is less of a problem on some other systems that can simulate a true DAC, instead of just trying to set the frequency so high you don't notice. The TI sound chip can ONLY output square waves. Even clones of the same chip, like that used in the Sega Master System, can output a flat line which is better for playback of digital audio.

 

As far as the hardware goes, sampling from the cassette port works, but at 1-bit, just like the Apple 2. (It was the Apple that inspired the digitizer I wrote and used for the TMNT title music). These days, though, it seems silly to reduce quality that much, when PCs make it so easy to create 4-bit samples. These will sound a lot better. For better volume, Sound F/X drives all three voice channels with the same volume at the same time.

 

An interesting theory (recently proven on the ColecoVision and long ago proven on the MSX) is that the sound chip is capable of better than 4-bit accuracy. This is because the attenuation on a channel is in dB, which is a logarithmic scale, rather than linear. This means that different combinations of volume across the three voice channels will in fact produce "in-between" volume levels. My first pass at the math showed good density of evenly spaced volumes up to about 9 or 10-bits of resolution, but the ColecoVision fellow (was it Daniel? Sorry.. I forget, but he's here!) disagreed with my math, and I wasn't sure of his, so I need to revisit it ;). Anyway, if you want to pursue that, start with the datasheet and do your own math. :) Either way it sounds even sharper than 4-bit. My own thinking was that you could improve your apparent sample rate too, by "chasing" the correct level and changing just one channel per sample interval, doing the largest changes first, and then the smaller ones. That would be a bit lossy and would need testing (but would be a little ADPCM-like ;) ).

 

There's one other way to output 1-bit audio -- toggling the 'Audio Gate' pin on the 9901, which controls whether audio from the cassette port is mixed with the output audio. Turning it on and off causes a tiny click, even if nothing is connected, so you can output 1-bit audio this way. The game Perfect Push uses this technique on it's title page to say "Golden Games Presents Perfect Push".

Link to comment
Share on other sites

Note that memory is an issue. The TI doesn't have a lot, and sampled sounds eat it fast. At 8kHz, a 4-bit sample consumes 4000 bytes per second (1-bit samples would be 1000 bytes per second). A 12-bit sample (using the proposed logarithmic approach) would consume 12000 bytes per second. You can lower or raise the sample rate, of course.

 

The second issue is there is no way to accurately time the sample rate in the TI. You will have to do it entirely in software. To that end, it's usually easier to time your code and resample the audio outside of the TI to match what you're playing. ;) The only timer in the machine is the 9901, but the overhead of tricking it into interrupting your own code generally costs too much time. (Maybe polling it would be okay, I've never tried that..)

Link to comment
Share on other sites

Note that memory is an issue. The TI doesn't have a lot, and sampled sounds eat it fast. At 8kHz, a 4-bit sample consumes 4000 bytes per second (1-bit samples would be 1000 bytes per second). A 12-bit sample (using the proposed logarithmic approach) would consume 12000 bytes per second. You can lower or raise the sample rate, of course.

 

The second issue is there is no way to accurately time the sample rate in the TI. You will have to do it entirely in software. To that end, it's usually easier to time your code and resample the audio outside of the TI to match what you're playing. ;) The only timer in the machine is the 9901, but the overhead of tricking it into interrupting your own code generally costs too much time. (Maybe polling it would be okay, I've never tried that..)

 

 

Mike....

 

Your entirely too smart. I didn't understand one frigging point you made. Remind me not to argue with you too much huh ;-)

Link to comment
Share on other sites

Note that memory is an issue. The TI doesn't have a lot, and sampled sounds eat it fast. At 8kHz, a 4-bit sample consumes 4000 bytes per second (1-bit samples would be 1000 bytes per second). A 12-bit sample (using the proposed logarithmic approach) would consume 12000 bytes per second. You can lower or raise the sample rate, of course.

 

The second issue is there is no way to accurately time the sample rate in the TI. You will have to do it entirely in software. To that end, it's usually easier to time your code and resample the audio outside of the TI to match what you're playing. ;) The only timer in the machine is the 9901, but the overhead of tricking it into interrupting your own code generally costs too much time. (Maybe polling it would be okay, I've never tried that..)

 

 

Mike....

 

Your entirely too smart. I didn't understand one frigging point you made. Remind me not to argue with you too much huh ;-)

What he said was...

A low quality sound that is 1 second long takes almost 4KB RAM. Want 5 sounds that size or a 5 second long sound? 20KB.

A high quality sound that is 1 second long takes almost 12KB RAM. Want a a 5 second sound? 60KB!

You need a lot of RAM for sampled sounds.

 

 

Timing loops are used to play back samples on most machines due to the time critical nature of it.

Just remember there is some interrupt latency on all CPUs even if you have a timer you can use to generate an interrupt.

Most timers can be polled but I don't know squat about the 9901 so I can't add anything to that.

Link to comment
Share on other sites

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.

Edited by in8regs
Link to comment
Share on other sites

Note that memory is an issue. The TI doesn't have a lot, and sampled sounds eat it fast. At 8kHz, a 4-bit sample consumes 4000 bytes per second (1-bit samples would be 1000 bytes per second). A 12-bit sample (using the proposed logarithmic approach) would consume 12000 bytes per second. You can lower or raise the sample rate, of course.

 

The second issue is there is no way to accurately time the sample rate in the TI. You will have to do it entirely in software. To that end, it's usually easier to time your code and resample the audio outside of the TI to match what you're playing. ;) The only timer in the machine is the 9901, but the overhead of tricking it into interrupting your own code generally costs too much time. (Maybe polling it would be okay, I've never tried that..)

 

 

Mike....

 

Your entirely too smart. I didn't understand one frigging point you made. Remind me not to argue with you too much huh ;-)

What he said was...

A low quality sound that is 1 second long takes almost 4KB RAM. Want 5 sounds that size or a 5 second long sound? 20KB.

A high quality sound that is 1 second long takes almost 12KB RAM. Want a a 5 second sound? 60KB!

You need a lot of RAM for sampled sounds.

 

 

Timing loops are used to play back samples on most machines due to the time critical nature of it.

Just remember there is some interrupt latency on all CPUs even if you have a timer you can use to generate an interrupt.

Most timers can be polled but I don't know squat about the 9901 so I can't add anything to that.

Link to comment
Share on other sites

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.

Edited by in8regs
Link to comment
Share on other sites

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

 

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.

Edited by in8regs
Link to comment
Share on other sites

Note that memory is an issue. The TI doesn't have a lot, and sampled sounds eat it fast. At 8kHz, a 4-bit sample consumes 4000 bytes per second (1-bit samples would be 1000 bytes per second). A 12-bit sample (using the proposed logarithmic approach) would consume 12000 bytes per second. You can lower or raise the sample rate, of course.

 

The second issue is there is no way to accurately time the sample rate in the TI. You will have to do it entirely in software. To that end, it's usually easier to time your code and resample the audio outside of the TI to match what you're playing. ;) The only timer in the machine is the 9901, but the overhead of tricking it into interrupting your own code generally costs too much time. (Maybe polling it would be okay, I've never tried that..)

 

 

Mike....

 

Your entirely too smart. I didn't understand one frigging point you made. Remind me not to argue with you too much huh ;-)

What he said was...

A low quality sound that is 1 second long takes almost 4KB RAM. Want 5 sounds that size or a 5 second long sound? 20KB.

A high quality sound that is 1 second long takes almost 12KB RAM. Want a a 5 second sound? 60KB!

You need a lot of RAM for sampled sounds.

 

 

Timing loops are used to play back samples on most machines due to the time critical nature of it.

Just remember there is some interrupt latency on all CPUs even if you have a timer you can use to generate an interrupt.

Most timers can be polled but I don't know squat about the 9901 so I can't add anything to that.

Speechless?

Edited by JamesD
Link to comment
Share on other sites

Note that memory is an issue. The TI doesn't have a lot, and sampled sounds eat it fast. At 8kHz, a 4-bit sample consumes 4000 bytes per second (1-bit samples would be 1000 bytes per second). A 12-bit sample (using the proposed logarithmic approach) would consume 12000 bytes per second. You can lower or raise the sample rate, of course.

 

The second issue is there is no way to accurately time the sample rate in the TI. You will have to do it entirely in software. To that end, it's usually easier to time your code and resample the audio outside of the TI to match what you're playing. ;) The only timer in the machine is the 9901, but the overhead of tricking it into interrupting your own code generally costs too much time. (Maybe polling it would be okay, I've never tried that..)

 

 

Mike....

 

Your entirely too smart. I didn't understand one frigging point you made. Remind me not to argue with you too much huh ;-)

What he said was...

A low quality sound that is 1 second long takes almost 4KB RAM. Want 5 sounds that size or a 5 second long sound? 20KB.

A high quality sound that is 1 second long takes almost 12KB RAM. Want a a 5 second sound? 60KB!

You need a lot of RAM for sampled sounds.

 

 

Timing loops are used to play back samples on most machines due to the time critical nature of it.

Just remember there is some interrupt latency on all CPUs even if you have a timer you can use to generate an interrupt.

Most timers can be polled but I don't know squat about the 9901 so I can't add anything to that.

Speechless?

 

 

 

Slightly tongue in cheek there captain literal ;-) As far as being speechless... Those who know me would chuckle a bit at that question.

 

I have a tendency to understand the broad picture but the use of verbiage I am unfamiliar with tends to bamboozle me. I have no formal electronics education and my computer education ended circa 1988. Perhaps what I should have said was "Your jargon confuses me. Please speak in layman's terms for use who are a bit on the illiterate side"

Link to comment
Share on other sites

VDP bandwidth estimates are a different trick than audio chip estimates -- the ColecoVision and MSX comparisons are only really useful for the VDP, which has its own timing requirements. The sound chip doesn't (well, it actually does, but one issue at a time), so only the TI comparisons are really valid, because it's entirely a CPU/architecture issue, that is, how fast can you move a byte from point A to point B.

 

Samples won't usually be stored in bytes. If you wanted to preformat them for the sound chip, though, you could achieve that max throughput. Most of the timing discussion occurred on one of the Yahoo groups six months ago, and I had the logic analyzer out to get the true values. Unfortunately I only put a tiny summary at the end of the thread at 99er.net:

 

The fastest instruction for moving data to the VDP is something like MOVB R1,*R13, and takes 26 cycles to execute, which is just over 8.6uS.

 

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.

Edited by Tursi
Link to comment
Share on other sites

VDP bandwidth estimates are a different trick than audio chip estimates -- the ColecoVision and MSX comparisons are only really useful for the VDP, which has its own timing requirements. The sound chip doesn't (well, it actually does, but one issue at a time), so only the TI comparisons are really valid, because it's entirely a CPU/architecture issue, that is, how fast can you move a byte from point A to point B.

 

Samples won't usually be stored in bytes. If you wanted to preformat them for the sound chip, though, you could achieve that max throughput. Most of the timing discussion occurred on one of the Yahoo groups six months ago, and I had the logic analyzer out to get the true values. Unfortunately I only put a tiny summary at the end of the thread at 99er.net:

 

The fastest instruction for moving data to the VDP is something like MOVB R1,*R13, and takes 26 cycles to execute, which is just over 8.6uS.

 

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?

Link to comment
Share on other sites

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.

 

You're assuming some kind of DMA, I think. There isn't any.. the CPU needs pretty tight control over the FDC to read data from the disk. Have a read at http://nouspikel.group.shef.ac.uk/ti99/disks.htm

 

In addition, seek time, finding the sector you want on the diskette, and stepping the head all take very notable amounts of time. 31.5K/s is great but there's no practical case in which you can sustain it. The entire floppy disk itself is only 90K per side.

 

If you can make it interleave useful work with the disk controller, that would be very awesome code to see. There's plenty of delay loops in there to fill, and nobody has attempted it on the TI to my knowledge. Unfortunately, there are other controller cards than just this one (Corcomp and Myarc also made common disk controllers, I believe with different chips), so you'd be limited. But even tied to a TI controller, it would be difficult. There are no useful interrupts you can use so you'll have to cycle count everything, and to get the precision needed for audio playback as well I suspect may be too difficult, even is trying to playback just a single track (ie: without stepping the head).

 

Nothing is impossible, of course. One thing that I see that is interesting, is that the FDC /does/ support a "read track" command. It appears you tell it to read the read, wait 15ms, then come in and read the data out a byte at a time. Potentially you could use that, interleaving the playback of audio with copying read data from the FDC to the playback buffer (or stepping the head to the next track).

 

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 CPU can be at whatever you want it to be for sample playback, it just affects your sampling rate. So long as it doesn't drop too low, as to make it unrecognizable.

 

Thierry's doc really makes me wonder if streaming from disk might be possible after all. A 90k SSSD floppy has 2k of sector data on a track. Some parsing of the track data is needed, but if you picked out one byte between each sample, and did 4-bit samples, then you'd have 4096 samples (at least). At 8kHz that gives you half a second to step, read, and parse a track. As long as it can be done without halting the playback process....

 

Damn you, now I'm thinking about how to do it. ;)

 

3.3MHz/34 cycles per byte~=95KB/s tr for preformatted streaming from cartridge, yes? Next up would be estimated cycles for parsing packed.

 

Playback from cartridge will be the same speed as playback from (normal) RAM (they both have the sample multiplexer/waitstate interface) - at this point just build it and see what you get. ;)

Link to comment
Share on other sites

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

Edited by in8regs
Link to comment
Share on other sites

http://ftp.whtech.com is up right now.

 

Lately people have been reporting it up and down a lot... I wonder if there's a problem with the server.

 

This topic comes up every couple of years on the groups, yeah. Most TI topics do come around in cycles, it seems. :) (That's probably true with all systems).

 

Hm. Digisynt, huh? 1994 would post-date the free package I uploaded to the Ottawa TIUG BBS (which would have been '92 or so), but I doubt that it's a rip-off (since it's an obvious idea and his utility set differs, plus the author wasn't trying to profit by making it commercial). Just disappointing that it was reviewed as "the only" solution. I never was very good at getting my stuff out there. ;)

 

I can't try the game right now... I would expect that it freezes the game while it plays the sample, especially since it's running from BASIC (without a good interrupt timer, which we don't /really/ have, there's no other way). I did a test once that showed I could still get reasonable sound quality leaving sprite automotion enabled, though... ;)

Link to comment
Share on other sites

http://ftp.whtech.com is up right now.

 

Lately people have been reporting it up and down a lot... I wonder if there's a problem with the server.

 

This topic comes up every couple of years on the groups, yeah. Most TI topics do come around in cycles, it seems. :) (That's probably true with all systems).

 

Hm. Digisynt, huh? 1994 would post-date the free package I uploaded to the Ottawa TIUG BBS (which would have been '92 or so), but I doubt that it's a rip-off (since it's an obvious idea and his utility set differs, plus the author wasn't trying to profit by making it commercial). Just disappointing that it was reviewed as "the only" solution. I never was very good at getting my stuff out there. ;)

 

I can't try the game right now... I would expect that it freezes the game while it plays the sample, especially since it's running from BASIC (without a good interrupt timer, which we don't /really/ have, there's no other way). I did a test once that showed I could still get reasonable sound quality leaving sprite automotion enabled, though... ;)

 

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?

Link to comment
Share on other sites

The problem with whtech is they require prepending http:// to an ftp url, which is.. unexpected.

 

Yeah... I don't like that interface... but the true FTP interface is still available too. :) ftp://ftp.whtech.com ;)

 

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.

 

Maybe.. but I don't really see the need. I'd rather spend time on a 4-bit playback routine than resurrect an old 1-bit one. ;) I guess some people would like to play with it.. but the most basic loop is only a dozen or so assembly instructions. :)

 

What's the highest precision timer available?

 

The 9901 has a timer countdown mode, but if you want it to trigger an interrupt you run into a big problem - the interrupt is completely handled inside the console ROM with no user hooks. The console assumes that /any/ interrupt can only come from one of three places. Either it comes from the VDP for vertical blank, a peripheral card for peripheral interrupt, or the 9901 timer for cassette operations. This is all hard-coded.

 

Jeff Brown documented a trick whereby you could get control from the cassette routine for the 9901 timer. It requires disabling VDP interrupts and setting a few flags to confuse the system into jumping to your code. There's a fair bit of overhead in using this trick as the system checks numerous interrupt sources (including all peripheral cards) before giving you control. As always, Thierry Nouspikel documents it quite well here: http://nouspikel.group.shef.ac.uk//ti99/tms9901.htm#Timer%20mode

 

I remember Jeff using it for playback of sampled sound, but I seem to recall he wasn't impressed with the performance of that method.

Link to comment
Share on other sites

Not knowing anything about hardware. Too bad the load interrupt signal is not on the cartridge port.

That way some genius could put a timer on a cartridge PCB for generating the load interrupt.

ok, this would require 32K memory as the vector is located at >FFFD and >FFFE.

 

hhmm, thinking about it more I recall we had some discussions about a cartridge PCB that plugs into the sideport.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...