[ 3 / biz / cgl / ck / diy / fa / ic / jp / lit / sci / vr / vt ] [ index / top / reports ] [ become a patron ] [ status ]
2023-11: Warosu is now out of extended maintenance.

/vr/ - Retro Games


View post   

File: 48 KB, 800x600, ManThinking.jpg [View same] [iqdb] [saucenao] [google]
3380740 No.3380740 [Reply] [Original]

How did people develop NES games back in the day? Did they use DOS or something? Fuck, maybe even an Apple II?

>> No.3380754

>>3380740
Assembly code

>> No.3380757

>>3380740
Pen and paper.

>> No.3380762

>>3380740
Sometimes they literally used pen and paper. Sprites and things like that were translated into assembly code by hand or through crude implementations using PCs of the time. Then the game was either burned onto an EEPROM and used in a special socketed cartridge, or it was sent directly to the NES CPU through a custom rig they built. Every company did it differently.

>> No.3380783

NES games were programmed in PC-98s or whatever they had at the time, since the NES used Assembly (specifically, 6502 Assembly). For graphics, they used stuff like DPaint (https://en.wikipedia.org/wiki/Deluxe_Paint)) or one of the old Mac programs.

It's pretty easy to find SDKs if you look around. I don't think they have the oldest SDKs (for Apple IIs), but there are a lot of them on DOS. I know the N64 SDKs was designed to be used in Windows 95 and 98.

To transfer the ROM to a cartridge, they used a serial connection.

>> No.3380798

>>3380762
>>3380783
Kinda cool, desu.

>> No.3381363

>>3380740
We used a wide range of systems. It wasn't one guy sitting there with a mario level editor. It was usually at least half a dozen people and they used whatever tools worked best.

We used a PC to program the ICE for the dev unit. It used a parallel connection not serial as >>3380783 said. That would have taken ages. It was also SRAM, not EEPROM as >>3380762 said. Certainly nothing was "sent directly to the NES CPU"

Code fragments were usually developed and tested on an Apple or Commodore as they used the same instruction set and had good dev tools.

We did our graphics using a digitizer. Not the kind you're probably thinking of, the drawing kind. I heard of other people who used graph paper but we'd all outgrown D&D by then and graph paper with it.

>>3380754
>>3380762
>assembly code
What on gods green earth is that?

>> No.3381372

>>3381363
So what games did you develop, Mr. I-Don't-Know-What-Assembly-Code-Is?

>> No.3381394
File: 55 KB, 512x512, mikematei.jpg [View same] [iqdb] [saucenao] [google]
3381394

>>3381363
>acts like he's "in the know"
>hurrr what's ASM

>> No.3381404

>>3381394
>>3381372
>"Assembly code"

>> No.3381417

>>3381404
That's one of the terms people use to describe the language NES games were programmed in, yes.

>> No.3381421
File: 6 KB, 390x470, Crying.png [View same] [iqdb] [saucenao] [google]
3381421

>>3381417

>> No.3381425

>>3380740

>Akira Kitamura: Back then, we had no in-game editing tools: you had to see what you’d coded in by loading it on-screen.

>> No.3381426

>>3381421
Do you actually have autism?

You still haven't said which games you worked on, probably because you never did.

>> No.3381429

>>3381426
I'm not the dev guy, I just find this blind leading the blind shit you guys do funny.

>> No.3381431

>>3381421
Code, instructions, it all means the same thing.

So what NES game did you work on?

>> No.3381448

Bigger devs with lots of resources like Konami had minicomputers with a 6502 cross-assembler

>> No.3381535

>>3381363
what NES game did you work on anon?

>> No.3381716

>>3381372
He's insulting you idiots for thinking that "assembly code" is both a legitimate and meaningful response and not vague as fuck at all. There's multiple different kinds of assembly for each architecture, but you idiots didn't even specify the architecture.

>> No.3381735

>>3381716
Assembly code makes about as much sense as Java code or C code. Might as well call programming coding.

>> No.3381738

>>3380740
>ITT: underage who speak english as a second code

>> No.3381739

>>3381735
t. Ruby programmer

>> No.3381746

>>3381716
>He's insulting you idiots for thinking that "assembly code" is both a legitimate and meaningful response and not vague as fuck at all. There's multiple different kinds of assembly for each architecture, but you idiots didn't even specify the architecture.
You should be able to figure out that assembly code in this context means 6502 ASM.

>> No.3381749

pretty sure i heard about SNES games being developed on the Apple IIGS

>> No.3381769

>>3381746
>There's multiple different kinds of assembly for each architecture
So which assemblers were popular with NES programmers?

>> No.3381772

>>3381769
what he means is the language itself changes for each type of processor

who knows what program they used to actually assemble the code though, maybe they even wrote their own in-house ones (from what I know, that really shouldn't be too hard, especially with the 6502)

>> No.3381785

>>3381772
Going to be extra clear. This is 6502 assembly:

mwa #dest ptr
ldx #192
do_line
ldy #39
mva:rpl pattern,y (ptr),y-
lda #40
add:sta ptr
scc:inc ptr+1
dex:bne do_line

This is also 6502 assembly:

* = $4000 “Main Program”
start: lda #$00
sta $d020
sta $d021
lda #$00
jsr $1000 // init music
sei
lda #<irq1
sta $0314
lda #>irq1
sta $0315
lda #$7f
sta $dc0d
sta $dd0d
lda #$81
sta $d01a
lda #$1b
sta $d011
lda #$80
sta $d012
lda $dc0d
lda $dd0d
asl $d019
cli
jmp *

//----------------------------------------------------------
irq1: asl $d019
SetBorderColor(2)
jsr $1003 // play music
SetBorderColor(0)
jmp $ea81

//----------------------------------------------------------
*=$1000 “Music”
.import binary “ode to 64.bin”

//----------------------------------------------------------
// A little macro
.macro SetBorderColor(color) {
lda #color
sta $d020
}

>> No.3381789

>>3381785
seems quite a bit higher level than what im using (ca65)

>> No.3381796

>>3381735
>>3381739
Decloaked.

>> No.3381836

>>3381769
probably lost to time desu, or at least obscure as fuck. or developed in house. (6502s were pretty popular at the time and used in a lot of things so wouldn't be surprising)

>> No.3381842

>>3381746
In this context it means the guy who's saying "assembly code" doesn't know what he's talking about. It's just a term he pulled out of his ass and means nothing. Pretty sure that's why the dev guy made fun of him for it.

>> No.3381847

>>3381363
That's interesting. When you mean SRAM, do you mean the whole cartridge used SRAM? It would make sense because the cartridge needs to be easily rewritable (for testing each build), but I wonder how much such a cartridge ended up costing.

>> No.3382051

>>3381847
Yes SRAM, the whole "cart" Yes very expensive. Thousands. But it was the cheapest and best solution at the time. Ever wondered why so many carts used SRAM and a battery?

>> No.3382161

Instead of ripping on the guy who doesn't know what assembly language is, how about y'all do some Googling and learn.

http://wiki.nesdev.com/w/index.php/Nesdev

>> No.3382201

Jesus christ you guys.

1) If it's a real NESdev what he meant was that he himself wasn't one of the guys doing the assembly. He was using the editors and shit, designing the game. Do you think they have Miyamoto writing a lot of code? Writing code is hard and technical and it's better to outsource that to a specialist if possible. Hence "what's that, I don't know that shit at all". If he was trying to pretend he was a dev (always a possibility here), he wouldn't come up with such a response asking what something basic is.

2) Saying it was written in assembly is a perfectly legitimate 3-word answer to give to someone who has no idea how NES games were written. So they weren't written in C or pascal, they were written in assembly. That's valid and interesting and the entire point of saying they were written in assembly. Sure it's a ridiculous basic response, but people like to take part and it doesn't take a second to go through the comments.

>> No.3382202
File: 87 KB, 503x494, 1435438835450.jpg [View same] [iqdb] [saucenao] [google]
3382202

My uncle worked at Nintendo and he told me he programmed NES games by blowing into the cartridge

>> No.3382205

Someone post the scan of the interview where shiggy stands before an insane IBM rig where SMB3 was compiling

>> No.3382260

>>3382202
>>>/v/

>> No.3382825

>>3381749
It's mentioned in the credits for the SNES port of Wolfenstein 3D. I'm not sure if it was used for other SNES games, but it wouldn't surprise me since they both use variants of the 65816 CPU.

>> No.3382849

NES used 6502 Assembly.
Sega Genesis used X68000 Assembly.
SNES used 65816 Assembly.
Master System and Game Boy used Z80 Assembly.
PSX, Saturn and N64 used MIPS Assembly.
Your PC uses x86/x64 Assembly.

If you google any of those terms above + assembly, you can find books on how to program on them.

>> No.3382862
File: 223 KB, 360x360, bemused baby.png [View same] [iqdb] [saucenao] [google]
3382862

>>3382202

>> No.3382880

How was the first programming language invented?

>> No.3382883

>>3382880
With bulbs that indicated on or off.

>> No.3382902

>>3381716
>There's multiple different kinds of assembly for each architecture,
Not really or 1 given architecture, at least in older CICS CPU design. The "api" calls are literally the op codes of the CPU it self, there is (often) no variation. We're not talking about high level languages here like C or FORTRAN.

If you really want to be autimal about it one could just say "6502 assembly"

>> No.3382904

>>3382849
>PSX, Saturn and N64 used MIPS Assembly.
>Your PC uses x86/x64 Assembly.
One can program in Assembly for these, but really, modern shit uses high level languages (like C) for the VAST majority of the work.

>> No.3382915

>>3382904
C only started being feasible in the '90s, though. You had to code in assembler on most 8-bit systems.

>> No.3383000

>>3382201
I was a coder. I was making fun of a bullshitter for using a made up bullshit term.

>>3382915
We were using C by the late 80's. Especially on the Amiga and ST. I'm not saying the games wouldn't have been 100% better if they'd been done in assembly, just that we used C. We wouldn't have been able to churn out so much shit without it.

>> No.3383025

>>3382849
>Sega Genesis used X68000 Assembly.
no

its just 68000, m68000 or m68k

>> No.3383128

Keep in mind that while those consoles use Assembly instructions, they are actually modified versions of consumer-level processors. So let's say, the Master System Z80 uses less instructions than a common Z80.

>>3383025
You're right, X68000 is the Sharp Computer that uses this processor. My bad.

>> No.3383145

>>3382849
The Saturn didn't use MIPS at all, it used a pair of SH2s for its main CPUs. Also, the Game Boy's CPU was more like an 8080 than a Z80.

>> No.3383149

>>3383145
i thought the GB's was more of a freak processor that was both

>> No.3383152

>>3383149
That's kinda what I meant, just that it's closer to one than the other.

>> No.3383443

>>3383000
>made up bullshit term
seriously? You don't get synonyms at all?

>> No.3383463

>>3383443
Let's help that poor anon
https://en.wikipedia.org/w/index.php?title=Assembly_code

>> No.3383491

>>3383000
>made up bullshit term
>doesn't know what assembly is

The irony.

>> No.3383493

I'd be interested in finding out if anyone ever found any tools or things of that nature companies used in NES/Famicom development, like any software they might have used for music in-house, or programming manuals specifically for the NES and not just the more general 6502 (as the NES has a few more features with the 2A03). Even just an idea of what people were using would be cool to know.

>> No.3383497

>>3383000
Most Amiga/ST games used 680x0 assembly though, at least any action game did.

>> No.3383529

>>3383491
it seems like anon was having issues with the term "code" in that context. Still needlessly nitpicky over nothing

>> No.3383541

>>3383529
And yet the actuality of it is that he's a bullshitter who was having issues with the word "assembly" and, thanfully, got enough followup posts to successfully play it off.

>> No.3383543

>>3383541
what's the problem with assembly?

>> No.3383545

>>3383543
Nothing. He just didn't know what it was, as he's not a programmer at all, let alone one working for Nintendo back in the eighties.

>> No.3383549

The programmer of Tengen Ms. Pac-Man said that Nintendo's official manuals sucked and they were poorly translated from Japanese. He said however that it wasn't anything difficult to figure out the NES used a 6502 and he'd already programmed for the Apple II and C64, so it was just a matter of figuring out how all the hardware bits worked.

>> No.3383550

>>3383543
Assembly is for weaklings. Real programmers write in untranslated machine code.

>> No.3383551

>>3383545
that anon knew his shit, he was just needlessly anal

>>3383550
same difference

>> No.3383557

>>3383549
>hardware bits
did the NES have any other bits?

>> No.3383564

>>3383549
I'd imagine the NES is pretty easy to code for against those computers though.

>> No.3383567

>>3383564
why?

>> No.3383587

>>3383567
Lot less overhead plus scrolling is ridiculously easy. Also no sprite multiplexer, that's done in hardware.

>> No.3383593

>>3383587
>scrolling is ridiculously easy
some anon a little back in another thread said the NES can't scroll unless the right MMC is used. Got a chuckle out of me

>> No.3383617

>>3383550
don't assembers literally just translate opcodes into hexadecimal and store them in a binary

>> No.3383621

>>3383617
a tiny bit more than that, but not much, yeah

>> No.3383629

>>3383617
>>3383621
to clean up the terminology a little, the little words are called mnemonics. The opcodes are just numbers. So an assembler turns the mnemonics into opcodes. As for the little bit extra, it picks the right opcode when there are multiple options. For example there are often multiple load opcodes, each of them for a different combination of register, literal or address. In mnemonics you just use the same word for all of them and the assembler will figure out which opcode you meant by reading the arguments you gave.

Some assemblers also may have luxury options, like macros or counters, and practically all assemblers have labels, to take away the burden of address calculation. It's pretty comfortable shit, all in all

>> No.3383631

>>3383629
>to clean up the terminology a little, the little words are called mnemonics. The opcodes are just numbers.
yeah that's a mistake i always make, but it is true

>> No.3383636

wasn't Ecco the dolphin written in C?

>> No.3383640

>>3383636
I heard the 68000 was designed with languages like that in mind, so it's not unlikely.

I think Motorola even gave C compilers to some devs, hence why Marble Madness was done in C.

>> No.3383641

>>3383636
Don't know about Ecco, but Sonic Spinball was.

>> No.3383642

>>3383641
Sonic's Pinball

>> No.3383673

>>3383636
>>3383640
Ecco was written in C, yes. However, many Genesis/SNES games did use straight asm especially if they were action games. I believe at least some Squaresoft titles used C, but RPGs don't really need speed.

>> No.3383675

>>3383673
>but RPGs don't really need speed
what they rather need is a sane state machine. C is really valuable there

>> No.3383676

>>3383629
For example, on the C64, this places a green A in the upper left of the screen.

LDA #$41
STA $400
LDA #5
STA $D800

>> No.3383679

>>3383675
yeah, i imagine keeping track of everything in a RPG (stats, flags) must be fucking awful in asm

nasir still managed to do it though

>> No.3383681

>>3383673
Sonic, Streets of Rage, and most other fast arcade/action titles I'm almost certain were written in assembly.

>> No.3383682

>>3383676
there are two mistakes here
$4000 is the upper left corner, not $400
and you're missing a cash sign on LDA #5

>> No.3383685

>>3383679
On 8-bit computers, some simulations used at least part BASIC code because it's easier to visualize and implement certain algorithms in BASIC. Sid Meier's Pirates! on the C64 for example has BASIC code for most of the game logic while sound/graphics/disk access uses assembly language.

>> No.3383686

>>3383679
>must be fucking awful in asm
They probably still had memos and a roadmap on paper though
If the game is well planned out, I can imagine even "slow" games being fun to program in ASM

>> No.3383689

>>3383679
it's possible if you're disciplined, and managed your data structures very cleanly. The "problem" is merely that the advantages of asm don't apply there, but all the disadvantages do. It's possible to do it despite the nature of asm, not because of it

>> No.3383693

>>3383689
Also
If you have a house full of competent 6502 guys, it's cheaper to let them do their magic instead of hiring C men.

>> No.3383694

Hold on, let me Google it up and then copy and paste from Wikipedia.

>> No.3383695

>>3383682
>$4000 is the upper left corner, not $400
No it's not. $4000 is an empty spot in the middle of BASIC memory.
>>3383682
>and you're missing a cash sign on LDA #5
Usually that's omitted on assembly listings because 0-9 are the same in hex and decimal.

>> No.3383697

>>3383693
you'd think C guys are the cheaper ones, as the language removes a lot of the difficulty

>> No.3383701

>>3383695
>No it's not. $4000 is an empty spot in the middle of BASIC memory.
oh shit you are right, i was talking about $0400

>> No.3383703

The classic 8-bit Ultimas were all written in assembly after Ultima I.

>> No.3383707

>>3383701
$400 is the power on default, of course in machine language games you'll usually move the VIC-II buffer to $4000-$BFFF because there's no character ROM to get in the way.

>> No.3383708

As far as I know, HLLs were always pretty common on PC compatibles from the beginning.

>> No.3383713

I think by the 5th gen consoles, C++ became the norm. Sony even recommended against assembly language in their programming manuals.

>> No.3383716

>>3383713
Right but that's when consoles all went to using RISC processors which are almost impossible to program in asm unless you're a masochist.

>> No.3383718

>>3383713
a rule of thumb is you use the highest level language possible and the lowest level language necessary. And you mix and match languages as you see fit. In general though, compilers nowadays will most likely do a better job than you when translating logic into opcodes

>> No.3383719

>>3383713
>I think by the 5th gen consoles, C++ became the norm
As it did for PC games. Other than 1-2 silly exceptions like Roller Coaster Tycoon, probably 90% of commercial PC software since Windows 95 has been written in C++.

>> No.3383723

>>3383719
Are you sure about the distinction between C and C++?

>> No.3383724

There's no real performance gain from writing modern PC software in asm because all you're going to doing is calling API functions in between using assembly code for algorithms which can just be implemented easier in a HLL.

>> No.3383725

>>3383719
>probably 90% of commercial PC software since Windows 95 has been written in C++
kind of. It's common now, and has been for a very long time, to write the engine in something like C++, but then integrate an even higher level scripting language, like LUA. Then the vast majority of non-time-critical scripting is done in that language. As comfortable as C++ is, it still has plenty complexity you often don't need. So the scripting languages take on that role.

>> No.3383726

>>3383723
Pre-Windows 9x stuff very often did use C, in fact it was the norm for Windows 3.x and late DOS software. From Windows 95 onward, C++ became the standard.

>> No.3383729

Back in the 8-bit era, adventure games commonly used a scripting language and not assembly. For example, most Infocom/Sierra/LucasArts games were written this way.

>> No.3383732

>>3383729
even crazier, infocom text adventures ran inside a virtual machine

>> No.3383734

>>3383729
Yeah actually when Ron Gilbert first started working on Maniac Mansion (on the C64), he decided the shit was too complicated for assembly language.

>> No.3383737

>>3383734
It kind of is. Maniac and Zak are among the most technically complex games on the Commie.

>> No.3383740

>>3383726
DOS4GW shipped with the Watcom C/C++ compiler so most games that used DOS4GW were written in that.

>> No.3383748

>>3383734
Nothing is too complicated because it's assembled to machine language in the end anyway. It just isn't pretty.

>> No.3383749

>>3383748
people using the word "complicated" refer to the human producing the artifact. Most people interested in computing understand turing completeness

>> No.3383750

>>3383718
>And you mix and match languages as you see fit
Nintendo did this shit up until the NDS. Dare I say most of Nintendo's first party NDS games were made in C (or C++) with some ARM pumped in between manually.

>> No.3383752

>>3383737
>>3383734
>implying Maniac Mansion is as complicated of a game as Turrican
Really, Americans?

>> No.3383754

>>3383750
it's common even today. There are things you can't express well in C++, or when you know you can make assumptions the compiler can't make. You just code up a brief routine or two in a lower level, and integrate it with the rest. Likewise, you provide hooks for higher levels, so you can leave C++ as soon as possible (possible here means the performance impact or negative side effects become small enough). It's not uncommon for a modern game to use a handful different languages

>> No.3383756

>>3383752
the state machine of an adventure or rpg is a hell of a lot more complicated for a human to understand than the game loop of an action game. It is not a statement of gameplay complexity or difficulty

>> No.3383758

Didnt someone make a modern devkit for the Atari 2600, that made making homebrew games easier? Wouldnt that be possible for the NES?

>> No.3383763

>>3383758
It's already as easy as it will go. You got your assembler, you got super comfortable emulators, you got editors with syntax highlighting. As far as NES development is concerned, you're in the high end. If all of that is not enough, you can whip out a managed language like C# or Java, code up an editor, say, for levels, or sprites, or a statemachine, and either let that editor produce binary output right away, or asm output you can throw your favorite assembler at. You won't be able to get rid of asm, not without greatly reducing the abilities of the system. You can push it into a dark corner though, if you insist.

>> No.3383767

>>3383754
For now, I guess.
With the advent of PS4, who knows how long until we see consoles just becoming generic x86 machines.

>> No.3383772

>>3383767
the processor doesn't matter for this, this kind of development happens on all machines. It's simply that the lower the language is, the more control you have, but the more complicated it gets. So, depending on the mechanical complexity of your game and code, and the realtime requirements, you pick your languages on a sliding spectrum between assembly and interpreted scripting languages, and you try to keep the complex/low sections as small as possible.
It's not a new concept either. It applied during the NES days and earlier. Only, at that time the sliding window for game devs was firmly stuck at "asm and barely higher", because processing power was in short supply, and, due to memory constraints, games were simple enough, that the cost of asm (insanity due to complexity) was low

>> No.3383776

>>3383772
>the processor doesn't matter for this, this kind of development happens on all machines
I want to believe this but I can't. Can I get a source or a developer anecdote of them going ASM-tier low-level on PS4/Xbone/WIIU?

>> No.3383784

>>3383776
>Can I get a source or a developer anecdote of them going ASM-tier low-level on PS4/Xbone/WIIU?
it does not happen, or if it does, it's super rare. These processors are excessively parallel, have out of order execution and all that funk. A modern compiler will take advantage of all these things, and you're very likely to write worse ASM than the compiler will generate.
Remember how I said the sliding window for developers was firmly stuck at asm during the NES days? It simply shifted to the point that with extremely few exceptions it's just not any useful to drop as low as asm. You will find it's still used on embedded systems, IoT stuff.
When I said the processor doesn't matter for this, I meant that this is a development regardless of the architecture or target device. Consoles were never special in that regard. They simply had a hardware composition that favored asm development to some degree. The lack of asm development does not make something a "generic x86 machine". There's nothing magical about asm, or its lack. It's a language like all the others, a tool to help the human translate their thoughts into something the computer understands. It had its days, and it's becoming less useful on modern machines. Simple as that. You're still free to use it. Even the latest powerPCs and x64 chips come with a fat asm manual. You'll quickly find out though, you need to be a specialist to get anything even remotely useful out of it. Compiler developers are these specialists. I'd rather specialize in game dev, and use the tools at my disposal to be as effective as possible.

>> No.3383790

>>3382201
>Do you think they have Miyamoto writing a lot of code?
Miyamoto can't code he's a appliance designer by trade.

>> No.3383809

>>3383784
>It had its days, and it's becoming less useful on modern machines. Simple as that. You're still free to use it. Even the latest powerPCs and x64 chips come with a fat asm manual. You'll quickly find out though, you need to be a specialist to get anything even remotely useful out of it.

>>3383724

>> No.3383810

>>3383809
you don't have to call api functions. And yes, of course it's easier in high level. The point of asm is control. The draw back is, if you don't know what you're doing, the automated systems will outperform you, and all that control was for nothing

>> No.3383816

>>3383810
>you don't have to call api functions
On modern OSes you sure as hell do. You think Windows 8 lets you directly bitbang hardware?

>> No.3383818

>>3382880
I'd imagine the first assembler would have been machine coded in binary on punched card or something. Then from that, a language compiler could be written.

>> No.3383821

>>3383816
when you go asm, you don't need Windows. Just bootstrap yourself and have fun. Also, while you can't bitbang, you certainly can do your computations purely in asm. The apis only pop up when you need to read stuff from outside, or write stuff to outside

>> No.3383825

>>3383821
That's fine for a hobby project, but you can't release commercial software like that in 2016. This isn't the Apple II days.

>> No.3383827

>>3383825
>That's fine for a hobby project, but you can't release commercial software like that in 2016
where did I suggest otherwise?

>> No.3383842

>>3383497
You are absolutely correct, but it scares me sometimes how many big name games were put together in AMOS which was like the Unity of the day.

>> No.3383845

>>3383145
>>3383149
We used to call it a Z40. It had less instructions than a Z80 and everything took longer to execute :)

