6502 or W65C816S to X86 Assembly Language

[satpro]

Yeah, I was having some fun, too. I think the gap is too wide for me to have much more fun with.

[sark02]

Can you imagine sending an email in 6502 assembly language? You need:

An SMTP-formatted message.
A DNS protocol implementation to find the MX record of the recipient
A UDP implementation to issue the DNS transaction
A TCP implementation to issue the SMTP transaction
An IP layer (over which you run the UDP/TCP apps)
A device driver for the specific Ethernet controller (these are different across PCs)... assuming you can even access the device registers, which will be up in PCIE memory space (above 64KB (16-bit address bus) or 16MB (24-bit address bus)).

The PC architecture doesn't lend itself to fixed devices and fixed addresses. Even more so with the modern platform vs. the old 80s PCs.

If you hide these details behind a convenient API (i.e. JSR magic_happens), then you haven't really accomplished anything.

I would suggest that an emulator (see MESS or MAME, or your favorite) would be a more straight forward way to run 65xx code on a PC.

[cbscpe]

I did that and much more in assembly, not on a 6502 but on a PDP-11. The machine had a total of 2Mbyte of RAM and was running RSX11M-Plus.The whole OS and TCP/IP stack was written in assembler, I still have a printed listing of the OS as a reference when I want to know how things can be done in a elegant fast and clever way. And there is already a TCP/IP stack for 6502 in assembly (Marina IP) using a W5100 Ethernet controller. So yes I can imagine to do that in 65816 assembly.

[GARTHWILSON]

sark02 wrote:

Can you imagine sending an email in 6502 assembly language? You need:

An SMTP-formatted message.
A DNS protocol implementation to find the MX record of the recipient
A UDP implementation to issue the DNS transaction
A TCP implementation to issue the SMTP transaction
An IP layer (over which you run the UDP/TCP apps)
A device driver for the specific Ethernet controller (these are different across PCs)... assuming you can even access the device registers, which will be up in PCIE memory space (above 64KB (16-bit address bus) or 16MB (24-bit address bus)).

I think the problem there is probably not the assembly language, but rather the monumental size of the task in any language. Since that's already in place though, I'm sure there's no reason to replace it just to get it working on a 6502 or '816 in assembly language. I expect Jim's purpose is to be able to do new things with it.

[sark02]

GARTHWILSON wrote:

I think the problem there is probably not the assembly language, but rather the monumental size of the task in any language.

Indeed. As cbscpe said, it can and has been done, and networking implementations for the 6502 has been around for decades.

Quote:

Since that's already in place though, I'm sure there's no reason to replace it just to get it working on a 6502 or '816 in assembly language.

I suspect I'm missing something w.r.t. what Jim is trying to do. He doesn't like having to declare data types or having to read 200 page manuals, yet understanding and using a networking stack would require including declarations and reading manuals. The 6502 manuals are in the 200 page range. He doesn't like the arbitrary syntax of high level languages, yet almost every CPU has its own mnemonics (EOR vs. XOR) and operand syntax. These differences can appear arbitrary and were likely chosen by individuals at the time of the CPUs' creation to either improve upon (using some personal criteria) or differentiate from competitor products.

The question of instruction-level translation isn't without merit. Apple famously implemented live translation of PowerPC to Intel x86 to enable the transition of the Mac hardware back in the day. JIT translation of the Java byte-code has been a thing for over a decade, and like many things in "modern" computing, if you look hard enough you'll probably find out the techniques were invented in the 60s (much like VMWARE pretends to have invented hypervisors, the grey haired hippies from the 60s just laugh at them).

It is, of course, possible to translate 65xx into x86 - both are Turing complete - but instructions are only half the battle on the PC platform. If you want to work across a range of PCs, you likely need a HAL with emulated hardware - taking an OS trap every time the JIT code touches a virtual hardware register. The alternative is to directly map hardware registers into the JIT memory space and then accept that only a specific (or limited) set of hardware controllers will work in your project.

TL;DR: Not quite sure what this guy is trying to do, but I sure do like to type.

[White Flame]

