Introducing myself to the 6502 forum

[kveroneau]

Hello everyone!

My name is Kevin, and I have been a developer since I can remember. My full-time job is a development job creating build and deployment software solutions for my company. I mainly use Python as a programming language, although I have recently been diving more into FreePascal/Lazarus(AKA FreeDelphi) in recent months, as I would love to have a compiled static language under my arsenal, and Pascal has always been a fun language to program in. My experience with assembly language is very limited, and even more limited is my knowledge in 6502... Actually, I just started diving into 6502 assembly yesterday, but have used assembly prior.

So, you might be wondering why I decided to take the dive into 6502 assembly now. Well, it's for a rather unique project of mine, which is actually what brought me to 6502.org in the first place. You see, my project requires a Virtual Machine of sorts, and my past experience with assembly comes from that. I have created my own VM instruction sets for past projects, both for the sake of learning, and for purpose. However, for this particular project, I wanted my user base to be-able to create custom content which would under the constraints of this 6502 Virtual Machine. I use this term, rather than emulator or simulator, because of it's general purpose. I equally joined this forum to also thank the maintainer for all the 6502 information provided, or I wouldn't have been able to do this in the 20 hours I have currently spent on it. I plan on using the resources hosted here a lot more during the next couple of weeks.

Okay, now you must be wondering what my project is exactly. I will not post any links to it here, as I am not aiming to advertise, however if you subscribe to PlanetPython RSS, you should see an 6502 related article pop-up, you can read about it there. In summary, I am the developer of an online multiplayer hacking simulation game. The game is terminal based, and very open world and user-generated content heavy(or at least will be eventually). Previously for this project, I attempted to use my homegrown Virtual Machine, however this would deter many users from creating any content(AKA custom programs), as it would require hours of learning, not to mention, I would have to write an extensive set of documentation... Sometime last year, I started reading about potential real-world processors, and the 6502 stood out as the best candidate. There is a wide range of online documentation, it's CMOS implementation is still widely used in embedded projects, and I thought there must be a large community of 6502 developers worldwide. So naturally, I took it among myself to integrate a 6502 Virtual Machine into my project. Today I finally finishes the initial integration, and it's live within the game for connected players to use to their hearts content. However, the integration is far from complete. To make using the 6502 within my project a 100% success, much of my hardcoded Python needs to be ported over to 6502 assembly...

This is the second reason why I have joined this forum, not only to thank you for all the great resources, but also for when I need help and/or guidance for when I dive into assembling my own 6502 Kernel... Yes, you read that right. Basically, this multiplayer game will run on 6502 code. So, the idea is that after the player connects, and if their host is not in an online state, the Virtual Machine memory will be initialized, and a Kernel will be loaded from their host into memory and executed. If the host is still online(AKA powered on), then the player will connect to their TTY shell, another program running in 6502 code.

So, I am here, because I have a really ambitious project ahead of me here. I need to build a working Kernel for these Virtual Machines, which would have some APIs for various routines and services. It will also need to initialize the virtual networking stack(as this is a multiplayer online hacking simulation), and initialize other services. Most of these virtual I/O, like networking, block device access, and the like will be performed through standard memory mapped I/O addresses, as that is commonly how the 6502 works. On top of the Kernel, a shell processor will need to be written as well, which I think might be fairly complicated to write in assembly.

I do plan on diverting from 6502 standard a wee bit, namely to support advanced operations like having more than 1 program in memory, and TCP-like networking. So, as a result, the stack segment will not be at 0x0100 as per standard 6502, but will be floating and can be set when needed. So, each program and the Kernel itself can have their own stack. I am also thinking of writing in memory protection, so that you can write-protect pages of memory. Both of these will be very useful in the environment where the 6502 is being used, it's a nice mix of vintage and modern architecture. I do not believe I will be adding/removing any op codes from the CPU core however, I do want to keep it as compatible with 6502 as possible.

So that's my project in a nutshell, as I said, it's a very ambitious project. If your up for playing an online multiplayer hacking simulation game with virtual 6502 hosts, and almost infinite possibilities, this will definitely be something to look out for once I have the full 6502 integration in place.

[GARTHWILSON]

kveroneau wrote:

I do plan on diverting from 6502 standard a wee bit, namely to support advanced operations like having more than 1 program in memory, and TCP-like networking. So, as a result, the stack segment will not be at 0x0100 as per standard 6502, but will be floating and can be set when needed.

Do consider the 65816 which is much better suited for these things. See also the 6502 stacks treatise which has 19 logically organized chapters plus appendices, with a lot of relevant material.

The things you're talking about have indeed been done on the stock 6502. See for example our member André Fachat's GeckOS/A65, a full-featured preemptive multitasking/multithreading operating system for the 6502, with dynamic memory management, implementing some Unix-like features, like signals, semaphores, relocatable file format, standard library, internet support via a kind of simplified sockets, and virtual consoles.

See also Jonathan Halliday's preemptive multitasking GUI OS for Atari 6502 computers. A little bit from the page:

• Atari 8-bit fans have long hankered after a GUI similar to GEOS on the Commodore 64. Diamond GOS went some way to addressing this deficiency, and since then there have been several creditable attempts at implementing a GUI OS on the A8. Now there's another one in the pipeline: an as yet unnamed project which aims to bring a pre-emptive multi-tasking graphical operating system to the 8-bit Atari.
  
  The completed graphical OS will include:
  • A pre-emptively multitasking kernel supporting up to 16 processes
  • Inter-process messaging system, supporting up to 64 open messages
  • Completely replaces the Atari OS and DOS
  • File system drivers supporting FAT12, FAT16 and FAT32
  • Overlapping, movable, sizeable windows
  • Cascading pull-down and pop-up menus
  • Movable desktop icons and shortcuts
  • Per-process and overall CPU load profiling
  • Dialogue boxes with a rich control set (list boxes, spinners, sliders)
  • 256 character fonts from 6 to 24 points
  • Italic, boldface, and underline, outline, and shadow styles for all fonts
  • Smooth, quick and responsive mouse control
  • Desktop file manager with drag-and-drop support
  • Comprehensive API and technical documentation for developers

