freetz

Thanks for listing 1K RainboX, but there is another entry "Rainbox" which can be removed since it is the same game. In the video, I call it "RainboX", but the official title is "1K RainboX".

...I've also made a short YouTube video where you can see the game in action:

Ok, then I'll start ... 1K RainBox is a one-of-a-kind puzzle game: It is probably one of the most colorful ones with tiles consisting of more than 100 colors of the ATARI rainbow (including 13 different colors horizontally), and it is most likely the smallest of its kind: Its size is less than 1000 bytes - bytes, not kilobytes or megabytes... The goal of the game is simple, yet addictive: After choosing one of the nine levels using the SELECT key, the game starts after pressing the START key or fire button. The ATARI then begins to mix up the nicely sorted ATARI rainbow. Once it is done with its task, the player’s task is to bring the rainbow back to its original order, making as few moves as possible. To do so, you can move one of the adjacent boxes into the empty spot. Step by step, you can restore the rainbow’s order, and the fewer steps it takes you compared to the moves it took the ATARI to mix it up, the higher your score will be. For the playfield, there are four different tile-sets available which you can change at any time using the OPTION key. And now have fun cleaning up the ATARI rainbow!

Thanks a lot! Is there a reason why the registers have to be accessed via @ and other memory locations can be accessed via db() etc.? And where were the values coming from that I got with db(y) for example? BTW, db(Y) would give me an error... EDIT: Ok, after reading .help ? more thoroughly, with db(y), I probably got the contents of the memory location that the value of the Y-register was referring to. And just FYI: .help ? mentions the X, Y, S, PC and P register, but not the A(ccumulator). Maybe it would be helpful to add. And in gerneral, a tutorial or text on how to use debugging with Altirra would be really great. I think I'm just using 5% of what Altirra is capable of, but that alone is already a huge life-saver, so I can only assume how much more power I'd have at my hands if I had a thorough introduction into all the other capabilities :)...

Great, thanks! Is this documented anywhere where I could have looked it up?

Hi everyone, I love Altirra's ;##TRACE function and it works great with labels, but I can't find any info on how to trace the accumulator or the X/Y registers. I'm using ;## TRACE "Accumulator = %d" db(a) but it gives me strange values, the same goes for db(x) or db(y). If I store the register in a labelled memory location and trace that one, that's fine, but I want to do it directly. Does anyone know how?

Ok, CharlieChaplin and me settled this via e-mail, everything is good, no need for any awkward silence here :). Just a quick note on the Image of Scaremonger 2.5 (haven't checked the others yet): Apparently, when I transferred the disk 10 years ago, it was already faulty, so while the game loads and you can play it, some of the quiz questions are corrupted, i.e. showing graphic characters etc. and since some of the answers are also corrupted, you may not be able to answer these questions correctly. Since I'm currently abroad, I won't have a chance until later next year to see if I can try another conversion, but I doubt that the disk has improved after 10 years (giving it a total of 30 years now). As for the gameplay, it's actually easy if you have a manual ;). You are asked to find a number, so you have to move the cursor to a spot next to an existing number (like in Domino). Then you are asked a question and if the question is correct, the empty field becomes the same number. If you answer the question wrong, then the field will become empty and unusable, making the game more difficult with each wrong answer. Back in the day, I thought this was an innovative twist to the quiz genre, but I agree that the game hasn't aged that well ;)...

@CharlieChaplinI'm sorry for your disappointment, but did you really expect a 1:1 SMB clone after Great Giana Sisters was taken off the market within a few months? Enrico is a platform jump and run game, and if everyone thought like you, I wonder why people still bought Enrico 2 in not much lesser numbers than Enrico 1, IIRC. You are of course entitled to think that these games were "shit" as you put it so nicely, and feel free to continue with reviews of my other 30+ year old games. I'm sorry if you were so hugely disappointed. Send me your bank account details and I'll reimburse you your costs of any of my games you bought back then. But with allegations that I was misleading people or selling broken software, you'll understand that I'll excuse myself from any further discussion.