>> No.3383850

>>3383842
why does that scare you?

>> No.3383851

>>3383697
Back then the C guys were usually professionally trained and desired by business so they were expensive. Whereas 6502 hackers were all bedroom coders and willing to work for pizza.

>> No.3383852

>>3383851
cold hard pizza, the one and only currency

>> No.3383862

>>3383851
Wrong. Most commercial software on the Apple II, C64, and NES was written by professional coders. Bedroom coders would more describe TRS-80 CoCo software.

>> No.3383865

>>3383821
>Also, while you can't bitbang, you certainly can do your computations purely in asm
Pointless since computations are easier to do in a HLL.

>> No.3383872

One of the guys who ported M.U.L.E. to the PC said that it was easy to convert games between the Atari 8-bit and C64, but IBM PCs were from another planet altogether.

>> No.3383884

>>3383862
Professional coders, as in they were paid to do the work. However they would have learned by hacker tradition and as such have no formal qualifications. C was not common in bedroom coder circles because C compilers were expensive and didn't run on the 8bit computer you were learning on.

C programmers were taught in universities with the intention of grabbing big salaries in big companies. They wouldn't be willing to work on the contract rates that C64/Spectrum/Amiga "coders" had to put up with.

>> No.3383887

>>3383884
>he's shocked that video games brought in less money than Lotus 123

