I am building a breadboard 6502, Ben Eater's design, and it's lovely. What would make it even lonelier would be a keyboard, monitor, file system, etc. Sitting next to it I have Windows and Mac machines that have all that stuff. The 6502 has a serial port and the computers will take serial in so I can physically tie them together.

Is there an OS for the 6502 that will allow me to use the stuff on the big, I remember when CPUs stook 5 feet high and were 6 foot long, machine?

An idea I have is an OS on the 6502 and an app on the other machine that would allow you to use keyboard, monitor, file system, ect.

Right now I take the ROM off the 6502, assemble on the Windows, write the assembly to the ROM chip, stick the ROM back in the 6502, boot, find I wanted to use a 4 and not a 5, do the whole thing again. It would be real nice if I could tell the 6502 to load a program from a file on the Windows machine and run it. The program could write some lines that would appear on the monitor and I could key in some input. Then I could change the 4 to a 5 and try the whole thing again with just a few keystrokes.

Back in the late 60s an IBM mainframe, with 24K memory, could have a 10K supervisor, 10K user program, 4K spooler. Why can't the 6502 do something like that. It has more memory, it's probably faster, The machine it's connected to has a lot more stuff, the old machine had 4 8 meg hard drives and I have an 8 terabyte NAS.

Typically when doing cross development you want to initiate the download from the development host, so that you can run just one command that builds your code, runs all the unit, functional and simulator tests, and then sends it to the SBC and executes it. But that's mainly about convenience, there's no reason you can't initiate the download from the SBC side if you really want to.

What you need is a simple monitor (a command interpreter for manipulating the machine, not a video display) that runs over the serial port. This typically lets you view data, enter it, and so on. WozMon, which I believe Ben Eater has actually had running on his design, is one of the smallest and simplest examples of this. My RC6502 system has it in ROM; I use it over a serial connection from my Linux host and have a script that does exactly what I described above, simply sending the same commands I'd type to enter and run the program but automatically.

_________________
Curt J. Sampson - github.com/0cjs

Keep watching the videos. At this point, Ben's breadboard computer has an LCD display, a PS/2 keyboard, VGA (kind of) graphics, a serial connection, WozMon (as Curt alluded to), and its own rudimentary library of system routines. There's no file system yet, but I can't imagine that an implementation of FAT on an SD card or something similar will be long in appearing.

_________________
"The key is not to let the hardware sense any fear." - Radical Brad

WozMon is nice, but I want more. I want to use stuff on the Windows computer, like have the keyboard be a keyboard for the 6502, have the monitor be the monitor for the 6502, and read/write files on the Windows machine.

I imagine an OS running on the 6502 taking commands from the user program and then communicating with the Windows machine over serial. On the Windows machine I would have an app that could pass keyboard input over to the 6502, have a window act as the display for the 6502, and read/write files for the 6502.

In general on the 6502 I would build a block in memory and then call the OS. The OS would package the data up and send it off to the Windows machine. The app would get the data from the 6502 and handle it.

The old 360s had the idea of a channel program that would do IO. You built this, along with your data or area for tata, caled the supervisor, and the io was done for you. I can imagine the OS taking one of these requests, massaging it a bit, sending it out the serial bus. The app on the Windows side would get the message, look at the header, and handle whatever the request was.

I know I can get a monitor, keyboard, and floppy drives for the 6502, but I have all that stuff sitting right next to it.

I don't want peripherals for the 6502. I have 2 other computer right next to it with lots of real nice peripherals. I want to use the peripherals on my existing computers.

Welcome, p7willm!

As noted above, it's convenient and normal to use the facilities of a monitor to load and save chunks of memory.

But indeed, it's quite possible to implement a filing system which runs over a serial connection: you need suitable code on the 6502 side, and complementary code to run on the host computer side. This has been done at least twice in the world of Acorn computers.

See for example gfoot's ROMless Serial Filing System (over on stardot) and see JGH's SerialHost. Unfortunately for you, I think both of those will assume some of the nice facilities of the Acorn MOS ROM, which you won't have. But both projects demonstrate that the idea can be got to work - with some significant ingenuity and effort!

(It's also true that the Commodore 64's connection to its disk drive is a high level protocol running over serial, and one might borrow that protocol. There might, or might not, already be an example of doing this, with the code to run on the host side.)

Edit: the UPURS project also offers serial access as a file system on the Acorn systems - a major difference being that the serial connection in this case is bit-banged, to work at higher speeds than the UART can manage. UPURS - Fast serial transfer utilities for the BBC Micro by Martin Barr. From the link:

Hmm. This doesn't seem that complex to achieve.
A simple C program on the PC that hooks into a COM port and uses SDL or a similar library for keyboard/mouse capture, drawing text and graphics, and stdio for file IO where some specified folder is treated as the root of a simulated drive (similar to how DOSbox does it).
Then you just need a defined command set for any connected serial device to make use of the features.
Which also means it wouldn't be limited to 65xx systems. Arduino or similar MCU boards would also be able to make use of it.

Honestly this sounds pretty cool, maybe if I can find some info on how to let a C program access a COM port could I try this out.

I've been wondering about this ever since I added a $5 Pi Zero or Pi Zero W with 'bare-metal' terminal emulator software to an SBC. There's hardly anything on the little 128-MiB uSD card in the Pi Zero and I was wondering when someone might add something like a 16-MiB disk image file to the SD card and extend the VT-100 command set to accommodate file I/O access through the serial port. It wouldn't necessarily be fast but it would be a relatively inexpensive and nifty solution for a pocket size SBC with keyboard, HDMI video, and file storage, wouldn't it?

