Jump to content

playsoft

+AtariAge Subscriber
  • Content Count

    578
  • Joined

  • Last visited

  • Days Won

    2

Posts posted by playsoft


  1. 15 hours ago, BIGHMW said:

    I actually wanted to open up my CX52 but because it's a Best Lifetime Gold one I didn't want to void the warranty on it, and, I also tried my new Best Lifetime CX24 7800 stick (through my Pixels Past/AtariAge Redemption 5200 - 7800 Edition I got almost 10 years ago), and found out the problem was not my controllers, it's the program itself, as my other Asteroids-like programs, Star Island (that you successfully converted for both @phuzaxeman and myself, thanks I still enjoy both it and Yar's Strike you also did last year), Delta Space Arena, Meteorites, and Megaoids, all run fine, everything seems normal on those ones. 

     

    I also wanted to ask that since I mentioned on this thread that I would be willing to pay someone here on AA to do it, as long as it's not a lot, as I am on a budget, as we have such tremendous programming/converting talent here on AA including you BTW, that if maybe for a fee if you can fix 5200 Asteroids or just simply re-port the 8-bit version to the 5200, which ever is the easier fix, and I can provide both my PayPal address (to send the money) and also the two ROMs in question if you can do this for (not only) me but for others who might want to try it out as well. Thanks. :) 

    You open up the console, not the controllers. There are 2 adjustment pots on the 5200 motherboard, one to adjust the colour, one to adjust the controllers. 5200 owners should make themselves familiar with the controller calibration process as it will need doing at some point. You've had your 5200 for 30+ years and have never recalibrated so there's a possibility it might be out. That you don't see the issue with other similar games doesn't necessarily mean your calibration is good as you might be getting away with it on games with simple fixed thresholds but not with Asteroids which uses dynamic thresholds. Checking the values read from your controllers would indicate the state of your controller calibration.

     

    I don't think it's worth doing anything with Asteroids unless you can show that your controller calibration is good. I don't mix hobby and money... you couldn't afford my rates anyway 😀

    • Like 2

  2. 11 hours ago, BIGHMW said:

    That's the same problem I have with both it and the 5200 port of the OG version, the controls on your ship spin, but a little herky-jerky action with the joystick (regardless digital CX24 or analog CX52) and it's as good as playable, and, as seen on my video review of Asteroids it's when it goes between thrust and shields that is when I have THE most trouble with those two ports, sometimes thrusting out of control, causing me to lose complete control of my ship and crash into either space debris or an enemy UFO, and that is what plagues this port in which was why I suggested the re-port, as the 8-bit version doesn't seem to have this problem (and I have played both).

    Have you checked what values your controllers are returning with that cal program, if so what were they? It might be that you need to calibrate your 5200, when was the last time you opened it up and performed controller calibration? 


  3. 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

    • Like 2

  4. 10 hours ago, bohoki said:

    i guess they didnt feel they sold enough units to make it worth while they made plenty of games for the c64

     

    demon attack,moonsweeper,dragonfire,chopperhunt,nova blast

    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.

    • Like 1

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

    • Like 2

  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

    • Like 5
    • Thanks 1

  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). 

     

     

     

    • Thanks 1

  8. On 4/21/2021 at 11:09 AM, rj1307 said:

    This is not true, no one is using the IRQ for YM yet. 

    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

    • Like 2

  9. 5 minutes ago, gambler172 said:

    worked now....there was something wrong with the connection....

    btw....how about a playable demo?

    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.

    • Like 3

  10. 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.

    • Like 2

  11. 17 hours ago, RevEng said:

    Very cool demo!

    Inaccuracies are likely due to a scanline length of 113.5 1.79MHz cycles (not 114 cycles like the A8), and the clock slowdown affecting Pokey whenever you access TIA and RIOT.

    That's (the 113.5 cycles) a very good explanation for why the interrupt position moves rightwards. Thanks!

    • Like 2

  12. 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

    • Like 8

  13. 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

    • Like 2

  14. 10 hours ago, Defender_2600 said:

     

    734421371_7800MarioBrosin320Cmodec.thumb.PNG.3ab880742d170670cf3d9fad9ead7935.PNG

     

     

    1 hour ago, darryl1970 said:

    I WANT to understand that this means.

     

    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).

    • Like 3
    • Thanks 1

  15. 9 hours ago, rensoup said:

    Nice!

    Weird, Shouldn't 

     

                            bits_moff = 6;
                            bits_mlen = 6;
                            bits_set |= 8;
     

    do that ? I've not really played much with custom settings though

     

     

    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.

     

    • Like 1

  16. 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.

    • Like 2

  17. On 2/26/2021 at 11:19 PM, rensoup said:

    Looks like more folks are using LZSS on the A7800 than on the A8... how ironic considering Pokey isn't standard on the A7800 😏

    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).

    • Like 1

  18. 7 hours ago, DrVenkman said:

    Looks gorgeous on real hardware with a real CRT through S-video (UAV), but no audio when played on my Concerto with POKEY installed. 

     

     

    IMG_6167.JPG

    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.

     

     

    • Like 2
×
×
  • Create New...