Incidentally, I should mention that a fellow in Australia purchased an assembled POC unit from me, including the SCSI host adapter. He indicated that he wanted to experiment with a "bare metal" sort of unit, but one that was functional beyond simple I/O tasks. I encouraged him to sign up here so he can exchange information with the rest of us on what he is doing.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

Now, all we need is a source for eight inch floppy disk drives.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

This times infinity.

As someone with no nostalgic connection to the 65xx, and probably one of the younger members here (I turn 25 this year), here's what drove me to the forum if anyone's interested, my thoughts on RPi/kits, and my thoughts on keeping young people interested:

First off, I'm primarily interested in making a 65xx system that is capable of doing useful work, either augmenting my vintage machines, or providing me an interface where I can play around, do math calculations/text manipulation (think Unix userland utils like tr, sed, grep), try mathematical algorithms, and apply blocks of code to I/O devices (such as a programming algorithm for an EPROM, which seems like a popular example).

1. I'm mainly interested in the '816 thanks to working with the SNES before. It's a pleasant assembly language and I assume this also applies to the 6502 itself.
2. I take more of an interest in the '816 because in general, it seems like a chip whose true potential was never used properly. Ditto with the '286, a chip I also like.
3. RPi is great for getting people started with playing around with simple, portable computers and interfacing designs using modern serial buses, protocols, and how to interface to I/O, at least using an ARM chip.
4. I have mixed feelings for using RPi as an embedded board/using embedded Linux as a teaching tool in general. My gut feeling is that an embedded Linux abstracts too much away from the hardware and scheduling (broadly, ensuring everything gets done in an orderly manner and resources are properly allocated).
5. I think creating a 65xx computer can give someone a fundamental look at how CPUs get their information to and from the outside world, and that it does not require 500+MHz to do useful work, such as a text editor, I/O device manipulation, and basic math calculations/text manipulation.
6. I would not use a 65xx computer for math intensive calculations- there's too many tricks modern CPUs use to ensure that everything stays in registers/cache because the penalty of RAM access is too great. The 65xx removes this logic for simplicity in silicon, and gets away with it thanks to single-clock cycle memory access, but this only works to the extent memory speeds can keep up.
7. I'd love to see a Unix ported to 65xx (especially '816) one day. But this would require someone to invent an MMU for the 65xx, and port GCC. The latter is an extremely poor match for the 65xx family because the 65xx is just simply not a GP register load/store machine. An MMU doesn't seem that farfetched. I have some ideas.
8. I have no problem with interfacing the 65xx family to more powerful chips, if said chips are being used to provide a specific task (which is what microcontrollers and chips like the Propeller are good at). Otherwise, I start questioning what the 65xx is even doing in the circuit . As an example, the SNES CPU was underutilized- Nintendo provided coprocessor chips on cartridge for game vendors that needed extra power, and one company- Argonaut- in fact got Nintendo's blessing to make their own chip- the SuperFX. There was a joke that the SuperFX did all the work and was the real CPU, and the '816 was just there to get the SuperFX up and running. This isn't really true, as the '816 was doing game control, but the SuperFX's clock speed was near (over?) an order of magnitude faster than the '816!

And the best for last:
I like the notion of doing address decoding on a parallel bus and having control over what goes where. I don't really see the appeal of bit-banging (of which I'm not particularly fond of anyway- however, I recognize for a minimal component 65xx CPU, using the VIA for this is effective.) I2C or SPI over the 65xx buses; if I want to use I2C or SPI, I'll use a microcontroller or RPi . That being said, I have no qualms of bridging the 65xx parallel bus to a serial bus that holds a microcontroller/serial peripherals, like Daryl Rictor's chip does. Multiple bus architecture is pretty cool in and of itself. An SPI I/O expander can also provide such an interface to the serial world.

@cr1901
And yet despite running at 500MHz+ as you say, some applications are still slow, dreadful programs. It seems these days that the solution isn't to create better code, it's to get a better computer. What a crock. And people wonder why their OSes are bloated.

I probably wouldn't go as so far as to port a unix-like system with GCC (btw, GCC isn't propietary Unix, but I'm sure you knew that.) Perhaps something like MINIX or an early BSD would be a better OS project to code for 65xx (PDP Unix, anyone?) This is one of my projects that I am currently working on, however it won't be 100% 4.3BSD compatible because quite honestly I lack the knowledge to do that properly. Still, LUnix ("6502 Little Unix?"), IMO, is dog slow and doesn't do much optimization (It has to read ALL the filenames from disk everytime it compares the command to the shell input! This means waiting 30s-1min just to type a command and receive any output, regardless of the type.)

PS Not to draw attention to myself, but just for the sake of saying, 19 years old here!

Go get 'em, tiger! I was never as smart and full of energy as I was when I was 19 (30 years ago!), but I wound up partying in college instead of doing something truly meaningful. The party damage was minor but permanent, and I lost that little edge ... an edge that I will never retrieve.

