rensoup

Thanks, I have plenty of experience with various machines but never attempted ports before. As for following techniques, I don't think I did... Though there's one thing I was told at my job: Always start from something that works... which I used to be very much against at first but turned out to be a saner method than starting from scratch... altough sometimes not by a big margin! I developed all the tools I needed in order to make my life easier. Haven't done much progress on that front... I've been doing much on work on a RMT based tracker (see "moving beyond RMT"). Hopefully we'll get more music coming to the A8 thanks to a slightly improved import process (and Tatqoo's efforts!)

Very cool! Can you share details on the process ? I believe you want to talk to @mrr19121970, I think he was involved in the C64 version of IK ultimate: https://www.lemon64.com/forum/viewtopic.php?t=67078 But like he said the frames can be extracted from the video and put back into the game!

Depends what your target is... Are you going to use extra RAM or ROM? 50/60fps ? With extra RAM/ROM you would be able to do many more optimizations. Mode 4/E are the only candidates with you want to maintain the original resolution. Both are 160x200 x4colors but mode4 gives you that limited 5th color at the cost of being more difficult/slower to use especially if want to mix software sprites with hardware ones which you're going to have to by the look of it.

Love matkamies! Still enjoying Still alive!

Absolutely! ...then we can all disagree in which direction to go

It's very very tolerable! Please post more for us to tolerate!

I'm using Dimgui C# bindings done by this guy: https://github.com/mellinoe/ImGui.NET for rendering I'm using his rendering library: https://github.com/mellinoe/veldrid Veldrid is a cross-platform, graphics API-agnostic rendering and compute library for .NET. It provides a powerful, unified interface to a system's GPU and includes more advanced features than any other .NET library. Unlike other platform- or vendor-specific technologies, Veldrid can be used to create high-performance 3D applications that are truly portable. So in theory, yes... with a caveat. I build from VS and it seems to produces all sorts of versions for linux,Win,... I've no idea if they actually work. The caveat is that I'm using a sound library (the wave output, not the pokey emulation) that is not portable, but I could switch to something that is like SDL ? If you're interested, perhaps you could try building the veldrid engine from github and see if it runs on MacOS as a first step ?

I wouldn't say it's top priority but it's one way to get music quickly to the A8 to demonstrate the potential. And you've produced so much cool stuff that it's definitely worth carrying on ! I will start looking into those since things are a bit more stable. Awesome, I really enjoy listening to them!

It's functional and somewhat familiar to those who use RMT. It's probably rougher in terms of pattern editing but I don't really know since I don't use it myself (0 music skills ). Instrument editing should be fine. It's still crashing a bit and has very few keyboard shortcuts so far. Perhaps @tatqoo can tell you more about his user experience... The player started as a C# version of the 6502 RMT player. On top of RMT, it's got a bunch of extensions like track effects. Those can be any effect that are worth implementing but right now I've added Amiga mod effects to demonstrate the possibilities so that means that mods can be converted more easily than with RMT... which doesn't mean it's easy, instruments still have to be done from scratch though. Most Amiga effects are based on manipulating sample frequency and/or volume. I don't really know how sliding samples frequencies relates to sliding Pokey frequencies but it seems to work okayish. For volume, it should be closer even though the A8 has less precision. Additionally, since track effects keep manipulating the frequencies until another note is played, it's not really possible to use RMT envelope commands (beyond the 1st step). So once the track effect converts the note to a frequency, it's not possible to go back to a note (I suppose?). But some stuff still works like instrument vibrato which can be combined with track effects. I've also added an extended Arpeggio effect based on a C64 tracker and suggested by Tatqoo, again as a demonstration. He also suggested adding the AHX amiga format because there seems to a good library of tunes for it. I suppose it uses track effects to so in theory it would be a matter of adding those effects to the existing MOD ones. (same could be done with FC13 FC14) A lot of RMT limits have been removed like instrument count. You can have 256 instruments (it's any number in reality) which leads to extra features like easy instrument bank creation (you can load files as banks and easily copy instruments to your main module). The benefit of not having a 6502 player but a C# one means that in theory any effect can be done, so it is possible to come up with effects that are specific to the A8, maybe easier PWM setup, effects that are compatible with instruments envelopes... again I don't really know due to my music skills. DearImgui turned out to be a great GUI too so it's quite easy to add widgets for new features ( especially combined with C# ). The file format is text so it's easier to debug/fix and output format for the A8 is LZSS so that's been working for ages (the player is used in both the tracker and RMT2LZSS)

