Jump to content

playsoft

+AtariAge Subscriber
  • Posts

    647
  • Joined

  • Days Won

    3

Posts posted by playsoft

  1. 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
  2. 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
  3. 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
  4. 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
  5. 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
  6. 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
  7. 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
  8. 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
  9. 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
  10. 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
  11. 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
  12. 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
  13. 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 pokey@450 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
  14. 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

    • Like 17
    • Thanks 1
  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).

     

    • Like 1
  16. 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).

    • Like 1
×
×
  • Create New...