rdefabri

Depends on the vendor, but most of the bigger titles came in a nice box. I posted the Aim Software Ambulance box - that was a cassette and I’m pretty sure I have Protector II on cassette - also in a box. Some of the smaller, independent programmers would just sell you a cassette. I recall buying Robert Jaeger’s Chomper at a JACG meeting and that was just a cassette in a case.

I see there is now an Atari Lynx homebrew of IM. I realize that the Lynx has a separate blitter / graphics capability, but it's 6502 based...not that it's any easier than porting the Plus/4 version, but just an added reference point.

I failed miserably at my attempt, I’m just not knowledgeable or capable enough as a programmer to do what others are able to do. On top of that, I was laid off by my employer so I need to focus on securing gainful employment. I’m amazed at the great work and efforts by those that can do this, they get better each year. I have some good ideas, but I need a good “teacher” (books or people) to get me over the line. I’m not a professional coder, so it’s harder for me. Good luck to all the entrants!

This is such a great thread - I was always interested in sound synthesis in days before digital synthesis / sampling was prominent. Bill Williams was a trailblazer with what he could do with POKEY. There’s no doubt that the sounds in Alley Cat are programmed (rather than sampled), and they are amazing. I would consider him an early influence, even though most of my (limited) POKEY experiments are musical rather than sound effects. His story is both tragic yet inspiring, and it brought tears to my eyes. Even better that another Atari legend - Cathryn Mataga - is here. This is such a wonderful community, I’m humbled to interact with people that have (and still have) shaped my life!

Awesome! Thanks for doing this!

Well it’s the original 400 I purchased when I was 12 years old (I’m 55 now), so I’m not looking to get rid of it!

I’m glad my thread inspired @vitoco to create the game - very cool! Now if I could only figure out how to do something similar on my own…

I'm an O.G. Atari 400 owner, purchased BITD. As others have said, immediately upgrade to 48K and a GTIA card if you can find them (I have no idea if any of this stuff is available). I never upgraded my keyboard, but that's always a nice option.

Man would love to see that

If I can get my head out of my bum, and get it wrapped around the Adventure Studio, I have a few ideas similar to this. Would like to see this one finished though!! Is there even a prototype?

Rare I see an Atari game that exists on multiple platforms (C64, ZX Spectrum, Atari 2600) that isn't on the A8 line. Didn't realize Road Runner is ported to nearly all the other platforms BUT the A8. This one came out around 1985 I think, so the "heyday" was over, and certainly a big reason we don't have this one. It's not the greatest game, but kind of sucks since it is an Atari title.

It's in the Compute! book referenced in a post above.

Has anyone actually typed in Front Attack? I can't find it, and if I copy paste the code, you lose the ATASCII characters. I don't see an ATR or BAS file on Atarimania - it's listed as "MISSING".

Yep I know you can't use machine language in 10-Liner, I kind of gave up on that until I can actually program something that works!

I forgot how simultaneously frustrating and enlightening programming could be (although I suck, so it's more frustrating than enlightening). Creating PM graphics in Atari BASIC is simple enough - the POKEs to set up virtually everything, including horizontal movement, are all there. It's obviously vertical movement that becomes an issue, and standard practices yield a much slower moving sprite moving up / down. There are known machine language VBI subroutines, and I can get them to work. However, I have some issues when I determine a collision (in this case, PM0 to playfield) - if I end the program, the PM stays on screen and when I go to run again, the program is corrupted and/or doesn't run. So a few questions - is there a standard way to clear all the memory out and reinitialize? I've tried CLR, and even loops to zero out everything. No dice. The other question I have is that the VBI subroutines I've leveraged (mostly from Atari BASIC programming books) use lengthy DATA statements. Not a big deal per se, but if I were ever to attempt a 10-line BASIC game, it's a non-starter...is there some simplified or smaller machine code subroutine to handle fast vertical movement? I know the simple answer is to use a different BASIC. BASIC XE and Altirra BASIC have built in PM commands that make it easier, but now I'm hellbent on doing this in BASIC. Any advice?

Moving to the next category might be an option. First I have to get this stuff to work - I'm a hack!

Still in the works. It's kind of a kluged up, Franken-code - just the way I seem to work! I have to get it operational, then I'll try to whittle it down. Right now, it's super inefficient and buggy.

I can't imagine how I can get my code down to 10 lines without some sort of magic. I might have to try a different category or language!!!

This is probably a dumb question, but if you have multiple DATA statements, is there a way to combine them? If so, I'm curious how the corresponding READ statements know which data to select?

Ok - there's a slight chance I'll have an entry, maybe in the PUR-80 category. The game sucks, but it's something, and the big if is IF I can get it down to 10 lines. I don't stand a chance to win based on the entries so far, but it will be a bucket list item completed.

This is kind of how I had the program structured. Main routine initializes the PMs, movement, collision detection, etc. Each turn has a physical change to the playfield, and I need that change to be "animated" or drawn. To do that, I would call a subroutine to each playfield change. Once the playfield is drawn / redrawn, it would return to the main program. As I thought through it, because the subroutine has to slowly draw the playfield change(s), I began to wonder if that would stop / halt the main routine(s). For a counter - definitely. For PM movement, I'm not sure. Either way, the counter stoppage would be a problem as that's the main scoring mechanism.

I think the work around would be for every subroutine, the value of the counter is incremented within the subroutine. It may make for some wonky timing (it doesn't need to be exact), but it could work.

Yep, I knew this but was hoping there was some "trick", like doing something with the VBI. More I look at it, the more I realize how much more complex this is in BASIC. I'm sure there's some way but it's over my paygrade.

Yep as I suspected. Everytime I think I've made a breakthrough, I hit a wall...gotta keep thinking through it.

My understanding of Atari BASIC is that it performs functions in a serial fashion (e.g, interprets a line, executes, goes to next line). Obviously, you can "interrupt" the flow with commands like GOSUB to run subroutines. What I'm not sure about is how you can run certain functions in "parallel" (I'm putting "parallel" in quotes because I know it's not really parallel but to the human eye - it is for all intents and purposes). For example, if you initialize a PM, have it moving around a screen, then want to have a background drawn behind it, will that work? In this case (unlike my previous thread), I want the background to "build" - you see it drawn. Assume that's done in a subroutine, does the main program handling the PM graphic / movement / collision detection stop? Take another example - you run a subroutine, but the main program has a timer. Let's say the timer increments every second, but the subroutine intentionally takes longer than a second to "build" / draw...does the timer not increment until you return to the main program? I know there are orders of execution, but I'm drawing a blank, I feel stupid that I can't remember or figure this out.