playsoft

It seems to me like the A8 original game also takes a long time to activate the shields but it does have flip over, hyperspace and no effect - where the 5200 prototype has shields regardless of the selection. Edit: Looking at the A8 original 8K cart every byte appears to be used; on the 5200 prototype it looks like there's about 1.5K free so maybe flip over and hyperspace were removed.

This is what I'd expect from the (unhacked) 5200 prototype. It allocates the dead zone based on the range of values it gets from the controllers so it won't know that range until it's seen a full up/down/left/right on the joystick. Once it's had that it's playable. It would be best to use an image dumped straight from the prototype cart but I don't imagine the controller code was modified. I am sure the first thing Atari would have tried is a simple fixed threshold. Perhaps this more sophisticated method was an attempt to improve on it that backfired and it just happens to be this prototype cart that was found. Or it's over engineering. Or all of your consoles are out. When I next set up my 5200 I will see how the unhacked prototype plays for me.

Well I guess you're never going to tell me what values you get from your controllers, so here is the original Asteroids port hacked to use a fixed threshold (same as Wing War). I've only tested controller #1 under emulation but if it works for you please do not call it a "fix" or the original port "botched" because I suspect there is nothing wrong with it, just that the more sophisticated threshold algorithm might not work so well on a 38 year old console that has never been recalibrated. By the way I don't know where your 16K image comes from but the two 8K halves are identical other than what looks like 3 rows of screen data containing: COPIED CFE SERVICES HARDIE Asteroids_hack_8K.bin

I think this is everything I've done on the 5200. Note that .hyb files only work on the Atarimax Ultimate SD. I did not include the 5200 hacks with Darryl since he has them all available here. 5200.zip

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 ?

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?

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

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.

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

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)

All I can say is it works fine for me with my CX52.

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

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

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

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.

I don't know why you can't download it, so I have put it here as well.

It would make a cool pause screen. You could leave yourself notes for when you come back to the game.

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.

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

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

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

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

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

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.

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.