6502.org

There was once 6502 development systems that were fully functional without the involvement of Windows, OS X, Linux, PCs or iMac computers. Are there any today?

There are many people who can program in 6502 family assembly languages. There are plenty of holes in the computing markets. There are many would-be entrepreneurs and existing small businesses that are effectively denied full freedom to invent because of the seemingly universal presumption that one must have a PC or an iMac and pay for development software on those platforms.

I would like to see devices that make no assumptions and preclude nothing. As an example, imagine a device that has a lot of ram, a lot of USB posts, no hard disk drive, a detachable keyboard, and an easily modified operating system that runs an alterable reset program and then goes into an infinite loop while waiting for an interrupt.

Such a device could be expanded to include any known peripheral, including an Internet connection. It could be the basis for inexpensive robots (automation has been hoarded by means of artificially expensive devices).

Does anything like this exist? Is there any objection to something like this?

Thank you for your help.

I assume you meant USB ports. The question is why would you want USB ports if this is to be a standalone system? USB is a consumer-oriented interface that is complex and somewhat opaque. Also, what do you have against mass storage on a disk?

We have this now. A simple, accessible, available example is the Raspberry Pi. Stand alone, lots of ports, silicon mass storage, free software, dirt cheap.

Obviously there are several similar machines out there, but the Pi has the mind share for it.

Small enough to bolt in to most anything resembling a "robot". Cheap enough that if your robot falls in to the lake and goes all sparky, you're not at your wits end. Plus you can even find these locally in some regions or they're available shaped overnight.

These range from $5 for the Pi Zero to the $35 for the latest one with USB, WIFI, GPIO, etc.

If you want to program 6502, you can readily extend any of the multitude of simulators to map RPi I/O pins in to the simulator space.

If you're super motivated, you can make a simulator that boots the Pi directly, skipping the Linux/BSD/Android options available today.

Apple IIe, Commodore 64, Atari 800 XL, BBC Micro, etc.
With the exception of USB ports, those computers can do all of that and more.

Or, did you only mean computers that are still being produced?

You don't need to spend $ develop. I haven't spent money on software since 2002 when I bought a new laptop and indirectly paid for an XP license. Since XP was defective I formatted it and installed Linux and have been using it ever since. There are plenty of dev packages that are free open source you can download and use.

As far as a standalone 6502 you could buy WDC's eval board which boots into an ML monitor and start programming from there.

Another thumbs-up from me regarding Raspberry Pi boards. For what they provide, I don't think you can beat them on price. The model B has an ARM64 which you can take control of from the reset vector, if that's how you roll. The other ones are ARM32, which is plenty powerful.

If you want a 6502 experience then you can use an emulator which will still run faster than a discrete device, and you can provide access to the Pi's GPIOs, etc as you desire.

They're great little devices at a regret-free price.

To be clear, as an extreme example, but in theory possible.

The W65C265SXB board has 32K of RAM, and a socket for a 128K Flash chip, mapped to the upper 32K.

The 128K flash chip has 17 address lines (as it should for 128K). A0-A14 are mapped straight to the address bus, but lines A15 and A16 are wired to pins 3 and 4 of Port 4 off the MCU (labels P43_F15 and P44_AMS).

Now, how this is mapped to the "upper 32k", I'm not sure -- it could be via the chip select logic. Seems to me that P43_F15 needs to be set high "all the time" for this to be mapped to the upper 32K.

Since there are 2 pins on A15 and A16, in theory, there's "4 banks" of Flash available. Since I can't describe how the mapping is done, it seems to be that there is at least 2 banks, with P44_AMS/A16 high or low.

Now, not only are there at least 2 banks, but the chip is wired up properly to where it should be possible to WRITE to the Flash from the board itself.

So what does that mean?

That means that with little more than a terminal of some kind, and leveraging the built in monitor, you could not just start building up some hand assembled code on this thing, but you can actually PERSIST the changes to survive restarts and power.

So, simply, you could run this as a machine with 32K of RAM and, at least, 64K of persistent storage.

Back in the day, my Atari's disk drive was only 88k. 64K is not a lot, but it's not nothing either.

Obviously, day one would be to write the Flash writing software and, well, write it to Flash .

And this brings up the second point.

Story has it, I don't know where I read it, that Chuck Moore bootstrapped one of his Forth implementations on a PC starting with nothing but DEBUG. He hand assembled his kernel, typed in the hex codes, and just kept overwriting the COM file on a floppy until he was able to uplift in to Forth. Eventually I guess he overwrote the boot sector and did away with DEBUG and DOS completely. Eventually this turned in to one of his chip design programs.

It's only believable because Chuck Moore is, well, Chuck Moore. This seems right up his alley.

Anyway, so motivated, one could do that with this board. It's not keying in code via bit switches, but by todays standards, it's pretty darn close.

Using one of the eval boards is a possibility, although getting information into and out of those could be annoying, depending on how you want to go about it, and which one you use. The non-microcontroller SXB boards have only one serial port as they come(The ones with the microcontrollers have 4 each, I think), so you might want to add another UART via the XBus header(which breaks out most, if not all of the pins on the MPU/MCU, plus a few select signals).
Personally, I'd leave the microcontroller-based boards well alone(WDC calls them SoCs). A bit too strange for me.