>> No.3383894

>>3383887
>>3383884
Though actually Lotus 123 (the classic versions) were coded in straight x86 asm.

>> No.3383907

>>3383894
Not gaming-related per se, but the NO$SNS emulator was written in pure x86 too.

>> No.3383910

Lotus and WordPerfect both used x86 asm until they went to supporting extended memory and then started coding them in C.

>> No.3383924

>>3383887
Atari was a Fortune 500 company in 1982.

>> No.3384068

>>3383443
I get synonyms. Clearly you don't. "code" isn't a synonym for "language".

>>3383463
Thanks for that. As you can see even wikipedia considers it the wrong term.

>>3383491
Damn your thick.

>> No.3384147

>>3383865
>computations are easier to do in a HLL
easier? sure. Faster? You know the boundary conditions and can reuse values or skip checks

>> No.3384150 [DELETED] 

>>3384068
>"code" isn't a synonym for "language"
Here's your chance to teach us infidels why assembly is not an encoding

>> No.3384161

>>3384068
>>3384068
wikipedia, unlike you, understands what people mean. Oh, and just for fun:
>Assembly language may also be called symbolic machine code
>The conversion process is referred to as assembly, or assembling the source code
So apparently people that are not you understand that you can use the assembly language to write source code. Source code written in the assembly language would be assembly code for short, to all but the most intellectually dishonest people.
Kind of a shame you pissed on the other points you may have had with your hubris. Now you just look like a grumpy old shit yelling at kids to get off his lawn.

