Jump to content


+AtariAge Subscriber
  • Content Count

  • Joined

  • Last visited

  • Days Won


Everything posted by playsoft

  1. That was the PAL build, not intended for running under NTSC. The reason for building PAL and NTSC separately is that I did want to so something with the extra PAL cycles - perhaps that will be COVOX. With NTSC I have to investigate whether the IRQ positioning is OK and if there are enough cycles, but that's not something I can easily do at the moment. Over the past few weeks I have been converting it to use bank switching, so that it can potentially support different tile sets for different missions. I have also been putting in hooks for where different missions might want to change things, but I have so many of them I don't know if it would be better to back them out and use different control loops instead. After that I intend to get the guns firing and add some proper attack waves - that will be the first indication of whether it's likely to be playable or not. Currently with the test waves it is impossibly hard without the enemy sprite/missile collision detection turned off. When I get to this point I'll post an update of both PAL and NTSC versions.
  2. That's (the 113.5 cycles) a very good explanation for why the interrupt position moves rightwards. Thanks!
  3. Here it's used in something I'm working on, a more typical game setting, playing samples between attack waves. It sounds pretty good, still using a sampling rate of 7860. I don't have the guns firing yet so there will be a few more missiles on screen when the samples are played but that probably won't affect it too much. Credits are @kiwilove graphics, @RevEng's TIA sound effects and I borrowed @Fragmare's Air Zonk for some background music (playing on the second POKEY as a channel on the first is used for the IRQ timer). I am reluctant to post a NTSC version because I can't test it and there's a bit of dodgy code needed to get it working. I have two DLIs, one to change the mode to 320 for the text area and another to change it back to 160. NMIs should have priority over IRQs but there is a timing issue where an IRQ can cause the NMI to be missed completely. Normally you'd get around it by positioning the IRQ to occur at a position on the scanline away from the DLI but I can't do that because for some reason the 15kHz timer is slightly longer than a scanline, so the position of the IRQ moves. Instead I reset the position of the IRQ in the first DLI, such that it's still OK when it reaches the second DLI and when it gets back to the first DLI again. This was very much suck it and see, I don't know if this position would work on NTSC where there are less scanlines per frame. portal_p.a78
  4. I tried out the timers/IRQ today and they work although the timing was a little different to the 5200/A8 where if you put POKEY in 15kHz mode 1 timer tick is exactly 1 scanline. If you set the timer running in the middle of a scanline and have the interrupt set the background to white then back to black, you end up with a vertical white line down the middle of the screen. On the 7800 it appears to take slightly longer as instead of a vertical line it veers to the right. I put a real POKEY in the Dragonfly and got the same result. If it had been accurate like the 5200/A8 then I was going to have the interrupts occur down the right side of the screen where Maria DMA is likely to have finished to avoid any delay in servicing the interrupt. Since the interrupt is effectively moving (by taking longer than a scanline) there is no way to avoid the DMA. In this test the same track is played but from the IRQ instead of the main loop so you need to enable the POKEY IRQ on Dragonfly to hear it. It's still playing at a sample rate of 7860, just that the time between samples is inconsistent. In the main loop it reads the controllers and lets you move the silhouettes left and right. I have a couple of things that I have been playing around with but I didn't plan to use samples so may not have enough cycles for the IRQ processing. I am going to try adding a sample and if successful will post here. wa_irq.a78 source.zip
  5. I tried out Covox from the Pokeymax in my Dragonfly cart and was pleasantly surprised by the audio quality. The attached is playing with a sample rate of 7860, writing to Covox every 2 scanlines. wa.a78
  6. I've not used it myself but my reading of the table is: "P2=0 : palette 0-3, P2=1 : palette 4-7" means that by setting bit 2 of the palette bits in the header you can choose which group of palettes to use, either palettes 0-3 or palettes 4-7. "D75/D64/D31/D20" are the 8 data bits of a byte of graphics data. This mode is 2 bits per pixel so 4 pixels per byte, but each pair of pixels are related; one pair of pixels is represented by bits 7/6/3/2 and the other by 5/4/1/0. The table shows what colours you get for a pair of pixels for all 16 possible values of these 4 bits. As stated you get 4 colours plus bg and transparency. However each pair of pixels must be one of: both transparent, both colour 2 of any of the 4 palettes (in the group selected) or one pixel set to colour 2 and the other set to bg colour (not transparent).
  7. Yes that comes down to 3489 bytes so the wasted bit is costing 283 bytes here. The lz12.s player would need changing for this, which sounds simple enough with one extra bit in the length and one less in the address, but I had a quick look and it wasn't completely obvious. The other thing I tried was using LZ16 with 2 wasted offset bits for a total buffer space of 576 again. It indirectly wastes 2 length bits too as it won't find a match longer than the offset, so it's like moff = 6 and mlen = 6 but using 16 bit records. This comes out at 3986 but there could be a slight processing benefit since it deals in whole bytes. In another project I took a 5.5K RMT file and that came out at 14.5K with LZ8. I put this in a switchable 16K bank and figured if I wanted more music I'd throw more 16K banks at it. Using LZ16 with 2 wasted offset bits bring this down to 6K. Using standard LZ12 it's 5K. So this seems like a good compromise; the RAM buffer is 50% smaller but the music data is only 20% larger and 2 such tracks would easily fit in a single 16K bank.
  8. It looks like it's the match offset bits that determines the size of the buffers required. For a quick test I took @dmsc's lzss.c code and hacked the maximum offset macro (max_off) so that it was half the normal size (1<<(bits_moff-1)). I then changed lz12.s so that each stream had a 64 byte buffer and it played OK. This does waste a bit in the match offset and (I presume) it would be better to set both the match offset and match length to 6 bits but I couldn't figure out the changes to lz12.s for that. With @Fragmare's TMNT track, LZ8 results in 6509 bytes of song data, LZ12 is 3080 bytes and LZ16 is 2796 bytes. With the above hack the LZ12 data increases to 3772 bytes but halves the amount of RAM required, 576 bytes of RAM instead of 1152. This seems like a reasonable compromise to me. Wasting another bit resulted in 4376 bytes with a total buffer size of 288 bytes, which is still quite a bit smaller than the LZ8 data with more or less the same buffer space.
  9. Something that's more of an advantage on the 7800 than it probably is on the A8, is that with the LZSS8 player you only need a 256 byte buffer which is a benefit with limited RAM. However that does tend to increase the size of the data quite a bit. I was thinking of taking the SAP-R data and running a standard RLE on each stream to see how much data that generates, see if it's more or less than LZSS8 (I suspect more).
  10. I added @DrVenkman's winner to the first post.
  11. Great, I did set the brightness for CRT as that is my setup too (but without the UAV). As she has thinner components the new robot needed to be slightly brighter than the Atari one. You do get audio with Dragonfly and the A7800, JS7800 and BupSystem emulators. The first three worked straight out the box - I set the [email protected] bit in the header and I could access POKEY at $450. BupSystem remained silent; the help says that for 48K ROMs nothing else is mapped. However it does support the XBoard interface and enabling POKEY through XCTRL got it going. I'm holding off getting a Concerto until it is ready for final production and don't want to spend too much time second guessing what might be wrong. It could be that it sees the write to XCTRL and assumes that an XBoard will be providing the POKEY. Or possibly like BupSystem it might not map anything else for 48K ROMs. These are both simple things to try, I'll PM you some test builds to see if any of those work.
  12. This is kind of pointless but it was an exercise in learning 7800 programming and a chance to dig into how the Atari robot demo worked (basically loads of graphics data). Thanks to @TIX for the new graphics, @Fragmare for the NES TMNT POKEY music. @dmsc for the LZSS compressor/POKEY player and @rensoup for RMT2LZSS. You can take control of a robot by moving the joystick left or right, port #1 for the Atari robot, port #2 for his lady friend. Pressing the trigger will change their respective colour, pressing select will change the road colour. Edit: to get audio on Concerto I padded it out to a 144K supergame cartridge. werobots.a78 we_sg.a78
  13. Actually I did put an Easter egg in there - after you have been playing the game for a long time you might get a fake crash followed by the credits.
  14. Great work on the emulator guys. When looking at the error log window, what causes the undefined MARIA and TIA reads? I assume they are generally nothing to worry about as I do see them in a lot of games?
  15. I wouldn't change the BIOS just for AtariBlast! since it doesn't make any BIOS calls. It does need CPU Services enabled on the Atarimax so that the game is able to read the level data from the atariblast.dat file. CPU Services are enabled by default but it's worth checking they haven't disabled in the Atarimax options, accessed by pressing * on the menu (see Atari 5200 Multi-Cart Documentation - Chapter 5 - Non-Volatile Menu Settings).
  16. Congratulations Darryl!
  17. For the 8-bit home computers a Joy2Bplus standard was proposed for 3-button joysticks: https://atariage.com/forums/topic/278884-2-button-joystick/?do=findComment&comment=4206381. It's probably fair to say it didn't set the world alight but there has been a decent amount of interest. There are now over 40 games which support it, mostly hacks but a couple of homebrews too. It sounds like you are aiming for more functionality than this, but perhaps it gives an idea of what sort of interest you'd get. With Joy2Bplus button 1 connects to the normal trigger line, buttons 2 and 3 to the paddle lines. It's not compatible with existing 7800 games because the trigger line is used to put the 7800 controllers in 2 button mode. However I have been able to use my Joy2Bplus joystick on the 7800 in my own code by clearing CTLSWB so all lines are inputs and reading INPT4/1/0 respectively for the 3 buttons (logic is the same for all buttons, the bit is 0 when pushed).
  18. I received mine yesterday, really pleased with it. Thank you so much Rafal.
  19. Obviously it's a bit odd with it working elsewhere, but Cybernoid2NtscPokey450.a78 crashed after ~5 minutes in A7800 for me. I ran it up with the debugger and it hits a brk instruction here: 193F: lda $1962 1942: cmp #$d4 1944: bne $18cb 1946: lda $1961 1949: cmp #$d8 194B: beq $195f 195F: rts 0001: brk Before it does the rts at $195F the stack pointer is $1FF so it's empty, hence where it ends up. I used dmsc's lzss-sap code on the 5200/A8 last year and I can't match that bit of code exactly but it does look a little like the test for the end of the song.
  20. Thanks for making these available, the sound effects in the library sound excellent and are really useful.
  21. Which you can, you don't need the programmer. You mount the .ATR programming image in D: (using something like APE or AspeQt), put a blank Atarimax 8mbit flash cart in your A8 and power up. The programming .ATR will boot and then proceed to flash the Atarimax cart. It does take quite a long time to flash an 8mbit cart this way. I used to set it flashing, go and have dinner (do the washing up, watch a bit of telly) and come back to it later. So when we were developing AtariBlast! the programmer sped things up. Nowadays we'd have used AVGCART or Ultimate Cart.
  22. This looks great! Could you please add me to the list for one with Pokey Max and YM2151. Thanks, Paul
  23. A quick question if anyone knows as it's just out of interest, but if graphics data is placed in RAM does Maria still require 3 cycles per byte or will it use 2 like the DLLs?
  • Create New...