/vr/ - Retro Games

Cool

What's your environment for doing this stuff like? I tried getting into NES programming long ago but I forgot what assembler I was using. I should give it another shot.

>>3717458
Right now I'm using NESASM, it's popular over at NintendoAge, but I've debated writing one of my own. And YY-CHR for graphics.

>>3717458
not him, but i use cc65, msys and emacs on windows

it's a pain in the ass to setup but it works well in the end

>>3717446
>not homebrewing with blast processing

Had to put my project on hold for a while, unfortunately. Doing a non-homebrew related commission job right now. Will come back to it once I'm done, I already wrote drivers for the console resources and built a framework along with a bunch of content processing tools.

>>3717776
i could never wrap my head around the genesis security stuff

i think i'm retarded

>>3717786
Security stuff? All it has it a simple trademark security requirement on some models that require you to write the ASCII string "SEGA" to the TMSS register. Gameboy used a similar technique.

>>3717793
yeah, i did all that

maybe it's just GAS acting up and putting extra shit in the binary

>>3718284
>GAS

The GNU assembler? I use asm68k from the PSY-Q dev kit. I also managed to find psylink, the linker from the same kit, after a little digging,which isn't necessary but helps with organizing your project. I've heard of people using the GNU assembler for Genesis dev, but it seems a little overkill to me since you don't need all the general purpose functionality.

If you were trying to display graphics there's a lot of initialization ritual involved with the VDP. You're probably better off trying to do a "hello world" using either audio or just writing to memory and checking it with a debugger.

>>3718369
yeah i use the GNU assembler because since I use linux and BSD I decided that I might as well use the same assembler as the system's assembler

and yeah I realize that printing hello world on the screen is hard, but I remember looking at my program in the debugger and I just couldn't find it, seems like everything was turned into BRK

>>3718370
Hmm, not sure. The Genesis was pretty much a stock m68k, it's not too hard to get a program running. Just make sure you setup the vector table properly and you should be fine. There's a Genesis-specific rom header you need to fill out, too, I'm not too sure what would happen if you didn't, a lot of it's optional aside from writing SEGA (separate from the TMSS I mentioned earlier) and possibly the region value depending on the emulator.

Make sure you keep code word aligned. Most assemblers *should* do that for you automatically, but there should be directives to enforce it if necessary.

>>3718370
>>3718389
Here's the header file from my project, it's probably going to be a mess since there're not code tags on this board:

********************************************************************************
* HEADER.68K
********************************************************************************
XREF UISR,EXTISR,HBISR,VBISR ;ISR.68K
XREF INIT ;INIT.68K
SECTION HEADER
*-------------------------------------------------------------------------------
* VECTOR TABLE
*-------------------------------------------------------------------------------
DC.L $FFE000 ;00 -> INITIAL STACK POINTER
DC.L INIT ;01 -> INITIAL PROGRAM COUNTER
REPT 24
DC.L UISR ;02-25
ENDR
DC.L EXTISR ;26 -> EXTERNAL INTERRUPT
DC.L UISR ;27
DC.L HBISR ;28 -> HORIZONTAL BLANK INTERRUPT
DC.L UISR ;29
DC.L VBISR ;30 -> VERTICAL BLANK INTERRUPT
REPT 33
DC.L UISR ;31-63
ENDR
*-------------------------------------------------------------------------------
* ROM HEADER
*-------------------------------------------------------------------------------
DC.B 'SEGA MEGADRIVE ' ;SYSTEM NAME
DC.B '(C)AGDG 2016.DEC' ;COPYRIGHT NOTICE
DC.B 'DEMO ' ;TITLE
DC.B 'DEMO ' ;TITLE
DC.B 'GM 00000000-01' ;CARTRIDGE TYPE AND VERSION NO.
DC.W $FFFF ;CHECK SUM
DC.B 'J ' ;I/O DEVICES
DC.L $000000,$3FFFFF ;ROM CAPACITY
DC.L $FF0000,$FFFFFF ;RAM CAPACITY
DC.B ' ' ;EXTERNAL RAM
DC.B ' ' ;MODEM
DC.B ' ' ;MEMO
DC.B 'JUE ' ;REGIONS
* EOF **************************************************************************

