I love writing 6502, or maybe just 8bit assembler in general . I got hooked after writing some NES games. Writing efficient (NOT “performant”) code that should not be possible is very addictive. Stay away if you value your time
I cut my programming teeth on an Acorn Electron[1][2]. BBC Basic came with a built-in multi-pass assembler unlike the other 8-bits at the time where you'd need to pay for that, so it was easy to tinker by integrating a little assembler for things that were too slow in interpreted BASIC. I used it for things like sprite drawing & movements, and tinkered with many other bits & bobs. Ah, the good old days...
I later used Z80's[3] at Uni for hardware projects, again programmed in assembler (via EEPROM which was less convenient, but we were practising for "embedded systems" development) which was fun too.
The only thing close to the BBC Basic experience was Delphi which supported inline assembly, which I used once to do some bitmap manipulation faster than I could convince the compiler to manage.
[1] a budget version of a BBC Micro Model B for most intents & purposes
[2] and later a BBC Master Series
[3] they basically started life as knock-off 8080s, the 8-bit chip that lead to the 8086/8088, so it'll feel familiar if you've done any old x86 assembly
So I've written assembly in college and love NES games. If I want to get into writing NES games, where's the entry point for me? What kind of learning curve am I looking at?
If you’re competent at x86 assembly, picking up 6502 will be pretty easy. This is a decent jumping point. Check out the optimizations link after you’ve cut your teeth a bit: https://wiki.nesdev.com/w/index.php/6502_instructions
Tools are everything here. Get a good emulator/debugger and assembler.
If as a human C compiler you unrolled a loop, that would be performant, but because you're space limited you do not unroll the loop and that is (memory) efficient.
Lets say you had a 6x8 character cell or a really small sprite for graphics, unrolling the loop would make a copy about 2x faster but would cost about 40 bytes or so.
Not sure if Excel is the best environment for this. Inserting a new line is multiple steps of shortcut keys in Excel while it's just Enter on a text editor.
> Not sure if Excel is the best environment for this
That's part of what makes it wonderful! The impracticality of it, plus it helps to dispel some of the "magic" around assembly. Looking at things like this help you understand that it's just math and transformations, which Excel is pretty great at.
Other things similarly impractical/awesome:
- Ray Tracer in Excel [1]
- Matrix recommendation system in Excel [2]
- Neural Networks in Excel [3]
Personally I never understood matrix-based recommendation systems until I watched Jeremy Howard build one from scratch in Excel [4].
I think ‘real spreadsheet games’ shouldn’t use VBA, but I also think that rules out arcade games with decent UI (you can animate by using iterations, but I think user input would require the user to hit enter to register commands), so, maybe, one should allow some minimal VBA in a subcategory of spreadsheet games that don’t use the spreadsheet’s scripting language)
Edit: I didn’t test it, but it seems using https://support.microsoft.com/en-us/office/cell-function-51b..., one could have a mouse-operated VBA-less Flappy-Bird that reacts to the user changing the width of a column, or use cut and undo to delete or reinsert rows or columns, thus providing user input. That’s workable for some value of workable.
So like, the thing that immediately jumped to mind seeing this is that if you're trying to write assembly for insertion into an existing program having it basically live assemble into byte representation as you work on it is pretty damn valuable for iterating on code while working under space constraints (esp. common on 6502).
It'd be nicer to have this kind of thing integrated into an editor (like vscode) with a live updating view of the assembled code, but I can definitely see myself using this.
>"if you're trying to write assembly for insertion into an existing program having it basically live assemble into byte representation"
This sounds interesting. Could you elaborate on what is meant by "live assemble into byte representation"? What exactly would the workflow be under which you would be doing this?
So imagine you're writing along in high-level language, that doesn't have a built-in assembler. But it does have the ability to store data in memory, and the ability to jump to a location namely the beginning of that data.
That is basically the native environment on many 6502 computers. You have basic, and usually you can call, or something to run a little machine language.
What you don't generally have is an assembler, unless you're on a BBC micro or something really spiffy like that.
You can open the spreadsheet, take me to origin, Constance a few instructions, and there are the bikes you need right there. It might be an 10 bytes or 20 bytes.
So you just typed them right in set up your call statement and carry on.
On these older or smaller computers, people do these kinds of things to get a little bit of speed, but they don't have a huge tool chain, or don't want to complicate call chain get that speed. Really they just want to tell the CPU to do a few things to be done with it.
Another case might be patching a piece of code.
So you reach a point where you need to code up a jump instruction, and then assemble the few instructions you need to make whatever changes going to make, and it returned so that the program may continue.
Open the spreadsheet type in the few things you need copy the bites done
You do have machine code monitors available for a lot of these computers, though. E.g. on C64, if you want that workflow you'd almost certainly have a freezer cartridge that almost universally had a machine code monitor built in.
You'll also have full macro assemblers with built in editors that'll load nicely out of the way that only becomes an issue if you're seriously RAM constrained.
This is really about a single environment that will just assemble a program that will run on that CPU, and it will do so in a really really super accessable way.
There are times when dealing with 6502 computers, and I honestly many small computers, or you just want a little tiny bit of machine code.
Now that said, people have written nice libraries with this thing, that can be called from the basic on Apple 2 for example.
> trying to write assembly for insertion into an existing program
Ah, all that was old becomes new again. One of my projects in university (35 years ago) was to write a pop-up 6502/8080 assembler for DOS. It hooked into the bios keyboard ISR, in a similar way to Sidekick (anyone remember that) and would assemble any code typed into the window on the fly.
The use case was to insert inline assembly code into high level languages without having to leave the IDE/editor.
