MrFish

I figured it was something along those lines. So, one solution would be to just test for <START> to be released, rather than all the console keys. I suppose it might be nice to have an option to "Return to DOS" too, as that's all I'm really looking for here.

I almost forgot about this image I was working on. At one point (after about 3 months of processing), Rasta crashed and the image restarted. But since then I've had no problems, and I back the progress up every so often. So, I think this was run off and on for about 6 months on a spare PC I have here, which is fairly old. The machine processes in Rasta at a rate of about 4,200. I wasn't able to do any further processing for about the last 2 years, because I didn't have the machine set up. But, I'm starting to process it again now, finally. The image is near perfect in all areas except the details of the dirt road, which have not processed thoroughly yet. Rasta had just started working on them about the time I took my machine down and stopped processing. My plan was to let it be processed as much as possible before posting anything; but since I was delayed for so long, I'll post this update. It's a PAL image with 39 colors at this point. Green Acres.xex

If that's the case, I should be able to hold down <OPTION> during reboot and avoid entering BASIC, which I had already tried and wasn't able to do.

Alright, some more feedback. When I use <START> to "Reboot" the system, BASIC is being enabled, even though it's disabled in Altirra.

I have Windows binaries -- and a PDF manual -- posted here as well: RastaConverter

Yeah, that's it. Thanks!

Thanks for addressing the issue, but the problem still persists. The only way to eliminate the problem is to ensure that the user has released the <SELECT> button prior to exiting.

Yes, I would agree that you get more responsiveness from the method you describe, rather than the "nothing happens until I release the button" that you get from the method I described -- which tends to make it feel like 2 actions are needed (button down, button up) to make anything happen. And inside your own app where you have full control, yours would be the preferred method. As you say though, This doesn't protect from having a problem with another app that you might exit to. So, I guess the best solution would be to use the method I describe "at least" for the function of exiting to another app [Edit: ...or I guess you would actually use a combination of both methods, if the NRV method was being used elsewhere in the program -- and the key had some potential for causing a conflict in the running app. So, test for "key not pressed", test for "key pressed", test for "key not pressed". I think that would cover it].

Well, this may seem like a trivial problem to bring up; but it's common, annoying, and easily fixed. The problem is when people set some input device action (joystick button or console keypress) to exit a currently running program and start another. Once entering the newly started program, if any of those input device actions are being tested for, guess what can happen? The newly started program can see the keypress and takes action. So, in many cases (most) you end up starting some action that may not be desirable (and in many cases can be unaware that anything happened at all, because it can happen so quickly). In the case of HW-Detect, <SELECT> is being tested for an exit to Atari's built-in "Self Test", and what happens is -- unless <SELECT> is only pressed for a minute instance -- <SELECT> will be detected by "Self Test" upon entry; and instead of the current menu selection being on "Memory", it will be on "Audio-Visual". As I said, this may seem like a trivial problem (with other programs I've seen, the problem can have more serious consequences); but the intention of Atari's "Self Test" program is that the initial menu selection is the top item ("Memory"), not the second item ("Audio-Visual"). The fix for this is easy. You simply test for <SELECT> to be pressed, then you test for <SELECT> to be released. That's it.

Nice, but that loading screen is liable to cause seizures.

Yeah, people put everything here. I think my only contributions in this thread are from a garage sale and a craigslist buy. There's been some discussion as to whether the thread name should be changed, or whether a new thread should be started altogether...

There are 4 binaries though (2 of them being separate levels). 1. Company Logo 2. Options Screen 3. Level 1 4. Level 2

Nice! First time I've seen it. A nice looking Miner 2049'er/Bounty Bob clone. Quite polished proto... Too bad there's no source code; otherwise it could probably be finished.

I don't think the Graphics 7 version looks bad at all -- and slightly faster too; but I think you made the right choice going with Antic E, by comparison.

Yes, I'm talking for the purpose of multiplying the amount of colors. Often, it doesn't matter that the resolution of GTIA modes are lower, because the added colors can make up for it (lots of antialiasing). In the case of your demonstration, it may not work out, given that it's circular. However, it may be possible to have an oblong shape (longer horizontally than vertically) in order to compensate. Graphics 7 is really no comparison to GTIA modes -- other than being lower resolution -- since you gain no additional colors with it. Even if doesn't fit in 256 bytes, it could still be interesting to see for comparison.

I wonder how good you could get something like this to look in a GTIA mode.

I've voiced this sentiment before too. There would be so much cool to having a loaded 8-bit inside of an ST case. Candle was working on it at one point years ago. I think he got as far as getting the ST keyboard working with it.

Thanks for posting. Your ROM is an exact match with k-Pack's.

He talks about it a little bit here: 1200XL keyboard to 130XE motherboard

You've got the picture above to prove it.

Alright, I'm not sure if there's actually any thread devoted to it or not at this point (I did a little searching). But here's a picture he posted of it. There are some threads where he lists the specs, of having 320K, etc. He actually has two (correction, four) of them set up like this.

@MEtalGuy66 took a 130XE motherboard, socketed the whole thing, and put it inside a 1200XL case. His whole idea was to get the newest motherboard revision (aside from the XEGS) and have it with the best keyboard. And also to have ECI, etc. There's a thread somewhere on here about it. TBH, the idea isn't too bad (especially if you can get the whole board socketed); but, if I recall correctly, he didn't do too much to the make the connector side look too pretty. I can't remember if he added some plastic there or what.

Well, they're both alien-looking characters, actually (M. Brace & Mr. Eeez); but you said player and aliens. The two characters that I changed are Player 1 & Player 2 (the protagonists), which are to be controlled by humans and fight against the Xenos (the antagonists).

There are no changes to any of the aliens, just the 2 protagonists' heads.

The dump (and any other related software) would be useful as verification for the other dump we have from k-Pack. It'd be nice to have a pictures of the cart and other software too, if anyone is interested in doing that.