In asm, I usually have a block at the top of the file (or even full-on include files, for that matter) of macros, data declarations, address declarations, constants declarations, assemble-time options flags, etc. Assembly code does not escape the need to have all that stuff compiled together for reuse and organization; it just usually happens not to specifically be data structure declarations (though that's not exactly out of the picture either).

A bit more on-topic, dynarecs (dynamic recompilers) are often found in emulators, translating the emulated platform's machine code to host's (usually x86). However, I'm not aware of any 6502-based system's emulator which does that. Since modern machines achieve realtime performance directly interpreting the 65xx's machine code bytes, there isn't much of a pressing need.

[barrym95838]

White Flame wrote:

... Since modern machines achieve realtime performance directly interpreting the 65xx's machine code bytes, there isn't much of a pressing need.

Agreed. My aging Windoze PC can effortlessly pretend to be a 100 MHz Apple 2 using AppleWin ... plenty fast enough for my little software experiments.

Mike B.

[Tor]

White Flame wrote:

Since modern machines achieve realtime performance directly interpreting the 65xx's machine code bytes, there isn't much of a pressing need.

Yep. My minicomputer emulator runs on my (year 2009) phone, and it's fast. On the other hand my other minicomputer emulation isn't as fast as I wish, due to terribly complicated addressing mode processing (after that implementation I understood what a mistake that architecture was - the original microcode had to do much of the same, which explained why it wasn't as fast as it should have been. I came to appreciate the more RISC-like architecture of the other mini I emulated).

Anyway, the nice thing about real-time (or much faster) speed of interpreted 6502 or whatever on a PC, as opposed to recompilation (by whatever means) to x86, is that with an interpreter/emulator it's so easy to add fantastic debugging aids. When and where you need it. Traps for specific memory addresses, instructions, illegal instructions, register dumps, extra registers to keep useful info for debugging, real-time disassembly trace. You can do such things with an FPGA too but not as easily and fast. And you can find a set of extra aids in many pre-made emulators, but there's something about writing all of that by yourself, you end up with something that works particularly well for you. You're the creator, so to speak, so you have divine access to a CPU and its hardware.

[Dr Jefyll]

Tor wrote:

Anyway, the nice thing about real-time (or much faster) speed of interpreted 6502 or whatever on a PC, as opposed to recompilation (by whatever means) to x86, is that with an interpreter/emulator it's so easy to add fantastic debugging aids.

Also, interpretation effortlessly tolerates 6502 self-modifying code.

[jamesadrian]

I thank you all for your participation.

Some of my projects require detailed input from chemists, engineers, and physicists. Most of them are not programmers and they don't want to be programmers in the languages that exist today. Their communication with programmers threatens to be a very substantial cost. A language that is something like what I have described could allow scientists like these to understand what a program is doing without devoting a lot of time to it. It can be a machine-like language or an algorithm-specifying language.

I came here with the idea of finding hardware-oriented programmers, like I was when I was doing that. There is no doubt that today's operating systems and prevailing methods present challenges.

I am 71 years old. A long time ago, I built three 6502 computers, connecting the parts by wire wrap. One of these used 7 of these microprocessors. They were all interrupt driven. None of modern-day programming features that I object to ever came up.

If this continues to be of interest to anybody here, please contact me by email. My full contact information is located at this URL:

http://www.futurebeacon.com/jamesadrian.htm

Thank you for your suggestions and warnings.

James Adrian
jim@futurebeacon.com

[GARTHWILSON]

A somewhat related topic here is, "Matt Porter presents the 6502 remote CPU on BeagleBone," at viewtopic.php?f=4&t=2331

Here's what Hackaday has to say about it, at http://hackaday.com/2012/11/20/discrete ... eaglebone/

Quote:

Often when we see projects using embedded Linux we think of them as not being hardware hacks. But this is a horse of an entirely different color. [Matt Porter] is leveraging a little known feature to directly access a 6502 processor from inside a Linux environment. In other words, this hack lets you write code for a 6502 processor, then load and execute it all from the same Linux shell.

The project leverages the best parts of the BeagleBone, which is an ARM development board running embedded Linux. It’s got a lot of GPIO pins that are easy to get via the boards pin sockets. And the design of the processor makes it fast enough to work well as a host for the 6502 chip. Which brings us back to how this is done. The Linux kernel has support for Remote Processors and that’s the route [Matt] traveled. With everything wired up and a fair amount of kernel tweaking he’s able to map the chip to the /dev/bvuart directory. If you want all the details the best resource is this set of slides (PDF) from his talk at Embedded Linux Conference – Europe.

This is one way to get out of all that hardware work [Quinn Dunki] has been doing to build her own computer around a 6502 chip.

[Thanks Andrew via Dangerous Prototypes]

Posted in linux hacks
Tagged 6502, beaglebone, embedded, linux, remote processor