Mike B.

First off, welcome to our 6502 world.


GCC is not tied to any one operating system. In theory, GCC can be built on any machine that has an ANSI C compiler and suitable I/O libraries.


Give it time and you'll learn how all that stuff works. If you can find a copy, I recommend reading Maurice Bach's The Design of the UNIX Operating System. A lot of the internal stuff is covered in considerable detail. You could also read Kernighan's and Pike's The UNIX Operating Environment, although that is geared more to the user and application programmer than system programmer.


Not sure what you mean by that. Doesn't LUnix do some disk buffering so as to avoid constant medium accesses?


I turned 19 back when telephones had a rotary dial, some vacuum tube computers were still in use and the Beatles were on the plane from the UK to the USA.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

Thank ya'.


The way he said it made it sound like if you had Unix on a 65xx you would have to port gcc.


I'm actually looking at Lion's Commentary on Unix (6th Edition) right now, which is very useful and has the source code for a early Unix. If I recall correctly there was some controversy surrounding this book, possibly copyright.. I will check out the titles you recommended as well!



When I finally managed to get LUnix running in an emulator, it seemed that it was grabbing a list of each file on the disk when you entered a command. I would think that the list of files available on the disk/floppy could be 'cached' in memory? Even if you typed a command, say, "echo hello" twice, it would still take the same time to execute (usually in the amount of 30s+). I was using v.19, which isn't the newest version, but it was the only one I could get in an emulator. Maybe I should play with it more.


Curious, what was your first experience with a computer?

Maurice Bach, Brian Kernighan (the 'K' in K&R C) and Rob Pike were all insiders at AT&T and had detailed knowledge of virtually every aspect of UNIX, especially the System V kernel. That's why I recommend those two books.


It sounds as though LUnix is doing no disk buffering (a bit of pedantry: a buffer and a cache are technically two different things), which would explain the ridiculously long response times. The original UNIX filesystem model uses a sequential file for directory structures, which means every search for a filename has to read in the directory a filename at a time and do a comparison. Disk buffering was very important if reasonable performance was to be maintained. That is still the case to this day.

As an aside, the ext3 filesystem commonly used with Linux supports directory hashing via B-trees to reduce disk activity during directory searches. On slower machines a substantial performance improvement is usually noted on large directories.


See here for some information.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

Welcome, Dvorak! It would be good to see you post your story in our Introduce Yourself thread, as linked by BDD.

You note that cr1901 mentions a need to port GCC to get a unix-like kernel onto the 6502. Fortunately cr1901 is wrong to say that's necessary: Alan Cox has been making strides in porting his fuzix OS to the 6502 using cc65. We have a thread or two for that too, but see here and nearby.

I meant to reply earlier to cr1901's points...

Just to pick up on a couple of RPi points here cr1901. The RPi had two great advantages: low cost (which means it's not a disaster to damage it, whether in your lab or in a school) and having all the system state on a cheap swappable SD card (which means each experiment by each user is totally independent, can use a different OS, cannot modify files belonging to another experiment, and no need to clean up before using.)

In fact you can readily use the RPi at the bare metal level, which means no interposition of embedded Linux (or other OS) and also means it can be used to learn assembly level programming. Or you can use Linux, or RISCOS, or a BSD. Or write your own OS. You get to choose the appropriate tool for your purpose.

Mostly, of course, the RPi is used as a platform for Pygame, or Scratch, to teach using a high level language, and that's fine.

Cheers
Ed

I'm aware of Fuzix and I have talked to Alan before wrt to his 8088 port of PCC. I keep a local copy up to date to test it out/report on the mailing list, and would eventually like to add segmentation support to the code it emits (ELF has provisions for arbitrary sections, so it shouldn't be horrible). It looks like an interesting project, and tbh, I should be following it more closely. Additionally, it's not as simple as just porting the OS, but the userland as well: http://comments.gmane.org/gmane.comp.compilers.pcc/3367

The TL;DR... GCC extensions have done more harm to between compiler/arch portability than any other construct. I'm bitter that I can't use code that uses GCC extensions for my vintage work. I half-jokingly say that those programs are written in a new programming language.

I have mostly avoided cc65 for the sole (perhaps no longer valid) reason that cc65 will use the Direct Page for compiler control information, which will crash the program if overwritten. I want control over my direct page, and don't want system-vars interfering. On a multitasking OS, I can see that getting ugly/being a source of global state that must be saved during a context switch. An MMU would be perfect for 65xx for this b/c each application could use the Direct Page in their own way.

I've used GCC since version 1.3x-something, but I have never used a GCC extension. In my opinion they are all nearly useless. And I have asked other developers now and then, and I have yet to come across anyone who actually use those extensions. Excepting Linux kernel developers, where at least some of those '__attribute' extensions (packing and whatnot) are used. As for user-level code, I keep building stuff on other computers besides Linux and thus use other compilers, and I have not had any GCC extension problems ever. I start getting C99 problems though.. but that's not GCC's fault.

