Jump to content


+AtariAge Subscriber
  • Content Count

  • Joined

  • Last visited

  • Days Won


Posts posted by playsoft

  1. Looks great, opens the door to using the 822 in games! (print maps etc...).

    Strange, my 822 seems to need the $4C in my test program; with Aux1 set to $00 there's no printer output at all, just farting noises; with it set to $4E I get normal text output, not bitmap.


    • Like 1

  2. I don't know if this will help but I disassembled the code from the owner's manual to see what it was doing.

    Basically if you send a SIO Put with Aux1 set to $4C ('L' for Line perhaps) then instead of printing the 40 bytes as characters it prints a single line of 240 pixels (the last 10 bytes are not used - although you do seem to have to send them).

    The attached test.s continually prints lines of random data out on the 822:


    The code in the owner's manual prints the screen out sideways; I attach the disassembly for that which I've commented but haven't done anything else with.


    test.s test.xex commented.s

    • Like 1

  3. 2 hours ago, Synthpopalooza said:

    I for one would love seeing Galaga on 5200 or 8-bit.聽 If 2600 can do it, why not us?

    Thoughts on sound ... WSG by Namco has 3 sound channels.聽 I'd do this:

    1 16 bit channel:聽 Alien death sounds.

    8-bit channel ... ship firing, ship destroyed

    8-bit channel ... aliens swooping, tractor beam sounds

    $Cx in 16 bit will exactly nail some of those alien death sounds.聽 馃榿

    Look forward to hearing them!

  4. 2 hours ago, rensoup said:

    Since you have the luxury of having 2 musicians, you could release 2 roms, each with its own set of tunes聽馃榾

    (...if you resume work on it聽馃樁)

    Yes I've set the build up to generate two versions. I am working on something else at the minute, so will see if I get back to it after that.

    • Like 1

  5. 11 hours ago, Synthpopalooza said:

    OK, this is all for tonight ...

    To step thru fx, hit start.

    Tractor beam 1, Tractor beam 2, Tractor beam 3, Insert coin fx

    The last one isn't quite to the arcade specs yet tho ...

    galaga-soundfx.asm 12.43 kB 路 3 downloads galaga-soundfx.s 11.18 kB 路 1 download galaga-soundfx.xex 1002 B 路 5 downloads

    They are really good. Obviously it might be quite a while before they are used, but I've pulled them into the player alongside the start tune. I'll keep it organised with anything you post.

  6. 2 hours ago, rensoup said:

    So the main glitch I'm hearing is 2-3sec in. After listening to the 60 version, it seems that the glitch is also there but not as loud (although it can be sometimes). Maybe that's something that can be fixed in the tune ?

    It seems that the same executable (no matter which) can sound slightly differently every time you start it.聽 So the glitch will be louder from time to time.

    I have very little knowledge of Pokey but聽maybe it's due to the chip itself ? I recently tried messing with SFX in RMT. I had a very short tune which just played the same SFX over and over again and it would sound different from time to time.

    I can't say resending the same data makes a difference ?

    I'm not sure 30 sounds very different from 60... so聽this could be聽pretty good news! Have you tried with the other tunes ?

    Not sure if you modified the LZSS compressor to skip half the data but you could just call the RMT player twice per frame(so at 120hz) because Altirra only records the SAP data once per frame anyway

    (I'm using headphones and I don't have super ears either...)

    I've not tried the other ones at 30Hz yet. I took the 60Hz SAP files and created new 30Hz ones from them by leaving out every other set of register values. They all sound much of a muchness to me and I didn't notice any difference resending the data again.

    I don't think I hear that glitch but it might be more noticeable with headphones - I don't have any but I will connect my A8 up to my hifi tomorrow and see if I can hear anything.

  7. 52 minutes ago, rensoup said:

    Yes there seems to be a click... just curious, have you tried resending the last data to pokey instead of skipping playback altogether ? (I'm guessing it will聽sound worse but you never know)

    I suppose lzs16 is out of question.... @dmsc聽once mentioned that if you have a lot of compressed tunes it might be possible to compress them together聽usinga fixed dictionary if the instruments are similar.

    I've not tried resending the last data, will give it a go.

    What was going to be my final experiment was to take the 60Hz SAP, remove half the samples for 30Hz playback and spread the decoding effort over 2 frames (half the channels on the odd frames, the rest on the even). The start tune LZSS went from 751 bytes to聽461. I'm probably not the best to compare how they sound as my hearing hasn't improved with age...

    Edit: both of these now repeat the last data when the registers aren't updated.

    jaden_5200_30.bin jaden_5200_50.bin

  8. To convert from RMT to SAP-R I export the RMT to a XEX and then record the SAP-R in Altirra. When doing this it makes a difference whether Altirra is configured for PAL or NTSC; in PAL it records the audio registers 50 times a second but in NTSC it's 60 times resulting in a bigger file.

    I did this for all of Jaden's RMT files, making PAL and NTSC versions of the SAP-R files and then compressing them with LZSS -8:

    RMT FILES                               LZSS PAL FILES                  LZSS NTSC FILES
    205 Galaga - Challenging Stage.rmt       96 challenging_pal.lzss        102 challenging_ntsc.lzss
    144 Galaga - Extra Life.rmt              74 extra_life_pal.lzss          87 extra_life_ntsc.lzss
    292 Galaga - High Score.rmt             291 high_score_pal.lzss         372 high_score_ntsc.lzss
    147 Galaga - Insert Coin.rmt             37 insert_coin_pal.lzss         42 insert_coin_ntsc.lzss
    670 Galaga - Perfect!.rmt               319 perfect_pal.lzss            570 perfect_ntsc.lzss
    309 Galaga - Results.rmt                283 results_pal.lzss            356 results_ntsc.lzss
    366 Galaga - Start.rmt                  598 start_pal.lzss              751 start_ntsc.lzss
    2,133 bytes                             1,698 bytes                     2,280 bytes

    I generated 2 versions of the build with the start tune - the 60 version uses the NTSC data, the 50 version uses the PAL data but skips the playback routine 1 frame in every 6 to correct the speed for NTSC.

    The advantage of the 50 version is that the data is smaller but I think you can hear a slight difference between the two.

    jaden_50.xex jaden_60.xex

  9. 27 minutes ago, Jaden (JRH) said:

    I've tried out the demos you sent over Playsoft, and I can't help but notice how harsh my music sounds on them. Is that because of the compression or is it something that I could fix? Because I'm not sure why they sound like that. Synth's version sounds perfectly fine. However, there are definitely some notes near the end that need fixed and I'm not the biggest fan of the waveforms used.

    Haha I thought you intended that distortion! If you play your file in RMT there's no distortion but if you export it as an Atari executable you get the distortion (you can try it, just select "file -> export as" and choose XEX).

    I think the distortion is caused by having the volume too high in the instrument envelope. I changed it from FEDC to 7654, exported it to a XEX and it sounded fine.

    • Like 1

  10. I generated builds using the two tunes. There's not really much in it, Synthpopalooza's is slightly smaller and requires less cpu cycles although it is not as consistent.

    I did try the sap/lzss process on Synthpopalooza's but it did not compress as well as Jaden's, presumably because of the 16-bit values.

    jaden_5200.bin synth_5200.bin

    • Like 1

  11. 13 hours ago, Jaden (JRH) said:

    The midi one sounds pretty good and the CPU cost and size are right in the middle of the other ones. So, if you good sounding music that doesn't take up much space or CPU time, midi might be the way to go

    I much prefer your RMT one over the midi (plus that was the only midi file I could find, so the other tunes would be missing) and with the LZSS compression it's much more viable to include them.

    I really don't know if the remaining functionality will fit in a 32K cart anyway - and if I do target a bigger cart I can turn the other sprite drawing optimisations on.

    • Like 1

  12. 41 minutes ago, rensoup said:

    I'd聽never heard of games dynamically blanking parts of the screen before.聽

    I used to think that blanking was for the top and bottom part of the screen and if you started messing with it dynamically, the screen would lose its sync or something.

    (Now that I'm thinking about it, Antic blanking may be different from screen blanking ? otherwise the sprites would vanish ?)

    Ah yes, blanking with DMACTL would be daring, I just put the blank scanline codes in the display list ($00..$70).

  13. On 3/28/2020 at 12:29 AM, rensoup said:

    You're dealing with some pretty severe constraints but you could use LZSS with a 256 bytes buffer and bad compression

    LZSS is compressed raw Pokey data so any player can be used... Out of curiosity I tried compressing one of @Jaden (JRH)'s tunes:

    Galaga - Perfect!.rmt 聽聽 聽聽聽 聽(670 bytes)

    Galaga - Perfect!.lzs8 聽 聽 聽(345 bytes)
    Galaga - Perfect!.lzs12聽聽 聽聽聽 聽(298 bytes)聽
    Galaga - Perfect!.lzs16 聽 聽 (264 bytes)

    Even at the worst setting it's half the size, so all those tunes would probably take just 1KB of ROM.

    galaga_perfectLZS.obx requires less than 300 bytes of RAM (ZP is optional and speed dif is minimal) and the player takes around 128 bytes of ROM.

    I've included the test files, now compare the CPU usage for LZS and RMT and laugh all the way to the bank...if you ever聽decide to pick that project up again of course聽馃槃

    galagaLZS.zip 6.31 kB 路 3 downloads

    Thanks, that's fantastic, it certainly makes a difference to the cpu and memory overhead.

    As a comparison I tried 3 different versions of the start tune; the 7800 one, a midi file conversion and Jaden's RMT using LZSS (I used the 12 bit one for this).

    In terms of what they sound like, Jaden's is obviously by far the best.

    In terms of cpu cost, the 7800 is cheapest, then midi, then LZSS - appears to be a little over double the 7800 cost.

    In terms of song size, the 7800 is 100 bytes, midi is 180 bytes, LZSS is 344 bytes.

    In terms of player size, LZSS is the smallest although the 7800 does have other things in there for sound effects which are not used by this tune.

    I can't say there would be the resources available for it in a 32K cart but it definitely makes it more viable.

    vcs.xex midi.xex jaden_start_lzss.xex

    • Like 2

  14. On 3/28/2020 at 12:29 AM, rensoup said:

    Oh, you're variably blanking in the middle of the screen?... a daring move 馃榾. The screen seems pretty full at times though... Plus a whole bunch of DLis for repositioning the PMG stars... ouch!

    It's pretty rare that mode4 is useful but this is a good showcase for it !

    No nothing daring - both the screen map and the display list are double buffered, so with the off-screen buffer erase the old sprites, draw the new ones and create the display list so that it only has ANTIC 4 rows for those on which sprites were drawn.

    You are right, there are single line incoming waves where there may only be a couple of ANTIC 4 rows empty but I think that's enough to cover the overhead of doing this. I roughly estimate there are 100 cpu cycles available on a blank scanline and 50 available (averaged) on a scanline that is part of an ANTIC 4 row. So each one omitted claws back around 400 cycles (minus the overhead).

    In this case where the sprites are spread out vertically the other optimisation kicks in; because of that spread they tend not to overlap much, so the blank character optimisation gets used a lot.

    The opposite scenario is when they are all grouped together moving to their formation positions. Here the blank character optimisation isn't used much but removing the ANTIC 4 rows is.

    The two optimisations work so well together I could probably convince people it was all planned out like this in advance...聽馃榾

    • Like 2

  15. 11 hours ago, rensoup said:

    Very nice demo, seems like a lot of pixels are pushed around!

    Have you considered dmsc' LZSS player ? It's basically compressed SAPR. Most of the time the files are usually the same size or smaller. The player is tiny but the buffers can be expensive, up to 9*256 bytes (depends if you want good or average compression on the tune ).

    Speed is where it really smokes the RMT player, about 8-10 scanlines.

    I don't know if you need to play sfx and music at the same time, which might be a problem?

    Thanks, being a space game I was able to make a couple of good optimisations with the sprites; (a) when drawing over a blank character just write the new data straight out, (b) replace any ANTIC 4 display list entries with blanks if nothing is drawn on those rows.

    I haven't picked this back up yet and I'm not sure I will (a bit too much pressure for me). I was aiming for a 32K cart - and there is about 8K ROM free and about 4K RAM free. There are times when it can't maintain 60Hz so I flicker one of the sprites. It's barely noticeable as it's 1 sprite in 10 and doesn't happen very often or for very long. I can speed up the sprite drawing but that costs another 5K ROM.

    I don't know if the remaining 8K ROM/4K RAM would be enough for everything else. It probably is a bit tight, so if it did need a bigger cart that might be the time to consider a more sophisticated music player, although to my non-musician ears I'm not sure the music in Galaga needs it - like Synthpopalooza says above, it might be more a case of mimicking the Namco sound chip.

    • Like 1

  16. On 2/23/2020 at 4:56 AM, -^CrossBow^- said:

    I was playing this in Altirra a bit ago and it is really cool! I was able to get 2 crystals so far and then did a save state on the world 3 password screen! I like how it is a wonderful mix of robotron, shamus, and berzerk. Is this an original game you created on the 8-bit series and ported over or your take on another game?

    Plus there are platform and puzzle elements too... I loved the snake puzzle.

    • Like 1

  17. It looks like a bug to me as you now have it crashing at the same point in 2 different scenarios. In Altirra with collision detection disabled the ROM image is unchanged, the collision detection registers simply don't report collisions. The hack tested on real hardware simply loads a 0 instead of reading the collision register.

  18. I hacked the 5200 ROM image from Atarimania to stop it reading the PM collision registers and it still crashes at the same point (the phoenix, not the spaceship) on real h/w:


    As there's no warp speed available on real h/w it does take over 11 minutes to get there, so maybe no one's ever got that far. Or perhaps there's a version of the prototype out there without this issue. I see you can buy a 5200 cart of it from the AA store, does anyone know if the ROM image used here was made publicly available?

    From the debug log in Altirra it's going out of bounds in a jump table. I imagine it will be tricky to fix given it's OK the first time round.


    • Like 1

  19. 9 hours ago, pixelmischief said:

    Thanks for weighing in Mr. Fish!

    Tell me.聽 Why do people still adhere to such a, now, unnecessary limitation.聽 I get that it was necessary "back in the day"; to maximize adoption.聽 But there's no need to live with ANY improvable aspect given that there are no commercial concerns and people are doing this for the love of it.聽 I wonder noone has done a disk version that fixes everything.聽 Or a 32K cart.聽 Or something that requires 64K.聽 I can understand loyalty to the original 400/800, but not to the extent that something both excellent and beloved could be made moreso.

    8 hours ago, MrFish said:

    Keep talking, and maybe Playsoft will get interested enough to revisit the hack...

    The hacked version is no longer bound by the 16K ROM/16K RAM limit but hacking the game from single buffer xor sprites to double buffer fully masked sprites is a bit much for me. It could probably be done by the original author though.

  • Create New...