I tried asking for help on AtariAge and those people were kind of jerks, so I figured I'd ask you. I have one way that would have a register increment every TIA cycle, and then have another register increment every scanline, but that would eat up a lot of precious CPU cycles and ROM space, so how would I do that? I can understand moving sprites vertically, you could just increment a register during horizontal retrace. But how would I do horizontal movement?
Interesting side note. Besides producing 5 popular game consoles (2600, 5200, 7800, Jaguar, Lynx), Atari also sold many popular home computers (400,800,1200xl, etc.).
I can't just assume that you mean a specific console, when you say "Atari". So, you should probably say "2600" if that's what you mean.
Also, dude, are you for real?
The one with TIA video is the 2600.
You can't possibly increment a register every TIA cycle. The TIA is 3 times faster than the CPU, and INX/INY take 2 CPU cycles, so the minimum you can have is one increment every 6 TIA cycles/pixels. But this is not how you go about positioning sprites anyway.
If you never reuse objects during the frame, moving objects can be really simple, because they retain their positions from one frame to the next, so you can simply use the HMOVE registers to move stuff up to 8 pixels to the left or 7 pixels to the right. If you're not comfortable with timing all the RESET writes, you can even reset everything to the far left and use HMOVE across several scanlines to get everything to the correct positions.
If you do need to reposition sprites mid-screen though, you better get acquainted with the method of counting cycles and resetting them near the desired position and adjusting with HMOVE. There are countless general-purpose routines for this that anyone can use, if you don't want to write your own.
As for vertical positioning, that happens completely in software, since the TIA itself only has enough state for 1 scanline (or even less, if you consider that the playfield is mirrored or reflected), so it's entirely up to you to count scanlines and figure out what should be displayed when.
One simple way to do it is to maintain an scanline counter in RAM, and every scanline (or every other scanline, in the case of a 2-scanline kernel) subtract the sprite's position from the scanline index, so that the result is the index of the row of graphics to use. If the row is valid, use it to fetch the graphics, otherwise, clear the graphics to make the object invisible. For example, say you find yourself with the following state:
Scanline: 27
SpriteY: 28
Sprite height: 16
GraphicsRow = 27 - 28 = -1
The result is not a valid row (i.e. between 0 and 15), so the sprite should not be displayed. Then, on the next scanline:
Scanline: 28
SpriteY: 28
Sprite height: 16
GraphicsRow = 28 - 28 = 0
Now we have a valid graphics row index, that can be used to fetch sprite patterns, by loading this index in Y and indexing from a pointer. The row index will remain valid until scanline 43. After that, we have the following situation:
Scanline: 44
SpriteY: 28
Sprite height: 16
GraphicsRow = 44 - 28 = 16
Index 16 is no longer valid, so we can stop drawing the sprite. If you were paying attention, you may have noticed that a single verification can tell you whether the index is valid, since negative numbers in 2's complement are > 127, so the check for > 15 will also catch negative numbers:
Code:
lda Scanline
sbc SpriteY
cmp SpriteHeight
bcc Fetch
lda #$00
beq Draw
Fetch:
lda (SpritePattern), y
Draw:
sta GRP0
As long as you have 128 or less scanlines where this sprite can be. There are several ways to optimize this further, but this is the basic idea.
DementedPurple wrote:
I tried asking for help on AtariAge and those people were kind of jerks, so I figured I'd ask you. I have one way that would have a register increment every TIA cycle, and then have another register increment every scanline, but that would eat up a lot of precious CPU cycles and ROM space, so how would I do that? I can understand moving sprites vertically, you could just increment a register during horizontal retrace. But how would I do horizontal movement?
I realize that Spiceware's tutorial might be a bit much for a beginner, but Andrew Davie's tutorial that you linked to in your AtariAge post has all this information. People here and on AtariAge are pretty willing to help, but, like people have been saying to you both here and there, you'll get a lot better answers to your questions if you refer to the tutorial, and then ask questions specifically based on what you read. It's not likely that a forum reply is going to have more in-depth explanation than 3 chapters of a tutorial, unless you have a very specific question about a part of the tutorial that you didn't understand.
So to answer your question, read
Chapter 21 - SpritesChapter 22 - Sprite Horizontal PositioningChapter 23 - Sprite Vertical Positioningthen if you're still confused about it, put a post in the
2600 Programming for Newbies section of the AtariAge forums, and ask about the parts you didn't understand.
It seems to me that you don't have the patience to go through an entire tutorial, like most beginners do. For some reason you want to skip all the basics and go straight to the "good stuff". Problem is, skipping stuff is clearly not working well for you. It's already been a while since you first started asking about iNES headers here, and from one of your recent threads it looks like you still aren't able to assemble a working ROM.
Anyone who follows the Nerdy Nights tutorials property can get a simple sprite moving on the screen in a few hours, but you, in your attempt to "save time" by not reading any of the uninteresting stuff, couldn't do that in months.
Please take some time to revise your strategy and the way you're approaching retro game development. There are no shortcuts for becoming a good programmer, and you certainly won't be coding anything impressive on your first few tries, but all the boring stuff you go through will prepare you for more interesting projects.
Sometimes when you find the existing documentation overwhelming, you come to the forum hoping to find a simpler answer, but like I said before, there are no shortcuts. The documentation wasn't made exceedingly complicated for the heck of it, the subjects are actually that complicated, and we can't possibly compact all the information in a short forum post that's easier to understand. We can, however, clarify parts of the documentation you don't understand, explain certain details differently or even give a simpler overview of a complex subject that might help you get started, but certainly won't give you everything you all the answers.
^That post needs to be stickied or something
Dictionary of Phrase and Fable, E. Cobham Brewer, 1894 wrote:
Euclid, having opened a school of mathematics at Alexandria, was asked by King Ptolemy whether he could not explain his art to him in a more compendious manner. “Sir,” said the geometrician, “there is no royal road to learning.”
I have one more question. The tutorial says you need to divide by 15 to figure out how many CPU cycles you wait before writing to the Sprite Reset registers, and it says you can do it with this code:
Code:
Divide15
.POS SET 0
REPEAT 160
.byte .POS / 15
.POS SET .POS + 1
REPEND
Which makes me wonder, would it be possible to divide by 15 using only bit-operations and maybe increments? I would think that you could because 15 in hexadecimal is F
No, but you can divide by 16 using only bit shifts, because binary is a base 2 system and 16 is a power of 2.
It's the exact same principle as why you can divide by powers of 10 in our decimal base 10 system using only a "digit shift" - e.g. 600/10 = 60, or 600/100 = 6.
At any rate: that code isn't dividing at run time on the 2600, it's dividing at assembly time, so it really doesn't matter how you do the division.
That code is building a look-up table at assembly time, so that the 6502 code can quickly look up the answer of any division by 15 at runtime, it doesn't get any faster than this.
Most TIA object positioning routines I've seen perform the division in real-time, because a subtraction loop can be made to take 5 cycles (or 15 pixels) per iteration:
Code:
lda ObjectX
DivideBy15
sbc #15
bcs DivideBy15
sta RESxx
This would take the same amount of time as if you were DEX'ing a value loaded from a look-up table, but without the look-up table, saving you 160 bytes of precious ROM space.
tokumaru wrote:
It seems to me that you don't have the patience to go through an entire tutorial, like most beginners do. For some reason you want to skip all the basics and go straight to the "good stuff". Problem is, skipping stuff is clearly not working well for you. It's already been a while since you first started asking about iNES headers here, and from one of your recent threads it looks like you still aren't able to assemble a working ROM.
dougeff wrote:
Also, dude, are you for real?
DementedPurple's only 12, I think what's going on is he's growing up in the 21st century, and the world is damn noisy. So much information coming from all angles. Gets into coding. Gets interested in retro games. Finds SO MUCH INFORMATION ABOUT IT. Gets excited about EVERYTHING. I had *some* of this as a teenager but there was so much less available out there, that it constrained what I could even do and I think it helped give me some focus? (completely by accident of having been born in the 80's, thus, less access to internet at same full-of-energy age) That's why I keep recommending to try something like Pico 8 and stick with that for a while. What do you think DementedPurple? Perhaps even seek out a mentor. Mentors can help you stay focused, too. That's a bit of an arcane idea these days too, isn't it? We just use google now I guess, no need to ask a human for help. Oh well.
That was part old man rant and part "gee I wish I could help this kid focus."
I sincerely wish you the best whatever you wind up digging into.
I don't think this is a dumb question at all, because getting the Atari 2600 to display sprites requires a lot of CPU optimization because it has to do all the sprite multiplexing, while always taking 76 cycles.
I don't think anybody thought this was a dumb question; we're just alarmed at the number of things DementedPurple is trying to tackle, and gently suggesting things to maybe focus on for a while first. It's all up to him in the end though
Quote:
Gets excited about EVERYTHING.
I'd imagine my autism doesn't help with this...
One of the traits my autism gives me is that when I have an interest in something, I tend to get too excited about that thing, which might be why I post so frequently. But obviously I'm on the low-end of the spectrum because I'm able to talk, walk, and pretty much everything anyone else can, as a matter of fact, I think my autism is more of an advantage rather then a disability, I mean, I probably wouldn't know how to program without it! So the point is, sorry, I'll try to do more research before asking questions on forums.
DementedPurple wrote:
Quote:
Gets excited about EVERYTHING.
I'd imagine my autism doesn't help with this...
One of the traits my autism gives me is that when I have an interest in something, I tend to get too excited about that thing, which might be why I post so frequently. But obviously I'm on the low-end of the spectrum because I'm able to talk, walk, and pretty much everything anyone else can, as a matter of fact, I think my autism is more of an advantage rather then a disability, I mean, I probably wouldn't know how to program without it! So the point is, sorry, I'll try to do more research before asking questions on forums.
I'm trying to offer words of support, that was not a criticism, because I have reason to believe I may be on the spectrum as well though never diagnosed. I see your environment growing up in the 21st century as being possibly challenging for developing focus on specific topics. If you feel like you'd benefit from chatting with somebody, there are lots of friendly people here who are just a pm away.
My diagnosis is Asperger syndrome, which would nowadays be classified as high-functioning autism with no language delay. But yes, when someone directs you to a resource, I agree that it'd be a good idea to try to get as much from that resource as you can before you ask about things you don't understand.
See "
How to Ask Questions the Smart Way" by Eric S. Raymond.
And as a bit of encouragement: your follow-up question about dividing by 15 based on what you read in the tutorial is the type of specific question that completely makes sense to ask. Posting the sample code that you posted gave some context that you read the information, and were looking for clarification.
The other issue is you are playing with NES which is totally hoekey and bare metal with bugger all to help you. Then you go to VCS which makes the NES look like a High Tea. You have to count every clock and deal with really really constrained coding styles.
To which I suggest you come over to Lemon64 and give the C64 a go first. In that you can start in BASIC and poke and peek to get started, there is an OS, with a keyboard, you can actually program on the machine to test things, i.e you can interact with the machine and see what happens. Then we have tones of official documentation, the Commodore 64 Programmers Reference guide goes into easy simple to read depth of 98% of the C64, and then there is
http://www.bombjack.org/commodore/books.htm which covers every aspect in great detail, start with the DK step by step, then try a Jim Butterfield book it will explain all the ins and out of a 6502 in easy to follow tutorials. We have codebase64, c=hacking etc that has lots of the fancy effects demoed and with code to crib etc
We have a few younger people over at Lemon, 12,13,14 etc taking their first steps so you can see their early questions and the help they get, look for Link6415's posts.
The C64 PRG file is just start address lo, start address hi, code... no fancy headers no custom assemblers just dead simple.
Some people at Lemon have commented they tried to start with a NES and that was a mistake, so they came over to the C64 side as it has a lot lower barrier to entry.
Once you know the C64 and you understand how the machine and all the concepts work, then you can take the training wheels of and hit the bare metal of a NES.
Most of the big Atari 2600 homebrew is now done in Batari Basic. There are proof-of-concept games based on Mario, Sonic, Megaman, and Portal. The games made with this tool have a somewhat distinctive look.
Oziphantom wrote:
You have to count every clock
Just to make something clear, so the OP doesn't get confused: this means that the programmer has to count cycles when writing code to make sure everything happens when it should and fits within the available time, not that the code itself has to count cycles using registers and/or variables.
Quote:
To which I suggest you come over to Lemon64 and give the C64 a go first.
I don't know about the OP, but I personally hate unsolicited platform suggestions. Maybe some people don't care where their software runs as long as it's "retro", or maybe they're fascinated by every obsolete architecture equally, but I believe most people pick their target platforms for more specific reasons. And since both the 2600 and the NES have accessible tutorials written for beginners, I see little reason for looking elsewhere if these are your platforms of choice.
Dwedit wrote:
There are proof-of-concept games based on Mario, Sonic, Megaman, and Portal.
The guy who made that Sonic clone used my sprites without asking for permission or giving me credit, which kinda sucks.
Quote:
The games made with this tool have a somewhat distinctive look.
Yeah, the blocky striped background is the most obvious giveaway.
And that all being said, I think you might have given up too soon on the AtariAge community. People there tend to be really nice overall, despite the one or two harsh replies you got. I know spiceware made some updates to his tutorial based on your feedback, to try to make it easier to find what you're looking for. If you really are interested in learning Atari development and have more questions, I'd say come back over there and give everyone another try.
tokumaru wrote:
The guy who made that Sonic clone used my sprites without asking for permission or giving me credit, which kinda sucks.
That's crappy. I always wondered what your connection was to that game/guy. I guess nothing :-/
Have you contacted Albert at AtariAge about it?
He's selling it on the store, and would probably want to know about it.
tokumaru wrote:
I don't know about the OP, but I personally hate unsolicited platform suggestions.
Man, hate is quite a strong word for friendly suggestions given to a young person experiencing what I'd call "option paralysis." Not everyone has an easy time choosing what they want to do. I had the same problem after college: I knew I wanted to get back into hobby oriented game development but wasn't sure exactly what to focus on. I had had a brief background in QBasic and DOS and had grown up with Atari, NES, gameboy, snes, N64. But at the time lots of new things were available: XNA, rpg maker xp, Uzebox...there were lots of options and most people were saying: "Do the new stuff like XNA!" But I fondly remembered the QBasic days. It took a while but eventually found my way to nesdev, and once I realized it was possible, it helped make the choice clearer. This individual likely did not grow up with any retro system so nostalgia from early childhood likely is not a factor which can help him decide. I think C64 is a great suggestion; sometimes I wish I had grown up with that system!
tokumaru wrote:
The guy who made that Sonic clone used my sprites without asking for permission or giving me credit, which kinda sucks.
I always thought that the sprite you used on your profile pic came from that game, now I realize you were first.
And also, don't feel like you have to treat me like a special little snowflake because I'm young, I can handle the real world. I'm rather advanced at programming for my age. I can handle programming these consoles.
I think we're all sincerely interested in your success as we are in the success of any member of nesdev to pursue and achieve what they are interested in. We'll continue to answer your questions and possibly provide suggestions. I see no snowflake treatment amongst any of that. Probably the contrary; or we'd be afraid to give you suggestions
Take what anybody says on any forum with a grain of salt in any case, in the end you are in charge of your destiny. You'll do just fine, after all you have a LOT of time ahead of you to learn what you want.
GradualGames wrote:
Man, hate is quite a strong
Sorry if that sounded rude, maybe "hate" sounds more trivial in portuguese than in English.
My point is, it's borderline off-topic when someone asks "how do I do this on platform X" and someone replies "better do it on platform Y". If they were constantly complaining about the limitations of platform X, or specifically asked what a good platform for a specific type of project was, then I could see such suggestions being of any actual use, otherwise it's just noise, IMO.
Many times I was discussing Atari 2600 development over at AtariAge and someone would go "This would be great on the 5200" or "this would be easy to do on the 7800", but I don't give a rat's ass about those consoles. They're obscure pieces of hardware that were never sold in my country and I didn't even know existed until a few years ago. I can understand that the forums are full of people who love all those different systems, but I posted on a specific section for a reason.
gauauu wrote:
I think you might have given up too soon on the AtariAge community. People there tend to be really nice overall, despite the one or two harsh replies you got.
Yeah, they're generally pretty cool.
gauauu wrote:
Have you contacted Albert at AtariAge about it?
Nah, didn't want to make a fuss over something I wasn't even using. I guess this is a risk you take when you post stuff online, but I was kinda surprised that someone in the same community would steal stuff like that.
The C64 suggestion is a good one and that's what I would have recommended also,with that said it's completely possible to learn 6502 on nes if one has a large desire to succeed.I'd suggest to have fast look at lemon64,some C64 tutorials and see if that interests you to learn 6502 assembly on.No pressure though,if nes is absolutely the platform of your choice you'll learn/succeed it's just going to take a bit of time.Best of luck to you young man.
tokumaru wrote:
Many times I was discussing Atari 2600 development over at AtariAge and someone would go "This would be great on the 5200" or "this would be easy to do on the 7800", but I don't give a rat's ass about those consoles. They're obscure pieces of hardware that were never sold in my country and I didn't even know existed until a few years ago. I can understand that the forums are full of people who love all those different systems, but I posted on a specific section for a reason.
Ugh. I received several comments like this, when I revealed my "top secret" VCS project.
Now, where's the fun in (potentially) using up to a 128KB ROM, when I could make the exact same game, in only 4KB!?
Figuring out ways to squeeze more out of limited hardware is fun. Writing needlessly bloated software, is not.
Alp wrote:
I received several comments like this, when I revealed my "top secret" VCS project.
I think that there are indeed people who have an idea first and then look for an adequate platform to code it for, but I believe that the vast majority already have a platform in mind and are not willing to switch just because another platform is more appropriate.
Quote:
Figuring out ways to squeeze more out of limited hardware is fun. Writing needlessly bloated software, is not.
That's what makes retro coding fun for me, thinking of clever ways to make consoles do things they weren't supposed to.
This seems to be an Atari Age problem, I feel there is another reason at work.
⌐■-■⌐■-■⌐■-■⌐■-■⌐■-■ <- first take a pair of Atari Rose Tints
So the 2600 was Atari first foray and it was AMAZING but then they brought out the 5200... then the 7800 and it was the best machine ever... just those clowns in retail never saw it so there are about 5 games for it only... this sucks...
RandomPerson : So I want to do this on a 2600?
Atari People : Dude don't waste your time on the 2600, when there is the glory of the 7800, which makes the thing trivial...
RandomPerson : The What? Nah 2600 is good for me
> Throw those glasses away
Atari People - have to stare in the absolute illogical apathy of the world... Nobody cares about their favourite system, and will gleefully time after time play with the
clearly inferior system and nobody makes any games for them to play on their favourite system
But they are basically doing the same thing as
A:I want to do this on NROM
B:You might be able to squeeze it out, but why? MMC3 and done
Just MMC3/5 etc are still perceived as a NES when in actual fact a MMC3 is to a NES as a 5200 is to a 2600
(well okay not quite but getting there )
Oziphantom wrote:
in actual fact a MMC3 is to a NES as a 5200 is to a 2600
(well okay not quite but getting there )The MMC5, maybe... Since it does away with 2 of the major limitations of the NES that newcomers often complain about: only 256 tiles for the background (the MMC5 can do 16384) and the 16x16-pixel attribute grid (the MMC5 can assign palettes to individual tiles). The extra sprite patterns you get if you use 8x16-pixel sprites (512 patterns instead of 256) and extra audio channels you get on the Famicom are not to be sneezed at either. The MMC5 is also fairly rare and obscure, just like Atari's follow ups to the 2600, and is not generally recommended around here.
The MMC3 on the other hand is pretty basic really... in addition to regular PRG bankswitching (which many 2600 games also have), it does CHR bankswitching in chunks fine enough to aid character and background animations. The other significant feature it has is a scanline counter, which several other consoles had out of the box (even the 2600 has some pretty useful timers, although they don't generate IRQs), so I wouldn't consider this cheating. Also, the MMC3 was so widely used back in the day (bootgod's database suggests that almost 1/4 of the games used it) that its additions were eventually considered "normal" for NES standards. MMC3 boards are very abundant and the mapper has been cloned by cartridge makers, so I see no reason to avoid it.
Should using the MMC5 be considered cheating, though? I get coding for NROM or even MMC3 can be more for a sport, but unlike any of the more obscure atari consoles, MMC5 is still compatible with a system that everyone and their cousin has or have had, figuratively speaking. Which means that if you can make a game or application for it, the barrier to see what cool stuff you can come up with for the MMC5 isn't as large. And the stuff can still be great for its own standard. The main problem is procuring the hardware, right?
FrankenGraphics wrote:
Should using the MMC5 be considered cheating, though?
I guess most people would say "no", but opinions vary. I just don't think it's practical, since you can't get cartridges made without cannibalizing old hardware.
This is funny. There's been similar debates in the Atari community about what things are "cheating" -- there's a good bit of work being done now using cartridges with a more powerul co-processor that feeds the data to the Atari, and some are crying foul.
When it comes down to it, though, the two leading opinions are:
- Anything that fits in a standard cartridge and runs on a stock atari (using the Atari's input/output) is ok
- Anything that uses mappers/bankswitching/technology that was available when the console was current is ok.
MMC5 is legit by both those criteria.
That definition means that for Game Gear, nothing is cheating because a TV tuner existed. Plug in an Xbox.
One might define cheating as that which can't be reproduced with all new parts. How big of a CPLD would a substantial subset of an MMC5 need?
I feel like the only reason people ever want the MMC5 is for the EXRAM modes (i.e. 8x8 attributes, left-and-right split), which is firmly in FPGA territory.
The other things provided by the MMC5 (two extra audio channels, IRQ, slightly more advanced PRG banking, extended CHR banking, more sophisticated nametable control, hardware multiplier) are mostly all provided by other "lesser" mappers.
Oh, the MMC5 does have the ability to bank PRG RAM into $8000-$DFFF. That's kinda important.
L/R split isn't ExRAM. 8x8 is relatively cheap, but nobody's bothered standardizing any other designs for it.
tepples wrote:
That definition means that for Game Gear, nothing is cheating because a TV tuner existed. Plug in an Xbox.
If you can fit an Xbox inside a standard game gear cartridge, then yes.
Myask wrote:
L/R split isn't ExRAM.
Where do you think the alternate nametable for the split is stored?
The Famicom Disk System, for example, doesn't fit inside a standard Famicom cartridge.
gauauu wrote:
tepples wrote:
That definition means that for Game Gear, nothing is cheating because a TV tuner existed. Plug in an Xbox.
If you can fit an Xbox inside a standard game gear cartridge, then yes.
Why? It's like the FDS RAM adaptor cart…
…ninja'd.
I'm not saying there aren't other valid definitions. I was just giving examples of two common definitions used, and how MMc5 fits both. (And how an Xbox connected to a game gear fits neither of the two descriptions that I describe).
Personally, I don't care what definition people use as "ok" vs cheating. People make games for their own reasons, who am I to say something is cheating?
tokumaru wrote:
The Famicom Disk System, for example, doesn't fit inside a standard Famicom cartridge.
But it meets criteria #2: technology that was available when the system was being sold.
I'll play along.
SEGA discontinued the Game Gear in April 1997, and Majesco's second-source units dropped support for the TV Tuner. So replace "Xbox" with consoles introduced before second quarter 1997: the Saturn, original PlayStation, and Nintendo 64.
In that case, sure, I guess? (Although making it use the game gear's inputs sounds painful, bit I'm sure you could rig it up)
Like I said, though. I think both sides of the argument miss the right answer, which is "people can do whatever cool thing they want, who has a right to call it cheating?"
The notion of "cheating" here is totally bogus, IMO. I don't think you need to try and rationalize it with criteria.
There are plenty of things that make MMC5 (or analogous thing) a poor solution if you have particular problems, but every one of them is a personal "if" about that specific problem.
Sometimes it's annoying when someone aggressively assumes that you have the same problems as them and want to "help" you with advice, but sometimes the same really is helpful because you do have those problems. Perhaps it is well meaning, but can becomes a nuisance... it's hard to know where to stop, and sometimes even advice that is truly helpful is annoying at the same time, unfortunately. (I'm sure I've annoyed many here with both helpful and unhelpful advice...)
I think the most careful approach begins with the question: "What do you want to do?"
Often this question cannot be cleanly asked, though. Conversations are rather complicated and difficult structures.
I agree that you can't objectively say what's cheating and what's not. I'll probably consider cheating stuff that deviates too much from the typical experience of playing a game. If I can buy a cartridge, insert it into the console and play it without hassle, I probably won't be bothered by what's inside the cartridge.
But if the thing is way too expensive due to having an entire more powerful console inside, if I have to plug lots of extra cables (power, video, etc.), if it uses a different type of media, or anything else that's too different from the usual experience, then yeah, I'd probably call it cheating, because you, the player, is required to do things differently from the expected for playing games on the machine in question. The hardware wasn't able to adequate itself to the regular distribution model.
The reason I don't consider the FDS, Sega CD or the 32X cheating is because their games aren't sold as Famicom or Genesis games, they carry the name of the extra hardware required to run them.
It is good to hear that other communities are just as random as C64 one
SuperCPU ( aka 20mhz 65816 + 128K RAM expansion ) - 100% cheating not even a thing how could you
Ram Expansion Unit - Officially made by Commodore - cheating, its NOT a 64
1MB bankable flash cart with usb connection and an extra 256bytes of RAM - the most purist thing ever and eveything should use it for it is great and allows us to have better stuff...
Hell even a C128 is a faux pas...
For me one of the important things with the mmc5 would be what it lets you focus on. The larger tile map is perhaps less evident than the 8x8 attribute resolution, but it essentially means you can have lots of details/smooth animations without bothering with continous uploads on a per instance basis or need to severely limit the number of types/objects. This should leave you with a bit more unreserved computing bandwidth to focus on something you find interesting without having to sacrifice anything in the visual department. Ultimately, it supports designing games with fluent action and/or responsive, interactive environments. With greater possibilities comes a larger project, though...
Perhaps the C128 is cheating for the same reason the SuperGrafx is: almost no one has one.
C128 is not "cheating" ,just a faux pas. Which is basically down to the misconception that is offers nothing over the C64, or very little over C64 and thus any game for it could be done on the C64 for the general masses and not us snobby rich kids with a 128. In actual fact the 128 is like a PS2, look at it normally and basically its a PS1 and you get PS1 levels with a little bit more, once you understand it and hunt around the quirky systems you can really get some extra omph out it, just nobody has (yet).
Fun Fact : There are more C128s than 8bit Apple IIs
only one is seen as a failure and the other is the all amazing machine that defined computers that everybody rushed to buy
Did Super Grafix even leave Japan? I recently tried to work out the NEC console line up and I just got lost in it...
I was mistaken. Perhaps U.S. school computer labs full of platinum enhanced Apple IIe computers gave me a misconception.
The data I'm basing it upon is
Code:
Apple II 20,000
Apple II Plus 590,200
Apple //e 4,250,000
Apple //c 450,000
Apple //c Plus 200,000
Apple IIGS 979,000
Total 6,489,200
Which comes from
https://retrocomputing.stackexchange.co ... -were-soldWhich you can seen basically the IIe is the one that sold and the rest are just why did they even bother
Where the C128 is touted as selling in the 5~6 million range, Wikipedia lists it as 5.7million.
Now if School computers don't count as "sales" and hence are not listed, that would change the equations. Apple are a very American centric computer, we had them at my school, but we had 3 IIes and a IIgs. Commodore wins because they were worldwide, so there will be more Apple IIs in the USA(as USA is the bulk market for Apple ) but more C128s in the world( Were Germany and UK where the big markets ). For example Apples IIs are only colour in NTSC, they are monochrome in PAL land, unless you bought the custom colour monitor for them. Mean while the 1/3 price C64 is colour on a TV, it was a very hard sell. Apple big and basically only push was Education software, but outside of the USA the USA software is unusable, seeing as the C64 was king in the UK, most of the education software was converted to English for the C64, with only the biggest titles or titles that didn't need localisation being sold for the Apple IIs here. For example at my school we never had the Oregon Trail, we had Maths Blaster.
My elementary school had ~30 Apple IIgs computers, maybe 5 IIe and a single C64 that didn't get used much. Later on they got a few Mac Classics too. I wonder what they have now 20 something years later...
I'd always presumed the IIgs was the most popular variant of Apple II, but perhaps it was just down to timing of when my school decided to budget for computers, and their price at that moment. I don't remember the school having much IIgs specific software though, so using the IIe vs IIgs had some "feely" differences of keyboard etc. for us but not much else.
Oziphantom wrote:
SuperCPU ( aka 20mhz 65816 + 128K RAM expansion ) - 100% cheating not even a thing how could you
For absolutely no good reason, the idea of grafting an SA-1 onto random other CPUs/consoles amuses me greatly. Still as a coprocessor, not replacement CPU like that is.
I really haven't ventured out of this website much for discussion of old computer hardware, but I've never once heard someone say "cheating" in this context. I'd think most people would be smart enough to judge games with different hardware separately, even if they are running on the same base system. However, outside of old computer hardware websites and whatnot, I know people will often act as if a game using more advanced hardware through some sort of expansion is more impressive than it is. Most every list of "most impressive SNES games" will list Star Fox, when I don't think the SNES is doing much of anything except one big DMA transfer during vblank. Frankly, I don't even know if the game is that impressive for the Super FX. Regarding that, when it comes to expansion hardware, I really don't think you can just say "impressive", but rather impressive for the base hardware, or impressive for the add on hardware. This is only relevant with coprocessors, which are a separate entity. With just a ram expansion, there would be no distinction between impressive for the base hardware and impressive for the add on hardware.
Oziphantom wrote:
It is good to hear that other communities are just as random as C64 one
SuperCPU ( aka 20mhz 65816 + 128K RAM expansion ) - 100% cheating not even a thing how could you
Ram Expansion Unit - Officially made by Commodore - cheating, its NOT a 64
MY take on this is that these devices are both out of production and can be hard to come by and expensive... but:
Quote:
1MB bankable flash cart with usb connection and an extra 256bytes of RAM - the most purist thing ever and eveything should use it for it is great and allows us to have better stuff...
The EasyFlash (the first version) is made from currently parts that are still in production (AFAIK), is reasonably priced for what it actually is and all the parts are through hole so it can be easily assembled, relatively speaking.
Quote:
Hell even a C128 is a faux pas...
For a while I wanted one real bad. The I realised that for something which is physically larger and has terrible GND noise, the first thing I'd be doing whenever I switch it on would by typing 'GO64' anyways.
Hojo_Norem wrote:
the first thing I'd be doing whenever I switch it on would by typing 'GO64' anyways.
Anyone that enjoys games would do the same
Oziphantom wrote:
It is good to hear that other communities are just as random as C64 one
SuperCPU ( aka 20mhz 65816 + 128K RAM expansion ) - 100% cheating not even a thing how could you
Ram Expansion Unit - Officially made by Commodore - cheating, its NOT a 64
I don't find using the REU cheating,being created by commodore and all but nobody wants to support it, nice for full screen,color scrolling games though...that's all I've done with it.
I feel bad for people that bought the SuperCPU,that has almost zero support from programmers,and it's not cheap.
Real cheating would be attaching the PPU's EXT pins to duplicate expansion port signals (that you cut) and then 32xing your BG with full 16-color. (argh why aren't they already)
But I agree that cheating isn't really a meaningful term here; it's merely disapprobation trying to garb itself in an unapproachable raiment of morality.