>>3718398
thank you!

i'll have to get my dev environment set up again sometime

>>3718403
Once I get back to it I'm going to set up a git. I'd like to do some tutorials, too. There's only a handful of resources on the Genesis out there, and most of it's either high level or just outright bad advice. Will be at least a month from now, though.

>/vr/ homebrew general

Let's make it happen, lads

https://www.youtube.com/watch?v=jAUgdxCghyM

>>3717446
>https://dl.dropboxusercontent.com/u/686170/demo.nes
Host it on github and make your source available.

>>3721734
I would normally do this, but I plan on implementing this in a full game, and there is a good market for NES homebrews

>>3721791
This is the problem with all homebrew ever. Your code is literally worthless. Watch both this thread and your project die.

https://github.com/gewballs/graviton

NES homebrew you say...

>>3717446
Neat! Are you making a roguelike? Or maybe a rogue-lite, something similar to The Binding of Isaac?

>>3717793
>Gameboy used a similar technique.
Yeah wasn't it the actual bitmap of the Nintendo logo that scrolls down when you boot up? Nintendo owned that bitmap so if you didn't have permission to use it in the game, the hardware would refuse to load. Or something.

>>3722129
Trademark security systems. The names Nintendo and Sega are trademarked, so technically it's trademark infringement to use them without permission. On the Genesis, the VDP will halt if "SEGA" isn't written to the TMSS register within a certain number of clock cycles of the unit starting up, and if I recall the Gameboy has a simple bootloader built into it that'll halt the program if a specific pattern (the Nintendo logo) isn't in VRAM at a specific time following the console starting up.

Was challenged in court and the judge declared it a gross misuse of trademark law, so they don't have any legal bearing under US law. It's perfectly legal for unlicensed games and homebrew to use their trademarks to boot their programs.

>>3722141
Explains why the GB would sometimes boot up with a corrupted logo, then hang. Any other console would simply not boot at all.

> running random ROMs from the internet (linked from 4chan thread, of all places)

I wouldn't do that. Even an .nsf music file starts a limited emulation engine, and then this happens: http://scarybeastsecurity.blogspot.com/2016/11/0day-exploit-compromising-linux-desktop.html

>>3722571
Wait, there's more recent one: http://scarybeastsecurity.blogspot.com/2016/12/redux-compromising-linux-using-snes.html

>>3722067
The idea isn't fully fleshed out, but yes some kind of zelda-inspired rogue-like

>>3721804
>Not selling your homebrew carts to basement dwellers
Some people value their work

>>3722571
Every emulator would have different security flaws, ROMs would be a really inefficient vector for malicious code. You might as well tell people not to view pictures on 4chan because there's been plenty of cases of malicious code embedded in image files exploiting flaws in well known image viewing software.

You could always run them on a flashcart or a virtual machine or a RPi or something if you were really that paranoid. You can also disassemble the code if you wanted, it'd be pretty apparent if malicious code was injected.

>>3722679
I'm not saying don't take pride in your work, but I am saying the only value the work has at this point is generating discussion on an internet forum. Seeing as OP didn't want to share his code, I decided to completely disassemble, decompile, and comment on what he did. You can find it here:

https://github.com/gewballs/unmap

OP used a random walk technique with a xorshift rng for entropy. For each map he walks 4 paths 8 steps long. That's it. 300 lines of assembly completely reversed engineered before this thread could slide off the board as it was close to doing before I posted.

