Xrhrft

6502 assembly is a language meant for humans to compile it themselves, not compilers. Its an older Assembly that powered the olden days of computing and consoles such as the NES and Atari 2600. I want to make an executable file that you can download and run without any other software. In short, all I want to know is:

• Can I compile 6502 assembly into a stand alone application, preferably for Windows?

Thank you for your time.

As with so many things, maybe. Assuming that "Assembly 6502" is a full 6502-compatible assembly language:

• If you assemble an entire bootable image and burn it into an EPROM (or equivalent) and install that in a 6502-based system, then the answer is yes. The typical alternative would be to assemble just an application and then run that (via ROM cartridge, disk, load from tape, etc.) using whatever operating system exists on the 6502 system, but technically that would use "other software" as operating systems are "software".


• You can't make a fully executable program file for Windows, simply because Windows doesn't run on a 6502 CPU and the program needs to be compatible with the CPU. You could run it in an emulator of some sort that is running as an application inside Windows, but then it is most definitely not "without any other software"

In theory, yes. You can translate anything in anything else. In practice, it's hard to do -- the plain assembly language (like any assembly language) only knows instructions that do one of four things or a combination of them:

• arithmetic operations


• read a memory cell


• write a memory cell


• check and/or modify some internal CPU state (this includes jumping)

But any meaningful program will also do some I/O ... and the CPU (which defines this language) has no idea about that. So, the way this is done depends on the concrete target system as a whole, e.g. on a C64, you would program the VIC-II chip for screen output. A "translator" would have to understand what these register accesses etc mean in order to create e.g. a windows program from your assembly source.

Anyways, such a thing was attempted for the NES: https://andrewkelley.me/post/jamulator.html

In this case, the input was the machine code, which creates additional problems: you must first understand what is really code and what is just data. If your input is assembly source instead, I'm pretty sure it can be done (given you know the exact target system) -- but it's definitely not simple.

It's a classic Yes, but... situation, not at least due the fact that the question is way to broad/unspecific. An environment isn't just a CPU with a certain instruction set, but a whole machine defined by it's interfacing capabilities and more often than not even it's timing characteristic.

Let's start with the CPU. There are at least three major way to do this (and many inbetween):

• 
  

  Bundle the 6502 code with a Windows executable interpreter that handles it as a byte code, following the execution path.

  
  
  

  That's the most simple way and will generate the highest comatibility (if done right). At the same time comparably slow - not that this would matter in real life situations where the Windows machine will be several magnitures faster than any back real 6502.

  
  


• 
  

  Compile the 6502 source code using an assembler outputting x86 code matching the 6502 functionality. With the right wraper for initialisation and exit, this code could be direct executed under Windows.

  
  
  

  Again not a big deal to do so. It also (might) produce the fastest possible x86 code to perform. But there are many issues to circumvent, even before it comes to self-modifying code. Not the least may be different code length and address usage. With self-modifying code this approach is impossible, as there is no active component turning such changes into modified x86 code.

  
  


• 
  

  Last would be a a just-in-time compiler. Somewhat of a middle way between the first two. Here as well an interpreter handles the 6502 code, but in addition to executing each statement, they are as well grouped into linear code chunks, translated into x86 and put in a side cache. When the code gets executed a second time the precompiled x86 code gets run from the side cache instead. Since thre is still the original memory/code image, every 'tricky' way, including self-modifying code can be detected and handled accordingly. Like with the interpreter solution this could be packaged with your 6502 code as a windows application.

  
  
  

  This aproach is much like Transmeata used for it's crusoe processors. In general it will result to great speed enhancements compared to interpreted code, and due the rearangement maybe even faster (*1). The backside is the need for a quite complex tool.

  
  

So far, this is solvable. But what makes an answer hard is that there is no hint about what system the hypothetical 6502 is embedded. After all, without I/O such a CPU is like a silenced blind man in an iron maden. All it can do is bleed electricity :>))

So either you

• have a certain existing 6502 in mind, then the solution is to take a fitting emulator for that machine for windows, and maybe package it with some script to load and start your code at startup.

Or you want to

• do 6502 programming in Windows. In this case you need either of the above solutions and create in addition an interface to call Windows functionality from within the 6502 code. At least that would require a way to transfer buffers for call information and in-/output data from the 6502 side to the interface code. Again, not a big deal, but a lot of work.

In any case, it might be helpful to get a bit more insight what your question is really about.

*1 - One of the interesting results of Transmetas research was that even code translation into the same CPU (read x86 to x86) may result in considerable speed up.