>> No.3384184

>>3383707
>>3383701
>>3383695
>>3383682
>>3383676

So, you guys still working on anything for the C64 or is this just random memory?

>> No.3384213

>>3383924
Console games are a mite more profitable than computer games desu.

>> No.3384251

>>3382202
Fucking Kek

>> No.3384284

Assembly code is a correct and accurate way of describing work done in assembly. You also say Java code and html code. That guy is probably a joker who stated some things he found somewhere else for credibility. You'd be surprised how elaborate some trolls get online.

>> No.3384302

>>3380740
>tfw the last class I took was ARM based ASM
>tfw the final was code Q*Bert from scratch in pure ARM ASM

It was beautiful, my partner and I were one of 2 teams that were able to get color graphics working, and the only one to implement a cheat code

I should have my notebook full of planned out data structures and sprites somewhere

>> No.3384340

>>3383752
>it's an "australia-kun tries to fuck another thread up for days" episode

>> No.3384349

>>3384184
im learning

it's surprisingly easy to get a decent environment setup if you have cygwin, cc65 (which comes with an assembler), an editor and an emulator

you can automate the whole write-build-run cycle really easily

>> No.3384358

>>3384349
>im learning
why? And why that system in particular?

>> No.3384364

>>3384358
6502 is literally the only processor i kind of get

