Leaderboard

Here's the build of Frantic that was shown at PRGE. Al needed the demo ROMs at the start of October so he'd have time to build all the carts. frantic_20231002_PRGE.bin Changes: Fixed issue where room sometimes changed color during transition to next room. Revised robot death sequence - when hit the robot's shape is now briefly color cycled (like the humanoid's death sequence) before the explosion sequence starts. Revised Otto logic for Frenzy variation. 1st hit slows down Otto, 2nd hit slows down Otto more, 3rd hit returns Otto to start location with a faster speed. The 2 slower Otto speeds use new neutral and frowning images. Haven't seen @espire8 around in 2+ years so I modified the smiling image to create these images myself. Revised initial robot count per room, minimum now 5 instead of 1. Fixed issue with tank colors being off by 1 scanline. Revised difficulty progression. Hopefully fixed screen jitter/rolls that were occurring at higher levels. Stress test routines (difficulty switches to A) were removed for the demo. Tanks and robots used to share the same missile offset table for missile position when initially fired. They now have their own offset tables. I'm hoping this resolves an issue where the Tank's homing shot would sometimes appear on the other side of a wall. I broke out some graph paper to figure out the missile offsets: The x and y offsets are in the program like this: const signed char missile_x_offset[3][8] = { // E SE S SW W NW N NE { 7, 6, 3,-1,-4,-2, 3, 7}, // humanoid { 7, 7, 2,-2,-2,-1, 3, 6}, // tank { 7, 6, 3,-1,-4,-1, 3, 6} // robot }; const signed char missile_y_offset[3][8] = { // E SE S SW W NW N NE { 3, 9,16, 9, 3, 1,-5, 1}, // humanoid { 5,12,13,12, 5,-2,-3,-2}, // tank { 6,12,13,12, 6, 0,-5, 0} // robot };

404 < PreviousIndexNext >

378 < PreviousIndexNext >

I have a little "apron" of belly fat (called the panniculus according to Google) and I developed a small lump under it about a year ago or maybe a year and a half ago. I hoped it would eventually go away by itself. Around August 17, 2023, the lump started getting larger and very hot. As it grew, it got even hotter. It was so hot that it felt like it might burn my Nitrile glove covered hand if I left it on the lump for too long. I cleaned the area and put Neosporin on it a few times every day with a Nitrile glove on my hand. I also started eating a fresh clove of sliced raw garlic once a day beginning on August 20. I would eat a sliced clove of fresh garlic on steak or a hamburger once in a while at the last house I lived at in 2020/2021, but I kind of got out the habit after moving to the house I live in now. I don't know if it was the garlic or the Neosporin or both, but the lump got smaller each day. I thought I was getting better. On Thursday (August 24), the lump started leaking reddish stuff that smelled like a rotten potato, so I went to urgent care to see if they would put me on antibiotics. The person I saw there squeezed out as much as they could from the lump, then said that I needed to go to the hospital and have intravenous antibiotics. He said I'd probably have to stay at the hospital for a couple of days. After the usual long wait in the hospital waiting room and a scan of the general area (the kind where they inject contrast dye), I was put in a room and bag after bag of antibiotics were dripping into me until Sunday morning (August 27). The doctor walked into my room a little before 9 a.m. on Sunday and said that I could go home after the discharge papers were ready. That was good news because he told me on Saturday that I might have to stay until Monday or Tuesday. Later that day a nurse brought the papers and took the PICC line out of my arm. Some hospitals I've been to made discharged patients ride in a wheelchair, but not this hospital. The nurse said I could just walk out, so that's what I did. Now I'm taking an antibiotic pill every 6 hours at home. What did we learn? If you have a weird little lump in an embarrassing area somewhere below your belly button, even if you hate doctors messing around down there, get it checked out before it turns into something that could be deadly. Hospital Tidbits They were surprised at the hospital that I didn't have a fever. The quality of the nurses varied wildly. The nurses working at night were usually better than the ones working in the day. My last nighttime nurse (Saturday night/Sunday morning) was kind of angry that they put the PICC line right in the bend of my arm instead of higher up or lower down. I had to keep my arm perfectly straight or the alarm would go off. Made it hard to sleep. The PICC line in the wrong spot wasn't the only thing that made it hard to sleep. As you'd expect, there were people coming in and out of my room throughout the day and night. There were all kinds of random loud noises that would wake me up. Sometimes it sounded like two giants were playing catch with a dead body and they weren't very good at catching. I was right across from the nurses station and they'd be talking as loud as they could and laughing at the top of their lungs. Sounded like they were having a party day and night. One night it was as quiet as a library and I asked my nurse about it. She said the supervisor was there that night. It was nice to have a quiet nurse station for a while. I heard one of the nurses at the nurses station talking as loud as she could about one of the other patients. They were all giggling and laughing as she talked about how gross a procedure was. The Saturday daytime nurse looked at the IV stand like she was trying to solve a cosmic riddle. She had a look on her face like it was the first time she ever saw one. She was my daytime nurse Saturday and Sunday. The first morning, she shook up the antibiotic bag to get it ready, then she tried to hang it upside down and about a fourth of the bag squirted out all over her and the floor. She eventually figured out that the end with the long tube faces the floor since the patient isn't on the ceiling. She never called anyone to clean up the puddle. She just left it there for someone to possibly slip in. Next time, she ended up squirting some out of another antibiotic bag, but it wasn't as much as the first time. Watching her do anything was like watching a new feckless employee at McDonald's trying to use the register. Problem is, she wasn't new. I don't see how she hasn't been fired by now. Speaking of trying to hang bags upside down, this happened on Friday. They were also giving me saline since I was slightly dehydrated and the big bag was hanging off a green plastic thing to make it lower and the bag eventually fell off. Scared the crap out of me. I pushed the button for the nurse and a baby-talking lispy girl came in who looked like she could have still been in high school or maybe even middle school. She picked up the big saline bag and tried to hang it upside down. It was just too hard of a puzzle for her. One end has a place for hanging and the other end has a long tube coming out of it that runs to the patient. A child could figure it out in seconds, but not her. She was standing there banging the tube end up there, totally mystified. My Friday daytime nurse walked in and took it away from her and hung it up the right way. The hospital pharmacy was a complete joke. I have various important pills that my doctors have me take twice a day, but the hospital gave me something like one pill on Friday, a couple more on Saturday, and a little pile of pills Sunday morning. You're not allowed to take your own pills, but they won't give you the pills you're supposed to take twice a day. I ignored them and worked around the problem to keep myself alive. No wonder so many people die in hospitals. What did we learn? Some nutty-ass low I.Q. people might be working at your local hospital. If you catch a problem early, you may not have to go to the hospital and that means some moron won't have a chance to "accidentally" kill you. I don't consider it an accident when a person is so stupid and incompetent that they clearly shouldn't have a job in health care.

403 < PreviousIndexNext >

400 < PreviousIndexNext >

386 < PreviousIndexNext >

Annnnnd we're caught up! 382 < PreviousIndexNext >

While getting ROMs together for Nathan for his RetroN 77 contribution to the Stella-thon 12 Hour Gaming Marathon Fundraiser! event I realized I've yet to publish the final ROM for Draconian. ROM: draconian_20171020_RC8.bin NOTE: newer versions of the Harmony Cartridge use a different chip that does not work with the above ROM. batari posted this patched version of the final ROM in this topic where he explains why the patch was needed: Draconian_Harmony_fix.bin Source*: draconian_linux.zip * linux is in the zipped directory name because I used my Linux laptop to finish Draconian on the way to PRGE.

https://www.atarilegend.com/games/bentley-bears-magical-anagramsIt has been asked over the years, if you have Sonic for Sega, and Mario for Nintendo, who is the mascot for Atari? And while this has been debated, and other mascots concepts were made, one has managed to sneakily remain just out of the lime light, but just in sight. A cute friendly looking bear that just likes to collect gems. Why? Who knows!? Because... gems! But he has a cool unlimited bag to hold the gems. A cool hat that he only gets for a few seconds to be invulnerable, and best of all, a big "B" belt buckle. I think Bentley Bear IS the unspoken mascot for Atari. At least over time he has gotten a lot of screen time and fairly well represented over the various Atari platforms. Check this out, I was actually quite amazed! Aracde - Crystal Castles (1983) Atari 2600 - Crystal Castles (1984) Download Atari (5200?) - Crystal Castles. Download 400/800, XL (Unreleased) (1984) Download XE (1988) manual and Download Atari 7800 - Bentley Bear Crystal Quest (homebrew). Download Atari Lynx - Bentley Bear-Honey Hunt (proto). Download Atari ST - Crystal Castle. ST, STE, TT version (1988) Manual and download Atari Falcon version. Download Bentley Bear's Alphabet Tutor. Manual and Download Bentley Bear's Equation Builder Manual and Download Bentley Bear's General Store Manual and Download Bentley Bear's Magical Anagrams Manual and Download Bentley Bear's Magical Math 1. Manual and Download Bentley Bear's Magical Math 2. Manual and Download Bentley Bear's Magical Math 3. Manual and Download Bentley Bear's Memory Master Download Bentley Bear's Memory Master II. Manual and Download Bentley Bear's Spelling Bee. Manual and Download Bentley Bear's Typing Tutor. Manual and Download Atari Jaguar - Atari Karts. Manual and Download Bentley Bear apparently made an appearance in Wreck-It-Ralph. Not a great likeness, but the basics are there... Other appearances: And I like how Bentley Bear is the main character shown on the Atari Mania cover art. Bentley plays a big part in the game where you as the Caretaker are solving a mystery during a night shift at the Atari Museum. Three appearances in 50th Anniversary with the arcade Crystal Castles, 2600 Crystal Castles, and Atari Karts. All this to say, I think Bentley Bear is already the unspoken mascot for Atari, or someone that Atari will at least feature on a re-occurring basis. And you know what, I'm ok with that. He's kinda cute, and I like how there is still a lot to know about the character. Some mystery left there for this somewhat greedy and yet friendly bear.

This is going to be a lot shorter than the last couple of projects. You can pick out details from those blog entries if you need to install a UAV mod of your own, but I'm not going to go over it all in detail again here - much of it is the same. One last console to mod, and no repairs needed! This time - a four-switcher. Or as I like to call 'em, a four-banger: Somehow, I don't think my console nicknames are catching on. 4x4? Foursider? No? Anyway... here's its RF: Pretty clean. And the parts bound for it: Yep - those are jacks! The plan this time was to drill holes in the case, and use jacks instead of pigtail cables. Also shown, from top left: a TBA internal audio board, a UAV mod, a Molex connector, and Console5 cap/refresh kit (lower left). When I opened the case, it was absolutely pristine. This console had never been opened since it was manufactured - the screws hadn't been broken loose yet, and it still had the inspection tag taped in place: The felt dust covers were still in like-new shape, as were the foil static strips (even though the adhesive had failed): Consequently, John decided to not have me drill holes in the case, and go back to pigtail cables instead. Same functionality, no holes. Fewer angry purists. But we still went ahead with the mod, because for the console to be useful to him, John needed it to have S-video and composite out. Here's where I found the connection points: Apart from +5v, everything had to be soldered to the leg of something. A little tricky, but not bad if you take your time. Ground is just a via on the ground rail, and the RF shield doesn't cover it, so it's super-easy to access (soldered it from the underside). And here's the mass of wires needed to connect it all: I really miss the mostly plug-and-play installation of the CyberTech mod. To get the wires out of the case, I used the RF-out hole. I modified it slightly, by filing about 1mm off one side: While not strictly necessary, this allows me to fit the Molex connector through it, and allows the output cables to be completely removed later if needed: The S-video and composite+audio cable fit quite easily. I used the same cables as the last two consoles I modded: The trick now was... how to secure the mod boards? I really didn't want to stick the circuit boards down with double-stick tape. I think that's inelegant, and makes removal difficult. The advantage of the four-switch though, is there's a ton of room in the case, unlike the Jr. or even the 7800. So I decided to use... double-stick tape! But not to stick the mods down directly. Rather, I stuck some heavy 3M double-sided mounting tape to the back of some 2mm craft foam (leftover from the Jr. mod), making a couple of adhesive foam pads: Then I stuck that down over a piece of solid wire (left over from some old cat5 cable): The thick double-sided tape will keep the foam in place, and prevent the wire from tearing through it. I added a second one for the TBA audio board: Then I used the wire (along with a little heat-shrink tubing for cushioning) to anchor the boards down. This is similar to what I did with the Jr. Easily removable later, if needed. The rest of the wiring is similar to what I did in the previous mods, including an inline Molex connector to allow easy disassembly later. The cables neatly fit into the stock RF cable guides. I cut a small notch into the RF shield (as I did with the Jr.) and covered the edges with electrical tape. RF is still intact and fully functional - but John would need to open the case up, and plug the cable back in: Just needed to reinstall the static strips (with the addition of some new, thinner double-sided tape), foam dust covers, and... why not - the inspection tag, and it was ready to button back up: Before I closed it up though, I wanted to check one more thing. When I installed the TBA audio board in the Jr., it seemed loud. This time I did a comparison test, and it is LOUD. I output a test tone from the Color Bar cart, and dialed the monitor's volume down until my iPhone's decibel meter app stabilized at 85dB: I then switched to RF - same console, same monitor, same volume setting and the level dropped nearly 10dB: When running the TBA audio through a mixing circuit with my AtariVox, I had to turn the AtariVox's internal volume level all the way up to be heard against the volume of 2600. Note for anyone making audio mods: adjustable output would be nice. That, or just match the level of the RF modulator. But this audio mod wasn't designed for the 2600. It works with it, but it was designed for the Atari 8-bit computers first. Much like the UAV mod itself. The picture (S-video shown here) is very clean. But it looks quite undersaturated to my eye. There's no adjustment for that, unfortunately. It is what it is: Although in comparison to its RF from before the mod, it's pretty similar: My sixer (with a CyberTech mod) is considerably more vibrant: I suppose the only way to really judge the UAV would be to run a series of tests of it and other mods all on the same console. It would be nice if somebody did that. Eh... maybe I'll feel inspired someday. Anyway, it's all cleaned-up and buttoned-up and on its way to John, along with the 7800 and Jr. It seems to have not gotten much use - even the orange stripe around the bezel has almost no sign of wear on it. The cartridge slot contacts were a little dirty, but some of that can just be attributed to age. Even the toggle switches were pretty clean (I polished them up anyway with some Flitz). So that wraps up all of John's consoles, and my series of UAV mod installs. At some point, I'll mod my own 7800, and may fix up a couple more 2600s I have. But other than just maintaining my own console, I'm not really interested in taking on any more hardware projects right now. Well... except for maybe one more thing. Published 9:00 PM, 3/29/23

