playsoft

Oh that's great! He does some fantastic games on the Speccy and was gracious enough to let me port one of them to the 5200/A8.

Is that Dave Hughes of ZX Spectrum fame or one of the other (lesser) Dave Hughes?

Thanks for the suggestion, I have a couple of ideas to try out.

No. So that it's accessible to as many people as possible, I'm sticking to a regular cart format. In this case a 128K supercart with 16K RAM as used by Epyx in their Summer Games and Winter Games. Not that I've extensively tested it, but it seems to run OK under ProSystem. It also seems to run well on Concerto, just some minor glitching on the title screen.

I made a youtube video of it in action:

@kiwilove and I worked on this quite some time ago, but it was sidelined for various reasons. We've picked it up again and hope to make something playable from it. Your task is to destroy all the turrets on the dreadnought, collect a hostage and return to the launch bay. This is complicated by a host of different enemies attacking you. Use the joystick to move your ship, left trigger to fire and right trigger to flip direction. If you destroy a dragon, it will be followed by a pickup that you can collect: S = Shield boost P = Protector W = Weapon upgrade The game finishes when your shield is fully depleted. There will be 7 dreadnoughts in total, but I've only sequenced the first 2 so far. ttda_0.1.a78 ttda_0.1.bin

From the VGM file you could (write a program to) generate a SAP-R file. For each frame, the SAP-R holds a record of all the POKEY (audio) registers. At 50 or 60 frames per second this can be quite big, but you can compress the SAP-R with @dmsc's SAP-R compressor and player: GitHub - dmsc/lzss-sap: LZSS compressor for Atari SAP music files

It looks good to me. I built a quick test program and it is working correctly. I don't think I made any changes (other than to adapt it to ca65) although I hardcoded it for NTSC only. scroll.a78 build.zip

I wrote the code, @TIX did the graphics and @miker contributed the C64 POKEY music. Prior to the Atari take over, @Albert had suggested changing the name and releasing it in the store but I was not comfortable doing that. If you are interested and can get licensing then I have no issues with it being released.

Thanks for playing Dungeddon! I didn't have time to add difficulty options, so the first three rounds are really for beginners and the fourth round is harder with enemies requiring multiple hits. It was disappointing to see the "Might it be that you have your cooked game and wait for the tile set to use?" comment by vitoco8bits. I imagine I'll be told it was a completely innocent question but to me it's an implication of cheating. The source code is in the zip file so anyone can see what I did and, by looking at the timestamps, when I did it.

I have 8 different enemies. They use simple paths but the graphics make them nice to look at if nothing else. For most of the enemies I can vary their number and how many hits they take. I may try for lots of enemies in the early rounds where a single hit kills them. Then in later rounds, where they need multiple hits, reduce their number. That's the theory anyway. I also have a large boss like enemy but it's very basic. I'd have liked to have done more with it but I have run out of time. None of the enemies are sequenced yet so that's what my remaining time goes on. Yes, I draw them as 77 tiles, each 16x16 pixels. It's good to know that drawing larger blocks will help - that would be an interesting part of owning a Lynx, trying out different blocks and seeing how they behave. I reduced the number of enemies yesterday but I still felt anxious because I can't tell when slowdown occurs under emulation. So I had a late night and made most of the changes for 30Hz. It doesn't look too bad as a lot of the enemies only moved left every other frame anyway. Probably the thing I notice most is that the flight of the arrows is not as smooth.

Thank you for checking. I will reduce the enemies down to a maximum of 15 and proceed with that. I already chain all the sprites together and only call tgi_sprite once per frame. There are a couple of optimisations which I haven't made. I'm used to coding on the 6502 and I missed that the 65SC02 has a jmp (abs,x). That would make my state machines quicker but I would have to swap my usage of X and Y in a lot of places and I would make too many mistakes. I can optimise the arrow collision detection by sorting them, it's just a question of time...

Thanks! DUNGED.LNX

I don't own a Lynx and normally wouldn't code for something that I don't have, but I entered the jam to get a taste of developing for the console. I ended up doing a scrolling shooter which probably has a lot in common with @drludos's entry. While it runs fine on Handy, Mednafen and Felix, it sounds like I'm going to be in for a disappointment when it comes to real hardware. I used 16x16 pixel tiles for the background, 7 rows of 11 tiles. The player, bow, 8 x arrows, 20 x enemies, 8 x axes, 5 score digits and 3 life indicators total to 123 SCBs which I chain together. Monitoring resource usage by modifying the palette, this is what I see on Felix when the screen gets busy: The white area represents the SCB processing, the green area the game logic. It returns to grey when the game logic has completed, so there are still some cycles free before the next frame. Attached is a test build with invincibility which continually repeats the attack from the screen shot. If anyone has the time to try it on a real Lynx I'd appreciate hearing how it performs. I will prepare myself for the bad news! I've not finished the game yet and don't think I will have time to convert it to 30Hz as well. Thanks, Paul DUNGED.O

It's going back a bit now, but from what I remember the original program is mainly graphics data. So it was just a question of understanding the disassembly enough to be able to extract that from it.

No I don't.

Yes, it was a great idea and works really well in 7800basic. For the vertical scrolling project we have allowed for a variable number of palettes per row, but here it's just a single palette per row. If you used a single palette for the whole playfield then you could use plotmap and wouldn't need much in the way of assembly code at all.

I have been helping with a 7800basic project that requires vertical scrolling and the idea of adding extra objects to the bottom row to use up all the Maria cycles seems to work very well. In case it is of any use, attached is the source for a demo program making use of the technique. scroll.zip Edited to add another example, this time using tiled graphics: basic.zip Darryl drew the sprites, the background graphics are from: Omega Team | OpenGameArt.org

I think both of these issues are down to Concerto. I have a POKEY in mine and while I don't get notes stuck on game over I often get them during pause. Hopefully firmware updates/CEM#0 will fix them!

Yes, I think has 1MB plus 32K RAM (like banked RAM except that you switch it at $FFFF).

Just to clarify that the DragonFly cart can support a full 1MB ROM + RAM image and runs the original BadApple demo OK. Practically speaking, anyone creating a 1MB + RAM image probably doesn't need every single bank and can leave the last switchable bank empty so that it runs on the GD.

I tried the version from the PROPack on Concerto and I do not see the issue using either a euro pad, proline or even a single button A8 joystick. I think the best place to ask would be in the Concerto firmware topic. All I can do is repeat what I was told, which would have been around Jan/Feb 2022, that support will be added in the next major firmware release.

Yes, nowadays you'd think it's not so impossible. On the 5200, the AtariMax Ultimate SD card exposed the cart programming interface to the 6502. It wasn't ideal for playing video because you had to disable the cart before you could read from the SD card into cart memory. It also wasn't quick enough to read an entire frame in the vertical blank period. This meant you had to keep a screen buffer in internal RAM, copying each frame from ROM into RAM before reading the next. I don't think this would be possible on DragonFly because the cart programming is performed via the interface on the cart itself. However on SD carts where the loader runs on the 7800 (like Concerto and 7800GD), if their programming APIs were exposed you wonder if it could be done.

In the JS7800 build I omit the YM2151@460 bit in the header but I have XM enabled: 7800 A78 Header Info : 1942j.a78 embedded game name : 1942 rom size : 262144 cart format : SuperGame ram@4000 controllers : 7800joy1 7800joy2 save peripheral : HSC xm/xboard : enabled tv format : NTSC One other thing is that JS7800 does not support the YM timers, so you cannot use them to detect YM presence. In the JS7800 build I let it do the detection, but when it fails I pretend that it was detected!

I tried 1.08 and no issues here.