and the C64's pretty well documented, unlike the NES which is mostly all reverse engineering efforts, it also takes a lot more effort on the NES to put a character on screen since there are no characters in ROM by default (obviously)

>> No.3384964 [DELETED] 

>>3384161
>kidlogic
Maybe I look like a grumpy old shit to you. You look like a narcissistic millennial to me. So stereotypes of our respective generations I guess. The difference is I get paid big bucks to write assembly while you fill out job applications for McDs.

>> No.3385003

>>3381372
>>3381394
>>3381404
There is no "assembly code" you numbnuts. There are a ton of different architectures for assembly like 6502, x86, MIPS, etc. When mentioning assembly, specify what architecture you're talking about.

>> No.3385004

>>3385003
we're obviously talking about the NES

6502 is implied

>> No.3385508

>>3384147
The speed bonus is insignificant today

>> No.3385517

>>3385508
let the developer and their performance test decide that. Unless you know something about their use case and their available hardware that they don't?

>> No.3385551

>>3384964
>muh lennials

>> No.3385557

>>3385004
You're wasting your time spelling it out for him, anon. Not understanding context is a sign of autism

>> No.3385559

>>3384364
C64 is probably the easiest 6502 system to program for other than maybe a Commodore PET.

As for the NES, one thing that makes it a headache to program is that you have to do all graphics manipulation during the VBLANK which is extremely timing-sensitive and requires you to pay attention to clock cycles.