Where's that "tear of joy" emoji ! Thanks Tatqoo for sticking to it for about 20 beta releases or so... ( no release yet as he keeps asking for now features )

It's not about it being a competition... you're saying it's convoluted to convert a tune and its output can be inaccurate. It converts a tune or more in a bunch of clicks and I spent a lot of time batch testing it against about 1000 RMT 1.28 tunes, and it's 100% accurate. For PoP you used custom hacked extensions which it wasn't meant for and painful to use but for getting a 1.28 tune into a game/demo, it is convenient and accurate. If for my use, there was any advantage in outputting straight from RMT, I would use that.

Thanks for the cheapshot... RMT2LZSS does exactly as the title says with a button click, and integrating it with the example source is just a matter of renaming the file and assembling the code

I'd say you don't because RMT tends to be a CPU hog but that's not always true... LZSS is the alternative but it can take more memory but that's not always true either...

I'm not a fan of mode4 usually, but it really comes down to how useful the 5th color would be in this case. And there's also potential for saving some space with it, which I'm guessing would be needed for software sprites. Online version for the curious https://impossible-mission.krissz.hu/

I randomly browsed through the code, it doesn't look like it's suited for 8bit. Vector math is all over the shop... So I'd agree that the P4 source may be the best bet.

Supposedly the oric version isn't as good though... I haven't played it, just some comment I read. Even without the source I doubt the biggest hurdle is the limited charset, I don't see what prevents the use of multi charsets.

Assuming the P4 author is willing to pass it, then yeah it'd be a better start than the Oric or BBC without source. Pretty unbelievable that it's available on Oric too Also never noticed that the main sprite on C64 is hires until now. A multi year one indeed... and so much effort was spent on rebuilding the source which like you said was recovered right after! But I won't argue why people like to do certain things which seem pointless to others. Interesting read! Too bad the author seems to lack the motivation... Perhaps it's time to ping him again.

this one looks interesting: While it's always entertaining discussing ports, the amount of work is just humongous (even for a crap game...). For PoP, I had the commented source code, which made it less humongous a task. Without the source, you need to figure out what the code does AND you need to produce a relocatable source so that blocs of data/code can be moved around. The amount of work required for that is likely to burn you out, if not completely at least enough to not make you not want to bother trying on making A8 specific improvements. A good candidate for a port is a good game with commented and buildable source on the original platform... not many of those are available. For producing a relocatable source it may be possible to rely on some custom emulation which would automatically anotate a simple disassembly. My point is that better tools are required if we want to make those quality C64 ports happen.

bollocks... looks like pretty much all asm entries on the 6502 platforms used OS calls 😝

The rules should have been more specific I think... memory/OS. I'm guessing using the OS will help too so perhaps there should have been more categories. Perhaps I should try to port my code to the C64 if I can find the motivation! spoiler

Also to people who posted sizes for asm versions, do you include the 6 bytes xex header ? Do you use the OS ? spoiler

ah right... not exactly fair since we have different models but the C64 doesn't so they can write directly to the screen I guess. The minimum it adds is 4 bytes but then Altirra basic writes over it because the star is plotted on the 1st line. No issue with Atari basic. Just wondering what the other folks using asm do ? hardcode the pointer or read SAVMSC ? I'm thinking I'll just leave it hardcoded... it should work with any A8 with 64+KB with Altirra/Atari OS and Altirra/Atari basic

You may be doing it wrong though 🙃 (saved a few more bytes)

Made my own asm attempt (hidden result) I'm assuming that the screen is always at $9c40, is that ok ? I didn't clear the cursor either... it's kind of conflicting to allow a ready prompt but not the cursor and at the same time not require the screen to be cleared edit: I guess it's ok to leave the cursor

Very nice, do you plan on adding colors for the main character ?