Xuel

Can you try this XEX? It uses a simpler load sequence: joust.xex

Looking great! Looks like you're using ANTIC graphics for the background and VBXE for the foreground? I suppose that's faster than blitting both background and foreground using the VBXE and disabling ANTIC? Would that be true even if you used X-scaling in the blit to get the same pixel size as ANTIC mode E?

Yes, Aleksi Eeben wrote a music editor, Star Bars, for the Commodore 64 which produces Atari 2600 ROMs which you can then burn to a cart and play on a real Atari 2600. The demo ROMs Aleksi has put on Dropbox have the extension .a26. You can download and change the extension to .bin if that works better for your environment. https://www.dropbox.com/sh/8oqoeix1e0uritf/AAC-HWxtJqRQeaTh0ckNby4Ja/atari 2600?dl=0&subfolder_nav_tracking=1 https://www.dropbox.com/sh/1ue30pcjup1zbbr/AADNfPVhQOa4UbwxRj2JoGAxa?dl=0 https://www.dropbox.com/sh/1ue30pcjup1zbbr/AAC_fNKONuZLkclJPvh2-7caa/quality test?dl=0&subfolder_nav_tracking=1 Hopefully more people will use Star Bars to create more nice tunes for the A2600 and/or incorporate the playback routine into new A2600 games/demos so we can have more pleasant sounding music on the A2600.

The description on third Youtube video, "Tiatonic Tuning for Atari 2600" has a link to a dropbox folder with assembly source code and a PDF with a bit more detail: https://www.dropbox.com/sh/1ue30pcjup1zbbr/AADNfPVhQOa4UbwxRj2JoGAxa?dl=0 Looks like each pitch has three bytes of information associated with it: 1) Dominant AUDF setting 2) 8-bit pattern for how often to switch to AUDF setting+1 3) AUDC setting Seems like the main innovation here is quickly twiddling AUDF between two consecutive values, in the correct proportion, to achieve the desired frequency when averaged over many updates. Encoding the proportion as an 8-bit mask that you rotate every update is very clever! If you build the demo code, you can tradeoff tuning accuracy for lower update frequency by changing the QUALITY setting in tiatonic.s: QUALITY equ $07 ; $03 = high, $07 = good, $0f = average, $1f = low, $3f = bad Those correspond to updates every 4, 8, 16, 32 or 64 scan lines. You can also completely disable the AUDF twiddling by holding down fire on joystick 1. Cheers, Xuel

Check out this awesome new 2600 music tracker by Aleksi Eeben: The "Star Bars Atari 2600 Music Competition" is open till Aug 15 for anyone who wants to try their hand at making some tunes using this new tracker technology: https://csdb.dk/event/?id=3323 Website: https://bit.ly/atari2600starbars Youtube: Cheers, Xuel

I took a crack at converting the .car file on atarionline.pl: http://atarionline.pl/arch/J/James Bond 007/James Bond 007 (1984)(Parker Brothers)(US)[!].car Here's my attempt to convert it to .xex: james007.zip I only fixed one issue in the code which allows it to boot up and play but there may be others that show up further into the game. Cheers, Xuel

FYI, looks like the palette doesn't get loaded properly if the VBXE is at $D700. Works fine at $D600.

Any chance for a stereo separation slider? It would be nice to have some stereo separation but less than 100% for headphone listening.

Make sure you disable cassette acceleration: System -> Configure System -> Acceleration -> Uncheck "C: patch" It takes about 7 minutes to load fully. You can hold down F1 to speed it up.

Here you go: v8x.zip The FastBasic version occasionally takes longer than a frame to update. This means it can't be easily be converted to a TYPE-B SAP for the following reason: The ASAP player interrupts the emulated 6502 every frame regardless of whether the last call to the player has returned or not. So, I translated the FastBasic code to straight assembly, pulling my hair out locating mistakes, and then converted that to SAP. I verified it produces an identical trace of POKEY writes to the original except for 4 extra writes to AUDF1 which I didn't bother to track down since they are just repeats of a prior write with the same value. Odd though... The attached .xex and .sap have no glitches. The player is quite efficient when translated to assembly. It appears to average around 2-3 scanlines per frame of computation. I'm fascinated that someone wrote the original in Atari BASIC given that it can't play at full speed. Maybe it was intended for upgraded 8Mhz machines?

Very nice. I was able to convert this to SAP. I'd like to give proper credit in the SAP header. Who wrote the original BASIC code? Did you? What date?

Can you post the original and/or FastBasic .bas files?

Here you go: RYDEEN.zip

I tried very hard on these about two years ago but came up short. Getting the BASIC environment and timing to match up proved to be too tricky. I went so far as to start writing a bespoke BASIC compiler to convert these songs into stand-alone assembly programs but I couldn't maintain the timing and I never could properly implement some of the wacky FOR/NEXT loops that some of the players use. Here's my shoddy work environment if anyone wants a laugh: the-music-box.zip I think the right approach here would be to create a TYPE-D player that can recreate the exact POKEY register update timing achieved by the BASIC programs. For one thing, a lot of the percussion in these songs produce bursts of sound that are less than a frame long. Furthermore, the songs' BPMs are not frame multiples and there is noticeable BPM jitter and drift that comes from using delay loops instead of a truly periodic timing method like VBLANK. This gives the tunes a certain charm as they tend to slow down a bit during more complex interludes and speed up when just a few instruments are playing. This might mean including the whole BASIC interpreter in the SAP or coming up with some as of yet non-existent format/player which can update registers after varying increments of VCOUNT. Maybe someone else can think of a quick and easy way to convert these?

You could use this command sequence: bx "vpos=0 and hpos<5" ".pokey" g Enter Enter etc. That "bx" expression will usually catch every frame start, just once, but it might fail if a write to WSYNC happens near the start of scanline. Perhaps use a "bp" breakpoint to stop when PC is just after your POKEY update routine. You could also just run the following two commands repeatedly: gf .pokey Not sure if those could be combined into a single macro so you could just repeatedly hit Enter to advance. You can also use "wb" or "ww" to watch memory addresses. Altirra displays them as an overlay on the main screen. But those won't work for POKEY registers since they have different meanings for read and write. But if you have shadow registers, that could work. Then you could just run "gf" repeatedly to advance frame by frame.