The xorshift is kinda cool, but for something that is fast, the code only produces 1 new bit per function call, and the Read-Modify-Write commands he is using ain't exactly cheap. OP also reads from ppustatus_r far too often I suspect, but as I wasn't really familiar with the NES hardware before I started, I can't say for sure. OP is also missing out on pulse functionality in his joy routine, which is useful. For some reason he put the full program inside his NMI routine which is a terrible design choice, which doesn't even mention his NMI routine is virtually non-existent. Pat yourself on the back for getting an image OP, no joke. Not many people have the know how. But you are far from anything marketable. Try to cultivate interest and share your work. You might learn something, or teach something.

>>3722673
Bingo.

>>3722769
As long as emulators clip their addresses to the right size before indexing into memory (as should be done to properly emulate), the game is effectively sandboxed. I'm sure their are a lot of exceptions though. Knowing that some emulators crash, you could potentially find a way to execute cpu on the game's memory, so you'd have to store x86 in your 6502 or something. That being said, a short analysis shows OP's code is harmless and every bit as gay as him.

>>3724832
One more criticism. Learn to use the Zero Page (Direct Page on 65816). It saves both ROM and clock cycles.

>>3724832
>so you'd have to store x86 in your 6502 or something

In terms of exploiting security flaws, a binary is a binary. Whether it's intended to represent 6502 assembly, pixel data for an image, or a text file is completely irrelevant. The most common exploit is some form of buffer overflow created just by not formatting the input in the way the program expects. Once you can achieve that you can write executable code directly into the program's memory space and potentially into the code segment where it could (potentially) be executed. There's probably tons of ways to achieve this in most emulators since security is pretty low on their list of concerns.

Again, nobody's going to bother because this would be an extremely inefficient and easily detectable vector. Even if someone did, the code being executed would still be somewhat sandboxed by the OS since it's unlikely an emulator is being ran in administrator mode or the like. You wouldn't be able to install something like a rootkit this way unless you were also able to take advantage of some security flaw in the OS itself, and if you have access to that kind of information (prior to it already being patched) you're definitely not wasting your time injecting malicious code into ROMs.

>>3724832
>>3724843
>>3724948
What's all that mumbo jumbo you nerds are spewing?

>tfw too stupid to understeand what you fucks are saying

>>3724948
Good stuff anon.

What resource would you recommend for (properly) learning 6502? I know some x86_64 already. Been interested in NES and 2600 homebrew for a bit.

>>3724973
Who knows, I'm not a 6502 programmer. Was just pointing out that a "malicious NES ROM" wouldn't involve any 6502 assembly, it'd literally be some trash data followed by a natively executable program that hijacks the memory space of the emulator itself.

>>3724832
I guess you got me, good job on the reverse engineering. You've got a talent.
The rng is a 16-bit maximal length lfsr, it was the last thing I implemented, which is why it isn't well optimized yet. As for the zero page, the map doesn't live there because once more game elements are implemented, it's going to need much more than 1 page of RAM.

>>3725085
Oh fuck. replied to wrong anon. Meant for >>3724832

>>3725993
You are absolutely right.

>>3725674
Yeah, I had never used that kind of RNG before. It seems like you could get 8 full bits with each call after reading about them online, which is a lot better than 1 bit. Not important, but to optimize the rng do the shifting on A and EORing on the RAM address; shifting on a RAM address reads the data, modifies it, and writes it back, all without you monkeying with LDA/STA, which is a good thing for onetime usage, but gets expensive for multiple shifts in a row.

OP, know your medium. The value of a homebrew these days lies in things that aren't easily copied. This usually means a cart, box art, and manual. It gives a more complete experience than downloading and playing the game, not to say people won't immediately dump your cart and upload/download it. If you want security, you'd have to implement your own mapper in hardware that no emulator knows about (actually pretty easy). Otherwise realize that people like me exist out there who can read machine code like an open book. I have no intention to do anything with what I learned, but I do like to peek where others can't.

>>3726084
The fact that people even collect NES homebrew carts is really nice. I actually already have a guy that will do the cart, and another that will do the box art and instruction booklet, for a different homebrew I made.