>> No.3385572

>>3384364
How to put a character on screen with a C64:

>poke the ASCII value into $400
>optionally, poke the color value into $D800

How to put a character on screen with a NES:

>create tile graphic for the desired character
>place it in CHR ROM (make sure it's in the section designated for tiles and not sprites)
>set up palette information for the desired color
>copy character into video memory during the VBLANK

>> No.3385581

>>3385559
The Apple II's gotta be pretty simple, right?

>> No.3385582

>>3385559
hm, i should've really just said "it's simply easier to get going"

the commodore was intended to be fucked around with, the NES really wasn't unless you were authorized by nintendo
>>3385581
from what i've seen, it seems on par with the C64

>> No.3385587

>>3385581
>>3385582
Apple II programming is easy if you just stick to text mode, but anything with sprite animation or sound is a serious beeatch and requires you to be really, really good at 6502 asm. It gets even worse if games need multiloads because you'd generally need to use a third party DOS or else write your own disk code (DOS 3.3 is too slow).

>> No.3385641

>>3385004
Why is 6502 implied? The NES used an RP2A03. If it were implied then that'd be 6502 assembly or 6502 assembly language.

>> No.3385643

>>3385641
don't be so pedantic

the 2A03 is literally a 6502 clone without decimal mode and with sound generation instead

>> No.3385957

>>3385587
Another nuisance with the Apple II is that checking for VBLANK differs with every model. The II/II+ use one method, the IIe another, the IIc and IIgs still another. It's probably unique among computers and game consoles in that there's no definitive method of testing for VBLANK. Some games can detect what model you're running on and adjust accordingly, most just ignore VBLANK sync entirely.

>> No.3386034

I asked this in /agdg/ but this seems like a better place right now

If I've never really made a game before outside of RPG Maker and Game Maker, how pie-I'm-the-sky would it be for me to learn enough on my own to create a game that I can burn and play on a Sega CD?

>> No.3386043

>>3386034
You would need to invest 6 months of your life to learn the necessary skills and tools.

>> No.3386046

>>3386034
Way out of your league. You'll want to learn how to actually program first.

>> No.3386048

>>3385641
Like someone said above, the console versions of those processors are basically clones of the consumer version with stripped-down features (and some hardware-specific additions).

>> No.3386208

>>3385559
>one thing that makes it a headache to program is that you have to do all graphics manipulation during the VBLANK which is extremely timing-sensitive and requires you to pay attention to clock cycles.
As long as you're doing simple homebrew stuff you wait for vblank and get going, no further timing issues, or cycle counting. The chance that you'll run out of the vblank period is marginal. Once you do, your stuff is complex enough that you're aware of pitfalls and schedule around them. Instead, the reliance on vblank is excellent for gaming, as it takes care of your game loop. You just do whatever shit you need to do in an iteration, then halt the machine. vblank fires, and you're back on the next round

>> No.3386212

>>3385643
>don't be so pedantic
pedantry is all that anon has left, after maneuvering themselves into a corner with their assembly code smartass-ing

>> No.3387775

>>3383636
>C?
No, D. For Dolphin.

>> No.3387793
File: 61 KB, 491x364, flappolol.jpg [View same] [iqdb] [saucenao] [google]
3387793

>>3385641

i like you, angry old programmer man

>> No.3387795

>>3381429

i lol'd