AkashicRecord

Thanks for the mention of the bug-fixed version, i stumbled across that yesterday and was pleasantly surprised. I was joking a bit in my original post, but I do agree that E.T. was actually a pretty good game...albeit with a few bugs. No one made games in 5 weeks...people were incredibly fortunate or lucky to have a (good) game in 5 months! Hell, it took probably 10+ months for Keystone Kapers, and David Crane himself said that designing just the cars in Grand Prix took 3 months alone; that game sprang directly from its graphics! That said, in my son's defense, he also really loves Adventure, Surround, Maze Craze, Space Shuttle, Haunted House and Starmaster, to name a few.

Should I be worried, or concerned? I'm not sure what's worse; that, or the fact that he can essentially get as far as I ever could! I'm sure that game is a thrice-beaten dead horse around here, but I've always thought it kind of got a bad rap over the years. But, I'm glad he can grow up with the VCS like I did in the early '80s, and hopefully have some nostalgia for it some decades later...

I thought of an implementation where the stack would be set to point to HMOVE preceding a BRK. In this case, both RESMP0 and RESMP1 would also be written to during the 7 cycles. Setting the SP to point to ENABL afterward would allow a following BRK to reenable the ball and missiles. (This same trick could also be used to disable the ball and missiles by BRKing over ENABL...) Of course, certain bits / flags have to be set or cleared for these things to be possible. I also wonder how the timing of HMOVE is affected here, because the timing of the strobed write should be at least 2/3rds of a cycle faster(?) via BRK rather than via STA.

I have to give a bump for the mention of Midnight Magic. I wouldn't have picked the title up yesterday if it wasn't for this thread, and the game is just spectacular for the 2600.

Have you seen Dennis Debro's disassembly of Al Miller's Basketball?

Yeah, I can't wait to run some of my test code on this machine using one, especially for working on the graphics and input control. As for the game right now, one of my current hurdles is coming up with an elegant solution to checking the playfield bitmap(s) for the game piece rotation and placement functions. I want to try to store and manipulate the playfield bitmap data "as is," or rather, keep it in the exact order as is needed for the actual display. The annoying issue here is regarding the reflected nature of PF2 in the case of the asymmetric 1-player game field; when a piece is situated on the field in a way that its bits essentially straddle both "copies" of PF2, then the bit tests necessary to check for rotation and placement get a little bit...ugly...to say the least. (In other words, the 10 columns of the game field are split and mirrored across 5 bits of 2 independent copies of one TIA playfield register per game row. It's kind of headache inducing to think about.) I might be over thinking part of this though, as I have some ideas on oaper here to work on tonight. One idea is to just kind of slease out and use some tables in ROM, since each piece rotation can only occupy a handful of horizontal positions within the game field.

Not to get too off track, but I was slightly bummed when my L6'er wouldn't power up the other day after I received it! I immediately suspected the 40 year-old power supply was at fault, and not having a voltmeter or ammeter other than the pink fleshy one that we are all born with, I couldn't taste 9V @ 500mA, so it was time to do a little electrical autopsy of sorts... Scavenging various boxes and such for orphaned AC adapters didn't produce much fruit, but I found a 500 @ 12V* which was still center positive on the tip, so I dissected that adapter and fashioned a makeshift power adapter with the help of a 3.5mm stereo audio cable for the end connector... After wiring up the ground / sleeve and tip (with crossed fingers, of course) everything was in working order on the first attempt...with the exception of Chopper Command and Keystone Kapers, though a bit of rubbing alcohol fixed those right up just as well. Now on to acquiring a Harmony cart I suppose? *I know that the VCS technically runs at 9V (and you shouldn't go around arbitrarily licking random wall adapters either) but the small amount of extra heat produced at 12V shouldn't damage the voltage regulator any more than my tongue.

Just took a little retro shopping spree and scored a light-sixer and a few games: Atlantis Pitfall! Starmaster Keystone Kapers Yars' Revenge Chopper Command Grand Prix Enduro Spider Fighter Solaris Demon Attack Dragonfire Defender Vanguard Venture Maze Craze and Q*Bert Over the next few days I hit up every retro game store within a 60 mile radius and scored more titles: Space Shuttle Adventure Pole Position Krull Berserk Midnight Magic <-- AMAZING Riddle of the Sphinx Centipede Outlaw Surround Video Pinball Frogger Haunted House Word Zapper and E.T. (I couldn't believe it when my 3 year-old son finished Adventure on difficulty 1...three times in under an hour!)