>>3726084
Unless you do something special in the mapper it will be easy enough to reverse engineer. It's probably best to give it additional functionality or add an extra chip anyway. You could stick in an FM chip and do your sound through that. No one would want to play without sound and it would give the appearance that it was an extra feature as opposed to a way to stop people from stealing some cunts precious indie shit.
Of course if the game is so meh that no one would bother even dumping it it's not an issue.

>>3718419
If you start doing genesis tutorials set up a patreon and let people know. Guaranteed you'll get some support. A lot of us would love to improve our gen skills. And tutorials would be much welcomed!

>>3726763
>patreon
fuck off back to tumblr you fucking retard.

>>3726776
>patreon somehow equals muh tumblr boogeyman

oh suck a dick drama queen. How else you wanna fucking pay someone who you appreciate. Fuck I though /vr/ at least was safe from you cunts.

>>3726084
>Otherwise realize that people like me exist out there who can read machine code like an open book.

Excuse me, your e-penis sticks out of my monitor, and I'm not sure if I should suck or bite it.

Gonna use this thread to ask this question: does anyone know what utilities were used to develop NES games during its lifetime? Does anyone like have pictures or videos

>>3726742
You need to mod the NES to get on-cart extended sound. It's a simple mod, just soldering a wire between two pins I believe, but it still needs to be done.

>>3726957
>You need to mod the NES
No you don't. You need to make a connection between pin 3 and 9 on the EXP port. This could be done with a small optional extra jumper pack. Tangible, unique, independently useful. Hipsters who are too stupid or autistic to mod their console would buy the game just for that part.

>>3726957
Not needed on the Famicom dumbass.

>>3727209
Take it easy on the lad. Not his fault his mom won't let him user her credit card to order a to from Japan twice his age.

>>3727209
And is that the NES? I can play my NES games on it? Oh I can't, because it isn't the NES.

>>3727643

Actually yes, you can. Just get a 60 to 72 pin adapter and you're good to go.

>>3727882
You're so desperate to show off your knowledge of the Famicom that you're missing the point.

If you make a homebrew game for the NES (not the Famicom) with a custom sound chip, you need more than a cartridge to use the sound chip.

Also I've never heard of a NES to Famicom adapter, and it would be pointless anyway because the NES is superior, external sound issue aside, which can be resolved with little difficulty.

>>3728018
>the NES is superior
This is what ameriblob nostalgiafags actually believe.

>>3728018
Not the anon you replied to but it seems you're the one who's so desperate to show off your lack of knowledge. Just because you never heard of something in the short time between learning about the NES on an LP and shitposting here doesn't mean it doesn't exist. You're a fool and a tool kiddo.

Hey lads, I'm interested in some Mega Drive/Genesis homebrew dev, been looking around the internet for various information about the system and m68k assembly, but I'm not quite sure where to get started and the thing seems a little bit overwhelming.

Does anyone happen to have any recommended tutorials/guides to MD/Genesis development? Any tips and advice are appreciated.

>>3730605
I learned 68k on the Amiga which had much more information available at the time than the MD ever did. Depending on your goal you probably don't need that though. You can write your game in C or even BASIC and just use asm where needed. Which is probably nowhere for a first off home brew.

>>3730690
i wonder if in-line assembly would somehow be less optimized/bigger

>>3730690
Thanks, using C would definitely make it much easier for me. I was thinking it might be a bit too slow for such a weak system but I suppose the compilers are good enough if I'm not doing anything too fancy. I'll try looking more into that

>>3728018
>Also I've never heard of a NES to Famicom adapter

http://www.stoneagegamer.com/nes-to-famicom-converter-72-pin-to-60-pin-en.html

>>3730605
http://dev-docs.atariforge.org/files/Asm_Lang_Prog_68K_Family.pdf

I don't know if it's the "best" book, but it doesn't assume much prior knowledge. Assembly languages are pretty simple. There's also the official documentation which goes into way more detail than you'll need, but could be useful as a reference:

http://www.nxp.com/assets/documents/data/en/reference-manuals/M68000PRM.pdf
http://www.nxp.com/assets/documents/data/en/reference-manuals/MC68000UM.pdf