There's also a couple of projects around on this forum that aim to be stand-alone. Oneironaut's Anvil-6502 and my own Ittiara(I've not made a thread, and I'm not sure if I will...) have this aim in mind, although we're going about it rather differently. BDD's POC might also be a standalone system. I'm not sure if it's totally standalone, but I know that it exists now.

The nice part of the XBus connector is that is exposes the decoded Address and Data lines, so you have access to all 24 address lines rather than the raw values from the CPU. I think the MCU boards are easier to expand because they expose the inbuilt chip select logic, so it seems trivial to add extra RAM to one of these. A 512K chip would be simple. The regular board is a rats nest of decoding logic. If nothing else, the MCU decodes the entire address bus "for free".

The shenanigans come in with pussy footing around the I/O ports, and a bulk of them are used for something. But you can get access pretty quickly to the raw CPU via the Flash ROM and reprogram it to your hearts content, but to do so you pretty much forgo any value the built in ROM monitor routines offer you. (You could certainly clone much of the start up code to fire up the hardware.) But there doesn't seem to be a need to bank out the built in ROM, it's just that your code get access pretty quick before the monitor has configured any of its systems (combination bug/feature depending on your goals), so it's on you to configure them the way the monitor would like if you want to leverage the ROM routines.

The "freest" port is P4, but it's used to bank the Flash ROM. So the hot tip would be to add RAM, put code in to the Flash ROM, download the Flash in to RAM, and run from that -- freeing up P4 as a full 8 bit port. And you could use the rest of P5 for SPI work, and still use the Monitors serial routines. You could also just mount new VIAs at the higher address ranges and use the built in CS logic.

The MCU boards are also $100 cheaper, but the normal board is twice as fast as the MCU. On the normal board, the monitor is part of the included Flash chip, the MCU board has a socket, but no Flash, but is has a ROM internal to the chip with the monitor.

POC V1 requires a dumb terminal (or terminal emulation on another machine). POC V2 by default uses a terminal as well, but the console port is rigged up so I can eventually attach Geoff Graham's VT-100 emulation-on-a-chip to it, which would truly make POC V2 standalone. V2 has 1 meg of almost-contiguous RAM and four high speed TIA-232 ports. Mass storage is optional

I plan to have a serial keyboard and display on Ittiara, and run it off a battery. The serial keyboard might have been a bad decision, but since that's actually ATMega328p-based(It even uses the Arduino firmware/bootloader), I can fiddle with that if I have to.

Yup. In the early days I used to use my heavily modified KIM-1 before it was succeeded by my KK Computer. Both featured Don Lancaster Cheap Video and lots of 6522 parallel I/O. Both ran FIG Forth, augmented by Bill Ragsdale's RPN 6502 assembler. There was also an MCS-48 assembler which accepted standard Intel syntax (despite being written in Forth). Peripherals included a homebrew Floppy Disk system and a homebrew EPROM / MCS-48 blaster. The 8748 and its MCS-48 siblings were cutting edge at the time -- arguably the world's first microcontrollers, and certainly the first from Intel.

My first microcontroller gig was in 1985 -- four years before I acquired my first 8088 DOS box.

Might be worth noting that a minimal computer offers a serial connection: historically, that would connect to a teletype or a dumb terminal. But these days we often use any convenient local computer to do that job. If my chromebook is acting as a dumb terminal, does that mean I've involved a more powerful computer and invalidated my minimal design? Well, yes and no, depending on how you look at it.

Also, as noted above, any USB peripheral is likely to contain a microcontroller. For a completely purist experience you'd need to vet your peripheral and use serial mouse and serial keyboard - or build your own parallel keyboard.

These days I'm using a 6502-based BBC Micro as a front end to a novel FPGA processor. It can just as well be used as a front end to a 6502-based processor, of course.

I'd also note that back in the day, the people developing the standalone 6502 machines we like to reminisce about might well have used minicomputers to run their assembler or to simulate their circuits. For the software side of the question, you might have a look at this thread:
viewtopic.php?f=2&t=4450

Back then displays and keyboards and such were uncommon and expensive. Now i can buy a brand new monitor and keyboard for under $. Or a cheap Android tablet from walmart for $50 and a usb-otg cable to connect to a system. Back then $50 would have gotten a few buttons and some LED's so you worked with what you had.

My college roommates had a KIM-1, I can a commodore 64 so we used what we had.

I certainly see this as much more of a software issue than a hardware one.

Once you start getting into tons of ports, networking, a standard OS supporting built-in things, etc, you no longer really have a "microcontroller" style setup. It's more heavyweight, and parts have to start playing together nicely, with lots of asynchronous event sources coming in. Memory management between all that stuff can require a lot more playing well with coordination as well.

However, what you talk about does remind me of ye olde Lisp machine philosophy. The user can reprogram it at any level, including assembly code & asm code generation, and even CPU microcode. The system software ends up being functionality that exists at your beck and call, instead of your software being a subservient tenant to the almighty OS. There are no protection levels between layers and documentation is integrated for every part. But things like memory management and garbage collection are infused everywhere in the system. While it might seem like some loss of control, since everything uses that same substrate instead of privileged systems having more control, it's still a level playing field between system and user code, while still keeping enough sanity to prevent things from trampling over each other.

It's a fine balancing act to have a bunch of drivers & software support while still maximizing user freedom down to the metal, that can easily spiral out of control if there isn't a higher level development floor. The trick is to keep both system & user software on that same foundation, instead of the system software itself being the impenetrable foundation that user software must rest on.