A TIM1T timer would expire fairly rapidly; this could be used as a good realtime random seed, unless I'm mistaken, as the counter decrements from $FF each clock cycle after timer expiration.

Maybe it should have been titled BRKOut? I'm glad that you mentioned that game, as it wasn't discussed in my recent thread questioning interesting and valid uses of the BRK instruction.

I've recently had some time to start working on this game again, and I've also been taking the time to study some disassemblies of other games, in addition to other Tetris games (and even the popular "official" NES version.) I've spent some time experimenting with abusing the BRK instruction, which is essentially a rarely used software interrupt instruction (for the VCS, at least). The thing with this instruction is that it pushes the Program Counter and the Processor status flags onto the stack and then executes a certain section of code... If one sets the stack pointer to an "interesting" location, then they can exploit the fact that the Program Counter and flags will be written to the stack in only 7 machine cycles. If the "interesting" location is a color register, then 3 TIA color registers can be changed in 7 machine cycles... It's not a groundbreaking feat, but it is certainly interesting and might have a future use. The primary difficulty with this ...method... is that you have to judiciously modify the PC to call the BRK from useful locations (since the PC bytes are pushed to the color registers, they should at least be useful colors), and the second issue is that the processor status flags can only be gently massaged to a certain extent. Even pushing *any* value to (a valid) stack and pulling the value into the status register (via PLP), certain bits of the status register will *always* be set to 1 ...or high ...or logic true ...or however you want to think about that. That said, there's a somewhat limited amount of colors that you can squeeze into the playfield and player color registers by abusing BRK. I wrote a quick program earlier tonight to test what values can actually come out of this sort of abuse and mangling of the processor status flags by having the program display the intended color via the background with a sprite overlay whose color comes from the BRK pushing the flags into the sprite's color register. This helped visually contrast the differences of (intended) color values after being mangled by passing through the processor status flags, courtesy of PHA / PLP / TXS / BRK. The results were actually quite interesting, and are definitely going into the arsenal.

I was experimenting with BRK this evening by pointing the IRQ vector to RIOT RAM and setting the stack pointer over COLUPF and then fixing up a 16-bit pointer in RAM (following a JMP instruction) to function as a sort of faux RTS for the BRK. I see some possible use for this, even though it is somewhat limiting. Changing 3 colors in 7 cycles is kind of sweet. Adding 3 cycles for the RAM JMP is still 5-8 cycles less than "standard" color changes.

I was just listening to the "Stella at 20" interviews yesterday, and I believe I heard Joe Decuir mentioning using the BRK vector to replace JSR calls in order to save like 3 or 4 bytes in order to get under 2K at some point...

Wow, I really love the look of this!

Thanks for this one, Joe!

Thanks! Yep, I'm back to developing it (as of just a few days ago.) I'll be updating it's main thread in the near future.

That's exactly along the lines of how I thought it could be utilized. The sound driver code example in the link is certainly interesting as well.

Since the Atari VCS and it's facilities are not interrupt-driven, are there any novel uses for the BRK instruction?

Color me interested, I've wondered about the same for my own project(s).

I used to shit my pants when things came after me in Venture after collecting the treasures.

...it's probably more accurate to say that "labels" can't start with a number (and almost certainly a few other characters.)

Variables can't start with a number. This is the case with most languages.

Just a small heads-up. I'm still plugging away at the game, but the most recent two weeks or so found me a new full-time job (with overtime) so I've had to focus on that recently. I did have a sort of business meeting with an acquaintance over dinner as well, discussing this and future games. I also did a little retro window shopping for an old VCS, so I have my eyes on a 4-switcher now...and the guys at the shop were pretty interested in seeing a cartridge of this game in 2019.