Pat Brady

December 16, 2023

Congrats @johnnywc and @Nathan Strum! Both games and both packages look fantastic.

July 24, 2023

I know mram@4000 is mirror RAM a la Rescue on Fractalus.

What's the difference between ram@4000 and hram@4000?

March 4, 2023

There is only one other currently available option. Regardless, I for one welcome discussion of 7800 hardware, whether it's standalone or an interface to something else.

@-^CrossBow^- @evietron — it sounds to me like Evie is/you are aware of all the POKEY addresses. Just to be clear, the list is: $4000, $450, $800, $440 (the last used for stereo paired with $450).

March 4, 2023

It's a good question.

I consider the 2600, 8-bit computers/5200, and 7800 to be 3 different platforms. They do share the same CPU (the 2600's runs slower), and the 2600 and 7800 use the same sound chip, but there's not much similarity otherwise (unless running the 7800 in 2600 mode, in which case it's a 2600). They have completely different graphics processors and memory layouts. The NES also uses the same CPU, so I don't see it as any further away.

Whether porting an existing game is easier than starting from scratch probably depends on the nature of the game and how it was coded. If the original was coded with the game logic cleanly separated from the display code, then porting the game logic might be fairly straightforward. If all the code is intertwined, it might be easier to start from scratch. Coding for reuse takes effort. My impression is that BITD it wasn't really a consideration: it was hard enough just to get a game working in the allotted time.

Since the graphics systems are all completely different, the display code — which might be a substantial part of the total code — cannot be reused in any case.

Even if the code is cleanly separated, the systems have big differences in RAM and practical CPU power. That's obviously a problem when going from a more powerful system to a less powerful system. But going in the other direction, it might make it hard to take advantage of that power, which we typically want to do. For example, the 2600 has only 128 bytes of RAM in the console, and games have to be coded around that limitation, and that might prevent desired improvements in a 7800 game, so you zmay end up rewriting it anyway.

I know some of the 8-bit computer homebrewers have done ports using code from C64 or BBC Micro versions (again, same CPU, different graphics chips). Maybe it makes more sense when the source and target platforms' capabilities are in the same ballpark.

March 3, 2023

3 hours ago, -^CrossBow^- said:

I've also provided Evie with the links to the threads regarding the new Banksets implementation and test roms so that can also be looked into.

Some of the issues with the Pokey audio on home brew games I'm sure is due to the fact that she hasn't implemented support for the Pokey at any other address locations aside from $4000 and $8000. So if home brew devs are willing to work with her on that she has stated she can program additional address support for the Pokey. She just needs support and assistance from the dev community.

I have never heard of POKEY@$8000. $8000 is typically ROM. Did you mean $800?

$800 is used in bankset and has some issue with startup due to the BIOS doing something in that space. RevEng and batari are the people to ask about that.

POKEY@$450 is common in homebrews that put something else at $4000.

The only other thing I'm aware of is double-POKEY, with one at $450 and the other at $440.

March 1, 2023

On 2/28/2023 at 11:04 AM, Zonie said:

I knew about this but didn't think it would be that good. Admittedly I only watched about 5 min of this, but I can see this as a mind blowing game if it came out in '82.

New 2600 games in 1982 were 4K or 8K. CC is 128K, which might have been viable in 1986, had the market not moved on to newer consoles.

18 hours ago, JagChris said:

Nah, CC is only about a year old. And more forthcoming was based on how well this does.

It's a 2-year-old 2600 game, one that received a ton of attention when it came out. I think it's not very realistic to think that promoting it at this point will move the needle enough to make them develop a 7800 game, especially since IIRC they explicitly stated disinterest in the 7800. It has no more relevance to this forum than any other 2600 game.

If you want to encourage more 7800 development, tell your friends to buy 7800 games from people who make 7800 games.

February 26, 2023

11 hours ago, Synthpopalooza said:

My 7800.Popeye POKEY music is available for this should anyone desire it.

Feel free to include my contribution.

February 19, 2023

10 hours ago, Andrew Davie said:

There's a tune, of sorts, running in the background. @Pat Brady helped me with the transcription; TY. I hacked the 2nd channel to be a sort of random-distortion backing track; I know it's horrible!

I've worked a bit on a bass line, but not finished it yet. Hopefully this week.

February 16, 2023

4 hours ago, x=usr(1536) said:

One thing I noticed with some of the ARM games: starting them (Ladybug Arcade, Galagon, Mappy) results in the 'Do not turn off your 7800' screen also shown during hbios updates being displayed before the game starts. This is what I see when Mappy starts loading:

Interestingly, Juno First doesn't do this. Don't recall getting this on the 7800 side, but haven't tested as extensively over there yet.

Juno First does not use the ARM.

February 14, 2023

1 hour ago, Aug said:

@Pat Brady
I not understand if that game use any extra hardware for sound.
You have done an great work If only was used the TIA. Congratulations 😃

Thanks! We aren't using CDFJ audio, it's just TIA. We sometimes update one register twice per frame, but never more than that. The notes with 2 updates sound distorted. I'm hoping to reduce that for the next release.

Thanks also for the constructive comments on the tempo. Speeding it up to arcade speed (128 BPM) makes some of the rhythms imperfect mathematically, but they're close enough that I can't tell the difference, so we're going with that.

February 13, 2023

17 hours ago, doctorclu said:

For those ripping on 2600 games, have you seen the Atari 2600? I mean, certainly you have, but let's remember...

It was powerful for it's time, but not arcade level powerful. It was mostly about interpretation into a lesser powerful system and gameplay.

Sure, we now have hacked these very games with better sprites, but it seems the programmers were not often graphics artists, or were just rushing to meet deadlines to get games out. And a lot of us who have hacked or programmed better versions in many cases were done over a more generous amount of time.

Yeah, AFAIK the lazy-programmer meme has no basis in reality. It might be more accurate to say mismanagement, at least at Atari itself from 1980-1982 when they were swimming in cash and still skimping on development costs.

EDIT: Regardless of whatever was going on at Atari Inc. at the time, I agree with you that most of these games are at least decent on the 2600. I definitely enjoyed Centipede and Defender BITD.

February 13, 2023

2 hours ago, Aug said:

Really the music tempo is more slow than the arcade.

It's right at 120 BPM. The arcade is about 128 by my measurement. That's as close as we can get while keeping it perfectly steady. I'll see if I can increase the speed a bit — the triplets won't be perfect but might be close enough for human hearing.

(The arcade game has a dedicated audio CPU which I think lets it choose an arbitrary tempo. Obviously we don't have that luxury.)

February 12, 2023

7 hours ago, bigmessowires said:

Was a 1.79 MHz clock possible at the time? I would have assumed Atari went with the fastest CPU they could get, but I don't know what the incremental cost would have been for going faster. If they increased the speed they would have needed a faster spec'd PIA as well as faster 6507, not sure about the TIA.

In my imagining, this 2600 Plus would have happened in the early 1980s, when a 6502 at 1.79 MHz should have been feasible.

I forgot another important and easy enhancement: a 2- or 3-button standard controller.

Even without any TIA enhancements, a 2600 with a faster clock, more RAM, bigger banks, and a multi-button controller would have been a significant upgrade.

6 hours ago, splendidnut said:

So, a POKEY chip?

Similar to POKEY in capability, but different in design, based more directly on (and remaining compatible with) TIA.

February 10, 2023

15 hours ago, splendidnut said:

Anytime someone talks about improving the TIA... it always reminds me of the Atari 8-bit chipset, where players/missiles were doubled and playfield capabilities were greatly expanded. I think that chipset would take care of about 3, maybe 4 out of the 5 things on your TIA expansion list.

From your list, being able to directly set the X position is the big one... but that was really due to the type of counters they used to save chip space. The team addressed that issue with the 8-bit chipset.

I think the two things that would have made the greatest impact would have been:

- increased CPU speed (1.79mhz like the rest of the Atari 8-bits).

- more built-in RAM (like 128 bytes more -> built-in Superchip without the separate R/W areas)

But, those were more likely time-frame oriented... if the 2600 would have come out a year or two later, those might have been a given.

I'm a bit annoyed at how much time I've wasted thinking about this particular alternative history, where instead of the 8-bit computers Atari made a 2600 plus that was compatible with 2600 games.

A few things could have been done without redesigning any of the big chips, and making compatibility mode relatively easy to implement:

The easiest thing: add more address pins and a R/W line to the cart connector (a la 7800). Allows bigger ROMs without bankswitching, and bigger banks with it.
Increased CPU speed, like you said. Even the modest bump to 1.79 MHz would make a big difference for the 2600 because you could do much more in the kernel.
Increased RAM, like you said. 128 bytes at $180 is the most obvious one, which would decouple the stack from zero page. Beyond that, put more 128-byte blocks at other mirrors, and/or put 1 or 2K at $800.
Add an ADC for paddles, so the kernel doesn't have to read them (admittedly this was not a widely-used feature in the 8-bit computers AFAIK).

Those 4 things (or just the first 3) would be a *huge* upgrade IMO.

Further into fantasy territory is a "TIA Plus" that might be implementable with a compatibility switch. My wishlist:

Allow full-width playfield using the other 4 bits of PF2 and mirrored addresses of PF0-1.
Provide 4 player sprites and 4 missiles, using mirrored addresses (which kind of explodes the collision detectors, so may need to be clever about that).
Improve audio (which gets the most detail here because it's what I know the most about):
1. Increase frequency counters to 6, 7, or 8 bits.
2. Tweak the distortion definitions to account for the higher resolution.
3. Provide a few more distortion settings (5, 9, 10, and 13 are currently redundant), ideally at octave intervals (useful and easy to implement) of existing settings.
4. Provide 1 or 2 more channels using the mirrored addresses.
5. Increase dynamic range to 5, 6, 7, or 8 bits.

Redesigning the 6502/6507 is too far out for me to think about.

EDIT: not annoyed at anybody here, I thought about all that before yesterday.

February 9, 2023

Looks great to me, including your idea to allow implementations to preload ROM into RAM in certain unusual cases.

Only thing I'll add is that single POKEY@$440 is not necessary AFAIK, though it doesn't hurt anything.

I have one other thought, purely about documentation. @RevEng mentioned a while back that some implementations of POKEY@$450 mirror it to some or all otherwise-unused addresses in the $400-$4FF space. From a software standpoint, this is fine: if I don't declare in the header what I want at, say, $440, then I don't care what's there. In C/C++ terminology they would say something like "behavior of unmapped regions is undefined." Should we add some language like that, so that implementors know they can mirror, and developers know not to rely on anything there?

EDIT: thanks again to both of you.

February 9, 2023

9 hours ago, SainT said:

Gotcha, I'm assuming allowing 4 POKEY's would be a little pointless, however. So up to two POKEY's simultaneously and then the other audio devices as well?

...

I'm trying hard to sanitise things such that it isn't just a massive mux with hugely redundant / invalid combinations.

It's important to recognize that you do not have to implement everything that the header can represent. That's true whether the header represents devices as bitfields or enumerations.

There are a few demos that use 2xPOKEY@$440. Nothing uses any other 2xPOKEY configurations, or more than 2 POKEYs, AFAIK.

From reading your posts earlier I infer that you may have to choose between a second POKEY and a first SN76489. If that's the choice, there's not really a right or wrong answer. If you do choose 2xPOKEY, limit it to @$440. Forgive me if I'm off-base here — my hardware design experience is limited and distant — but I don't think you need a massive mux. Each address can only correspond to one device and only the 1st POKEY might be at multiple addresses ($450, $800, $4000). (You could map them differently, the only important thing is that $450 goes to one and $440 goes to the other.)

For a microcontroller-based carts, the limitations might be different.

Don't spend any resources on POKEY@$810 in any case. No released software uses it, and any future software that needs 2xPOKEY should use the existing $440 mapping. I don't believe it needs to be in the header either.

I argued for bitfields earlier, but not in the context of POKEY mappings. If enumerating the POKEY possibilities (none; @$4000; @$800; @$450; @$400+@$450) would make it easier to implement, then let's do that.

February 9, 2023

Thanks for picking this up. I like the approach. I have a few quibbles.

12 hours ago, SainT said:

Linear ROM

Size is implicit from the payload size upto 52KB. If RAM is enabled the maximum loaded ROM size will be 32K regardless of payload size.

Probably not a huge deal, but my preference would be for size to be implicit even if RAM is enabled. For example, 40K ROM + 8K RAM seems like a useful configuration that doesn't seem difficult to implement.

9 hours ago, RevEng said:

My preference is to have the v4 header bytes set in parallel with the existing v3 bytes.

Strongly agree with this.

8 hours ago, SainT said:

Another possibility, which was actually suggested by Tailchao, is to have the V4 header data in the ‘cart data starts here’ section and the V3 header bytes would replicate the V4 setup as closely as possible.

We're really only replacing the cart type bytes, right? I have no love for ACTUAL CART DATA STARTS HERE, but IIRC a few existing implementations do look for it. Why not put the V4 stuff at $40? And maybe deprecate ACTUAL CART DATA STARTS HERE, so that V4 readers know to ignore it.

Gonna respond separately about the audio stuff.

February 9, 2023

2 hours ago, splendidnut said:

From my own personal experience, ROM size makes a BIG difference. Please don't discount that.

2 hours ago, splendidnut said:

If you want a good apples to apples comparison between ARM / no-ARM:

(Mappy and Aardvark)

Two EXCELLENT games, both 32kb. One of them uses DPC+ / ARM.... the other does not.

There are also excellent games in 16K and less.

Reading these two posts back-to-back, in a context where nobody is proposing to remove ROM size information, it seems like you are suggesting that an ARM processor does not make a big difference. From your other posts, I don't think that's what you believe, but I can't find any other way to read this sequence.

February 8, 2023

2 minutes ago, zzip said:

IDK, it was the hottest game around at the time, if that isn't worth spending extra money on to get right, what is? They could charge extra for the game and still sell a ton. Also we were seeing 8K standard within months after Pac-man, how much extra cost was it really at that point in time?

My semi-educated guess is that the cost would have been in the millions.

My point was that if they cared about getting it right, they could have done much better in 4K (e.g. by giving Frye better guidance, more time, and/or more help). And if they did not care about getting it right — which I believe is the case — then going to 8K might have made it only slightly less awful.

February 8, 2023

2 hours ago, Crazy Climber said:

All I'm saying, comparing it to 4k versions made 25+ years later (with no time restrictions and a lot of collective/shared knowledge available) isn't very fair haha.

By 1981, Atari's in-house developers were extremely familiar with the 2600, and had come up with lots of clever tricks. I'm not sure that a decent Pac-Man needs many tricks besides flickering and 6-digit score, and Atari's original 2600 Pac-Man uses both of those (though the flicker could be improved). From what I've read, Tod Frye's knowledge of the 2600 was definitely not the problem. I think the fundamental problem was that Atari management at that time just did not care whether their customers liked their games. They understood (correctly) that Pac-Man would sell well even if it stunk, and they either didn't anticipate or didn't care how that would play out in 1983.

2 hours ago, NE146 said:

Nukey did a lot of those in his hack to Atari pacman. Sure he made it 8k (for intermissions, etc.), but it at least gives you an idea of what you're talking about IF we're talking only about improving the original VCS Pac-man we all know and love.

Aside from that of course at this point there's Dintar816's amazing port of the arcade game to the VCS

Also DEBRO's port, which is excellent and only 4K.

2 hours ago, zzip said:

Also Pac Man was one of the last 4K carts- Atari switched to 8K shortly after so Atari probably could have made it 8K if they wanted to.

Asteroids was 8K and came out before Pac-Man, but was an outlier. 8K had a real cost at the time and was not absolutely necessary for Pac-Man. The decision to keep Pac-Man 4K was at least defensible, unlike some of the other decisions.

1 minute ago, SpiceWare said:

Additionally the newer 4K versions are all single player games - not having to keep track of 2 sets of scores, lives, dots, etc. frees up quite a bit of RAM that can be used to implement things like sprite flicker logic.

Undoubtedly true, but Atari chose to spend RAM and ROM on the 2-player variant instead of making the 1-player game better, and that's one decision (among many) that made it a bad port. I'd say the same for attract mode color cycling.

The colors and the shape of Pac-Man's mouth were bad decisions that had no benefits at all. I hacked it so the colors are correct and Pac-Man's mouth opens as a wedge. It's not great, but feels more like Pac-Man. Took about 30 minutes, and most of that was finding the sprite tables and color-changing code.

To be clear, I don't blame Frye specifically. I think he gave Atari what they asked for.

February 6, 2023

8 hours ago, Karl G said:

If you are going for a one-button game, I would use button 0 instead of button 1.

If not adding more launchers, I recommend leaving the 7800 in 1-button mode. That way, both buttons work, as will the single button on a CX40 or compatible.

February 2, 2023

10 hours ago, zzip said:

Can it do a proper isometric game that isn't a mirrored image (like the 2600 Crystal Castles)? I thought that was one of the things that was very difficult on the 2600

DPC+, CDF, CDFJ, MovieCart, and ACE have really obliterated all of the old rules about what is possible on the 2600.

Even without any on-cart processing, we have Space Raid (4K and 8K versions, both ROM-only, both outstanding achievements IMO) and Atari's own Desert Falcon (16K with 128 bytes of RAM). I expect the above cartridge types could put more objects on the screen.

EDIT: @Andrew Davie's MovieCart reproduction of Zaxxon arcade gameplay is also worth seeing. It's not a 2600 game, but it demonstrates what the 2600 is capable of displaying.

February 1, 2023

59 minutes ago, vrocko said:

Wish they'd do that for Zaxxon but I don't know if the 2600 could handle it.

Given sufficient processing power on the cart, the 2600 can do Zaxxon and a lot more.

January 30, 2023

@Andrew Davie I sent you a PM.

January 30, 2023

2 hours ago, splendidnut said:

I was able to get the ROM usage under 2k with 2 screens. Might be possible to get a full game within 4k.... depends on how much gameplay logic is needed and how much graphics is needed. BUT, I'm thinking it would probably end up needing 8k or more.

The original came out in 1984, for more-powerful systems, and only on disk and cassette. I always think it's a laudable goal to minimize cart hardware, but in this case, even if you're going for something that could have been done BITD, bankswitching (and also SARA/CBS/BurgerTime RAM, if that would help) would be totally appropriate. By 1984 bankswitching was the norm for new 2600 games.

Profiles

Forums

Blogs

Gallery

Events

Store

Posts posted by Pat Brady