Playing Samples

[Rybags]

I'm thinking here that a LDA $xxxx,Y might be best in an IRQ routine.

 

Then all the VBlank code has to do is self-modify the xxxx. Y initial value can be simply stored in z-page. Y initial value obviously is 0 at VBI, and would increment to around $40 or $80 depending on your frequency of playback.

Also, if you have a long running Stage 1 VBlank, you could play the first one or two samples in the VBI.

Stage 2 isn't really a worry since it runs with IRQs enabled.

 

The DMA during mode E isn't too bad - at worst you lose 41 cycles per line or 43 in an LMS (add 5 if PMGs also used). The text window is the big theif here.

But if you're only playing a sample every 4th scanline or so, having a few delayed by one scanline shouldn't have an adverse effect anyway.

 

You can save significant time by just using the immediate IRQ vector. Of course then, you'd need to disable all other IRQ sources when doing samples. The alternative is that you have to handle all the other IRQs (no great drama).

 

Keyboard handling can be done without interrupts - just requires a bit of programming, best done in the VBlank routine.

[Heaven/TQA]

Pete, all my interrupts are doing this nowadays (when I am in optimising mode... not official mode):

 

int: sta intend+1

stx intend+3

sty intend+5

...

intend lda #0

ldx #0

ldy #0

rti

[peteym5]

I forgot to ask something about the NMI, IRQ, and Reset Interupt vectorts at the top of memory area. I realized they are in the ROM area and can not be changed. I wonder how people get those jump to another area rather than what is there. I will figure it out sometime in the future for sure. Either there are pointers in somewhere or they copy the OS to RAM.

[Rybags]

On XL/XE machines with >= 64K, you can just roll your own OS, or copy the OS to RAM and modify the vectors.

 

Of course, that then makes your program incompatible with 400/800/600XL. Another hassle is that some DOSes and programs also want that RAM.

 

Unless it's super time-critical, you're probably best off just using VIMIRQ ($216). It adds 8 cycles or so of overhead, but you can make up for it in other ways (like the register save/restore Heaven mentioned).

[atariksi]

Very interesting stuff and I have been requested to incorporate this stuff into a project I am involved with. One issue is my game is using a graphics 31 (gr.15, with text box) and a several DLIs to split up the player missile graphics and the game is all done in a VBI routine. One problem is with trying to play a wave sound during game play is that there may not be enough time to complete the VBIs when its playing one of these sound effects. Have to consider that Antic is going to be stealing main bus cycles for all the Antic 14 lines there.

 

I did examine the source code that uses the IRQ vectors. There were several obvious ways I can get these routines to take up less time. One is instead of doing a LDA (sample),y is do a LDA $ffff and modify the address (self modifying code). The second thing is not store 2 nibbles per byte, but what the volume + the force out. I know it will double the memory size, but will play quicker. Also I would remove the JSR Playsample and make it a single routine. If you don't intend to run it from Basic and don't need the floating point registers, you can use most of page 0. Instead of pushing and restoring the registers, save them somewhere in page 0.

If you optimize your IRQ routine, you don't have to worry that much about a few DLIs interfering. I was able to play about 14Khz digital audio nibble packed in Graphics 9 using SPS sending it over the joystick port and getting bufferred in the background. It's not worth having it unpacked-- just make a 256 byte look-up table like:

 

XFORM: DB 16 dup(240), 16 dup(241), 16 dup(242), ... 16 dup(255)

 

that saves you from doing 4 LSRs and ORAs instead you just do:

 

LDX SamplePtr,Y

LDA XFORM,X

STA 53765

 

and for lower nibble don't do the AND $0F so you have something like:

 

LDA SamplePtr,Y

ORA #$F0

STA 53765

 

DLIs pre-empt IRQs so if your DLI is complex (running across the screen) you would need to do find right locations to do CLI/SEI and perhaps WSYNC back on track. I did not use any VBIs in my SPS/Atari stuff so I did not have to deal with that.

[Rybags]

If you have a long-running DLI, you could use that to do one or two of the samples anyway.

 

Probably also have to clear the IRQ status at the end, and restart the timer, though.

[snicklin]

since you guys are still talking about converting WAVs on the A8... how about a nice dos/windows program to do it in a few seconds instead?

 

http://www.hyakushiki.net/convert4.exe

 

Quoting quite an old post here, but which version of Windows is this supposed to work with? I can't seem to get the compatibility settings right.

[Rybags]

2008 - probably XP or even Win98. Newer versions can have compatability issues not to mention often needing to run as Administrator. And probably has to be launched from a CMD window too.

 

If the objective is to just massage some data to convert samples then it could probably be done more easily in a scripted language. Added advantage would be that it's easier to customize.

[DamageX]

It's a 32-bit DOS command line program, and should work in any 32-bit Windows. Not sure about Win 3.1 or 64-bit.

[snicklin]

I tried Windows XP, 2000 and 7 and none of them worked. Perhaps I should try 98 also. I'm running a 64 bit Windows though which I think may be my issue. I thought that 64 bit OS's automatically were able to run 32 bit applications though (ignoring the fact that it may be for the wrong version of Windows).

[snicklin]

Perhaps if someone knows the source and destination file formats, a Perl script should be easy enough.

[+CharlieChaplin]

Works okay for me with Win XP 32Bit (using the DOS, errm, input prompt). But my 2Ghz MS-DOS PC does not like this program, since MS-DOS is only 16Bit. Maybe my Win 3.11 with 32Bit enhancements will execute this converter... have to test this...

 

Hmmm, source = 16 Bit WAV, mono (only mono is supported!), dest. = 4bit sample, mono

 

Afaik, there are various 4bit sample formats on the A8, so I have to test which sample player can play these 4bit samples...

 

Since most of my WAVs are 16Bit stereo, I have to convert them to mono first. (The WAV to 4Bit sample converters for the XL/XE require to convert the WAVs to 8Bit mono first, then the A8 programs will convert them to 4bit samples.)

 

---

 

There is also a WAV-player for the A8, named "The Sound Utility" by CTH / Tom Hunt. This program loads/plays 8Bit Wavs (not sure if mono or stereo, I guess only mono) and 4Bit samples (only mono) and works best under Sparta-DOS format (SDFS). It even supports up to 1024k RAM, alas, everything beyond 128k RAM, sounds extremely noisy (no clue why, maybe something is wrong with the way the program uses the additional XRAM banks...?)

WAVPLAY.ATR

Edited November 9, 2015 by CharlieChaplin