Jump to content

playsoft

+AtariAge Subscriber
  • Content Count

    525
  • Joined

  • Last visited

  • Days Won

    2

playsoft last won the day on August 7 2018

playsoft had the most liked content!

Community Reputation

871 Excellent

About playsoft

  • Rank
    Dragonstomper

Profile Information

  • Gender
    Male
  • Location
    UK

Recent Profile Visitors

11,398 profile views
  1. For general compression I tend to use LZ4 on the A8/5200 and have made a quick 7800basic test. I'm not that familiar with 7800basic so I probably haven't interfaced to it in the best way. Basically you need to set 3 variables; the LZ4 data source address, the destination address and the destination end address then call lz4_decode. The lz4_decode routine needs 6 bytes in ZP for pointers, plus some other variables which can go anywhere (these are all temporary and only needed for the duration of the lz4_decode call). The my_lz4.exe command line program is the standard LZ4 code with the header information removed, just run this with the file you want to compress (e.g. my_lz4 graphics\image.dat). test.zip
  2. Yes it looks like Quick Step and Wing Wars were both written for cart but ended up on a compilation disk, so it seems they were cutting their losses on the Atari 8-bit computers.
  3. Ray, The Asteroids code keeps track of the lowest and highest values it reads from each POT. It splits this range into quarters so that a value in the first quarter is up/left and a value in the last quarter is down/right. The other 2 quarters form the dead zone, which is 50% of the range, which ought to be enough. A perfectly operating POT would give values in the range $00 to $E4. You probably won't get that but you want the range centred around the mid-point. The CX52 I have plugged in a the moment reads $0F/$CE/$09/$D7 when fully up/down/left/right. Run the attached cal.bin to see what values you are getting from your controller. cal.bin
  4. Ray, you could always try another game which uses the alternate button and see whether that works. The instructions for the A8 version can be found here: Imagic 1-2-3.pdf (atarimania.com)
  5. All I can say is it works fine for me with my CX52.
  6. Your mileage may vary with these quick conversions. Both were new to me, so no nostalgia and I can't get into playing either of them. I like that Wing Wars keeps everything very simple (no scrolling, basic P/Ms) but it does the job OK. I changed the controls so the second trigger launches a fireball, no need to hold the joystick down. There is some impressive programming in Quick Step where it changes colour registers on the fly each scanline so that every individual item of food has a totally independent colour. ww.bin qs.bin
  7. Perhaps the lime green is yellow? The 7800basic IRQ routine, which is triggered when the 6502 executes a BRK instruction, will set the background colour to yellow (colour value $1A) and halt the 6502. The BRK instruction has an op. code value of $00 and usually wouldn't be used, but $00 is frequently found elsewhere (in data, RAM). So when a BRK instruction is executed it's normally a sign that something's gone wrong. A quick test would be to change the colour value that the 7800basic IRQ uses and get @john_q_atari to retest; if it freezes with the new colour then you know the IRQ is being triggered. It's probably not the same thing but during the development of Popeye Darryl encountered intermittent IRQs on Dragonfly that did not occur in emulation or on the versa-cart. Mike added the crashdump so that the IRQ routine displayed the contents of the stack and we could see that the BRK instruction executed was the $00 part of a BEQ $00 instruction. BEQ $00 is pointless in that regardless of whether the branch condition is true or not, the next instruction is executed. However it ought to work and it did most of the time as the issue was intermittent. So there would seem to be specific conditions under which BEQ $00 can cause a fault running from Dragonfly. Looking at why 7800basic generated the BEQ $00, one instance was: if popeyeDeath > 0 || IntervalCount <> 3 then returnMoveLetters Which generated: 30884 10e91 .L02435 ;; if popeyeDeath > 0 || IntervalCount <> 3 then returnMoveLetters 30885 10e91 30886 10e91 a9 00 LDA #0 30887 10e93 cd 5a 01 CMP popeyeDeath 30888 10e96 b0 03 BCS .skipL02435 30889 10e98 .condpart1157 30890 10e98 4c a1 8e jmp .condpart1158 30891 10e9b .skipL02435 30892 10e9b a5 ff LDA IntervalCount 30893 10e9d c9 03 CMP #3 30894 10e9f f0 00 BEQ .skip439OR 30895 10ea1 .condpart1158 30896 10ea1 .skip439OR Not only has it generated a BEQ $00 but it doesn't jump to returnMoveLetters at all. To get around this Darryl made every goto explicit and changed any label names which started with a keyword (in this instance returnMoveLetters starts with return).
  8. I've recently experimented with the YM IRQ and it works well. I was resampling VGM files but at 50/60Hz the main instruments weren't too bad but timing for percussion was out. So I used the YM IRQ and resampled at a higher frequency. Attached is the VGM for Shinobi playing at about 2kHz (you can change tracks by pressing the trigger). shinobi.a78
  9. That is what I intend to do - eventually! For now, if you press reset you take over control, left trigger to fire, right trigger to turn. Collision detection with enemy sprites/missiles is disabled as it is impossibly hard. You can still collide with the guns though.
  10. I don't know why you can't download it, so I have put it here as well.
  11. It would make a cool pause screen. You could leave yourself notes for when you come back to the game.
  12. 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.
  13. That's (the 113.5 cycles) a very good explanation for why the interrupt position moves rightwards. Thanks!
  14. 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
  15. 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
×
×
  • Create New...