Jump to content

Xuel

Members
  • Posts

    849
  • Joined

  • Last visited

  • Days Won

    2

Everything posted by Xuel

  1. Can you try this XEX? It uses a simpler load sequence: joust.xex
  2. 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?
  3. Xuel

    Star Bars

    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.
  4. Xuel

    Star Bars

    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
  5. Xuel

    Star Bars

    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
  6. 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
  7. FYI, looks like the palette doesn't get loaded properly if the VBXE is at $D700. Works fine at $D600.
  8. Any chance for a stereo separation slider? It would be nice to have some stereo separation but less than 100% for headphone listening.
  9. 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.
  10. 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?
  11. 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?
  12. Can you post the original and/or FastBasic .bas files?
  13. Here you go: RYDEEN.zip
  14. 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?
  15. 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.
  16. BTW, many thanks to @tebe for sharing the source code. It made patching Bomb Jake a much more tractable problem.
  17. Here's a 21-byte patch: Bomb Jake Xuel Patch.rom This fixes the title and hiscore screens but the game play seems slow on PAL and OK on NTSC. Not sure if this is due to being an older version of the code or maybe something else that's broken. For this I shortened the NMI entry sequence by about 8 cycles which is enough for DLIs to meet the deadlines for writing to WSYNC. To achieve this I changed the way the current bank is saved and restored such that it is never saved, just restored from the game's shadow register. Both this fix and the one that I did for Yie Another Kung-Fu are more about fixing ANTIC timing issues than anything to do with Corina hardware. I don't see how either cartridge would work reliably on real Ataris. The hires issue and the WSYNC deadline issue are both confirmed in hardware AFAIK. Have people actually tested these carts on lots of different machines? I wonder if the devs happened to have Ataris with oddball timings? Or maybe the cartridge itself affects ANTIC timings? Edit: grammar
  18. Here's a six byte patch that at least stops the flicker on the first level: Yie Another Kung-Fu Xuel Patch.rom I just shortened the double-buffered display lists by one line to avoid the hires bug that phaeron identified in the thread you quoted. Not sure how it works on real hardware.
  19. Xuel

    Atari Beaglebone Expansion

    The existing AVG firmware couldn't support these types of movies. It would need to implement a bank switching scheme similar to ABX. Currently it only supports a streaming mode similar to SIDE or MyIDE. The fundamental requirements for RastaConverter-esque movies is a memory bank where Sally and Antic can intermix reads in a somewhat random access fashion. Ideally it would be large enough to hold both the bitmap data and the 6502 code for a full screen. Otherwise you'll have to dedicate some 6502 instructions mid-screen to bank switching and even then the underlying hardware might not be able to bank switch fast enough. ABX actually streams in the next bank during the vertical blank period.
  20. A simple conversion would not be possible since color register values may be reused as player positions and vice versa. For example, if the program determines that the optimal 6502 instruction stream at some point in the middle of the screen for NTSC is as follows: ... LDA #$3C STA COLPF1 STA HPOSP3 ... Then, you can't simply change the LDA #$3C to LDA #$2C for PAL because that will also change the position of player #3. You pretty much have to rerun from scratch to target a different palette. I suppose the tool could have an option to work on PAL and NTSC versions simultaneously but it will double the amount of computation necessary, so it would anyway be comparable to running the tool twice.
  21. I would need to work with tmp to get that working based on file extensions. I'll work on it.
  22. Done. This is now implemented in 0.3.5. Select "Covox" under "Playback Method" to get "cov" or "cos". All other playback methods are assumed to be "pdm" or "pds". The PDM Settings are now also disabled when selecting Covox. This means .cov and .cos files will have a simple linear mapping from sample values to 8-bit values, i.e. the same as you would get with PDM preset "16 16 0". https://lybrown.github.io/fujiconvert/
  23. Xuel

    AVGCART

    Awesome! You are truly making use of the field-programmability of the FPGA! So many options to explore with the same hardware. And kudos for designing the whole cart to support all these possibilities from the start. Nice tease at the end too.
  24. I found and fixed a couple bugs in your compressor (a couple missing GOTOs). I also wrote a version in Perl. I'm attaching both: rle.zip Both compressors reduce Gollum_C64_Rensoupp_Tebe.scr from 1200 bytes to 262 bytes, not the 253 you mentioned earlier. I'm curious if they are missing an optimization that you did in your hand encoding?
  25. @flashjazzcat It looks like the new SIDE loaders (v0.43) don't initialize the second POKEY when playing .PDS files so the right channel is effectively only 4-bit resolution instead of 8-bit since the oscillators are never started.
×
×
  • Create New...