Get comfy! These next two entries are going to be a bit on the long side. There's some saying in some profession or something somewhere where they say something like, "the first rule of whatever is to do no harm". Or something. This poor 7800 has been through enough grief without incurring any more damage. But as they say, "You can't break any eggs without making an omelette". Or something. As I was cleaning up the case of the 7800, I decided to try to polish some of the marks and scratches out of the aluminum, using Flitz (which is a non-abrasive metal polish I've used before). Unfortunately, I inadvertently removed a little bit of the red ink from the rainbow stripe in the process: Now, this wasn't meant to be a "bring it back to like-new condition" restoration, but it was still a bit of a bummer. Fortunately, John was cool about the whole thing, saying he liked the "vintage, faded" look. If I had an airbrush, I'd take a shot at repainting it. But the metal is all scratched and dented anyway, so it's never going to look "factory fresh" unless you go to some pretty expensive lengths. Not gonna happen. Anyway, there are a lot of other issues with the case besides the aluminum plate - namely a bunch of holes drilled into the case that I won't be reusing. John really didn't like the location of the previous mod's three RCA jacks, plus there was a gaping hole for the HDMI port (formerly where the RF out was), the now-unused channel switch hole, and more holes where a previous mod had apparently been. Oh, and a hole for the "HDMI on/off" switch. So... yeah - the case was far-from new. But again, this isn't a restoration. It's a repair. And while I'm intent on fully undoing the horrible mod that was done, the scars are a part of the history of the console. So I'll replace/repair/patch what I can, but the goal is to get the console properly functioning. But these are pretty bad. So we're going to do at least something about them. Besides the holes, two of the screw posts in the top of the case are in bad shape. One is completely broken: The other has a massive spiral crack running around it: So it's time to bust out my favorite plastic-repair kit: J-B Weld and paste wax. Johnson doesn't make their paste wax anymore (for some reason), so I had to find a lemony substitute (my old can got lost in a recent move): For the half-missing post, I made a mold out of painter's tape: Filled it with epoxy: And screwed the wax-coated screw into it: For the other post, I filled it with epoxy and troweled some epoxy into the crack from the outside: And drove in the other waxy screw (neatness doesn't count as much as strength): For the other holes, I cleaned up outside where they were drilled, and covered them with painter's tape: And filled them up with epoxy from the inside: After they dried, and the tape was removed, I had some nice, solid patches: I did the ones on the back in a separate pass, since they're at a 90° angle to the first ones: For the big former-HDMI hole, I needed to do something a little different. I approximately shaped the tape into a rectangle with a notch in the top: This is so I could fit a Molex Micro-Fit 3.0 connector through it. I'll get more into that in the next installment. After letting the epoxy cure 24 hours, it was time to see if I could back the screws out. I used a very snug-fitting screwdriver tip, and applied a lot of downward pressure while slowly turning the screw. After a few very nervous moments, the screw finally broke free and backed out, leaving threads behind: The broken post worked as well. I'd later go back and add more epoxy to the outside to further strengthen it: The other holes needed a little clean-up, some shaping and filing, but were solid: Well... except for a few voids. Guess I need to trowel it in there a little more enthusiastically next time... After a little carving and filing, I ended up with the hole that I needed for the Molex connector to fit through: I'm not mounting the connector here - I just need it to be able to fit it through: The posts got filed down and cleaned up a bit, and held the screws nicely: I test-fit the case back together to make sure they held, which they did: I'm not going to over-tighten them though. I suppose someday I should test just how much stress one of these can handle before it breaks: After getting the case patched-up and cleaned-up, I tackled cleaning the cartridge slot. I've described this before for the 2600, but here's a 7800-specific version. First, I found some cardboard about the same thickness as a typical 7800 cartridge circuit board. Then I measured the cartridge slot, and started cutting the cardboard with an X-Acto knife to fit: I trimmed it until it fit while still contacting all of the contacts in the slot: Then I gave it a good soaking with some contact cleaner: Then I just worked it up and down in the slot multiple times: Yep... those were pretty dirty contacts: On both sides: I can re-use it over and over, just by trimming off the worn/dirty part. I also went through and used contact cleaner on all of the console's switches. Surprisingly, they were all in good shape, so I didn't need to worry about replacing any. So now the console is modded, fixed, patched, and cleaned! What's left? Reassembly! Coming real soon! Published 1/29/23 at 12:22:AM

I'm over 50, thus I have 1 deceased parent (from year 2000), 1 elderly mom and her elderly husband (of 21 years) , my stepfather. This year I spent a lot of days in support of my 2 elderly parents. My stepfather's health deteriorated a lot in particular, and thus there were many trips to hospitals, caregiving, then in-home hospice, then his death in December at age 84. Now my mom is a widow again. The first time she was widowed in 2000, she was only a few years older than I am now. So, things like Atari, and homebrewing, well there wasn't much time or energy for that. But I did make some progress on these: Koffi Redux. I've been reworking the OG 2002 game in the same 32K memory space. Got some new tweaked graphics like more colors and more interesting backgrounds, a 2-player simultaneous gameplay, and plans for a more pinball-game inspired style of gameplay. But I did all this in the 1st part of 2023 with little progress in the tail end of 2023. I want to include things like appearing bumpers and targets (on the clouds and tree edges) for Koffi to hit and earn you points as you play. I'd like to release whatever I can accomplish in 32K as a demo, then bump it up to bank-switched 64K for a more fleshed-out follow up. Adventure II 5200 2023. I applied bug-fixes, minor gameplay tweaks, and engine improvements to the OG 2007 5200 game, still 32K as well. These improvements were based on what I did on Adventure II XE in the 2010's. I don't have much ROM space left. I was trying to make a new 'base' version of Adventure II 5200 that I could then modify for future DLC ROMs which would have fresh new things for folks to play. The changes significantly improve the efficiency of the sprite engine. The only problem is that these fixes introduced an old bug. I could put in a simple plug to identify if the bug happened and fix it on the next frame - but I really would like to solve the root problem that causes it. I put in an error trap , played in Altirra until the bug happened, then investigated memory. But I haven't really solved it as I haven't had time the past few months. Very little progress of another long-running 5200 Homebrew "Detective Powers". Going forward in 2024, after this end-of-year period where I'm really slacking, drinking, and just playing games and watching movies - I hope to get back into the rewarding creativity of homebrewing games for 5200 and A8.

(click here for ridiculously-oversized version) 413 < PreviousIndexNext >

406 < PreviousIndexNext >

391 < PreviousIndexNext >

Still catching up... 380 < PreviousIndexNext >

During a discussion with @SvOlli about how to optimize calculations required for a low-res, playfield based plasma effect within a 512 byte demo for the 2600, I started coding myself to verify my own ideas. This eventually led to the current code. Usually the plasma effect is created by combining sine waves. Since one of the goals was to use only minimal ROM space, I started by using precalculated, small sine tables. This worked OK, but still needed some ROM space and also a lot of checks in the code when wrapping around the table index. This also affected my second goal negatively: display as many scanlines with the highest vertical resolution possible. While looking for improvements, I found this website, which uses easy to calculate parabolas for generating sine tables. A stock 2600 cannot make use of this, due to the limited RAM. But Svolli wanted to use CommaVid bankswitching, which allows up to 2K of RAM. Great! After a little optimizing, I came up with the following code. Since it is placed right after the initial clear loop, A and X are 0 already, so that saves a few bytes too. ldy #$3f ; A = X = 0! ; Accumulate the delta (normal 16-bit addition): .loopSine ; Reflect the value around for a sine wave: ; clc ; this makes no difference pha ; = .delta adc .value sta .value lda .delta+1 adc .value+1 sta .value+1 sta SinLstW + $c0,x sta SinLstW + $80,y eor #$7f sta SinLstW + $40,x sta SinLstW + $00,y ; Increase the delta, which creates the "acceleration" for a parabola: pla ; = .delta adc #$08 ; this value adds up to the proper amplitude bcc .skipHi inc .delta+1 .skipHi ; Loop: inx dey bpl .loopSine The result is a 256 bytes sine table, ranging from 0 to 127. So now we have a large table which automatically wraps around. Nice. For creating the plasma effect, several sines with different offset and frequency have to be combined. Svolli's idea was to aggregate two sines per axis. And then aggregate the results per playfield pixel. If that result overflows (carry set), the pixel would be set. Even for a mirrored playfield, the number of calculations required for the final aggregates exceed the available CPU time by far. So the plan was (and still is), to do that on-the-fly during kernel display. Here is an excerpt of the original code: LoopKernel lda YSinLst,y ; from CV RAM, e.g. 50 aggregated sine values tay adc xSinLst+19 ; from ZP-RAM, 20 aggregated sine values ror .tmpPF0 tya adc xSinLst+18 ror .tmpPF0 tya adc xSinLst+17 ror .tmpPF0 ... ; and so on for 20 pixel and 3 PF registers lda .tmpPF0 sta PF0 This fully unrolled code would need 10 cycles per pixel for the sine list aggregation. So that's 200 cycles already, and with some overhead (e.g. colors), it would barely fit into 3 scanlines, and most likely need 4 scanlines. That's when Svolli contacted me, asking if I have any ideas how to optimize this. Since I had never coded the effect, initially I barely understood all the details. But somewhere in the back of my mind I had the idea that there must be a simpler solution. I first thought about using deltas in xSinLst to avoid the TYA, and this would have saved 2 cycles per calculation. But then I came up with something completely different. Instead of adding the two sine lists, due to their symmetric nature, subtracting them might work as well. And since we only need the carry flag, we could use CMP instead of SBC. Which means we could use A for aggregating the carries. Here is the new, faster code: ldy #KERNEH_H-1 LoopKernel ldx YSinLst,y cpx xSinLst+19 ror cpx xSinLst+18 ror cpx xSinLst+17 ror ... sta PF0 Now each pixel requires only 5 cycles, 50% saved! Which makes the code fit into just two scanlines now. But does it really work? Svolli was not convinced, so I started coding myself to test the idea. The initial results where OK, but no exactly what I was expecting. But that was due to a lack of understanding of how to prepare the sine lists. Svolli was kind enough to give me some detailed explanations. Later it turned out, that the new kernel code works almost exactly like the original code. Just that everything is shifted by 180°. Which doesn't matter for the plasma effect at all. The missing piece was the calculation of the sine lists for X and Y axis. Since we combine two sine tables per axis with varying offsets, we first have to change their offset each frame. To make movement smooth, 16 bit math is used here. So that's four 16 bit additions. Again we can make use of the 256 byte table size to ignore any overflow checks. And then I had the idea, that we could do eight 8 bit additions instead. Which makes the loop a bit smaller and saves some bytes. I only had to rearrange the variables a bit. offsetLst ds NUM_SPEEDS*2 xOffsetAHi = offsetLst ;xOffsetALo = offsetLst+1 xOffsetBHi = offsetLst+2 ;xOffsetBLo = offsetLst+3 yOffsetAHi = offsetLst+4 ;yOffsetALo = offsetLst+5 yOffsetBHi = offsetLst+6 ;yOffsetBLo = offsetLst+7 ... ldx #8-1 .loopOffsets lda offsetLst,x adc SpeedTbl,x sta offsetLst,x dex bpl .loopOffsets Pretty simple. What's left now, are the final calculations of the two sine lists from two sine tables each. This is pretty time consuming, as we have to do 20 calculations for the X-axis and about 100 calculations for the Y-axis. Since the X-axis goes into ZP-RAM and I need X and Y registers for the offsets, I make heavy use of the stack pointer here. For that I did put the list at the beginning of the ZP-RAM, so that I can now easily check the N-flag in the loop branch. ; setup X-list: ; A = xOffsetAHi from previous code ldx #xSinLst+PF_BITS-1 ; 2 txs ; 2 SP also used as loop counter ldy xOffsetBHi ; 3 = 7 LoopCopyX tax ; 2 ; clc ; 2 lda SinLst,x ; 4 adc SinLst,y ; 4 pha ; 3 tya ; 2 = 15 adc #13 ; 2 tay ; 2 txa ; 2 ; clc ; 2 adc #-11 ; 2 = 8 tsx ; 2 bmi LoopCopyX ; 3/2= 5/4 That's 28 cycles per loop. Nice! Adding 13/-11 to the offsets for each column simulates using sinus tables of higher frequencies. So we can use our single 256 bytes sinus table here too. The values used for adding are arbitrary chosen, they just have to look nice. The code ignores clearing the carry flags, because I found that the differences are hardly noticeable, only of you look very closely. Since my goal is to minimize the ROM space, this is an acceptable compromise, IMO. Now to the Y-axis. Here we have to do the same calculation for about 100 values, so this is very time consuming. Especially since I cannot use the stack pointer, so I have to use variables to keep track. Initially I planned to put the previous code into Overscan and the Y-axis calculations into VBlank. But then I would have wasted some remaining CPU time in Overscan. But I wanted to display as many scanlines of plasma as possible. So I had to split the calculation between Overscan and VBlank. Doubling the code was out of question, and a subroutine would have made the code more complex and slower. Then I had the idea, that I could check the timer during the loop, do the VSync when it is due and continue with the loop. The timer check would have cost me extra cycles, but the extra CPU time gained from Overhead made more than up for that. Still the timer check was bugging me, since reading INTIM takes 4 cycles. Eventually I realized that all my code execution timings are constant (or can be made constant), so I don't need the timers are all! ; setup Y-list: .tmpX = tmpVars lda yOffsetAHi ; 3 sta .tmpX ; 3 ldy yOffsetBHi ; 3 ldx #KERNEL_H-1 ; 2 = 8 LoopCopyY txs ; 2 = 2 dec .tmpX ; 5 ldx .tmpX ; 3 tya ; 2 adc #5 ; 2 tay ; 2 = 14 ; clc ; 2 lda SinLst,x ; 4 adc SinLst,y ; 4 = 8 tsx ; 2 sta YSinLstW,x ; 5 = 7 ; Instead of splitting the loop, do the vertical sync in the middle of the loop. ; This maximizes the available CPU time for the loop and minimizes the code. cpx #OVERSCAN_X ; 2 bne .skipVSync ; 3/2= 5/4 lda #%1110 ; each '1' bits generate a VSYNC ON line (bits 1..3) .loopVSync sta WSYNC ; 1st '0' bit resets Vsync, 2nd '0' bit exits loop sta VSYNC lsr bne .loopVSync ; branch until VSYNC has been reset .skipVSync dex ; 2 bpl LoopCopyY ; 3/2= 5/4 41 cycles per loop, ~3977 cycles (~53.3 scanlines) in total. That would have never fit into Overscan only, even if we deduct the 5 extra cycles for the VSync check. Finally I just have to waste the few remaining cycles (~150): ldx #VBLANK_X ; waste remaining time .waitTim dex bne .waitTim sta WSYNC For now, everything was just black and white, which looked pretty dull, even with animation: But the kernel code had ~25 cycles free within its two scanlines. By rearranging the code a bit, I was able to merge the free cycles into one block. And after a bit of experimenting, I came up some code which mixes the values of PF1 and X. Not exactly what plasma usually looks like, but still nice looking. Maybe one could use a precalculated a color table here, but what do I know. ; A = PF1, X = YSinLst,y and #$60 ; 2 ; 0, 2, 4, 6 adc colorOr ; 3 ; +2, 3, 4, 5, 6 sta .tmpCol ; 3 ; 2..12 txa ; 2 lsr ; 2 lsr ; 2 lsr ; 2 lsr ; 2 ora .tmpCol ; 3 sta.w COLUPF ; 4 = 25 @17 To make the colors move lively, I change colorOr every 256 frames: inc frameCnt ; 5 ; update color bne .skipColor ; 3/2= 8/7 lda colorOr ; 3 cmp #$50 ; 2 bcc .ok ; 2/3 sbc #$50+1 ; 2 .ok adc #$20 ; 2 sta colorOr ; 3 $28..$68 .skipColor That looks much more interesting: One last little trick is, that I use BRK to jump back to the begin of the main loop. Now, what's the final result? The minimal code (no color) needs exactly 247 bytes, with colors added ~30 bytes more. And in the end I managed to display 97 double scanlines (NTSC, 117 for PAL). So a nice demo with sound and some bells and whistles within 512 bytes seems very double. I also experimented with a 32 pixel wide, non-mirrored playfield, but that takes at least 385 bytes and halves the vertical resolution: Anyway, I am no demo coder, so I stopped here. But I learned some new tricks, which I can maybe use in the future. I have attached some ROMs and source code files. PlasmaCompact.asm shows the cleaned code, with all options and further distracting stuff removed. Then I have the same code, prepared for PAL and NTSC, and with some assembler options. I also added my code for the non-mirrored playfield. And last not least, a version with Svolli's nice full coloring. The ROMs show the results with all options enabled, which means you can change the settings with the joystick: With left difficulty = B you can change the offset steps within the setup loops. Left and right for X offset steps, up and down for Y offset steps. Since there are two values each, you change be 2nd value by holding the fire button. With left difficulty = A you can change the speed of the initial offset changes. Again, left and right for X offset speeds, up and down for Y offset speeds. And since there are two values each here too, use the fire button for the 2nd one. By using RESET, you can reset all settings to their initial values. The effects of the changes are hard to describe. But when you experiment with them, you will get an idea. Here is an example: I hope that made sense or you have at least some fun playing with the plasma effect. Thanks to @SvOlli for contacting me and helping me out quite a lot. Therefore I respectfully waited with the release of this entry until after the Nordlicht 2023 demo party (September 8. - 10.), where he successfully presented his demo. Plasma.bin Plasma.asm PlasmaCompact.bin PlasmaCompact.asm PlasmaAsym.bin PlasmaAsym.asm Plasma_FC.bin Plasma_FC.asm