Well, not sure if I want to explain further on these games of my youth under this pretext, but since there seems to be some interest from others: Scaremonger was written in 1990 and published under my own "Powersoft" label (not to be confused with Markus Rösner's label of the same name, gosh, were we creative back then ). Then Kemal was interested in the program and expanded it, most notably with a better title screen and some other graphical improvements. That was Scaremonger 2.0. Things didn't really work out with Kemal back then, so it was re-released as Scaremonger 2.5 with (IIRC) the removal of some parts that Kemal provided. At some point (IIRC) I sold the non-exclusive rights to these games to Werner Rätz as well as Ulf Petersen to use for his UserMag. I know these games were not great, but for a quiz game, Scaremonger was not that much worse than, say, Quiwi (spelling?). But tastes differ. Mad Marbles was my first ever game I wrote when we were on holiday in the Harz mountain region. Without an Atari, mind you, just on paper. All I had was the Happy Computer Sonderheft where I got a first understanding about PM graphics and how to use them with Turbo Basic XL. I wrote this game specifically for my first Atari which had (and still has) a broken second joystick port where the pin for moving to the left was broken. That's why player two in Mad Marbles is always moving to the left and player one is always moving to the right. You have to move the blocks to block each your opponent and thereby win the game. As for the master password, I had totally forgotten that there was one - I don't even know that the Turbo Basic source code is available somewhere so that someone could figure it out :). But yes, both games didn't fare remotly as well as Phantastic Journey I and II did, of which I think I sold around 100 units of each in the beginning of the 1990s, most of which went into my first PC ;)...

Thanks! Will try it that way...

Thanks, @Rybags, never heard of the bounding box method, is there anywhere I can read up on that? I assume it's somewhat mapping missile position to a playfield map, but I wonder if there is some kind of best use-case approach...

Thanks, @phaeron, at least I know I've hit a dead end here. Mode 10 is unfortunately not an option for the reason you mentioned. So I guess, I'll have to look at other ways to deal with this...

Hi everyone, I'm trying to understand how missile/playfield collision detections (do not) work. I know that in GTIA modes 9 and 11, it is not possible to detect whether a missile has collided with playfield graphics. But I'm trying to get my head around at what stage this detection becomes no longer possible. The background if my question is that I'm only using some lines in my display list where I set PRIOR to 192 and thus enable GTIA mode 11 for these lines. This change in PRIOR is done as part of a DLI. If I remove these lines, I get the ordinary GRAPHICS 8 (ANTIC mode $0F) lines, and collision detection works as expected. I'm wondering at what stage the collision detection takes place and if it would be possible to somehow work around this. My (maybe naive) idea was to set PRIOR back to 0 as part of the VBI, so that collision detection would happen during the virtual blank and thus would not affect the image which would remain visible as GTIA mode 11. But I guess if it would have been that easy, others would have come to that conclusion way before me. OTOH, GTIA modes are rarely used, so maybe there is a slim chance that this is a solution? The other idea I had would be to test collision right after STA WSYNC, before PRIOR is set to 192. But I haven't really gotten this to work either. My assumption now is that the collision bits are set the moment the image is rendered in the Atari. So if the missile is rendered over a GTIA mode line (as it should), it is the status of PRIOR at that moment that determines whether the collision bits are set or not. If that is the case, then it wouldn't make a difference at what other time I'd change the value of PRIOR because it would either be before the rendering or after. Can anybody confirm whether these thoughts are right/wrong and if there is any other way to detect missile/playfield collision in GTIA mode 11? Thanks in advance, F.

That is bizarre - and make me wonder even more how some people were able to come up with something amazing as the Freezer or the Black Box, but nothing much else of such impact. But then your work on your guide is even more important...

While my professional backgrond is neither in IT nor in engineering, I've been working on microcontrollers for several years now and also developed some (lesser complex) hardware. Still, such aspects like why and what for I would need buffering and multiplexing is something that requires deeper understanding of the hardware in use that I don't have (yet). As for breadbards, I prefer doing the initial design on a breadboard because I can work with trial and error as well as through-hole parts. I may use SMD in (external) production, but never in development, simply because my hands are too shaky ;). It may not be feasible due to the number of wires needed in the case of the PBI, but I'd think that if Ben Eater can design a CPU on breadboard, then some kind of simple PBI peripheral should not be impossible ;). Again, I'm just stating what I would need and how I as an amateur would approach this. If I find a way to get an understanding of the processes, I'd be motivated to learn about them, but so far, I've often hit a barrier (and apparently, many hardware developers in the 1980s, too, otherwise the PBI might have been used more often compared to SIO or joystick-port-based devices)...