Jump to content

playsoft

+AtariAge Subscriber
  • Content Count

    581
  • Joined

  • Last visited

  • Days Won

    2

Everything posted by playsoft

  1. With Dhor's great rendition of the music, Miker suggested using it in an A8 port of the demo I had running on the 5200. Attached are versions in a number of different resolutions for 8mbit AtariMax MaxFlash cart and 1088 Rambo memory expansion. I'd never considered epilepsy warnings before but I included one here since there is quite a bit of flashing with the strobe option. atarimax_bin.zip atarimax_car.zip rambo1088.zip
  2. Thank you for doing this and to everyone who replied. With a display of more than 192 scan lines, what would you recommend doing with the vertical blank and over scan... take half the extra scan lines off of each?
  3. Here are some from 2014/5 when I was doing ports to the 5200. wrk.zip
  4. I had used all 4 audio channels, so it should have been cpx #8. With cpx #4 it is only using 2 channels. I just tried and it sounds ok, but not as good as it does with all 4 channels.
  5. That will be it. The second value of the pair is an offset into the audc_data volume curve: ; AUDC volume curve, used for all notes audc_data: .byte $C5,$A6,$A6,$A6,$A6,$A6,$A5,$A5,$A5,$A5,$A5,$A5,$A5,$A5,$A5,$A5 .byte $A5,$A4,$A4,$A4,$A4,$A4,$A4,$A4,$A4,$A4,$A4,$A4,$A4,$A4,$A3,$A3 .byte $A3,$A3,$A3,$A3,$A3,$A3,$A3,$A3,$A2,$A2,$A2,$A2,$A2,$A2,$A2,$A2 .byte $A1,$A1,$A1,$A1,$A1,$A1,$A1,$A0 audc_data_end: .byte $00 When nothing is playing it should index the $00 byte at the end. Above audc_data_end - aud_data will result in a value of 56 ($38).
  6. Smeg! In this one if you only want the first two parts remove all the bytes in the .if 1/.endif in output.txt. red2.zip
  7. Hi Jason, if this is of any use I made an edit of the midi file from the sheet music link and converted it to (frame delay, AUDF) pairs in output.txt. I've included ca65 source for playing it. red.zip
  8. There is this one in the programming section: http://atariage.com/forums/topic/249885-atari-a8-donkey-kong-hack/page-11?do=findComment&comment=3497095
  9. That is truly excellent work. The big advantage of character mode is that it's character mode! All the advantages of characters and more games are written in it, so you should get good mileage out of your sprite routines. I am doing full and/or plotting. Looking at Delta there are lots of attacks where the sprites are all on top of each other so I don't think you would get away with anything less. It does lda/and/ora/sta for the draw and sta for the erase. If you add a background then you have to do lda/sta for the erase so it will reduce performance by about 1/6th. I added a background and tried the same sized sprites - no music though. 12x24 pixel sprites @ 25fps = 12 sprites and 70 scan lines remaining: modeE12hb1224.xex 8x16 pixel sprites @ 25fps = 22 sprites and 40 scan lines remaining: modeE22hb816.xex I did look into character sprites some time ago but I only wrote little test routines (it's complex!). Despite the faster erase it always seemed to turn out slower than bitmap mode for me (which was my primary interest). Ignoring the complexity of the code there are a few other areas where bitmap mode benefits: You only have to write the bytes that are actually used by the image. In character mode you have to copy the unused leading bytes in the first character and the unused trailing bytes in the last character. You can access screen memory with absolute addressing instead of indirect. So the lda/and/ora/sta is 2 cycles quicker. That might not seem like much but it is what the code is doing most of the time. I think less cycles are lost to DMA. With Delta I'm confident that bitmap mode can handle the 7 big sprites (12x21) and have more than enough time for everything else at 30fps (i.e. supporting NTSC). I still don't know about character mode though!
  10. I'm not keen on working on another shooter right now but it's always interesting to see what can be done with playfield graphics. You can get a nice lot of sprites on screen with a PM multiplexer but you are limited horizontally by the amount of flicker. Looking at the game it seems that when the playfield graphics appear at the top and bottom that the sprites do not move into them. This means you could use a bitmap mode which I think gives better performance than a character mode here. Implementing C64 sprites in software will require a compromise of some sort. In the attached tests, modeE7 runs at full frame rate under PAL with 74 scan lines spare but this will not be enough time to do everything else that Delta does (and NTSC is out of cycles already). The following tests use the number of scan lines to give a crude indication of how much processing time is left in the worst case (all images visible, largest sized frame spanning 4 screen columns). modeE7no = ANTIC E, 7 sprites, no PM DMA PAL: 248 - 160 = 88 scan lines NTSC: 248 - 236 = 12 scan lines modeE7 = ANTIC E, 7 sprites, single line PM DMA PAL: 248 - 174 = 74 scan lines spare NTSC: 248 - 248 = 0 scan lines ==== slowdown modeE7c4 = ANTIC E, 7 sprites, single line PM DMA, 4-byte column draw PAL: 248 - 160 = 88 scan lines spare NTSC: 248 - 240 = 8 scan lines spare ...but xex size increases by +12K and it's no longer a multi-purpose draw routine modeD7 = ANTIC D, 7 sprites, single line PM DMA PAL: 248 - 42 = 206 scan lines NTSC: 248 - 108 = 140 scan lines modeD14 = ANTIC D, 14 sprites, single line PM DMA PAL: 248 - 177 = 71 scan lines NTSC: 248 - 240 = 8 scan lines ==== slowdown modeE7h = ANTIC E, 7 sprites, single line PM DMA, half frame rate PAL: as modeE7 (74) + 312 = 386 scan lines NTSC: as modeE7 (0) + 262 = 262 scan lines modeE14h = ANTIC E, 14 sprites, single line PM DMA, half frame rate PAL: 248 - 84 = 164 scan lines NTSC: 248 - 249 = -1 scan lines ==== slowdown modeD24h = ANTIC D, 24 sprites, single line PM DMA, half frame rate PAL: 248 - 22 = 226 scan lines spare NTSC: 248 - 153 = 95 scan lines spare I'd probably opt for ANTIC D at half frame rate myself. It may not look as good (although designs done for this mode will improve their appearance) or as smooth but it is more fun to play around with more sprites. xexs.zip sources.zip
  11. The glitch has gone here, thanks.
  12. My Windows 7 machine has 2.70 installed and that gives the same results; the 32-bit version has the issue, the 64-bit version is fine.
  13. Running under Windows 10: 1.9 is 32-bit only and does not have the issue. 2.0 is 32-bit only and has the issue. 2.1 is 32-bit and 64-bit. The 32-bit version has the issue, the 64-bit version does not. I imagine this will be true for all subsequent versions as with 2.90-test22 the 32-bit version has the problem, the 64-bit version does not.
  14. I was running 2.80 when I first noticed the issue. I then updated to the latest 2.90 to see if it still occurred. I am running under Windows 10. I have been making my way back through the old versions and 1.6..1.9 are all fine, it is 2.0 where this starts happening. I will dig out my old Windows 7 machine, see what happens there.
  15. This is what I get: And someone else confirmed the flickering lines on Snow Plow, so I don't think it's just me.
  16. I noticed a minor issue when running Snow Plow - little flickering lines to the right of the display. The program reads the P0PL and P1PL collision detection registers quite frequently and I found if I removed them the flickering stopped. I put together the following test program. It displays lines of ANTIC 2/4/5/F/E/D, waits for you to press a key and goes into a tight loop reading those registers. ANTIC 2 and F are fine but the other modes appear to be showing data from the next byte. test.xex test.s
  17. Interestingly in Altirra when the plow is stationary I see flickering little lines to the right of the display. There are 3 in this image: Does anyone else get this? I do not see this on real hardware, I tested on both PAL and NTSC machines. I don't see it on Atari800Win PLus either. It seems to be reads of the P0PL and P1PL collision detection registers which are causing this. The program (unnecessarily) reads these quite frequently - if I take them out the little lines go away.
  18. I modified the program so that it will attempt to read files D1:SMAP.A, D1:SMAP.B, D1:SMAP.C etc. I created a new GETDIR function which just sets the DIRNAM file extension to "A". I created a new GETFIL function which tries to open the DIRNAM file and then behaves like the original GETFIL, either copying DIRNAM to MAPNAM or doing that jump out to MAP2. It also increments the DIRNAM extension so that the next time it's called it will try the next file in sequence. I also made one other change to clear down an area of memory which is displayed when you are right at the bottom. It is only a single scan line but depending on how you load it might not be empty. sp.atr
  19. Page 84 of the Technical Reference Notes (CO16555) clearly states: The opening of another diskette file while the directory read is open will cause subsequent directory reads to malfunction so care must be taken to avoid this situation. The first file loads fine since nothing has gone wrong at that point. That the second file loads is the nature of the DOS code. If you want to explore why the second works but not the third you will have to step through the DOS code and work out what it does!
  20. I only know Atari DOS but I like the idea of simply incrementing the filename extension.
  21. It opens the directory looking for matches with D1:SMAP.* and performs a get record to retrieve the first match. It then opens and reads the matching file. When you finish the level it performs another directory get record expecting to get the next matching file. Unfortunately that won't work with Atari DOS - opening another file while a directory read is open will cause it to go wrong. To fix it you'll need to keep a count on which matching file you want and each time open the directory, repeatedly call get record until you reach the one you want and then close it.
  22. Hi Jason, I just meant a standard MaxFlash 8Mbit cart which I'd flash initially - you would still be able to reflash it. Had I decided to do a cart release I would have been able to buy MaxFlash carts without a label so that I could print and attach my own. So it would have been exactly the same cart h/w, just with an AtariBlast! label instead of a MaxFlash one. I imagine the same is true of your Space Harrier cart and you could reflash it (not that I'd advise this, since you would lose your save data). I've only used the cart for AtariBlast! (I also converted HawkQuest for Harvey to eliminate the disk swapping). While I was able to generate a Rambo 1088 version of AtariBlast! it required different code because the bank switching is different. On the MaxFlash cart it is a 8K bank at $A000, on the Rambo it is a 16K bank at $4000. So having a MaxFlash cart won't let you run expanded memory games unless the author decided to make a version for it.
  23. Hi Jason, In the October 2016 Update with new music - Various formats link you posted ab_cart.zip contains the MaxFlash 8mbit cart version. There are 3 files in the .zip: (1) atariblast.car - This is the ROM image with a cart header. This can be used with Electrotrains' Ultimate SD cart and it is also the best file to use under emulation (since it should run in pretty much any configuration). (2) atariblast.bin - This is the plain ROM image without any headers. If you had a MaxFlash 8Mbit flash cart and a MaxFlash USB Programmer this is the file you would use to flash the cart. Run MaxFlash Cartridge Studio and select Cartridge - Program - MaxFlash 8Mbit Flash Cartridge and select this file. (3) atariblast.atr - This is the "programming ATR" disk image which can be used to flash a MaxFlash 8Mbit flash cart without the MaxFlash USB programmer. However you do need something like SIO2PC to boot the disk image. Insert the cart in your A8 and power up, the disk will boot and you can proceed to flash the cart. Note that if the cart has been previously programmed it may prevent the disk boot. If this happens then try holding down the Option key when you power up (that is a convention for allowing the disk boot which might be supported). If that doesn't work then you will have to do a live insert of the cart - boot without the cart and insert it afterwards... I have one machine which is fine doing this but another which crashes more often than not. When we decided to move from disk to the MaxFlash cart we knew it would restrict it being played on real h/w. To offset that a bit we decided it should be limited to 16K RAM so that those with a MaxFlash cart could play it on any machine. The MaxFlash cart is the primary version, the Rambo 1088 and MegaCart versions were requests that I was able to support. It's just a hobby and I don't want to commercialise it by selling anything. However I do appreciate there may be people who do not want to flash a cart themselves. Currently the MaxFlash 8Mbit carts cost $40 + $6 p&p individually or $100 (free p&p) for 5: http://atarimax.com/flashcart/documentation/ If anyone in the UK wants a cart I am happy to buy one and flash it for you. With the current exchange rate the cost per cart is £16 ($100 = £80), add a jiffy bag and postage it will probably come to about £20. Or if you already have a MaxFlash 8Mbit cart but do not want to reflash it yourself you could send it to me with return postage (but make sure it is a 8MBit cart, not a 1MBit one). PM me if interested. Cheers, Paul
  24. The cart versions of AtariBlast! run on a 16K machine (but you do need a 1024K MaxFlash cart or MegaCart).
×
×
  • Create New...