Next project..

So, remember how Sean Connery would pronounce "Junior" whenever he was talking to Harrison Ford in "Indiana Jones and the Last Crusade"? Well, there you go! I'll be repairing and adding a UAV mod to John Champeau's 2600 "Chewnyor". Let's take a look at this crusty, disgusting thing, shall we? In all fairness to John, he thinks he picked it up like this either as part of an eBay lot or from a yard sale. It looks like it had been buried in a yard... It's certainly been well used... the power switch actually has a worn-out spot on it. And a lot of... "patina" . The switch also doesn't work reliably - so that's going to be one of the first things to get fixed. The other switches are just... gross. And the Reset switch doesn't work at all. It must have been getting progressively worse over time, since you can see gouges in it where someone stabbed it with something trying to make it work. Can't imagine someone getting that upset at a Reset switch. So first things first - I took the shell off, removed the switches (actually, they're just switch covers), and gave everything plastic several really good cleanings. Toothbrush, dish soap, whatever it took. That really highlighted the gouges in the Reset switch. But I decided instead of replacing it, to try and just fix it up a bit. Why? Well, for one thing, the cover was functionally fine. And also, at the time I started working on this (which overlapped the 7800 project), Best Electronics was limiting orders to only three items per order, and I needed the replacement power switch from them, plus I was ordering a new 7800 power supply and one of their upgraded Pro-Line controllers as well. So that ate up my three items. Incidentally, I documented how the upgraded Pro-Line controller didn't work properly. I exchanged several emails with Best about it (which included several implications from them that something had to be wrong with the consoles on my end, because clearly the joystick worked perfectly before they shipped it ), but after including photos and a thorough recount of exactly what was happening and how I tested it, they agreed to take it back as a return. So I shipped it off to them and waited for what I thought would be a replacement. And waited... And waited... Eventually, what I got, was a refund on my credit card. No further emails. No replacement. No "yes we tested it, and it's just as you said". Nada. Now, I like many of Best's products. Their upgraded 7800 power supply is very nice (although I had to do a bit of filing to the plastic, because the connector is too tight of a fit). And I've bought 2600 joystick upgrade/rebuild kits from them, a Lynx replacement speaker, and more spare Atari OEM parts than I can count. But I'm not going to waste my time (or money) on their Pro-Line upgrade again. Not unless they come up with better installation instructions than: Even if they manage to make a better kit that doesn't require a cigarette lighter, I've played the 7800 enough recently to realize that even if working properly, the 7800 controllers are an absolutely terrible design. They've earned their nickname "Pain-Line" very well. So I'm going to do something else. But that's for another blog entry, on another day. Meanwhile, back to Chewnyor... I used a four-way emery board to sand out, refine, and polish the worst of the gouges on the switch: In the end, it turned out pretty-well. Certainly worth salvaging: Now... about making the Reset switch actually work. With the switches (actually, switch covers) removed, what you end up with are a couple of very thin mylar switches: Just tapping on these with my finger triggered them without any issues. So the mylar switch itself seemed fine. (Replacements are available from Best, but again - three-item limit. ) I clipped on a multimeter so I could test them without going to the hassle of hooking the console back up: When I swapped the Select and Reset switch covers, the problem went with the covers. So the mylar switches, again, just fine. The switch covers use foam rubber "springs" that are stuck with double-sided tape to their underside. This gives them enough rebound so they're not always "down". But these have been worn nearly flat - the Reset one is on the left. When I swapped just the foam springs, the problem followed the foam. So the switch covers and switches - both fine. So maybe the foam had spread out just enough to prevent the switch cover from actuating the switch. Or it was so compressed, it no longer had any give to it. At any rate, they needed to be replaced. Now these are one thing Best doesn't sell. Which is odd, because they're easy to make. I went to a local craft store and picked up a couple of sheets black craft foam. One with an adhesive backing, one without (since I didn't know how well it would stick, and I might have to use other double-stick tape): 2mm is just the right thickness to match the un-squished original foam: So I measured and marked out the foam (including the centers of each square): The "X" was so I could align a 5/16" hole punch. 1/4" would be too small to leave any space around the post on the switch cover. You can get a 5/16" punch off Amazon pretty cheaply. I didn't. (To be fair - I bought mine at the craft store, and it was the only 5/16" one they had.) A little cutting, and presto! New sponge spring-things! I made a few attempts at these, but these are the final ones. I cut these just a tiny bit smaller than the originals, so there wouldn't be any clearance issues as they compressed over time. The adhesive backing worked just fine! So I installed them, and Select worked just fine. Reset, however, didn't. I could press it pretty hard and get it to work, but that wasn't going to cut it. Taking it back out, I noticed a small, round dent along one edge (near the lower right corner). Something was keeping the switch cover from fully depressing. Turns out, there's a round "key" of sorts, that sticks up: This holds the mylar switch in position: So, I cut a notch around it, figuring that would fix it. And it did! It worked great - but not for the reason I was expecting... When I looked back at the mylar switches again, they had slid out of position. Bother. So I put them back where they belonged, and taped them in place: However, now Reset didn't work again without applying a lot of pressure to it. When it was slightly off-center, it worked perfectly fine. So... go with what works. I punched a new hole to reposition the mylar switches (who's laughing at my overpriced multi-punch now?), and that fixed it. Both switches now work with just a tap (yes... you can just "tap" a Reset switch - you don't have to stab it). At some point, the mylar switch may indeed need to be replaced. But that's an easy enough fix later, if needed. As long as you only need to order two other things. So up next... time to get inside this thing. Atari made it quite compact. And kind-of cheap. Long-gone are the industrial tank-like components of the heavy-sixer. Here's what will be going inside it, at least in part. From left: a Console5 recap kit (including a new voltage regulator and power jack), a UAV mod and internal audio board from The Brewing Academy, and replacement power and TV Type switches from Best. (You can order multiple quantities of your three items. So I figured I might as well replace both switches.) First up, the switches. I had tried cleaning the power switch, but it was just worn out. It would turn on, but the slightest nudge would cause the power to flip back off. The newer switches (bottom) have quite a different profile than the originals. This was a bit of a concern at first... But, there's plenty of height in the switch covers to accommodate them: Here's the difference between new (left) and old (right): And with both replaced. Note that the caps have also been done at this point (along with the power jack and regulator): One oddity about this Jr., is that the difficulty switches were different from each other. The channel switch (far left) and left difficulty (center) are the same. But the right difficulty switch is a different model entirely, and worked much more stiffly than the others. So since the right difficulty switch gets used a lot more than the channel switch, I swapped them around: The last bit of maintenance/repair work to do, was clean that nasty cartridge slot! Canned air only gets you so far. Time to break out the cardboard! Just find a piece no thicker than a typical 2600 cart's circuit board. After soaking it in electronics cleaner (isopropyl alcohol would also work) and working it in and out of the slot a few times, you can see how gungy the contacts were: No need to throw it out though - I can re-use this, just by snipping off the dirty part: Here's the Jr.'s RF output. That's with a stock Atari RF cable. It'd be a bit cleaner with a proper one. Look at how dim that power LED is though... you can hardly tell it's on. May have to address that. And this Jr. does bus-stuffing, too. Not that it will likely ever get used... but it's nice to know. Here it is, all cleaned up: Up next: adding a UAV mod. (Spoiler alert: it's not going to be fun.) Published: 2/23/23 2:47PM

A friend and I decided to check out a place the other night that reportedly had classic arcade games: Let's Play Cafe in Monroe, WA. Admission was $20 and everything was set to free-play. I was pleasantly surprised by the number of actual classic arcade games they had there - most of which actually worked! I played: Joust, Defender, Robotron: 2084 (all three part of a Williams multi-game cabinet), Qix (which had a slightly wonky joystick), Gorf (very reassuring to see that we nailed the blue-background in Astro Battles for the Champ Games version), Scramble (which had a very unresponsive joystick - it felt like there was a super-stiff spring preventing it from moving), Centipede, Asteroids (there's nothing like playing on a real vector monitor!), Popeye (I don't recall this having a strict four-way joystick, but it made playing it really difficult), Roadblasters (which crashed with a "Bankswitch error" not far into the game), Pac-Man, Hydro Thunder, and possibly a few others I don't recall. But they had a good selection, especially comapred to what passes for most arcades these days. They had some newer games (and by newer - I mean 1990's), as well as quite a few pinball machines. They had a few unusual games in there too, including a Starblade which was under repair, and a true rarity: Baby Pac-Man - a fully working one at that! Having played Bob and Kurt's version for the 7800, I couldn't resist trying to play the original. We spent over two hours at Let's Play, and I spent much of that time on Baby Pac-Man (along with Qix and Gorf). Man... that is one addictive (and incredibly hard) game. After countless attempts, I finally managed to clear the first maze. I probably got my 20 bucks worth out of that game alone. We'll be going back again at some point. Hopefully they can expand their selection (would love to see Battlezone and Tempest), and make a some repairs to their existing games. Anyway... speaking of the 7800 and making repairs - let's wrap this project up! How's that for a segue? Time for some cablin'. Here are the donors, plus the Molex connector I'll be using to hook them up: The video cable is a leftover S-Video cable from a patchbay I had at work (from Clark Wire and Cable), and the audio cable is a 3.5mm stereo to dual RCA cable from Monoprice. However - I'm not using it for stereo audio. I'm using it for mono audio + composite video. The reason I'm using that particular audio cable, is because the UAV mod only outputs mono audio, so instead of having two cables hanging out of the back of the 7800 for a superfluous "stereo" output, I'll use one connector for audio, and I'll repurpose the other for composite video. John can add a "Y" cable if he should need to plug the 7800 into stereo inputs. He wanted composite video in addition to S-Video (since not all of his monitors have S-Video), and this provides a second RCA connector in a compact form factor. The only downside? The right audio connector is color-coded red. Yellow is typically used for video. But we can fix that... Presto! Composite video, mono audio, and S-Video! Job done! (As an aside, I tested an S-Video to composite adapter to see if it would be an acceptable substitute for a dedicated composite output - it wasn't. The picture was terrible.) Just to make sure everything worked end-to-end, I used a terminal block to temporarily hook everything up and test it: Composite works! And S-Video works! (Audio also worked.) In previous mods, I've used Molex Micro-Fit 3.0 connectors to connect the mod wiring to the output cables, but have always had trouble crimping the pins. The connectors are tiny, and I had bought a crimping tool that did not cost $400. The tool I had could (in theory) crimp the conductor and insulation at the same time, and was a ratcheting-type crimper (which I've used at work for other connector types), but I could rarely get the pins in exactly the right position to crimp them, and it was a massive source of frustration. While starting on the 7800 wiring , I completely trashed multiple pins in the attempt and finally gave up and did some more research on finding an alternative crimping tool. And, I found one: It's not a ratcheting crimper, and you have to crimp the conductor and insulation in separate passes, but it works. I can align the pins in the tool every time, and it crimps them solidly with a very reassuring "click". Well-worth 1/10 the cost of Molex's tool. All crimped up and ready-to-go! The reason I use the Molex connector is so the main board can be unplugged from the output cables, in case the 7800 has to be taken apart (again) and repaired. The 7800 board has to be tilted up at the back in order to be removed, so the output cables need to be completely out-of-the-way for that to happen. Since they're going out the back of the case right above the main board, the only way to do that is to make that cable fully removable. The excess cable fits through a hole in the side of the RF shield (originally intended for the non-existent expansion port on this 7800). The blue heat-shrink tubing is there to protect the wires as they go through the shield. The output cables are held down to the board with a twist-tie where the RF modulator used to be. I'd usually use a zip-tie for this, but I didn't have one that skinny, and this does the job just fine: When I get around to modding my own 7800, I'm going to have to route the cables differently because I won't be removing the RF modulator or drilling any holes. Fortunately, someone has already solved that problem. One more job to do. See capacitor C64? Of course not! Because its label is hiding underneath it. But disconnecting its right leg should improve compatibility with certain games (mostly Activision games and the SuperCharger). ' -^CrossBow^- made the suggestion of adding a switch to enable/disable it. I checked with John and he liked that idea, so I decided to add one. But I wanted a small, unobtrusive switch (unlike the toggle switch used for the previous HDMI "mod"). So what better brand to use than Radio Shack? You can still buy their stuff from Amazon! It seems completely period-correct to add a Radio Shack switch to an Atari 7800 too. Man... that brings back memories. Now if I could only find my Battery Club card! Score! I even still have eleven free batteries remaining! Time to cash this puppy in! So first, some very careful measuring, followed by some very careful drilling, cutting and filing: Perfect fit! Found C64 yet? Hint: it's mounted horizontally. I desoldered the right leg, and re-soldered the left one to more firmly anchor it to the board: More Molex! I tidied up and reinforced the connections with some heat-shrink tubing. Also, it will protect the wires when going through the RF shield: Here, I bent the orange heat-shrink tubing while it was still hot, so it cooled and stayed at the angle I wanted it at. The blue tubing just keeps things untangled and tidy. All hooked up! Again - the Molex connector keeps the main board easily removable. One finishing (P-)touch: Before final reassembly, it's time to clean off the solder blob on the RF shield leftover from the previous mod: And to clean up the solder blobs and adhesive gunk on the inside of the shield: Also, I needed to make a small notch for the Compatibility Switch™ wire to feed through: I covered the notch from both sides with electrical tape to protect the wires, and cut a slot for the wires to feed through: On the expansion port side, I did the same thing, but left a larger area for the wires: I removed the solder and cleaned up the adhesive, then polished up the whole thing with some more Flitz. Shiny! It took a lot of solder wick to get the blobs off. I couldn't get rid of the fingerprints though - they're etched through the finish into the bare metal beneath. I'm wondering if this happened at the factory when it was first assembled? With everything ready to be put back together, it's time for some final testing: Thanks to Trebor for adding a POKEY 4000 version of the 7800 Utility Cart to his ROM pack! I can see the POKEY in my Concerto cart now: And it works! (You'll have to pretend to hear it.) 2600 video looks good: 7800 video looks good! Right - time to put this back together! But first... I'm missing a screw. Rather, the 7800 is. Fortunately, Atari used the same sized screws for other things - in this case, CX-40 joysticks. So I grabbed a spare screw from a broken joystick, colored the top of it black to match the rest, and NOBODY WILL EVER KNOW!! Unless they read this. So, like... five people. Cables are routed... RF shield is reattached... time to button 'er up! Underneath, showing where the cables exit. Also, in case anybody wants to add this to the list... The Magic Switch of Compatibility™! FWIW - every Activision game I've tested works with the switch in either position. However, I've been testing them on a Harmony cart, since my real carts are still packed away. But hey - it has the switch! One more thing to add... it's always driven me up a wall that Atari didn't even care enough to label the difficulty switches. They barely even get mentioned in the manual, and even there they got them backwards! So this fixes that little problem: And the final, finished console! All cleaned up, fixed up, re-modded, and ready to play all of the awesome 7800 homebrews, Food Fight, and... well, the rest of the 7800 library is pretty-much crap. But it plays 2600 games, too! One final thing to check... how does the S-Video output look scaled up to HDMI? For reference, you can revisit Part 1. The RetroTink 2X-Mini: And the Gefen GTV-COMPSVID-2-HDMIS: And since I got to play the real Qix the other day... I just had to fire up the Champ Games 2600 version - Qyx: And of course, Baby Pac-Man: Looks great in HD, too! And yes... my HD monitor is having some light leak issues at the corners. Guess I'm going to have to get a new one pretty-soon. Edit: Whoops! Forgot to show what the finished console looks like in action, featuring the not-blinding-plain-old-red-LED: Much better! Well - that wraps up the 7800 Mod Mixedup Messup Whatever Fixit Thingy! Special thanks to -^CrossBow^- and alex_79 for their help with this project - working on a 7800 is new territory for me, and I really appreciated their insight, experience and advice. That kind of support from the AtariAge community is one of the reasons I've stuck around here for over 20 years! But we're not done with John's consoles just yet. Stay tuned... as next time I fix (and mod) a 2600 Junior! Hopefully, that one will be a lot shorter. Published 1/29/23, 2:22 PM

I realized that there is no place where people can download my ROMs. So I decided I should use my blog to provide them. There will be ROMs of all my homebrews. And maybe I will add some demo or unfinished stuff later too.

409 < PreviousIndexNext >

402 < PreviousIndexNext >

Wow... the last Spoiler-free review I posted was waaaaay back in October 2020! Of course 2020 was during the pandemic, so the only movies I was watching then were on home video. I have been back to the theater to see movies since then, but frankly, none of them were really worth reviewing. Actually, I don't even remember most of what I saw now. Maybe I'll do a Spoiler-free catch-up edition, with just short one or two sentence reviews and a score for each movie. (More to warn people away from seeing them, than anything else.) I had intended to write up reviews for some of them, but just wasn't inclined to do so. I'm not all that inclined to write much about Godzilla Minus One, either. Except this: Go see it. It's awesome. This movie isn't part of the recent slog of Legendary Pictures' "Monsterverse" films featuring Godzilla, King Kong and so on. This is by Toho - the company that originated Godzilla in the first place. It was filmed in Japan, the dialogue is Japanese with English subtitles, it takes place in a devastated, war-torn Japan just after World War II, had a budget of less than $15 million, and is awesome. No, I didn't drop a zero there. $15 million. Not $150 million. And even though at times the visual effects belie the film's incredibly tiny budget, it just doesn't matter. The story and the characters are deeply compelling. Everything else is secondary. This is how movies should be. If you're engrossed in the story and care about the characters, the trappings of the film itself don't matter. You're far more likely to just enjoy the film for what it is. And this isn't a knock against the movie's visual effects at all. They serve the story perfectly. I think many big budget films (or TV series) get knocked for subpar special effects because the audiences get so bored, there's nothing left to do but look at the effects and pick them apart. The best blockbuster films were great not because of their effects, but because of their characters. Movie studios have totally lost sight of that, and have turned movies into just being excuses for spectacle. That said, Godzilla Minus One certainly has the requisite scenes of Godzilla wreaking havoc. But the stakes are personal. They're emotional. You care about the people in his path of destruction and what happens to them. The theater I went to last night was pretty packed, and at times the entire audience was absolutely silent, because they were completely captivated by the human story playing out on the screen in front of them. Godzilla Minus One has heart. The actors, notably Ryunosuke Kamiki as Kōichi Shikishima, are wonderfully cast and a joy to watch. I was rooting for them throughout this film. Not to just defeat Godzilla, but to triumph over their own personal wars as well. To just live. Go see it. It's awesome. Godzilla Minus One gets a 10/10.

397 < PreviousIndexNext >

389 < PreviousIndexNext >

385 < PreviousIndexNext >

384 < PreviousIndexNext >

Almost there... 381 < PreviousIndexNext >

Two episodes in one day? Buckle up! Artie's got some catchin' up to do... 379 < PreviousIndexNext >

My older brother gave me his Atari 2600 in 1996 when I was 8 years old, and it was my first gaming console. A Sega Genesis soon followed and a couple years later, I got a PlayStation. I still played my 2600 though, and within a few years, I had amassed quite a collection of games for it. Anytime my mother and I would visit a flea market or Good Will store, I'd pick up a few cartridges for about $0.25 a piece! I maintained a (mostly) casual interest in my Atari into adulthood. Sometime in 2010, I saw the Tinkernut video and learned about bAtari Basic. I installed the program and soon put together a demo that bore a striking resemblance to the one Tinkernut had made. I didn't make much progress beyond that initial demo and eventually lost interest in programming although I still continued to collect Atari cartridges. Fast forward to 2023 and I'm not much into gaming anymore, but my kids are playing Nintendo Switch and PS4. They also like watching gameplay videos on YouTube and my son discovers a series of videos by 8bitsinthebasement about making Atari 2600 games and an old interest is rekindled. I downloaded bAtari Basic again and resumed a 13-year-old project of mine. Within a few weeks, I had thrown together various demos and completed a hack/clone of another game using someone else's program and filling it with my own "guts", replacing the sprites and playfields with ones I had created then changing the sounds, win, and game over screens, then finally adding a title screen. While this was somewhat of a personal accomplishment and I learned quite a bit from this elaborate hack, I wasn't entirely satisfied and wanted to learn more and try something different. I purchased the book "Programming Games for the Atari 2600" Programming Games for Atari 2600: Toledo Gutierrez, Oscar: 9781387809967: Amazon.com: Books and decided to give 6502 Assembly a shot despite all of the warnings out there about this language. I installed Visual Code Studio with the Atari Dev Studio extension and started from the beginning with the simple example demos. From the start, I had several issues and was discouraged. I finally decided to reach out to the members of atariage forums and received help and advice immediately. I've never really participated in forums, but instead have always been a "lurker". I was surprised by the quick response and assistance without any condescendence whatsoever. After correcting my mistakes, I finished the first demo, which was simply displaying a blue screen. Later in the morning, I finished the second demo, displaying a split color screen, then the third, adding a ball.

It has been a while since I have written one of my blog entries about the technical challenges of making my RPG "Penult" for the Atari 2600. By far my biggest challenge has been making the game with the extreme memory constraints of the console, so this entry will discuss how I dealt with those issues. RPGs tend to be very memory-hungry. You need to keep track of a character's name, stats, inventory, experience, location, current state, etc. If there are multiple party members, these need to be tracked for each character. The Atari 2600, on the other hand, only has 128 bytes of RAM. For Penult, I am using a cartridge format that lets me double that, for a total of 256 bytes of RAM, or one quarter of a kilobyte. Over half of this RAM is used to track the tiles currently displayed on the viewport portion of the screen as well as the text characters in the two text lines below the viewport. The visible map is 12 tiles wide by 7 tiles tall, for a total of 84 tiles. The text lines below the viewport are each 24 characters long, or 48 for both. All of these together take up 132 bytes of the 256 bytes available, leaving 124 bytes remaining. The Stack On the Atari 2600, stack space comes from the same limited pool of RAM. Every subroutine call takes two bytes to store the return address of that routine on the stack. Due to the extremely limited RAM available, I was careful to never use more than 4 bytes of stack space, which means never having more than two levels of nested subroutines. Allowing 4 bytes for the stack means that the actual amount of RAM available for the game is only 120 bytes. Hero Name and Gender When you only have 120 bytes of RAM to work with to make an RPG, even allowing the player name their character seems daunting, as that name would have to be stored in RAM. I considered having the hero already be named, or letting the player choose from a variety of pregenerated names, but these options didn't appeal to me for the style of game I was making. In the end, I allowed players to use up to 6 letters for the hero's name, and I have code to compress this along with the choice of gender down to 4 bytes of RAM. Companions With extremely limited RAM, having a party of characters each with their own stats simply isn't feasible. Even a single companion would require at least 16 bytes to keep track of stats, equipment, etc. However, having the hero adventure alone didn't fit the style of game I was trying to make, either. My solution was to have the hero have a small fey dragon companion that under the hood shared most of the hero's stats, and didn't need any of its own equipment. The dragon e.g. has the same maximum hit points as the hero, and always starts with maximum hit points at the beginning of combat. The hero's level is used for things like attack roll modifiers in combat. Finally, the power of the dragon's abilities is based on the hero's game stats. E.g. if the hero has a high strength, then the dragon's bite will do more damage, or if the hero has a high intelligence, then the dragon's breath will be more damaging, and its heal ability will heal more hit points with each usage. This also has the side effect of having the dragon companion of different heroes have different strengths and weaknesses, and it also means that dragon's effectiveness will automatically increase as the hero becomes more powerful. Single-bit Variables A byte has 8 bits, and I keep track of as much as I can in the game with bits instead of bytes. I use 7 bytes to effectively make 56 single-byte variables in the game to save RAM (actually more than this since some bits end up getting reused in different parts of the game). Temp Variables Since the Atari 2600 doesn't have screen memory, a character display, etc, 28 bytes of RAM is used to build and display the 96-pixel visible screen kernel that I use for the viewport and text lines. Since these bytes do not have to maintain their values after the screen is drawn, it means they are available in other parts of the code to use as temp variables. Whenever I can, I make heavy use of temp variables in my code to avoid reserving more of the very limited RAM for permanent variables. Variable Reuse Also to save RAM, there are many variables that get used for multiple purposes. E.g. variables that are used in combat may be used for other purposes out of combat. This can be tricky to do correctly to avoid situations where both variable values would be needed at the same time, but is vital to avoid running out of RAM. Combat Combat can use up a lot of RAM since you need to track the position and hit points of each opponent in addition to the hero and fey dragon companion. For this reason, there are never more than four opponents on the screen. Even enemies that can spawn more of their kind only do so when there are less than four of them on the screen. I also save seven bytes by encoding the X and Y positions of the combatants and any active missile in a single byte instead of using a byte to track each axis. Static Map Games like Ultima have cities where people wander around, and outdoor areas where you see monsters roaming the land. Doing this in my game definitely wasn't feasible, since this would require a huge amount of RAM to track all of these NPC and monster positions. Instead, the town maps have NPCs with fixed positions on the map, and the outdoor map doesn't show opponents until you encounter them. Also for reasons of limited RAM, the game can only track one ship at a time. If one becomes inaccessible and a new one is purchased to replace it, then the old one is lost. Simplified Inventory The game keeps track of the hero's melee weapon, ranged weapon (if any), armor, and a few miscellaneous items. If e.g. their armor is upgraded from leather to chain, then it is presumed that the old suit gets donated to that city's defense effort. This greatly streamlines inventory management and vendor interactions, but more importantly it saves a ton of RAM by not having to track unused equipment. Dungeon State Dungeons in Penult are 8 levels of 16x16 tiles. I wanted to have treasure chests that could be looted, and the game would keep track of which chests have already been looted and which ones hadn't. As there could be chests in any location on any level, there simply isn't enough RAM to keep track of all of these in a normal fashion. The solution I came up with is in a separate blog entry: The Problem of 2048 Treasure Chests. While there were sacrifices that needed to be made along the way, all and all I am quite happy with how much of an "Ultima RPG feel" I was able to create with the limited resources I had to work with.

Happy Towel Day! Celebrating Douglas Adams who wrote Hitchhiker's Guide to the Galaxy. (HHGTTG) I dare say, if you like the lunacy of Bubsy, you'd like the off the wall turn tropes on their head comedy like this book series. I have a shot of the Infocom game that originally introduced me to the HHGTTG series.... This is the same company that Bubsy creator, Michael Berlyn, also wrote Cutthroats and Infidel for. And I believe I have this same game package for those games too. These games came with the "feelies", in this case the "Don't Panic" badge, the bag of pocket fluff, a bag of a microscropic Space fleet, and the glasses that turned black whenever something dangerous was around, keeping you from panicing. Awesome series. And this HHGTTG logo/mascot of a sorts was the inspiration for the Bubsy Fan Blog icon. Saw that on the Bubsy pilot and thought... hey... we could have some fun with that. So Bubsy fans, enjoy out there, and don't it's a tough galaxy out there so don't forget your towel ! ------ Don't see pictures, try this link: https://forums.atariage.com/blogs/entry/18548-cruizin-the-galaxy-happy-towel-day-may-2023/

Well at least some time this month. Every time I see "May the 4th Be With You" I am all "Oh yeh... Bubsy's birthday month!" So have a great month out there fellow nerds! And be careful tomorrow for the RETURN OF THE FIFTH!! (Sith pun).

Time to cut stuff up! Choppity-chop! And yes... this part is non-reversible. But the cables have to exit the Jr. somewhere. There aren't many places to do this, unless you repurpose the RF jack, or remove the RF modulator and the channel 2-3 switch. Neither is happening here, so I need to cut a hole. Because of how I routed the cables and the location of the mods, I decided the space between the channel 2-3 switch and the corner post of the case was the best spot. So I measured the width of the cables (stacked vertically) and notched the plastic with an X-Acto razor saw: I measured the height of the cables, then cut three slots, to minimize the chance of cracking the plastic when I broke the pieces out with pliers: Test fitting the cables - the bottom cable lies on top of the circuit board, so the top of the case will need to be notched out to accommodate the height: A little more cutting and filing, and the Jr. has a new hole: And the cables fit neatly through: While I'm working on the case, one of the plastic tabs that holds the circuit board in place had broken off. Here's the intact one: And the broken-off one: I used some painter's tape to align it... And globbed some J-B Weld in there to repair and reinforce it, adding more tape to hold it in place while it cured: More test-fitting. It all fits - I just need to trim the output wires to length, and solder them to the mods: Just making sure the case still closes... More soldering! Solder one, clip the next one to it. Rinse and repeat. I trimmed the excess off afterwards. And yes, I remembered to install a smaller tip in my soldering iron this time. Thanks for asking! Many (Radio Shack Helping) Hands make light work. Or in this case, re-soldering the +5v and ground wires to the UAV board. You might be able to tell in the photos above, I had soldered them so they came off the edge of the board and ran headlong into the RF modulator. I didn't like that, so I desoldered them and reattached them so they went off to the sides: With everything finally connected... would it work? Well, rather anti-climactically - yes! First try! While testing, to avoid shorts, I used some leftover wire to tie some unshrunk heat-shrink tubing to the underside of the the mod boards as insulators. More on that in a minute. I still need to do something about that LED though. Once the case lid goes on, it's almost too dim to see. While adjusting the colors and checking the S-Video picture quality, I noticed some odd thin black vertical line running down the center of the screen: Adjusting the trimmer on the UAV mod made it go away: Remember the parrot from part 1? Here it is, now in all of its S-Video glory (ignore the moiré patterns - it's my camera, not the video): So - time to button this all up! But how am I going to attach the mods? Tape? Glue? J-B Weld? Screws? Chewed-up bubble gum? Nope. Wire! I took some leftover solid Cat5 wire, and soldered the ends to a couple of empty vias on the main board: I put some heat shrink tubing on it for a little extra cushioning, and used it to tie the two boards in place. I left the large pieces of heat-shrink tubing underneath them from before. This anchors them in place nicely, and protects everything from shorting. No glue, no tape, and completely reversible. The black wire to the left is ground for the UAV mod and the audio board. And finally, the finished mod install. Or more colloquially, ten pounds of crap in a five-pound bag: And yes - the repaired clip held up just fine: All buttoned-up with its pigtail S-Video, composite video and audio cables: Pictures! RF is quite saturated, but looks okay. Although see if you can figure out what's different with these RF pics, from the ones from part 1: Composite video. Looks good... but is definitely less saturated: And S-Video. I just couldn't get my camera to reliably capture both interlaced frames. I need to figure that out. But this all looks fine in real life: RF again. Very saturated, and the color difference between the upper and lower half is far more pronounced than with composite or S-Video: But since this will be mostly used for composite, I calibrated the color for that: And S-Video is pretty-much the same. But the text is crisper: Again, the RF is very saturated. And pretty dark: And composite is... uh... hey! Those vertical lines are back! And in S-Video, too! But I didn't change anything. What's going on? Sometime later... without changing anything, they were almost gone again: After going back to part 1 and looking at the RF pic there, it's pretty clear those lines were always there. This isn't a mod artifact, it's a Jr. one: Did you catch the difference in RF pics? And yes - I did replace that super-dim power LED. Sourcing it was easy - when I replaced the one in John's 7800, I had 99 leftover. It's silly, but it's cheaper to buy 100 LEDs off Amazon with free shipping, than to buy one off Mouser and pay for shipping. I miss Radio Shack. So that concludes fixing and modding this Jr. It's a far cry from the gross, crud-encrusted mess that I started with: Even the mangled Reset switch looks pretty-good now: One thing I overlooked in Part 1 is that the Select and Reset switches are "hinged" at the top (you can see the plastic tabs that serve as hinges in some of the photos there). This is why the entire lower third of the switch has PUSH on it. If you push there, the switches work effortlessly. If you push higher up, there's more resistance and the switches don't respond. I'm sure Atari saved a whopping penny or two by not using actual momentary switches there. A couple of final shots of the finished product: Some final thoughts on the Jr. UAV installation: the more I work with the UAV, the more I wish there was a better solution. This took a fair amount of time and figuring out in order to install it. The documentation is really lacking. The need for a separate audio board is clunky. And I'm not sure the results are all that great. The picture is clean, but it still seems quite undersaturated to me, and I don't see any way to adjust it. I miss the CyberTech S-Video mod, but I think it would've been too tall to fit under the Jr's RF shield anyway. Now, if you didn't click on every single link in Part 2 (and why wouldn't you?), you might have missed thread about the CleanComp Composite Mod, currently under development. I only came across that thread a few days ago, and the Jr. was already finished by then (it takes awhile to write up these blog entries), but that mod looks very promising indeed. There are a lot of tech-savvy eyes on that thread, giving insight and feedback, and this could end up being the best (and most straightforward) 2600 mod yet once it finally gets sorted. It's making me reconsider using a UAV in any of my own consoles. Up next: the final chapter in the saga of "Adding a bunch of UAV mods to John's consoles" as I install one in... a four-switch woody! And this time, I'm drilling holes. Lots, and lots of holes. Published 2/25/23 12:30PM

So, it's time to throw a UAV mod into this 2600 Jr. As far as installing mods, this isn't exactly my first rodeo. But it is my first time installing a mod into a Jr., and it's my first time installing a UAV mod into a 2600. When I installed a UAV mod in John's 7800, I had the advantage of using an auxiliary board from -^CrossBow^- that served as both an audio board and a mount for the UAV. This made installation pretty simple. For the Jr., though, the UAV instructions warn: So that wasn't encouraging. And even though it looks like there may be plenty of space with the RF shield removed, I'll be putting the shield back since one of the goals here is to keep RF output intact: For one thing, John requested it. It's important for developers to be able to see what their games look like with RF, because that's the standard for the system. Some graphical elements can look radically different (or even disappear entirely) in RF that might otherwise look fine on a modded system or in emulation. Besides that, whenever possible, I like to make these mods reversible. It's possible the mod may fail at some point, or a better mod may be developed, or the console fails and the mod needs to be moved to another system. Whatever the reason, it's just good practice. (I couldn't make the mod fully reversible with John's 7800, because a previous modder gutted the RF modulator. But it is still removable by desoldering the resistors it's attached to from the console, then desoldering each resistor from the mod, then reinstalling the resistors back in the console.) Another warning that comes in the UAV instructions is this one: This is especially true of the Jr. installation. Which reads, in part: So, there are no instructions for the Jr. for the alternate "outside the shield" installation method. Which is unfortunate, since that's the method I'll be using. The detault instructions call for removing the CD4050, and installing the UAV mod in its place. Initially, I had considered doing this, so I desoldered the CD4050: I'm going to pause here for a moment, and interject a mini-rant I have about their instructions for doing this, which read: Uh... no. First, I disagree about this being easier. It may seem quicker, but you still have to clear all of the solder and clipped-off legs from each hole. You have to desolder them anyway. Desoldering is not that hard, and you can pick up a perfectly effective desoldering iron for cheap on Amazon. I used that Radio Shack model for over 20 years (at work and at home), before finally upgrading to the Hakko one I have now. The big difference between the two? The Hakko has a temperature control and a trigger to actuate the vacuum. Otherwise, they essentially do the same thing: melt solder, and suck it up. (And honestly, the Radio Shack one is more fun to use because to clear it, you squeeze the bulb really hard and it blows hot molten solder everywhere!) If you're going to desolder any components, just buy one. Get the cheap Radio Shack model - you don't need anything fancy. Then just practice on some old throwaway electronics until you get the hang of it. It will make your life easier, and your projects much more enjoyable. You also won't have to destroy components to remove them. And while CD4050s are still in production and readily available, other components are not. And why waste money having to re-buy components if you don't have to? So... end of mini-rant. Back to the default install. The UAV mod kit comes with standoffs that mount the board to where the CD4050 was, and jumpers to configure it for the particular system you're installing it in. It's important to remember: this was not originally designed for the 2600. This was designed for the Atari 8-bit computers, and then adapted to work with the 2600 later. Consequently, there are some compromises with it. One such compromise, is that in the case of the Jr., the CD4050 has to go back in because the Jr. won't work properly without it. For the default installation, the instructions read: Did you follow all of that? This might help: So now you're looking up, at the underside of the board, and the underside of the CD4050, with the UAV mod mounted on the top. Incidentally, "Figure 5", and the accompanying instructions, are wrong. I'll admit to not trying it, but pin 1 is at the opposite corner of where it should be. Maybe it still magically works. Somehow. In short, you chop the pins off the CD4050, and install it on the underside of the Jr.'s circuit board, in the exact same orientation it was in originally, by soldering it to the UAV pins that stick through the holes on the bottom. Basically, you're sandwiching the Jr.'s board between the UAV on top, and the CD4050 underneath. Also, you put a bunch of jumpers in there, that aren't documented in the manual. (Oh, it shows you which jumpers to install... but it doesn't tell you what each one does.) It was at this point I decided I wasn't going to install the mod this way. For one thing, it's not easily reversible (especially because you have to mangle the CD4050), but also it doesn't address another major shortcoming with the UAV mod: no audio. While using the CD4050's location seems like a tidy solution for installation, you're still going to have wires running to and from it, and you're going to have to install a separate audio mod somewhere anyway. The audio board sold as a companion to the UAV has no such provision for convenient mounting. It doesn't attach to the UAV (which would've been nice), it wasn't incorporated into the UAV (which would have been nicer), and the instructions provide no insight on where you might actually locate it inside the Jr. So I decided to go with the non-default (and undocumented) Jr. installation method, leaving the CD4050 intact, and instead running wires to the UAV mod outside the RF shield. This is actually a common installation method shown in the manual for several other systems. I just had to decipher what was going on, and adapt it to the Jr. And, of course, find some place to put it. And the audio board. First though, I needed to remove the connector pins from the audio board. They were just going to get in the way, since I wanted to solder straight to the vias instead. So, off came the shrink tubing (and the adhesive gunk inside it): And off came the pins (desoldered... not clipped): One nice touch - they listed what each connector is for on the underside. Not sure if that's why the board has so much wasted space though. They could've made it significantly smaller just by relocating one component. Still - documentation! Anyway... so the question is: where to put the two mod boards? One solution would be to put them inside the RF shielding somewhere, and stick them down on top of other components using double-stick tape. This appears to be a pretty common installation method for the UAV mod in other systems. But after having cleaned off someone else's double-stick gunk from the inside of John's 7800 (and having cleaned off a lifetime's worth of double-stick tape in my day job), I decided I didn't want to do that. Reversibility, remember? Double-stick tape is great stuff. Removing it, is not. So I put the mods in what turns out is a pretty-much perfect spot. Next to the ribbon connector on the main board, just in front of the player 2 joystick port and RF out jack. They just fit, and there are only a couple of rows of resistors underneath them: My initial thought was to make a couple of standoffs out of scrap plastic, then attach those to the main board and mods using (wait for it...) double-stick tape. But the tape wouldn't touch any components, and be pretty easy to remove. Before I got to that point though, I needed to figure out how to route the cables from inside the RF shield. There were a couple of nice gaps in the shield near the cartridge slot that I could feed the wires through: So I soldered on (most of) the wires going into the UAV and audio boards. Here's a handy chart (your wire color may vary): Then, I test-routed the cables where I wanted them to go... And promptly realized that the plastic cartridge slot was going to get in the way, because it sits flat on top of the Jr.'s main board, and blocks those access points: Okay, take two. Run it around the cartridge slot to the other side... Where there are also gaps underneath the RF shield: Then, I had a slightly better idea... I noticed a vertical gap at the inside corner that offered more clearance from nearby components: I just needed to add a little electrical tape to soften the sharp edges: And do some more test fitting: You'll notice the other set of wires draped across the Jr. in the above photo. Those are in-progress output wires. I'm making those wires pretty-much identical to what I made for the 7800 mod, using a Molex connector to join the S-Video and composite+audio cables to the internal wiring coming from the UAV mod. Strictly speaking, this wasn't really necessary with the Jr. For other consoles, I use the Molex connector to make disassembly of the console easier. Unplug-and-play, so to speak. But with the Jr., I added them anyway because I like making more work for myself, I guess. Also, this gives me more flexibility in which wires I use where. So we'll go with that. At this point, I was just making sure there was enough room in the Jr. to fit everything in. Success! I also updated my wiring diagram to include the polarity markings on the S-Video cable that I use, and the Molex pinouts: When you get old, it helps to write everything down. Pictures are even better. Okay, so the wiring will fit. The mods will fit. Now... where do I hook all this stuff up? Unfortunately, the UAV instructions are of almost zero help with the Jr. There are some photos showing where to connect wires for a six-switch and four-switch mod, but not a Jr. It's at this point this blog entry will devolve into another mini-rant. This time, about graphic design. Feel free to skip ahead if you'd like. On the plus side, the UAV mod comes with a printed version of the installation instructions. I really appreciate that, since I like having printed instructions to refer to, and I don't have to go back to my computer, or have an iPad nearby just to look up a step. I'm old like that. On the negative side, besides the definitely work-in-progress nature of the instructions, is how it was printed. The printed version comes on standard, 8.5" x 11" (US Letter) paper, folded in half. That's great - it results in a nice sized (5.5" x 8.5") manual, and is very cost-effective to produce. The problem is, they made no effort to fit the content to the paper size. It appears the digital version was created first, with no consideration given to how it would be printed, then they just took the digital version, and copy/pasted it as-is into the middle of a 5.5" x 8.5" document, without adjusting the layout, margins, photos, text, or making any changes to improve legibility or clarity. Consequently, you end up with a manual printed on 5.5" x 8.5" paper, that only takes up the middle 4" x 5.5". The resultant oversized margins are just wasted space. The photos especially could've benefited from being printed larger, and it would've made the text far more readable as well. Ideally, the manual would've been laid out for print from the get-go, and then exported as a PDF for a digital version. As it is, while I liked having the physical manual to refer to, I often just left the digital version open on my computer so I could better see it. (You can download both the digital and "for print" versions of the manual here.) Anyway... So without instructions for how I wanted to install the mod, a little detective work was in order. First, let's update my chart a little bit to include the TIA: Now, lets find out where those are on the TIA itself (thanks to various online shematics): Now, I could just solder wires straight onto those pins. But that's harder than it needs to be, and again - reversibility. Let's find some easier places to attach wires. The reason the UAV (presumably) uses the CD4050, is because some of the signals needed to generate video pass through it, and are therefore easily accessible. Let's update the chart again, this time to include the CD4050. While we're at it, let's add +5v as well, since we'll need that to power the UAV and audio boards: What you won't find on the CD4050, are Color or Audio. So for the UAV mod, you will always need to go elsewhere to find those two signals. In this case, there are a couple of handy vias right near the TIA. Just below R28 for Color, and just to the upper right of the TIA (next to pin 1) for audio (this has both TIA audio channels combined). This shows us where the UAV was designed to get signals, but we're not using the CD4050 install method. And soldering to the CD4050's pins directly is not an option (in case you haven't been following along). But a little sleuthing with a multimeter, and you can find alternative locations. You do have to end up soldering to the legs of three resistors (Sync, Lum 1 and Lum 2), but the rest are handy vias, which you can remove the solder from very easily with that desoldering iron you just bought for $24. So with the connections sorted out (and wires routed, tested, measured and trimmed to length), It's Solderin' Time!™ I soldered the first wire in, then clipped the second to it to hold it in place, soldered that one... Then worked my way down the line... And yes - there's some folded-over masking tape up there to temporarily hold the mods in place while I work. Temporary. We'll get back to that. Eventually, I got everything routed where I wanted it to go: Don't forget to slide any heat shrink tubing onto the wires before you start soldering. And yes, I put the CD4050 back. Socketed, this time: Then I temporarily installed the RF shield, to make sure everything still fit: And I'm done! No I'm not. But the UAV is now connected to the Jr. However, until I solder on the rest of the wires, I can't actually test this. But I've been checking continuity carefully as I've been going, so it all should work. Right? Published 2/24/23 5:20PM

393 < PreviousIndexNext >

390 < PreviousIndexNext >

392 < PreviousIndexNext >

I thought I would do everyone developing Jaguar Homebrews a favor. Just open these up in Paint.net, Photoshop, Aseprite, Paint Shop Pro, Krita, EDGE, Graphics Gale, etc.; add a couple of layers and create some fonts. f_16x16 Template.pdn f_8x16 Template.pdn f_8x8 Template.pdn

Turns out there's an updated version of VecMulti that requires a slightly different format for the menu file. The menu created with MenuMaker 0.3 would show extra characters on those VecMulti cartridges, resulting in the names shifting. Starting with Page 2 the names would no longer line up with the numbers 1-4 (game 1 on page 2 is AllGoodThings). With the help of @NeonPeon I've been able to reverse engineer the new format, and have updated MenuMaker to support both versions. By default the menu will be created for the Original VecMulti. If the resulting menu is shifted, then select 2019+ VecMulti to create the menu with the new format. The selection will be remembered. Also fixed a one-off bug I discovered in version 0.3 that caused the last game in the Games directory to not show up in the menu. Program with Source MenuMaker20220110.zip

Yes, that blog title is hinting at the subject of this post. Care to take a guess? Ok, yes, it was obvious to anyone with half a functioning brain that I'm referring to the Atari VCS, of which I am now a proud and unworthy user. As you can see by my thread in the VCS forum, I purchased this last December when Atari had a big sale going on, but didn't hook it up then because I simply didn't have room to do so. Fast forward about 9 months or so, and the recent news about Atari purchasing this very website has kind of lit a flame under my rear, and one of the consequences of that was me finally getting around to hooking up the box. Well, you can read my impressions of it in that thread if you want to know what I think. It's both a car crash and a miracle rolled up into one piece of technology, and I'm having quite a good time with it so far, despite its obvious flaws. There's tons of unrealized potential in this box, but at the same time just looking at it fills me with excitement....it's really hard to explain. Should I be enjoying it as much as I am? Probably not, and let's face it, there are plenty of good and valid reasons to find it an utter disappointment. The system has plenty of glitches and bugs that drive me to the point of insanity at times, such as my controller not wanting to sync up for a full minute despite the fact that it actually wakes up the unit (explain that to me, someone, PLEASE), the fact that I sometimes have to double-press the A button on the home screen to open a game, the default settings for MAME in 7800 games being far less than ideal....the list of problems goes on and on and on. Yet....I can't stop playing with it, going round after round in Amoeba Jump, doing a few rounds of Caverns of Mars Recharged, or getting my butt kicked in Donut Dodo, I've spent far more time the last 3 days playing on this system than I have spent on my Wii in the last month. It's crazy. Maybe it's that glowing fuji that's putting so much joy into me? Maybe it's the promise of what could come of this iteration of Atari in the future? And actually, that last bit I think hits the nail on the head. I'm feeling inspiration from my all-time favorite brand that puts me back to how I felt as a kid when I first played on the Atari 2600, or when I first opened a present on Christmas to find a 130XE, or when I walked into Babbage's first thing after getting home from boot camp to buy my Atari Jaguar, or even the first day I discovered this website. It's the magic of Atari being rekindled in me for some strange reason, giving a person who feels stuck at the moment in life the swift kick in the ass they need to make something good happen. And I think that's best thing that this little black box that somewhat resembles a Vader 2600 could possibly give to me.

These kicks kick it old school!

Atari acquires the Accolade titles, like ... I'm going to start this off with a request of the Bubsy Fan Blog to come and post on this message that thinks there is only one Bubsy fan... Let's shock and awe, and discuss what we think of Atari getting the Bubster back. Yep, back. Atari and Accolade have courted before, and Bubsy has stepped in and out of the Atari doors so much it is almost a revolving door. Let us count the times, which admitively are two. Atari had the rights to Bubsy to make at least one game to be ported from Sega Genesis code for the Atari Jaguar. That being of course "Claws Encounters of the Furred Kind", the first game in the Bubsy franchise originally released in North America in May 1993. It was decided however to create a new game as they were working in the late summer of 1994, and so "Fractured Furry Tales" was born. And that game would manage a North American release of December 9, 1994. So right here, Atari had the rights to two games, the first game that they purchased the code and rights to, and the game they created. It has been said by the Atari dev team that Bubsy II was too far into development to get the code for that. And by the time Bubsy 3D was being created and released around 1996 Atari was going through a reverse merger with JTS. However, but 1999 the company Infogrames acquired the rights to Atari, and changed their name to the more iconic brand name. And Infogrames acquired the rights to Accolade. And various titles were created. Nothing really of the Bubsy line. And after a few other selling and acquisition of the Accolade and Bubsy franchise, here we are, yet again, with some owner of Atari picking up the Accolade titles, yet again. Not complaining as I (Doctor Clu) am a huge fan of seeing the big Atari logo at the beginning of Fractured Furry Tales. I always enjoyed the idea of Bubsy, a cat, being one of the spokescats of the Atari Jaguar, a system named after a larger cat. Also I greatly enjoyed the Atari 50th anniversary collection released for the PS4 and PS5, as well as I believe the Atari VCS and a few other platforms. The Jaguar emulation in that was awesome, and personally I know a lot of people who would like to try at least Fractured Furry Tales without having to set up Jaguar emulation, or buy an Atari Jaguar in retro market prices. But what I would also like to see, Atari, is Bubsy 3D, and Bubsy 1 and 2. Maybe the newer games, Woolies Strike Back and Paws on Fire on more platforms. And even Kitt'n Kaboodle for the Atari 2600. Well, I was happy with how Atari featured software from Big Five Softeware and the Miner 2049er series on the 50th anniversary and I think the Bubsy series would add another colorful addition. Personally, I would love to finish up Bubsy 3D on my Playstation 4. And maybe, just maybe, Atari can go in an tweek a few things in that game. Adjust the controls a bit. And there was a more graphically enhaunced version of that game, but it was pulled back due to Playstation 1 limitations. So exciting, and I look forward to what everyone has to say on that message thread. Here are a few articles about the Accolade purchase by Atari... https://www.globenewswire.com/en/news-release/2023/04/19/2650476/0/en/Atari-Announces-Acquisition-of-More-than-100-PC-and-Console-Titles-from-the-80s-and-90s.html?fbclid=IwAR2PjffP-R146bFmx6C-Qj9LTj_0Td_z1cFcBYzZ4jjWQeHvRl7Zj57AxZk Talk soon! Originally posted here: https://forums.atariage.com/blogs/entry/18521-cruizin-atariage-atari-acquires-accolade-titles-april-2023/

The PC I bought ~10.5 years ago is still up and running. I only doubled the RAM and bought a new 4 TB HDD (which I plan to continue to use) when the 2 TB Seagate HDD died early. But the small SSD does still well: 63 TB total writes bytes means ~500 writes per byte. The wear level count is at 55, so it could last more than twice as long. I wonder if my next Samsung will do as well too. Anyway, even though the SSD is still healthy and the CPU is also fine for most tasks, I thought it would be time for some new hardware: ASRock B450 Pro4 R2.0 ATX AMD Ryzen 7 5700G (I don't need a dedicated GPU) 2 x 16 G.Skill Aegis 32 GB DDR4 3200 MHz Samsung SSD 980 1 TB be quiet! Pure Power 11 400W (quite a bit oversized) This did cost me less than 500€. Everything will go into my old BitFenix Shinobi case. Should be a quite simple task...

Found out a friend of mine, Michael Berlyn, passed away at 73 yesterday. As I've mentioned to some this morning, I had a great time talking to him in this interview as he talked about the various games he created, among which Bubsy Bobcat. And it's been great talking to him since. He was a great friend on Facebook liking my jokes, sharing some of his own, and sometimes just talking from time to time. A creative, supportive man with a fun sense of humor. He will truly be missed. More about this... https://celebritiesdeaths.com/sad-news-bubsy-creator-michael-berlyn-dies-at-73/

First off I want to apologize for taking a few months to get to part 2 but real life keeps rudely intruding on my hobby time. How dare it. Anyway, since I’m also hiding out at a Zaxbys to just have the time to type this up it’s not going to be as intensive as I would like, since life will eventually find me after all. Note: you will want to read through the Part 1 before attempting Part 2. Also, because of the vagaries of Windows PCs your experience may vary. I have also included more utils that you will need in paert 2. Now on with the show. After you got the computer looking all blank like it’s time to make the real changes. Again note: these changes include registry and OS hacks which could crash your PC if not done right. Be warned. 1.) First you want to get rid of that pesky arrow pointer. Use the Take Ownership program to take ownership of WINDOWS\CURSORS. Also make a copy of CURSORS to safe place, just in case. Copy the contents from Tools file of CURSORS into WINDOWS\CURSORS. It’s OK to overwrite the contents. Now take the CROSSDOT.REG registry file and install. This next thing you might want to wait till you are finished to do this since you won’t have a pointer anymore. Open the Mouse Pointer and choose the new CROSSDOT pointer profile. The pointer should now becomes just a dot. 2.) Now lets get rid of that fancy blue logon page. Open from tools Login Studio. Choose the BLACK profile picture and make it the current Logon Screen. Blue gone, black in. Done. 3.) Take ownership of WIN\BRANDINGS dir. Copy content to a safe place. Use Resource Hacker from tools and mod the file WIN/BRANDINGS/BASEBRD.DLL. Remove the bitmap files. 4.) Take ownership of WIN/SYS32/IMAGERES.DLL. Copy to safe place. Now use Resource Hacker to modify that file. Remove spinners, bitmap, mui. 5.) Take ownership of WIN/SYS32/EN-US/WININLOGON.EXE. And you REALLLLLY want to make a copy of this file to a safe place. Just sayin’. Now use Resource Hacker and remove all: 63-1033 1002 welcome 1003 logoff 1005 welcome OK this part is experimental. I have got this hack to work, sometimes. For a split second the pointer comes up then changes to the .dot. I wanted to get rid of that split second standard pointer so I experimented with changing in the registry HKEY/USER/DEFAULT/CONTROL PANEL/CURSOR from the default to .DOT. It worked on some of the virtual PCs I created but didn’t on others. Not sure why. Anyway, good luck. Now reboot. If you have a black screen it works. Copy from TI99REOURCES the MAME Geneve package to the PC. Make a shortcut of the GENEVE.BAT in the Startup folder. Reboot and that should make the Geneve come up after a short while of black. As I stated this works much faster and better with the use of a high speed SDD drive. That’s it. Now back to that life thing. Enjoy. utils for win7 conversion.zip

TI-99/4A Memory Map >0000 Console Rom; Interrupt vectors, XOP vectors GPL Interpreter, Floating POINT routines, XMLINK vectors, >1FFF Low-level cassette DSR etc. >2000 Low Memory Expansion Ram; Varies according to the loader used (Assembly). Generally >3FFF not used by XBASIC programs. >4000 DSR ROM; Device service routines. Determined by CRU bit setting >5FFF Disk Controller, RS232 etc. >6000 Cartridge Port (ROM & MINI MEM) 12k of XBASIC ROM. Upper 4k @ >7000 - >7FFF is flipped to page in another 4k for a >7FFF total of 12k. >8000 RAM Memory Mapped Devices - VDP,GROM, SOUND, SPEECH. >8000 Duplication of scratch pad RAM at >8300 - >83FF >8100 Dup. as above >8200 again >8300 Scratch Pad RAM >8400 Sound Chip >8800 VDP READ DATA >8802 VDP STATUS >8BFF >8C00 VDP WRITE DATA >8C02 VDP READ/WRITE ADDRESS >8FFF >9000 SPEECH READ >93FF >9400 SPEECH WRITE >97FF >9800 GRON/GRAM READ DATA >9802 GROM/GRAM READ ADDRESS >9BFF >9C00 GROM/GRAM WRITE DATA >9C02 GROM/GRAM WRITE ADDRESS >9FFF >A000 HIGH MEMORY EXP RAM XBASIC high memory usage, Free space end pointed to by CPU RAM PAD address >8366 Numeric Values Line Number Table XBASIC Program Space >FFFF for a total of 24k bytes. Additional Memory Space not in the CPU address space; VDP RAM >0000 - >3FFF 16k bytes. This is the console RAM space, and is separate from the rest of the CPU memory. Without memory expansion, XBASIC and BASIC programs reside here (BASIC does not use expansion memory.) (Assembly language does not use this area.) BASIC does not use memory expansion at all. Only XBASIC, Assembly, FORTH etc. use it. Chunks of memory are used by various peripherals as buffers, thus the amount indicated by CALL SIZE is right. By using CALL FILES(1) followed by NEW, you can get back some, but disables the disk system. If you don't have it installed, but have mem exp. you will have more memory to use automatically. Original Source as posted on July 8th 1984 by Gene Sampieri The following is priceless as found in the below address: http://www.unige.ch/medecine/nouspikel/ti99/tms9918a.htm#Registers VDP memory The videoprocessor has 16K of private RAM that it used to store the screen image, the character patterns and colors, and the sprite characteristics. Unless it is used in bit-map mode, only a small portion of this memory is effectively needed. The remaining is therefore available for use by the CPU. However all reading and writing operations must be carried on by the videoprocessor. The CPU passes the required address to the VDP as two bytes at address >8C02, and can then read bytes from >8800 or write bytes at >8C00. The VDP increments an internal pointer after each read/write operation. Contrarily to the GROMs, one cannot retrieve the value of this pointer from the VDP. Instead, address >8802 is used to read the VDP status register. This is definitely a slow way to access RAM, but it probably allowed to market the TI-99/4A at a much lower price, since RAM was fairly expensive in the 80s. VDP registers The first eight registers are used by the CPU to control the VDP. Very unfortunately, these are write-only registers, which means there is no way to determine the current display mode, unless it has been saved somewhere in RAM by the program that set it. Registers 0 and 1 contains control bits, registers 2 to 6 contains pointers to various tables in the VDP RAM and register 7 encodes 2 colors. The VDP also contains a read-only status register that is uses to pass various information to the CPU. VDP register 0 This register contains two control bits. All other bits must be zero. The register contains >00 after a reset. Bit 6 (weight >02) selects a bitmap graphics mode when set to 1. VDP register 1 determines which bitmap mode is used. Bit 7 (weight >01) enables external video input when set to 1. VDP register 1 This register contains 7 control bits. All are set as 0 after a reset. Bit 0 (weight >80) selects the memory size. For 4K of memory the bit is 0, for 16K it is 1. Bit 1 (weight >40) enables the screen. When this bit is 0 the screen is blank. Bit 2 (weight >20) enables interrupts. When this bit is 1, the VDP issues interrupt signals on the INT* pin each time it resumes refreshing the screen (vertical retrace signal). Bit 3 (weight >10) selects text mode when set as 1. Bit 7 of register 0 can be set for bitmap text mode. Bit 4 (weight >08) selects multicolor mode when set as 1. Bit 7 of register 0 can be set for bitmap multicolor mode. If both bits 3 and 4 are 0, the display is in standard mode (or in bitmap mode, depending on register 0). Bits 3 and 4 should never be set together. Bit 5 (weight >04) is reserved and should be 0. Bit 6 (weight >02) selects the sprite size. When 0, sprites are 8x8 pixels. When 1, sprites are 16x16 pixels. Bit 7 (weight >01) selects sprite magnification. When this bit is 1, each sprite pixel is replaced by a 2x2 pixels box. VDP register 2 Defines the location of the screen image table. Only the last 4 bits are used, thus possible values for this register are >00 throught> 0F. The value is multiplied by >400 to find the location of the screen image table in the VDP memory. This table contains 1 byte for each character position on the screen (left to right, downwards), this byte contains the character number. VDP register 3 Defines the location of the color table. Possible values are >00 through >FF and are multiplied by >40 to find the location of the color table. The table is not used in text mode, nor in multicolor mode. In bitmap mode (i.e. when bit 6 in register 0 is set) the meaning of this register changes: bit 0 (weight >80) is the only one used to determine the address of the color table, which means the table has only two possible locations: >0000 or >2000. The remaining bits are used to define the table size, by the way of an address mask. This is done as follows: the righmost 7 bits are shifted left by 6 positions, filling the rightmost bits with 1s. The result will be a number between> 003F and >1FFF, which is ANDed with the address of a character in the table. As a result, the table can have any size between >40 and> 2000 bytes (however, note that the maximal usable size is >1800: 3 times >800 bytes). VDP register 4 Defines the location of the character pattern table. Only the last 3 bits are used, thus possible values are >00 through >07. The value is multiplied by >800 to find the location of the character pattern table. Each entry in the table is eight bytes long and define the pattern of a character, in numeric order. Each byte in an entry defines one line of pixels in the character pattern: bits set as 1 result in foreground color pixels, bits set as 0 encode background color pixels. In text mode (i.e. when bit 3 in register 1 is set) the last two bits of each byte are ignored since characters are only 6-pixel wide. In bitmap mode (i.e. when bit 6 in register 0 is set) the structure of this register changes: bit 5 (weight >04) is the only one used to determine the address of the color table, which means the table has only two possible locations: >0000 or >2000. The two rightmost bits are used to determine the length of the table, by the way of an address mask. This is done by shifting them 11 positions to the left, filling the righmost bits with 1s. The result will be a number between >07FF and >1FFF that will be used as an address mask. At least, this is what happens in bitmap + text mode (i.e. when bit 3 of register 1 is set). In standard bitmap mode, the righmost bits are not necessarily 1: they are taken from VDP register 3, i.e. the address mask of the color table is used for both the color table and the pattern table addressing. VDP register 5 Defines the location of the sprite attributes table. Only the last 7 bits are used, thus possible values are >00 through >7F. The value is multiplied by >80 to find the location of the sprite attributes table. Each entry in the table is four bytes long and defines a sprite position and color, in numerical order of sprites. See the chapter on sprites for a detailed description of this table. VDP register 6 Defines the location of the sprite pattern table. Only the last 3 bits are used, thus possible values are >00 through >07. The value is multiplied by >800 to find the location of the sprite pattern table. Each entry in the table is eight bytes long and defines the pattern of a sprite, one byte per line. Bits that are set as 1 result on a pixel of the color defined for that sprite in the sprite attributes table, bits that are 0 result in a transparent pixel. If the large sprite size is selected (bit 6 in register 1 is set as 1) each entry is 32 bytes long and define a sprite as a set of 4 characters arranged as: 1 3 2 4 VDP register 7 The first nibble of this register defines the color of all characters in text mode. It is not used in the other modes. The second nibble defines the background color wich is used for all characters in text mode. In all four modes it defines the color of the backdrop plane: this is the color of the screen outside the display area and the color that appears under transparents characters. When this color is set as transparent the external video image appears if it is enabled, black color appears otherwise. Status register The first 3 bits of this register are automatically reset as 0 when the register is read or when the VDP is reset. It ensues that the status register should only be read when an interrupt is pending, otherwise an interrupt could be missed. Bit 0 (weight >80). This bit is set to 1 at the end of the raster scan of the last line of the display area (i.e. before drawing the bottom margin). If interrupts are enabled (by bit 2 in VDP register 1), the INT* pin is low when this bit is 1 and high when it's 0. This is why the status register should be read after each frame, in order to clear the interrupt and be ready to receive the interrupt at the end of the next frame. Also, if bit 2 in VR1 is cleared and set again while status bit 0 is set, an interrupt is issued immediately. Bit 1 (weight >40) signals that there are 5 or more sprites on a given pixel row. Only the topmost four will be displayed. Bit 1 (weight >20) is the coincidence bit. It is set when two sprites or more have at least one overlapping "on" pixel. This occurs even if the sprite color is transparent. Note that coincidence is checked only every 1/60th of second (1/50th of a second for the TMS9929A), thus if you change sprite positions during that time a coincidence could be missed. Bits 3 to 7 contain the number of the 5th sprite on a pixel line, if any. This number is only meaningfull if bit 2 is set as 1 (else it may contain the number of the last displayed sprite, but no guaranty). If such a situation occurs more than once, the 5th sprite listed is the one closest to the top of the screen. Summary of the VDP registers contents Bit: Weight: 0 > 80 1 > 40 2 > 20 3 > 10 4 > 08 5 > 04 6 > 02 7 > 01 VR0 0 0 0 0 0 0 Bitmap Ext vid VR1 16K Blank Int on Multic Text 0 Size 4 Mag 2x VR2 0 0 0 0 Screen image VR3 bitmap Color table Addr Address mask VR4 bitmap 0 0 0 0 0 Char pattern table 0 0 0 0 0 Addr Address mask VR5 0 Sprite attributs table VR6 0 0 0 0 0 Sprites pattern table VR7 Text color (in text mode) Backdrop color Status Int 5+ sp Coinc 5th sprite number Video modes Standard mode (Graphic I) This mode is selected by setting all mode bits as 0: bit 7 in register 0 and bits 3 and 4 in register 1. VR0: 0 VR1: 0 0 In this mode, the screen is divided into 24 rows of 32 characters. Each character is 8x8 pixels and has two colors: one for the "on" pixels (foreground color), one for the "off" pixels (background color). If a color is set as 0, the color of the backplane will be used (defined by register 7). The screen image table is thus >300 bytes long (24x32=768). Each byte in the table contains the number of the character to display at the corresponding position on screen. This number is used to locate the character pattern in the pattern table and to look up its colors in the color table. The color table is 32 bytes long. Each byte encodes the two colors for a group of 8 consecutive characters in numeric order (i.e. the first byte affects characters 0-7, the second characters 8-15, etc). In each byte, the first nibble encodes the foreground color, the second nibble the background color. The character pattern table contains 256 entries, one per character in numeric order. Each entry is eight bytes long, each byte defines the pattern of one pixel row in the character: "1" bits set the pixel to the foreground color used for this character group, "0" bits set the pixel to the background color of this character group. --------| | 00000000 = >00| *** | 00111000 = >38| * * | 01000100 = >42| * * | 01000100 = >42| *** | 00111000 = >38| * | 00010000 = >10| *** | 00111000 = >38| * | 00010000 = >10 -------- The pattern table entry for the above character would be: >00 38 42 42 38 10 38 10 Sprites can be used in standard mode, see below. Text mode This mode is selected by setting bit 3 of VDP register 1 as 1. Bit 4 must be 0, as well as bit 7 of register 0. VR0: 0 VR1: 1 0 In this mode, the screen is devided into 24 rows of 40 characters. Each character is made of 8 rows of 6 pixels. All characters have the same two colors, defined by VDP register 7. The screen image table is >3C0 bytes long (24x40=960).Each byte in the table contains the number of the character to display at the corresponding position on screen. This number is used to fetch the character pattern from the pattern table. The color table is not used. The foreground color for each character is taken from the first nibble of VDP register 7, the background color is transparent, which lets the backdrop plane color appears. As the backdrop color is encoded by the second nibble of VDP register 7, one can consider that this register specifies both the foreground and background colors for each character. The pattern table is organized just as in standard mode, except that the last two bits of each byte are ignored since characters are only 6-pixels wide in text mode. ------| | 000000xx = >00| *** | 001110xx = >38| * *| 010001xx = >42| * *| 010001xx = >42| *** | 001110xx = >38| * | 000100xx = >10| *** | 001110xx = >38| * | 000100xx = >10 ------ Sprites are not available in text mode. All this makes text mode the least memory-hungry mode: only a maximum of 3008 bytes (>0BC0) of VDP RAM is required in this mode. This can be further reduced by not using all 256 characters and/or by partly overlapping the tables. Multicolor mode This mode is selected by setting bit 4 of VDP register 1 as 1. Bit 3 must be 0, as well as bit 7 of register 0. VR0: 0 VR1: 0 1 In this mode, the screen is divided into 48 rows of 64 boxes. Each box is 4x4 pixel and can be independently assigned a color. The screen image table is still >300 bytes long, but each byte now represent a "character" made of 4 boxes. The boxes are arranged as: 0 1 2 3 The color of the boxes are defined in the character pattern table (!). Each entry in the table is 8 bytes long but only 2 bytes are used to define the colors of the 4 boxes that make up a character: >01 >23. To avoid wasting 6 bytes in each entries, the characters on 4 consecutive rows use the same entry, with an offset of 2 bytes: characters on row 0, 4, 8, 12, 16 and 20 use bytes 0 and 1, characters on row 1, 5, 9, 13, 17 and 21 used bytes 2 and 3, characters on row 2, 6, 10, 14, 18 and 22 used bytes 4 and 5, characters on rows 3, 7, 11, 15, 19 and 23 use bytes 6 and 7. This reduces the size of this table to 1536 bytes (24 rows x 32 columns x 8 bytes). The color table is not used in multicolor mode. Sprites can be used in this mode. To summarize, the screen organisation is the following: Column: 0 1 ... 31 Row 0: a b q r ... c d s tRow 1: e f u v g h w xRow 2: i j y z k l ...Row 3: m n o p The corresponding screen image table could be: Column: 0 1 ... 31 Row 0: >00 >01 ... >1F Row 1: >00 >01 >1F Row 2: >00 >01 >1F Row 3: >00 >01 >1F Row 4: >20 >21 >3F ... And the pattern table would look like this (letters a-z represent the color of a given box, i.e. a digit in the range >0-F): Byte: 0 1 2 3 4 5 6 7Row: 0 1 2 3___ Entry >00: >ab >cd >ef >gh >ij >kl >mn >op Entry >01: >qr >st >uv >wx >yz ... ... This mode is fairly complicated to use (and does not yield very interesting results). A way to simplify it is to fill the screen with fixed character numbers, as shown in the above example. Drawing is then achieved by changing the color values in the character pattern table. Arranging the character numbers as in the example makes easier to calculate which byte must be changed in the pattern table, but there are other solutions. Bitmap mode (Graphics II) I'm sure every TI user had this great idea one day or the other: "Hey, lets fill the screen with all available characters: 0, 1, 2, etc. Then I can draw pixel-by-pixel by just changing definitions in the character pattern table". If you have tried, you must have realised there is a big problem: with 256 characters, we can only cover 1/3 of the screen. Not to mention the fact that the color table defines 8 characters at a time, which makes color drawings almost impossible. Bitmap mode takes care of these problems (sort of). This mode is selected by setting bit 7 of register 0 as 1. Bits 3 and 4 in register 1 should be 0. VR0: 1 VR1: 0 0 In this mode, the screen is still devided in 24 row of 32 character, just as in standard mode. However, we now have three character pattern tables, one after the other: the first table applies to characters displayed in the top third of the screen (i.e. the first >100 bytes in the screen image table), the second to characters displayed in the middle third (bytes> 100-1FF) and the third to characters displayed in the bottom third of the screen (bytes >200-2FF in the screen image table). Now we can fully cover the screen with non-redundent characters, by just writing >00, >01, >02 ... >FF three times in the screen image table. As the three pattern tables are consecutive, it is easy to calculate which byte is to be accessed to modify a given pixel. There are also three color tables, arranged in the same way as pattern tables. Each entry in a table is eight bytes long and defines the colors for one character. Each byte in an entry defines the colors of a row in the character: the first nibble sets the pixel color for bits that are set as 1 in the pattern (foreground), the second sets the pixel color for the 0 bits in the pattern (background). The major drawback of this system is that each line of pixels in the display is chopped into 8-pixels clusters for which there is only a choice of two colors. This forces us to pay a lot of attention when drawing complex images, as 3 colors in a given pixel line must be at least 8 pixels appart. Sprites are available in bitmap mode and work just as in standard mode. Not so surprisingly, bitmap mode is extremely memory-hungry: it requires> 3300 bytes, not counting sprite tables. To summarize, here is an example showing the correspondance between screen, pattern table entry and color table entry: Screen Pattern table Color table B 1 B B B B B 1 0 1 0 0 0 0 0 1 1 (black) B (l.yellow)B B 7 B B B 7 B 0 0 1 0 0 0 1 0 7 (cyan) BB B B C B C B B 0 0 0 1 0 1 0 0 C (green) BB B B B E B B B 0 0 0 0 1 0 0 0 E (gray) BB B B B 8 B B B 0 0 0 0 1 0 0 0 8 (m.red) BB B B B 5 B B B 0 0 0 0 1 0 0 0 5 (l.blue) BB B B B 6 B B B 0 0 0 0 1 0 0 0 6 (d.red) B2 2 2 2 D 2 2 2 0 0 0 0 1 0 0 0 D (magenta)2 (m.green) The VDP register setting could be the following: VR0 >02 Bitmap mode on VR1 >C0 16K, screen on VR2 >08 Screen image at >1800 (we can't have it at >0000 since either the pattern or the color table must be there) VR3 >FF Color table at >2000, address mask = >1FFF (full size table: 3 times >800 bytes) VR4 >03 Pattern table at >0000, address mask = >1FFF (full size table: 3 times >800 bytes) Hybrid bitmap modes Note that the trick of covering the screen with three repeats of characters 0-255 is just an easy way to calculate which byte corresponds to which pixel, this is by no means an obligation. You could use the tables just the way you do in standard mode: having fixed pattern definitions (and colors) and placing a character number in the screen image table to display it. The address masking trick becomes very handy in this case. Rather than having three copies of the pattern table one after the other, let's just have one and set the address mask to 0: in the example above, VR4 would become >00. The advantage over standard mode is that we can set different colors for each character (rather than for a group of . In fact, we can even set a color pair for each pixel row in a character: this is a nice way to create iridescent characters! Finally, both solutions can be mixed in the various thirds of the screen: the top two thirds could be arranged for easy bitmap drawing, whereas the bottom third could be arranged for rapid character writing. Some games use this solution to display prompts and scores at the bottom (or top) of the game screen. You can use the mask bits in register 4 to assign a >800-byte pattern table to each third of the screen: > 00 (or >04): only one pattern table, identical for each third of the screen. > 01 (or >05): two pattern tables. One at >0000 (or >2000) for the 1rst and 3rd thirds, one at >0800 (or >2800) for the middle third of the screen. > 02 (or >06): two pattern tables. One at >0000 (or >2000) for the 1rst and 2nd thirds, one at >1000 (or >3000) for the bottom third of the sceen. > 03 (or >07): three pattern tables. One at >0000 (or >2000) for the 1rst third, one at >0800 (or >2800) for the 2nd third and one at >1000 (or >3000) for the bottom third of the screen. Then we could do the same for the color table, using bits 1 and 2 (weight> 40 and >20) to select the number of tables. The remaining bits will affect character grouping within a table. Since they also affect grouping whitin the pattern table, we'd better be carefull with these! In summary, these would be the addresses of the tables in 8 possible situations: VR3 VR4 Mask Top 3rd Middle 3rd Bottom 3rd >1F >00 >07FF >0000 >0000 >0000 >9F >04 >07FF >2000 >2000 >2000 >3F >01 >0FFF >0000 >0800 >0000 >BF >05 >0FFF >2000 >2800 >2000 >5F >02 >17FF >0000 >0000 >1000 >DF >06 >17FF >2000 >2000 >3000 >7F >03 >1FFF >0000 >0800 >1000 >FF >07 >1FFF >2000 >2800 >3000 To group characters within a table, we could further alter the color table mask: VR3 = >0F results in >400-byte tables. This means that characters> 80-FF will have the same colors and definitions than characters> 00-7F. VR3 = >07 results in >200-byte tables. This means that characters> 40-7F, >80-BF and >C0-FF will have the same colors and definitions than characters >00-3F. At the extreme, VR3 = >00 results in >40-byte tables. As there are 8 bytes per characters, this means characters are arranged in 8 groups of 32 identical characters: chars 0-7 are identical to chars 8-15, 16-23, etc. We could even get weird grouping schemes by using values like> 02,> 04, >55, etc. The table below lists the six most logical values, plus two gooffy ones (just for fun). VR3 Mask Character grouping Chars Repeats >00 >003F 0=8=16...=248 1=9=17...=249 7=15=23...=255 8 32 >01 >007F 0=16=32...=240 1=17=33...=241 15=31=47..=255 16 16 >03 >00FF 0=32=64...=216 1=33=65...=217 31=63=95...=255 32 8 >07 >01FF 0=64=128=192 1=65=129=193 63=127=191=255 64 4 >0F >03FF 0=128 1=129 127=255 128 2 >1F >07FF Each char is unique 256 1 >02 >00BF 0=8=32=40... 4=12=36=44... 16 16 >04 >013F 0=8=16=24=64... 32=40=48=56=96... 16 16 Bitmap text mode This is the mode TI forgot to tell us about. It works just like standard bitmap mode, except that the screen is now 40 columns and that only two colors are available. This mode is selected by setting bit 7 of register 0 as 1. Bit 4 in register 1 should be 1. VR0: 1 VR1: 0 1 The screen is now divided in three, each third is 8 lines high and thus occupies >140 bytes in the screen image table (8*40=320). The colors are taken from VR7, just like in regular text mode. There is no color table, and the contents of VR3 is irrelevant. Just like in standard bitmap mode, there can be upto 3 pattern tables, located either at >0000 or at >2000. You can use the address mask bits in VR4 to determine which third of the screen uses which table. The main difference is that the color address mask is not used to fill-in the patten address mask: >07FF is always used instead. No character grouping to worry about, then! This mode comes handy for black-and-white drawings. Bitmap multicolor mode Another undocumented mode. It works as a mixture of bitmap and multicolor mode. This mode is selected by setting bit 7 of register 0 as 1. Bit 3 in register 1 should be 1. VR0: 1 VR1: 1 0 The screen is now divided in three, each third is 8 lines high and thus occupies >100 bytes in the screen image table (8*32=256). Just like in standard multicolor mode, there is no color table and the contents of VR3 is irrelevant. The color of the boxes are taken from upto 3 pattern tables, located either at >0000 or at >2000. You can use the address mask bits in VR4 to determine which third of the screen uses which table. Since a single table would be sufficient for this purpose, there is no real point in using this combined mode... Illegal modes It is not allowed to set text and multicolor mode together, whether in bitmap mode or not. VR0: x VR1: 1 1 If you try, the VDP will display a fixed image, that is not influenced by the contents of the VDP memory, nor by registers VR2 to VR6 (sprites are not available). The screen is 192 pixel lines and 40 columns. Each column is made of 4 pixels in foreground color, followed by 2 pixels in backgroud color. These two colors are taken from VR7. Sprites Sprites are special characters that can be displayed at any position on screen, i.e they are not limited to a grid or rows/column, instead each sprite position can be defined with a precision of one pixel. Sprites can be either 8x8 pixels or 16x16 pixels depending on the setting of bit 6 in VDP register 1: when this bit is 0 all sprites are 8x8, when it is 1 all sprites are 16x16. In addition, bit 7 in VDP register 1 provides a mgnification feature: when this bit is 1 all sprites are magnified by a factor of two. Concretely this means that each "pixel" becomes a 2x2 pixels box. Each sprite can have its own foreground color. The background color is always transparent, which lets the underlying image appear under the sprite. Upto 32 sprites can be displayed at a time. Each one can be seen as an extra image plane on the top of the screen, overlapping each others, with sprite number 0 at the top. Thus the virtual image planes are: - Black - External video - Backdrop plane (color in VDP reg 7) - Image plane (characters) - Sprite number 31 - Sprite number 30 - etc upto: - Sprite number 0 There is one restriction however: the VDP cannot display more than 4 sprites on a given line of pixels. Thus, if 5 sprites or more must be drawn on the same line, only the topmost four (those with the smallest numbers) can be displayed. The number of the 5th one is placed in the status register together with a flag bit and the others are ignored. This occurs whether or not the sprites are actually overlapping: one could be on the left of the screen, the other on the right with the same result. Coincidence is a different condition: whenever two "on" pixels in different sprites occupy the same screen location, a bit is set in the VDP status register. This comes handy for games programming: an easy way to check whether the bullet hits the target. Note however that the VDP does not tell you which are the overlapping sprites... Sprites characteristics are defined in two tables pointed by VDP registers 5 and 6: the sprite attributes table and the sprite patterns table. Sprite attributes table This table is pointed at by VDP register 6. It contains upto 32 entries for the 32 sprites arranged in numeric order. Each entry is four bytes long, thus the maximum size for this table is >100 bytes. The four bytes define sprite characteristics as follows: Byte 1 Byte 2 Byte 3 Byte 4 Sprite 0 vertical position -1 horizontal position pattern number clock bit sprite color Sprite 1 " " " " " Sprite positions are expressed in pixels relative to the top left corner of the display area. This will be the position of the top leftmost pixel of the sprite (unless the early clock bit is set, see below). Note that the vertical position coordinate in the table is offset by one: therefore the topmost pixel line is >FF, the second is >00, the third is> 01 and the last is >BE. Any sprite whose vertical position is greater than> BE won't be visible on screen, although coordinates close to >FF can result in the bottom of the sprite appearing at the top of the screen. Similarly, row values just under >BE result in partly blending off the bottom of the sprite. The same thing is true for sprite approaching the right border of the screen (horizontal coordinates close to >FF): the sprite appears to blend-in from the right. However this won't work on the left of the screen: when the horizontal position is 0 the whole sprite is visible, when it's lower than 0 (i.e. >FF, >FE, etc), the sprite appears at the right of the screen. To allow for sprite blend-in from the left of the screen one can set the "early clock" bit (bit 0, value >80) in the color byte: the horizontal coordinate now refers to a point located 32 pixels to the right of the upper left corner of the sprite. This results in shifting the sprite 32 pixels to the left and allows for partial disappearance on the left side (but not any more on the right). The pattern number refers to the entry containing the sprite pattern in the sprite pattern table. Finally the sprite color is defined by the right nibble in the byte 4 of the entry. The sprite attributes table does not need to define all sprites: if the vertical position of a sprite is set as >D0, the sprite won't be displayed (as it's off-screen), but neither will any of the following sprites. This comes handy to quickly erase all sprites by just changing one byte in the attributes table. Sprite pattern table This table contains patterns to be used by the various sprites, arranged in ascending order. Each entry is either 8 bytes long or 32 bytes long depending on the sprite size. If the sprite size is set as 8x8, entries are 8 bytes long. Each byte defines a row in the sprite: "1" bits result in pixels of the color specified for that sprite in the attributes table, "0" bits encode transparent pixels and are ignored for display purposes. If the sprite size is set as 16x16 (VDP register 1, bit 6 set as 1) each entry is 32 bytes long. These bytes define the sprite pattern as if it were made of four "normal sprites" arranged in a 2x2 formation: 1 3 2 4 Thus, bytes 0-7 define the top left quadrant, one byte per line of 8 pixels. Bytes 8-15 define the bottom left quadrant in a similar fashion. Bytes 16-23 define the top right quadrant, one byte per line of 8 pixels (which now corresponds to pixels 9-15 of the sprite rows 0-7) and bytes 17-23 define the lower right quadrant. Even wiith a 16x16 pixels size, 32 sprites require at most >400 bytes (32x32). Thus there is room enough for extra sprite patterns and a sprite can be animated by quickly changing its pattern number in the attributes table rather than by modifying the sprite pattern table. Timing issues The VDP needs 2 microseconds to read or write a byte to its RAM. In addition, it can only communicate with the CPU at precise moments, when it is not too busy with building the screen. Such moments are known as CPU access windows and may arise at various intervals depending on the video mode. In standard or bitmap mode, a window occurs every 16 memory cycles, each cycle being 372 ns long. This means the VDP may have to wait upto 5.95 us before a CPU access window occurs. Adding the 2 us needed for RAM access gives us a maximum delay time of 8 us. Of course, it can be as fast as 2 us if a window just happens to open (even less for reading operations, thanks to the read-ahead buffer). In text mode, a window opens every three memory cycles, i.e. at intervals of 1.1 us. In multicolor mode, a window opens every four memory cycles, i.e. at 1.5 us intervals. There are two exceptions to these rules, however: When the screen is blank (because bit 1 in register 1 is set as 0) the VDP does not handle the screen and a CPU access window is permanently open. Consequently, there is no wait time. When the VDP is done with drawing a frame and enters vertical refresh mode it issues an interrupt (if enabled) and opens a 4.3 milliseconds (4300 us) window for CPU access. Condition Mode RAM access delay Time waiting for a window Total delay Building screen Standard / Bitmap 2 us 0 - 5.95 us 2 - 8 us Building screen Text 2 us 0 - 1.1 us 2 - 3.1 us Building screen Multicolor 2 us 0 - 1.5 us 2 - 3.5 us Vertical retrace Any 2 us 0 2 us Blank screen Any 2 us 0 2 us Contrarily to standard memory, the VDP cannot hold the CPU in a wait state until it is ready to accept/send data. This means that the application program must contain appropriate delays to prevent the CPU from going on with the next operation before the VDP has completed the current one. A typical example is passing the two command bytes to the VDP: using two successive MOV instructions is too fast and the second byte won't be read. The program should thus contain another instruction in between the two MOV (such as a NOP or a SWPB). Programming examples *------------------------------------------------------------* VDP write to register. * Expects register # in R0 MSB and register content in R0 LSB*------------------------------------------------------------VWREG ORI R0,>8000 Set command bits as 1xxx xrrrCMD SWPB R0 Send a command to the VDP MOVB R0,@>8C02 Send first byte (least significant) SWPB R0 Delay MOVB R0,@>8C02 Send second byte (most significant) B *R11*------------------------------------------------------------* VDP set address to write in RAM* Expects address in R0*------------------------------------------------------------VAD2WR ANDI R0,>7FFF Make sure command bits are 01xx xxxx ORI R0,>4000 JMP CMD Send command*------------------------------------------------------------* VDP set address to read from RAM* Expects address in R0*------------------------------------------------------------VAD2RD ANDI R0,>3FFF Make sure command bits are 00xx xxxx JMP CMD Send command*------------------------------------------------------------* VDP write byte to RAM* Expects data byte in R0 MSB and address set by VAD2WR*------------------------------------------------------------VWRBYT MOV R0,@>8C00 Send data to VDP B *R11 Delay*------------------------------------------------------------* VDP read byte from RAM. Assumes address was set by VAD2RD* Result will be in R0 MSB*------------------------------------------------------------VRDBYT MOV @>8800,R0 Get data byte B *R11 Delay*------------------------------------------------------------* VDP read status. Result will be in R0 MSB*------------------------------------------------------------VRDSTA MOV @>8802,R0 Read status register, resets bits 0-2. B *R11 Delay http://www.unige.ch/medecine/nouspikel/ti99/architec.htm