As far as the Genesis itself goes, you have the official documentation:

https://emudocs.org/Genesis/sega2f.htm

but it's absolute shit. Your best reference would be these:

https://emu-docs.org/Genesis/gen-hw.txt
https://emudocs.org/Genesis/Graphics/genvdp.txt

Just with that you have more info than most developers had access to when the console was still relevant. It's plenty to write a game.

I'd recommend the emulator Exodus for testing. It's not the fastest or more stable emulator, but it's supposedly the most accurate and it has tons of debugging features.

>>3730697
C is fine if you want to go that route. Yeah, there's some overhead, but the Genesis can handle it unless you're really pushing the system. A lot of official releases were written entirely in C, including Ecco the Dolphin.

I think there's a project out there with a C library for the console which could save you some time, I never really looked at it though since I'm fine with m68k.

>>3722141
any idea how Robopan bypasses this and displays the "Robopan" logo at boot?

>>3731232
Never heard of it. Closest I could find was Robopon for the GBC? I tried running it in an emulator set for GB mode and it showed the standard Nintendo logo. If you mean in GBC mode, I don't think GBC games had any specific requirement like the GB.

>>3730693
Th assembly will compile pretty much the same no matter what. You'll have some overhead for the c or basic stuff. Maybe 10-15k or so, not much.

>>3730697
The C compiler will probably generate faster and more efficient code than you could write yourself in asm. They're pretty good.

>>3731386
>The C compiler will probably generate faster and more efficient code than you could write yourself in asm. They're pretty good.

That's true for modern architectures like x86 and ARM. It's not true for older architectures like the 6502 or m68k. Mainly, there's a lot of unnecessary overhead involved in C function calls. That overhead is about the same no matter what architecture you're talking about, but in relation to total processing power it's virtually negligible on a modern CPU whereas it's a significant chunk of instruction cycles on an older CPU. Any kind of program-wide compiler optimization benefits are completely wiped out by the function call overhead.

Also, compiler optimizations are architecture specific. There's been millions of manhours put into optimizing x86 and ARM compiler optimization. m68k compilers... not so much.

The m68k is right at that point where yeah, you can do an entire game in C if you want to, but you're delusional if you think it's going to be faster and more efficient than the equivalent handwritten assembly. The question should be, are you even making a game where you're going to be counting cycles. On the Genesis, unless you're doing something crazy, it's very unlikely that your general game logic is pushing the console in the first place so a lot of frames you're just sitting around waiting for vsync anyways.

>>3731403
It's true for 68k. There's been a lot of time put into optimization. gcc will absolutely generate more efficient code than someone who's just learning assembly.

>>3730896
>>3730903
>>3731386
Thanks a lot guys, I really do appreciate the links and the tips, gonna try making something happen.

>>3728018
>NES is superior

Well that's patently false.

>>3731435
Look, you can't really argue that C code will be more efficient than assembly on the m68k. This was already decided decades ago. There's simply not enough benefit compared to the amount of indirection involved. Every C function call involves a couple levels of long word indirections, in assembly you can usually get away with a simple short branch to a label or a word branch to a subroutine. A C function call typically involves pushing all the arguments to the stack prior to the jump, jumping, creating a second stack pointer for your local workspace, popping your variables off the stack, then finally getting to work. In assembly, you can potentially skip almost all of that if it's not necessary for that specific task. C also tends to be very heavy on these function calls, you're doing lots of them. In m68k assembly you tend to program more towards simple branches when possible.

I could go on, but that's really the bulk of the issue right there. On a modern architecture, who cares - you're talking hundreds or thousands of megahertz and blazing fast memory and caching and all kinds of stuff, the benefits outweigh the costs. It's really hard to make that argument on the m68k.