(And yes, some of those extensions _are_ a new programming language.. nested functions, in particular)

-Tor

I'd like to reheat this thread and suggest that the simplest way to get people, young or old, started with the 6502 might be the W65C265SXB development board (http://wdc65xx.com/134_265_SXB-engineer ... ngstarted/, "265SXB" for short): All you need is the board and a USB cable of the type most people have for their mobile phones anyway. Start a terminal program, and you're off.

The rather big problem, unfortunately, is the documentation. For a lot of stuff, there simply is none (for instance, how to write a byte to flash memory), for others, it is misleading (the manual doesn't mention that you can just use the normal USB cable for console work out of the box).

As you might have seen in a different part of the forum, Andrew and I have started a collection of notes aimed at provided a lot of what is missing (https://github.com/scotws/265SXB-Guide). My idea would be to start it off rather simple for beginners and ramp up the complexity with projects that can be added via the 50 pin interface and a breadboard, then on to daughter boards ("shields"). That way, the 265SXB should allow not only a quick start ("plug and play", as we said back in the day), but offer a path from first hardware projects to more complicated examples that will give people the confidence to put together their own actual computer from scratch.

(I'm trying to get into contact with Rod Biresch to get permission to include his most simple "Blinkenlights LED" example at https://rodbiresch.wordpress.com/2015/0 ... llo-world/ as well.)

We also have some third-party programs in addition to the (Windows-only, closed source) WDC tools, such as Joe Davisson's EasySXB (https://github.com/Mortis69/EasySXB), and Andrew's W65C265SXB Hacker for messing around with the firmware (https://github.com/andrew-jacobs/w65c265sxb-hacker).

The other downside is that it isn't that inexpensive as you might hope. Also, it's 5V only, which means it is not easy to attach all the nice SPI stuff (unless the serial ports are easier to bit-bang than the 6522). It would be nice if WDC could put together a SXB board with 3.3V and maybe even built-in SPI support, but until then, I'd go with the 265SXB as the best bet for a painless start.

Hmm, I think I might be working on a 6502 project which would adhere to our younger generation. I am 32 btw, turning 33 next month...

Kids nowadays love video games, and some even like the aspect of "hacking", recall the movie WarGames? I know I do, and always wondered what it would be like to be in his shoes, being at home with a VIC-20, and a phone modem connecting to many random phone numbers...

As it so happens, I am working on a somewhat ambitious project, which combines a 6502, gaming, and online hacking! I originally started this project back in 2012 as a web-based game, but soon after turned into a terminal-based game with a custom assembly language and virtual machine. After awhile I thought using a custom virtual machine may deter players from actually creating programs, as the learning curve might be a tad too high... I really wanted to have a persistent world full of user-generated content. Finally last year, I had the idea of scrapping the custom virtual machine to use something more common, but it needed to be lightweight enough to be usable in a situation like this. The end result was to use a 6502 compatible Virtual machine and a VIC-20 compatible assembly language. There is a vast amount of online documentation and community behind both, so it felt like a natural fit. Besides, in the movie WarGames, the computer used most likely ran a 6502 chip.

Anyways, I spent the last 20 hours putting together a 6502 Virtual Machine and Assembler that I finally partly integrated into the game. It can assemble and run VIC-20 style 6502 programs. Of course there is no framebuffer here, only a TTY device, so naturally VIC-20 programs won't run out of the box. However, since user-generated Kernels will be possible, a user will eventually come around and create a VIC-20 Kernal(VIC-20 spelled it Kernal?!?!), which should enable compatibility with most text-based VIC-20 programs.

Once the 6502 core is fully integrated into the game, the virtual network hosts which players will connect to, will run 100% 6502 code. When a player first connects to the game world, their host is in a "powered off" state, and during the connection phase, this is detected, and a virtual 6502 is powered on, KERNEL is loaded in it's virtual memory space, and a shell program is loaded after the kernel finishes up. The 6502 will have full network access via a TCP-like interface to other virtual 6502 hosts, making a full virtual Internet of TCP connected 6502 machines. This allows players to create networking applications. Currently this virtual Internet is simulated in pure Python code, with no actual underlying protocol. So, when a player connects to another host, there's nothing magic about it... With the 6502 code being put together, this will all change, and my hopes is to create a fully simulated packet-switched network.

The general goal of this game is raise ones rank, virtual credits, and taking over other 6502 hosts on the network. However, nothing is stopping the player from playing around with general 6502 assembly and learning in a simulated environment. It can both be used as a learning/teaching tool, as well as for entertainment. With the benefit of skills learned and used can be adapted to general 6502 uses, such as embedded CMOS programming, and vintage coding.

Do you think this would a great way to expose the younger population to 6502?