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

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.

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.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

Indeed. As cbscpe said, it can and has been done, and networking implementations for the 6502 has been around for decades.
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.

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.

_________________
WFDis Interactive 6502 Disassembler
AcheronVM: A Reconfigurable 16-bit Virtual CPU for the 6502 Microprocessor

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.

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.

Also, interpretation effortlessly tolerates 6502 self-modifying code.

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html

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

_________________
Jim Adrian

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

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/

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?