And again, don't worry about efficiency. It's EXTREMELY unlikely that you'll be pushing the Genesis. Lots of retail games were programmed partially or entirely in C. If you like it, then use it. Game logic is won't be your bottleneck unless you're doing demoscene tier stuff with software sprite rotations and scaling and 3d and shit. Any issues will probably be during your draw kernel and what you can fit into a single vblank, which is more limited by the VDP and DMA speeds than it is your code.

>>3731446
Oh, and that just applies to the m68k. Don't use C on a 6502 processor. On the NES you can get away with C for like a hello world or the like, but you don't want to do a game in it. Hell, you don't even want to call subroutines on the NES if you can avoid it, just branch to labels if possible.

Atari 2600, forget C even exist. On the Atari you are, in the most literal way, counting instruction cycles. I mean that exactly as it sounds, that's actually how you draw things on screen at the correct horizontal position, you wait for a horizontal sync and then you count CPU cycles and map that to "how far has the electron beam traveled in this many microseconds" type of crap. Absolutely impossible to do that in C.

>>3731262
https://twitter.com/robopanda777
this dude

>>3731470
Hmm, I'm not sure exactly what I'm looking at? Does it use original Gameboy hardware? If so, that means they replaced the bootstrap ROM. If it's emulation then it'd pretty much be the same thing but in software.

I was thinking the game had to write the logo to VRAM, but I reviewed the bootstrap code and it looks like the game just has to have the Nintendo logo data in ROM at a specific location and the bootstrap code automatically reads that, compares it to the logo data stored in boostrap ROM for a match, then displays it. The game code itself isn't actively involved aside from storing a copy of the logo data. So a custom bootstrap would just skip the security check and do whatever it wants.

>>3731486
http://gbdev.gg8.se/wiki/articles/Gameboy_Bootstrap_ROM

Some info on the topic. It's a little bit of code stored on a ROM chip in the Gameboy itself that runs prior to the game being loaded.

>>3724963
They're talking about magic

>>3726838
Do both you naughty girl.

>>3731446
Of course I can. I've done optimization of C compilers for 68k and can assure you that what we have now will generate far better code than a novice writing in assembly. You're focusing entirely on your understanding of function calls and your understanding of how code should be written. You don't have to write code that way. Even if you do the compiler may still be able to fix it, if it's a common mistake it knows how to deal with. And you're completely ignoring all the other areas where optimization is done.
It's exactly because the 68k is limited compared to later processors that so much effort has gone in to optimization. As long as you avoid 80's compilers you'll get decent results, even if you don't know how to code efficiently for the architecture.

>>3731439
it can run games from the two most important regions (NA and Japan) with very little effort

>>3732096
And the FC can do that with no effort. Checkmate burger boy.

>>3732712
enjoy those wired in controllers, one of which is missing a start button

>>3732712
enjoy that rf output, with an extra side of "jailbar" noise from a circuitboard with poorly placed traces

>>3732028
I don't know what to tell you, man. Ignoring the absurd claim that you're some kind of professional C compiler author for the m68k, you're just plain wrong. Feel free to use C all you want, it's perfectly fine for typical homebrew on the console, I just don't understand why you're pushing misinfo that C compiles to more performant assembly than handwritten assembly here. You probably read that in a book in relation to x86 processors, in which case it's absolutely correct, but it simply doesn't apply to every and all CPU architectures.

And stop with the "novice writing" stuff, that's just moving goalpost garbage so you can pretend to justify any argument.

>>3730605
Hey anon, this is the guy who ripped apart OPs code.

So you want to get into hacking on old consoles? I don't have experience with the Genesis or 68k, but once you know how one of these old systems works it's not hard at all to pick up other ones because they all follow the same pattern.

Here's what you need to understand to start hacking:

0) hex
1) assembly
2) system architecture
3) how a game's program is structured

>0) Hex
Learning hex and being able to quickly convert between binary and hex is an indispensable (and easy) skill, but it's also one that you just pick up over time. Being able to go from bin or hex to decimal isn't nearly as important (or easy), but still useful.

