RevEng
-
Posts
7,607 -
Joined
-
Last visited
-
Days Won
12
Content Type
Profiles
Forums
Blogs
Gallery
Events
Store
Posts posted by RevEng
-
-
3 hours ago, zzip said:
There's a huge difference between making static images that follow the rules and making a moving game. When you move objects around, they'll move to zones where they can't use the colors they had been using if you aren't careful. Sometimes even when you understand the rules, you will find they are too restrictive for your project. If the 320 modes were easy to use, there'd be more games using them and not so many threads around from coders struggling with them.
I can't think of a single game that switches between 320 modes for different zones, with the exception of switching for a non-game score/status area. Certainly none of the previously mentioned 320 mode games - the same ones that you said required elite programming skills to pull off.
All of the palettes you can assign to a sprite are available anywhere on the screen. Those palettes aren't pegged to any particular zone, like you're thinking. Sure you can use a raster interrupt to change the values in those palettes, but it's not as widely used a trick as on the A8, because we have different palettes to choose from. In any case, dealing with the palette values you yourself changed via interrupt hardly requires the elite programming skills you've claimed are needed.
Defender_2600 produces graphics that are directly actionable on the console, and they can move around without problem within the game screen area. Sorry, you're just flat-out wrong here about vertical movement being an issue. You're inventing complications that aren't actually there, not even on the games you said required elite 320-mode programming skills to pull off.
3 hours ago, zzip said:Sometimes even when you understand the rules, you will find they are too restrictive for your project.
This is true for any given system constraint or rule, on any console. There is no console from the 80s where any game design choice can be made without regard to the console hardware - even your imagined super 5200 successor would have had them. Ask an NES dev how simple raster interrupts are on their platform (without resorting to advanced mapper hardware) or how they add together BCD numbers for score display.
-
2
-
-
2 hours ago, zzip said:
I never said it was impossible, just that it was difficult and hence the tendency to avoid it.
It's not difficult, you just have to follow the rules of the mode. It doesn't take some exceptional elite coder guru to follow those rules. As I already pointed out, we have a non-programmer non-hardware guru regularly demonstrating a perfect understanding of them. Every console has rules and constraints you need to adhere to, and this one is no different.
2 hours ago, zzip said:But the problem is you need to be a hardware expert to achieve that quality and that means the vast majority of coders won't be able to do it.
I'm likely gonna blow your mind here, but NES coders also have to understand their hardware and follow the rules.
2 hours ago, zzip said:I'm judging it by its overall commercial library (the stuff that makes or breaks it) and its place in history.
There's too much noise in your data (other factors like lack of funding, lack of dev support) and too few data points (game titles) for you to soundly come to the conclusion that the tech was lacking. That's why I'm saying your pet theory is the result of confirmation bias. Well, that and the fact that I've actually used the 320 modes before.
-
3
-
-
6 hours ago, zzip said:
The fact that there's only a handful proves my point.
Reread what I wrote again. I was talking about all of the commercial releases together only being a handful of titles, and even then we got three 320 mode games.
6 hours ago, zzip said:If it's just a design choice, then why were even low0color games like Galaga implemented in 160 rather than 320?
Dunno. Maybe they didn't want to go over 32k. Maybe they thought filling out the width of the screen was better than using vertical bars at the side. The GCC stuff was co-developed with the hardware, so maybe the 320 modes weren't finished when Galaga development started. Maybe the dev wanted to reuse 160-specific routines from some other project, to save time.
It's a mistake to make up your mind about a technology based on it's worst implementations, and you've done again and again here. We've provided examples of 320 mode used well, both during the commercial console life, and after. Pointing at some of the worst commercial games in 160 mode as evidence for your pet theory - when there were so many non-technical challenges going on at that time - is misguided.
6 hours ago, zzip said:But I've read developer descriptions of the pitfalls in 320 modes and know it has several limitations that make it challenging to work with, and that's why it's infrequently used. It's unfortunate but that's the way it is..
Here's the thing. There are certain, very clear, rules about using color in 320 modes. 160 mode is simpler, but not in some "oh my god, 320 mode is impossible!!1!" kind of way. It just takes a little bit of understanding and planning. We're successfully using 320 for all kinds of homebrews now, and the tech is the same as it was when those original three 320 mode games came out. We haven't discovered anything new about the hardware regarding 320 mode.
Sometimes new devs start using these modes without bothering to read or understand the docs (which admittedly are a bit arcane - I do wish Atari would have invested in the docs a bit more) and then they complain about the results or ask for help in the forum. On the other side we have Defender_2600, who is a master at designing art for these modes, and he's not even a programmer - he just spent a little bit of time to understand the rules.
I dare say that if a non-programmer can understand the 320 rules so well, then maybe... just maybe... they aren't the difficult challenge that you're making them out to be. But what do I know, I just program for the console.
-
5
-
-
4 hours ago, zzip said:
There was no 7800basic BITD. Developers had to deal with whatever dev system and documentation Atari provided, and those often weren't the greatest.
There's two aspects that programming in 7800basic differs from traditional development. First, it allows you to not know a lot of assembly language and still create impressive games, and second, it provides what amounts to a library of assembly macros to accomplish certain tasks. Since we're comparing development in comparable systems like the NES, the first aspect is moot - the NES devs would have also had to program in 6502 assembly.
The second aspect is a hill to climb with your first 7800 assembly game. On your second game, you reuse a ton of your 7800-specific routines from your first game, turning that hill you originally climbed into a mound. If you're part of a game dev company with decent funding, you share those routines with team mates - same as what happened on the NES. This second aspect isn't the big advantage you think it is, nor is the NES markedly easier to program than the 7800.
Your "dev system and documentation" points aren't relevant to the argument that 7800 hardware (and Atari consoles generally) is intrinsically more difficult to program, compared to NES and other contemporaries. If anything they bolster what I've been saying this whole time - the poorer 7800 commercial titles were due to lack of dev support, not the tech.
4 hours ago, zzip said:PETSCII robots appears to be running in 160 mode except for the text at the bottom of the screen. I'm specifically talking about the 320 mode being difficult to work with except for developers with a special skillset. That's why the majority of games used 160 mode back then, which looked outdated compared to the competition.
Even narrowing the hardware superiority discussion to just hi-res... We only have a handful of commercial carts (in any mode) to actually point at, and at least three of them are using the 320 modes. (One on One, Jinks, and Tower Toppler) The difference in usage bitd is just a preference for high color (which matches my own taste) vs the lower color 320 modes.
It's the exact same on the A8 - most games didn't use Antic F despite it having the highest resolution, because greater color depth was often desired. In no way is using Antic F any harder than using the other modes.
I don't know where you're coming up with this notion that it's sooo hard to use the 320 modes that nobody was able or willing to attempt it under now, without your having any experience programming the console. And then you debate the point with someone who has experience, because you have some inferred knowledge that trumps actually knowing the console's inner workings. Hubris.
-
6
-
-
3 hours ago, zzip said:
I think it's like so many Atari systems where if you have the time and skills you can make it do amazing things. But the average programmer hired to do a port BITD didn't necessarily have those skills and had a deadline, so you got games that looked inferior to the competition. The reason for that is on the other systems it's easier to get better results.
Maybe that's true of the 5200, I don't know. It doesn't match any of my experience on the 7800. Many of the impressive looking games coming out on the 7800 are using 7800basic, which manages the display in a very generic way. There is no arcane months-long tinkering involved, just a small bit of system knowledge, some great game mechanic coding, and some kick-ass art.
mksmith got the 7800 Petscii Robots port up and running in petscii character mode, and it was my job to juice up the display for the 7800. That uplift work on the tile engine - which is most of the visual impact - took me less than a week of dev time. The rest of the dev time we spent on more mundane stuff - hooking up the rest of engine fully, adding controls, creating menus, QA and fixes, etc - all very pedestrian stuff and totally comparable to what you'd do on any non-Atari systems.
What allowed the game to look so good was the fact that the 7800's strengths aligned with the amazing c128 pixel art, in addition to having Defender_2600 and TiX creating beautiful sprite art. The art makes the difference, and programming on the other consoles doesn't eliminate the need for pixel artists.
-
4
-
-
2 hours ago, zzip said:
Even the 2600 can sound good at times. Still when you get into any kind of distortion, the 7800 clearly reminds you of it's TIA sound. Even at TIA's best, Pokey sounds better, and SID and YM 2151 sound better than that. There's simply no excuse for a 1984 console to have such an ancient soundchip as its primary.
Well, you're fighting against claims not made. I never said TIA is the same calibre as Pokey, SID, YM2151, etc. I just said it was good enough for the original launch titles, which it was, after which TIA audio would be supplemented by whatever was in-cart. +$2 or whatever per cart isn't a deal breaker, and it opens the door to custom per-game wavetables. (part of the minnie design) The Famicom has a similar in-cart audio feature, and the NES folks missed out on enhanced audio for some games.
I'll also suggest that If the 7800 had been shipped with quad pokeys, it wouldn't have helped sales in the least.
2 hours ago, zzip said:The eventual 5200 replacement could have been based on some 7800 tech. The Maria chip was ahead of it's time. But GCC would have had an extra 2 years at least to refine it. At minimum it has a decent soundchip and a resolution fix. 7800's 320 mode has issues that kept many games from using it. Either fix the shortcomings if possible, or come up with a 256 mode like some of Atari's competitors had. 160 just doesn't cut it for the late 80s.
There aren't any issues with 320 mode that kept games from using it - it has some quirks, but you can design around it without much difficulty - people just preferred high-color to high-res visuals at that time. People's tastes have skewed the other way, so now you see more 320 development on the console. That's the nice part of having selectable modes.
I think you're getting a bit caught up in the idea that a console must be dramatically superior in most aspects to win a console war. It's about the experiences the console can deliver, and always has been. The 7800 was in the same class as the NES, with each one having strengths in different directions.
2 hours ago, zzip said:Well yeah, I'm sure Jack & Co would have screwed whatever console they inherited. They weren't videogame focused, and it took them a long time to get there. In the meantime Nintendo ate their lunch.
Part of my scenario assumes Atari was better managed and perhaps a panic sale to Jack wouldn't have been necessary. I don't think the Tramiels could ever have beaten Nintendo, but I think Warner could have.
TBH I agree with your assertion that Atari shouldn't have put out so many platforms. But if we're undoing business decisions, Atari should gone with the Candy game console concept in the first place, rather than making the 400 computer, and later re-entering the console market with 5200, 7800, and XEGS.
I just disagree that the 7800 tech as launched wasn't competitive with contemporaries. The tech was there - as many homebrew titles have shown - but the management and development wasn't.
-
4
-
-
1 hour ago, zzip said:
Too bad developers weren't able to get this level of performance out of it in 1984-88 when it mattered.
Compare NES Ballblazer to 7800 Ballblazer, or NES Commando to 7800 Commando. The tech and performance was good enough to compete in 1984. The development support and direction was the problem. Like NES, the performance would have gotten better over time, had the 7800 been a commercial success.
1 hour ago, zzip said:It didn't need ST performance, it just needed to squash the NES, and that includes not just hardware, but games library. Instead playing a 7800 felt like playing a glorified 2600 because of the horrid sound. It really should not have been that way
The TIA sound was always a stopgap, and TIA music quality is also a function of the care given to it. I can point to several amazing homebrew/demo TIA tunes. Even going back to the original lineup, I reject that Ms Pac Man, Food Fight, Joust, Robotron, and Xevious have "horrid sound".
Your original argument was they should have built a 5200 successor instead of the 7800, based on your perceived 7800 hardware issues. When we point out it's mostly a matter of software, you pivoted to the quality of commercial library, which nobody was arguing about. Your imagined hyper-capable 5200 successor with an arcade port library would have also crumbled against the NES software library, especially in Jack's hands.
-
3
-
-
I haven't updated or modified it since that post. The "paddle"is a full player sprite - thepfcolpad2 demo name is from Gemintronic's original demo, which I just added the paddle minikernel to. No idea on the shimmering.
-
1
-
-
On 10/10/2023 at 4:14 AM, werpu said:
I am still scratching my head on why they did it like that, it would not even have made sense if the 5200 came out ca 1980 and the 7800 in lets say 84, given the absymal sound and face it the resolution of the Maria chip was subpar to similar offerings coming out in 84 like the NES!
On sound, you're missing context as to why the decisions were made. Maria itself was supposed to have built-in sound originally, but it got squeezed out for the Maria2 silicon updates which were much needed. But even then the plan was never perpetual TIA audio - not all that long after Maria2 was in production, GCC had a $2 in-cart sound chip prototyped and playing music in their offices.
This plan was interrupted by the sale of Atari, which unfortunately halted all dealings with GCC. On the plus side, this circumstance gave us line-in audio on the cart, which is a very neat feature.
As to which system has better resolution, it's more of a "which system fits the game design" sort of thing. 7800 can display both 320 and 160 modes, while the NES has a 256 mode. The NES resolution is a great middle-ground, but there are trade-offs. The NES can't produce graphics or text as dense as the 7800 320 modes (see Rikki+Vikki, or recall all of the NES "press A to continue" over and over again whenever dialog was involved. ) nor can the NES manage as many simultaneous colors as the 7800 160 modes.
Whenever you compare consoles that are contemporaries, it's rarely as cut and dry as "A" being better than "B". You may prefer one set of trade-offs over another, but it's hardly universal.
-
3
-
-
49 minutes ago, ledzep said:
Oh, really? That would suck to program. I remember in high school I was in a computer class, we had some new TRS-80 computers (not color, I think the IIIs) and the pixels weren't square on that thing, either. Really irritating trying to program simple games on it.
Nah, its doesn't particularly suck. Basically it's double-resolution in y, compared to x. If you really want near-square pixels, you can double-stack pixels vertically, but it's a waste. The finer y resolution allows for better resolution in slanted lines, and makes dithering more effective. You could also use one of the 320 modes, which do have squarish pixels.
FWIW, the 2600 has the same non-square resolution for players and missiles, as do the Atari 8-bit computer Antic modes C & E.
-
1
-
-
He's following the instructions in this post, which builds arm binaries. Good catch on the stella bit - i just copied and pasted his reported path.
@Lavalamp let us know the results of "ls -la ~/.vscode/extensions/chunkypixel.atari-dev-studio-0.9.2/out/bin/compilers/bB" instead.
-
1
-
-
What's the output of for the following?
ls -la ~/.vscode/extensions/chunkypixel.atari-dev-studio-0.9.2/out/bin/emulators/stella/darwin
-
Try "git clone https://github.com/batari-Basic/batari-Basic.git" instead.
-
Game mascots and cinematic universe, ready to go...
-
9
-
-
The glitchy/glittery pixels and glitches are a sign that something is out of spec, either in terms of bus timing, or something interfering with the bus. Maria is sometimes getting bad data when it's fetching the graphics data.
-
1
-
-
Taking a step back.. if you double-check the size, is your generated rom 32k?
-
33 minutes ago, SpiceWare said:
I get that error too. I did a search on my drive and found the zip file, which was created on the same date as that post:
Thanks!
md5sum confirms that arm file is the same one being distributed with bB since v1.4.
-
1
-
-
5 hours ago, Karl G said:
I'm looping in @RevEng in case he has anything more helpful to offer. 🙂
Not really sure I have much to offer, at least until batari responds... I replaced the dpc+ bin file a few years ago. I think it's the same file as the one referenced in Darrell's post, but I can't be sure, because I get an error when I try to download his file.
-
1
-
-
53 minutes ago, Shawn said:
I would tend to believe this guy
It's a wry statement. The emulation will "perform" amazingly fast if it doesn't emulate Maria faithfully. The screen will be messed up in several scenarios, but the framerate of that messed up screen will be fantastic!
-
1
-
6
-
-
17 hours ago, John Stamos Mullet said:
So then help rewrite a7800 to work on ARM chips.
How about the for-profit company do it for their product, instead? This isn't rocket science - the source code is all there, and thoroughly commented. One could back-port the a7800 driver improvements to an earlier mess code-base (the mame4all approach) or port them to prosystem. (basically what I did with the a7800 pokey driver, for js7800)
-
13
-
-
I'm going to take a shot in the dark and guess it's a ground loop issue. If you have a sacrificial cable, you can remove ground connectivity from the end that plugs into the retrotink. I guess you could even avoid sacrificing a cable by using some thin paper or plastic shimmed between the rca male and female to isolate ground. If symptoms improve it will tell you that ground loop is the problem.
The usb charger is probably putting out switching noise in the mhz range, as they all do to some degree, but I wouldn't expect that to only affect chroma, so it's a less likely candidate.
-
1
-
-
49 minutes ago, Karl G said:
1) I wouldn't post any more about what you may or may not do for a Knight Rider project until you have at least some small amount of working code
The lack of working code I can live with. It's the lack of quotes from Moby Dick that's the real problem.
-
3
-
-
1 hour ago, Crazy Climber said:
Nah dude, at this point is HAS to be everything @HardWork promised us or nothing at all. Some generic driver in batari basic with the knight rider name slapped on it will simply not do 😆
How about a knight rider pac-man clone? You know that's what the suits would have asked for, back in the day.
Here's my earlier comment, which matches your sentiment. I'm quoting it for easy access to the HardWork design docs...
On 3/2/2023 at 12:03 PM, RevEng said:-
1
-
2
-
-
One more thing... for anybody using "underthehood" techniques, the underthehood sample now has a "updateobjects4.asm" assembly file suitable for 4-byte sprites.
-
3
-
1
-
md5sum confirms that arm file is the same one being distributed with bB since v1.4.
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
Robot Zed 7800 first demo and progress
in Atari 7800 Programming
Posted
Very nice start!
I think the problem mostly amounts to the fact that a7800 and js7800 only have mapper support for formats that have existed in the past, or are available formats for AA carts. 32k+ram@4000+pokey@450 isn't one of those. 7800basc is a bit looser, allowing you to mix-and-match some hardware, because i want it to be usable for anyone to create a test rom if they're developing new hardware. I don't have time to look it up just now, but there's a blurb in the 7800basic manual saying that it's on you to ensure the hardware combo you choose can produce carts. (or works in emulation)
My suggestion is to go for "set romsize 128kRAM" and "set pokeysupport $450', just like the rmtramdemo. That should work on the various modern emulators and flash carts - plus you're almost certainly going to need bankswitching for this game eventually.