There's also uIP for 6502. See André Fachat's page on this and 6502 Ethernet.

[kveroneau]

Thank you GARTHWILSON, I didn't realize that the 6502 was that capable, I am rather glad that I choose to use it as the Virtual Machine for my project now. This has definitely sparked my interest. I do recall now that the Apple IIe had a GUI, which also resembled the Mac interface, but lacked in multi-tasking, and was based on ProDOS 8-bit, which does not support multi-tasking. I do hope I did not come off at ignorant in my original post there, as I didn't realize originally how capable the chip really can be. Thanks for the suggestion of the 16-bit variant of the chip, however I don't believe for my purposes I need a full 16-bit core, as it will take more processing time for each operation, and if this projects grows, my server may not be-able to emulate that many virtual machines at once. I may consider it in the future if I feel it would bring overall benefits.

After looking at those 6502 projects you posted, I can tell that my project is not quite as advanced. The 6502 is only being used to allow for player generated content to easily thrive. It's not being used to drive a full multi-tasking graphical operating system. In fact, I don't think my implementation will allow multiple tasks/processes to run simultaneously, as this would take too many resources on my server.

I am rather excited to get into 6502 assembly for this project however, as it will be a very fun learning experience. My first goal is to port the previous kernel I wrote for my custom Virtual Machine in it's assembly language to 6502 assembly.

[GARTHWILSON]

kveroneau wrote:

Thank you GARTHWILSON, I didn't realize that the 6502 was that capable, I am rather glad that I choose to use it as the Virtual Machine for my project now. This has definitely sparked my interest. I do recall now that the Apple IIe had a GUI, which also resembled the Mac interface, but lacked in multi-tasking, and was based on ProDOS 8-bit, which does not support multi-tasking.

The Commodore 64 also had GEOS available, although its slow method of interfacing to the disc drives made it an exercise in patience. I understand the 512KB RAM expansion unit (REU) made an absolutely huge improvement in that. Then there was the SuperCPU unit that plugged into the expansion port that used a 20MHz 65816. There's a demo of GEOS/Wheels on a Commodore 128 using the SuperCPU and a uIEC memory card controller at https://www.youtube.com/watch?v=mPdOKuZcrNc . I don't think that's multitasking though, only GUI.

Quote:

I do hope I did not come off at ignorant in my original post there, as I didn't realize originally how capable the chip really can be.

No problem. It's kind of fun to show what dedicated people can do with given resources.

Quote:

Thanks for the suggestion of the 16-bit variant of the chip, however I don't believe for my purposes I need a full 16-bit core, as it will take more processing time for each operation

It's not just for the 16-bit registers and 24-bit address space, but that the '816 has a lot more instructions and addressing modes that make it more suitable for things like multitasking and relocatable code. (The stacks treatise touches on this a bit, having a chapter on synthesizing some of the related '816 instructions on the '02.) It is actually easier to program than the '02, if you're constantly dealing with 16-bit quantities, and will run much faster than the '02 at a given clock rate. My '816 Forth runs two to three times as fast as my '02 Forth at the same clock speed.

[White Flame]

Plus, it really doesn't take more host processing time on a 32 or 64 bit machine to emulate a 16 bit vs 8 bit processor. Your host processor will work with larger values, and you need to mask off the smaller results anyway, no matter the size. The only overhead of the 65816 from an emulation perspective is that there are bank registers for addressing which need to be added in. Everything else should be roughly equivalent, but do twice the bits worth of arithmetic work "for free".

[BigDumbDinosaur]

kveroneau wrote:

Thanks for the suggestion of the 16-bit variant of the chip, however I don't believe for my purposes I need a full 16-bit core, as it will take more processing time for each operation, and if this projects grows, my server may not be-able to emulate that many virtual machines at once.

Unless a 65C816 instruction reads from or writes to memory or I/O, execution time is unaffected by register width. For example, INX executes in two clock cycles, whether processing an eight or 16 bit value. Only when a memory or I/O access occurs does register width matter, adding one clock cycle per access if a 16 bit value is being processed. That little extra bit of time is more than offset by how more work gets done. One 16 bit read/write takes much less time than two consecutive eight bit reads or writes.

[GARTHWILSON]

I posted an example of the huge efficiency increase the '816 gives, at viewtopic.php?f=9&t=1505&p=9705#p9705, where the Forth instruction @ (pronounced "fetch"), which is used heavily, takes ten instructions for 6502 and only two instructions for '816 to do the same thing.

[BigDumbDinosaur]

GARTHWILSON wrote:

I posted an example of the huge efficiency increase the '816 gives, at viewtopic.php?f=9&t=1505&p=9705#p9705, where the Forth instruction @ (pronounced "fetch"), which is used heavily, takes ten instructions for 6502 and only two instructions for '816 to do the same thing.

Adding insult to injury, the 'C02 code includes a branch whose execution time may vary from one pass to the next.

[GARTHWILSON]

Here's a very impressive update video on the Atari 8-bit GUI I posted about above:
https://www.youtube.com/watch?v=T14dL9M ... e=youtu.be
He has up to eight windows up at once, and moves them around very quickly with the mouse, and you can see that the ones not selected are still doing their jobs and updating a graph.