>1) Assembly
Unlike the other anon's advice, skip C compilers. Whereas the 68k has been a work horse for a long time and compilers are probably pretty good for it, by actually learning assembly, and then learning how C is mapped to assembly, you unlock the magic behind your computer and become a MUCH better programmer because you can claim to know EXACTLY what is going on inside your machine. An entire thread could be dedicated to this topic, but I can point you to some important highlights. Learn about the following:

+The three broad categories of instructions : data movement, arithmetic, and program flow
+CPU Registers : These are the internal CPU memory locations that all computation takes place. Different CPUs have different designs, but generally you have the Program Counter (PC, tells you where the next instruction to be executed is), some general purpose registers for anything (often called accumulators), and a Stack Pointer (S, points to the next place on the stack, a special hardware-implemented data structure used for function calls and temporary memory storage).

>>3733086
...cont...

+Vector : This is a special area of memory set aside for storing the start of your program (usually called the RESET vector), in addition to some other specialized programs. When RESET happens, the PC is loaded with the address found at the RESET vector.
+ Interrupts : Events that can temporarily change the flow of execution in response to time critical shit, such as vblank's NMI (see below)
+Status register : this tells you about results of recently executed instructions (ie was the result negative, or zero, or did it produce a carry, etc). Sometimes the CPU's behavior is also set from here.

>2) System architecture
this is were you go out and download either a Genesis dev manual or scour romhacking.net for useful docs. These docs tell you how the CPU is connected to various memories (RAM, video RAM, Audio RAM), and also how to interact with specialized hardware (GPU) through special memory locations called "memory mapped I/O registers". These docs will also tell you about graphics formats and audio formats used for your system.

>3) Game structure
A video game is simply a loop that tells the GPU it controls how to draw the next frame of the game and then waits for an opportunity to update the GPU. You need to understand what vblank is (a period in TV tech that nothing is being drawn to the screen), why it's important (VRAM can only be modified when the GPU isn't reading from it to draw the screen), and how it fits into the code (vblank triggers an interrupt called an Non-Maskable-Interrupt (NMI) that is used to execute the GPU update code).

Clearly this only scratches the surface, but you should have enough to orient yourself.

Use this thread to ask question you may have.

(btw, if anyone in here hangs out in the /rhg/ and the old "megaman series" of what a computer is and how to hack, plz post it. It was a gold mine of useful shit for beginners.)

>>3733037
> I just don't understand why you're pushing misinfo that C compiles to more performant [68k] assembly than handwritten assembly here
The dude you are criticizing is probably right to a degree. The 68k has 16 general purpose registers, and a compiler would have a good chance to produce high quality output based on register analysis.

Now if we were talking about the 65816 or 6502, that would be a different story. It only has 3 general purpose registers, and 2 of them have important roles and severe limitations. No way is a compiler going to produce better output than a skilled programmer.

Also, with static allocated memory and static analysis, you could potentially avoid using the stack for most function calls (besides pushing the return address of a subroutine call). Embedded systems have tighter constraints placed on them, and compiler authors aren't deaf to those needs (although you may have to be careful with your choice of compiler and its settings, as well as carefully examining its output).

>>3733037
You're the one moving the goal posts champ. The 68k discussion started here >>3730690. You might want to read what you're replying to.
Enjoy ignoring the absurd claim that everyone here isn't as young and inexperienced as you. tl;dr project harder

>>3721804
>https://github.com/gewballs/graviton
Too bad it died.

>>3722067
>roguelike
>rogue-lite
Literally the same thing

>>3735273
Sorry, buddy. PhD got in the way. One of my New Year's resolutions is to complete that fucking assembler I was designing and make it available with a guide on how to make a simple game. Finishing Graviton would be the step after that.

Honestly, I really want to throw together a game I would be proud to put on a cart and box up with a manual. I would make anything I write available online for free, source included. If I pace myself right this year, it could happen, but that's being pretty ambitious. I need people to bounce ideas off of to get a good game design plan going...

>>3735273
Goddamn it. I just loaded it up for the first time in ages. Why didn't I finish this?