Yep, I think it's all about multiplexing several purposes over the one serial stream. The Agon firmware very much does exactly that - the eZ80 runs z80 applications and OS, and the esp32 runs the input, output, and filesystem operations and the two are connected over a serial link. The two things happen to be on the same board, but the architecture is exactly what's wanted in this thread - except the host side is a microcontroller, not a PC.
https://github.com/breakintoprogram/agon-vdp#readme

Looks like the Neo 6502 by Olimex might be the thing for you - it fronts a real 65C02 with an RP2040 MCU which does everything else.

There is also the Pico Computer project - another RP2040 system: https://github.com/picocomputer

My own Ruby system has real 65C02 (and 65c816), real RAM, real 65C22 but that's fronted by an ATmega that does bootstrap, serial and filing system and that's fronted again by a "smart" terminal program running on my Linux desktop that can do high resolution graphics, sprites (and sound when I can be bothered to implement it) as well as keyboard and mouse input - all over a single 115200 baud serial line to the ATmega.

-Gordon

_________________
--
Gordon Henderson.
See my Ruby 6502 and 65816 SBC projects here: https://projects.drogon.net/ruby/

Hmm, those projects are using a microcontroller, rather than an existing PC, to provide facilities. One might be able to borrow from the serial protocol though, if that's how they are connected.

But, I just had an idea. We want a program running on a PC, capable of sound, graphics, serial I/O, and of course keyboard input. Ideally that's a portable program and easily customised. So - write the program in BBC Basic! It's free and runs on Windows, Linux, Mac and Raspberry Pi, and it can do full-screen graphics using a byte-serial protocol. (In fact, Revaldinho and I have used it this way, connected to an Amstrad CPC, to do full-screen graphics to a DVI (HDMI) display, with an Acorn-style byte stream.)

I'm fairly sure JGH's tube-over-serial project will have a Basic implementation already. This isn't going to be Lego levels of easy, but I think the building blocks exist.

That reminds me of QBASIC64, a modern evolution of the original QBASIC for MS DOS. It internally converts the BASIC code to C++ and then simply compiles it. So you don't need QB64 itself to run the programs unlike python or similar.
And it was my first step into the world of programming!

Actually yes - no - but - maybe...

So the RP2040 / Picocompute solution adds anothe computer into the equation.

As for my ATmega front-end.

But that needed do anything more than "enable" the higher functions to run on a good (or poor) desktop PC.



I sort of have that with my RubyTerm thing. Although primarily it interprets Acorn VDU commands (and adds on some more like sprites, circles although I've tried to stick to the Graphics extension pack where possible) it does one other thing which is implement a file pull/push function, so I can *GET and *PUT files to/from the desktop from the 6502/65816 side of thing.

My RubyTerm is actually a stripped down version of my BASIC interpreter that I originally wrote to run under Linux. (With a front-end to interpret Acorn VDU commands). It supports Acorn/BBC Basic sound/envelope commands but I never pushed them from the BASIC interpreter over to the RubyTerm side, although it would be easy to do so.

Extending that to be a proper file system - well not hard, just time consuming.

But I still need something to boot the 6502/816 and I think having local RAM and at least one peripheral (6522) is a good thing, but you can emulate anything over serial given enough time and resources - I have a version of my "wiring" library that runs over serial and TCP - it's just a matter of what you want at the end of the day.

I think the challenge is finding a microcontroller with enough pins to enable the boot, act as a serial port and anything else you feel you need to do the communication.

As an aside, I got the code in the ATmega to recognise it was talking to a RubyTerm or not - and if not, then it translates the Acorn VDU commands coming from e.g. BBC Basic into ANSI codes so I can run it under Minicom, or even a real serial terminal that understands enough ANSI codes to work.

-Gordon

_________________
--
Gordon Henderson.
See my Ruby 6502 and 65816 SBC projects here: https://projects.drogon.net/ruby/

Which is exactly what you have when you have a serial terminal connection to your 6502 board. What you type on your Windows computer keyboard goes to the 6502, and what comes back is displayed in a window on your screen.


Most terminal programs also have upload and download facilities. When you want to send a file of code , turn it into WozMon deposit format (addr: bb bb bb bb ...) with CR line endings and choose the "upload" command from your terminal program to send it. I actually use a slightly more sophisticated command line program, since I don't want to have to manually invoke the upload command after my build process: my wozmon-deposit script directly reads the output files generated by my assembler (which include address information) and generates WozMon deposit commands that it then sends to the SBC. I can run this while I've got a terminal program open, so after the deposit is done I can R the address where I want to start.

If you want to get a bit more sophisticated, there are monitors that will accept Intel or Motorola hex format (both have checksums) and even Xmodem uploads. If you really want to fetch the file using a command typed into the SBC, you can modify a monitor to support Kermit protocol which allows the remote to generate commands to the terminal program at the other end to load and send a file.

Saves are much the same thing, though you'll of course need to specify a memory area to save (just as you would with a BSAVE command). The simplest thing to do is just turn on terminal capture and print memory dumps, but if you want to get more sophisticated you can, again, use a monitor that supports Xmodem or Kermit. I believe that some of the more sophisticated versions of the Xmodem protocol, as well as Zmodem and Kermit, can send a terminal sequence that will automatically trigger a download in your terminal program (assuming it supports that sequence) and save the data to a file specified by the remote end.


Yes, as you can see from the above, that's called a "terminal program."

Note that this was a standard way a lot of us interacted with computers, especially remote ones (slowly, via a modem) in the '70s and early '80s.

_________________
Curt J. Sampson - github.com/0cjs

No, SerialTube passes all assumptions to the host. Whatever is available is whatever the other side of the serial link provides. The 6502 client code is 4K, but it can be crushed down to 512 bytes and just provide keyboard input and VDU output. You can have SerialTube on a 6502 single board computer, and SerialHost on a Windows PC, and nary a Beeb in sight.

_________________
--
JGH - http://mdfs.net