DeanOS - Intro to my project

[deanflyer]

I am in the early stages of writing my 6502 operating system. So far I have achieved the following:

1. Cycle-perfect, interrupt-driven bit-banged RX/TX at 9600 baud using a WDC 65C22.

2. Debug code for RS232 timing (output to logic analyser for RX and TX timing analysis)

3. XMODEM implementation for binary file transfers.

4 Hardware Abstraction Layer: For when I am away from my 6502 SBC, I have implemented PY65MON aware get_char, put_char and check_char routines that are macro driven and compile accordingly depending on the target platform (PY65 or physical)

5 Terminal input - A non-blocking get_line routine handling backspaces, echoes, and null-termination (cooked input)

6. A cooperative multitasking loop (foreground_loop) with an indexed-indirect command/dictionary dispatcher.

My next goal is to get started on the command parser and monitor. Id like some input on what you find essential from a good monitor/disassembler.

[BigEd]

Sounds good!

[deanflyer]

Thanks. I've just come back to this after a long layoff. I've done a ton of 6502 coding in the past, but always wanted to write an OS to get to grips with the underlying design issues. It is early days, but I am enjoying the challenge.

[floobydust]

Sounds like a fun project...

From your initial post, I'm thinking what you've done so far would be closer to creating a BIOS for the hardware. Do you have a hardware design in mind? Just trying to understand what you're creating.

As for monitors, I think you can likely find many examples out here and elsewhere. I think it really depends on what your goals are. Also, are you thinking disassembler or debugger? I wrote a disassembler as part of my monitor code years ago. The main reason was to include all of the additional opcodes and addressing modes for the W65C02 CPU. Writing a debugger can be more of a challenge, as you will likely need to integrate it into the hardware and provide some specific hardware features to make it more useful.

Lastly, have you come up with a set of functional requirements? I find having such a list useful so you can plan your project and get things moving more quickly. Keep us up to date on your progress.

[drogon]

deanflyer wrote:

My next goal is to get started on the command parser and monitor. Id like some input on what you find essential from a good monitor/disassembler.

I went through this myself when doing my own Ruby project a while back. What I found was that it was hard to not let my past experiences on the Apple II (c1978) and the BBC Micro (c1981) influence me.

The Apple had a "classic" monitor with the usual memory operations, single step, breakpoint, mini assembler/disassembler and so on...

The Beeb had ... An Operating System with none of that old fashioned "monitor" shenanigans. It was 1981, who needed that any-more? (was apparently the view of many, including me at that time!)

The Apple did help me learn 6502 assembly, but the Beeb really let me use it - a built in full featured assembler with macro capabilities disguised as a Basic interpreter...

So when I wrote my own system, I did start with a little Apple II-like monitor but very quickly threw it sway and ended up with an Acorn MOS compatible OS - which worked well enough to run a good number of Acornsoft ROMs directly including Basic, Comal, BCPL and so on.

The basics was a command-line interface with good line editing and history recall. (Most systems back then had a form of screen copy, but I was at the end of the serial line, so it seemed storing history was a good thing) Many built in commands (including memory fill and dump but not 'monitor' commands) with a good and well-defined interface (vectors at the top of page $FFxx) to handle character IO, filing system interface and so on.

What would I do if doing it again? I really don't know. I've racked my brains to see if I could come up with something different but I feel it's tricky to get away from what I grew up with. Apple/Beeb or a CP/M like environment. Unix for me, VMS for others... Who knows.

I am a believer in keeping things as high level as possible - to the point that if I can blink an LED, I can print a character, and if I can do that, I can print a string, then numbers, etc. "Debugging by printf" is a thing but as frown upon by as many as like it... However it works for me and has enabled me to develop a large run-time environment for my systems including a bytecode interpreter in 65816 code which enabled me to bootstrap a BCPL run-time environment and eventually get a BCPL compiler running on my 65816 hardware.

So essential for a good monitor, etc.? A very well defined IO system and interface to a filing system. Friendly keyboard input with a plethora of editing commands. My system implements

Code: Select all

; (Simple) Editing:
;       Ctrl-A - Start of Line
;       Ctrl-E - End of Line
;
;       Ctrl-D - Delete char under cursor
;       Del/Bs - Delete char to left of cursor
;       Ctrl-U - Delete whole line (also Ctrl-K)
;       Ctrl-S - Swap this + next
;       Ctrl-F - Find next char
;       Esc    - Abandon line
;       Left/Right arrow keys move the curor.
;       Characters are inserted under the cursor.
;       Up/Down arrow keys wind back and forwards through history

Once the IO system is defined then it's application time - Basic, word processor, spreadsheet and so on - and make it easy to adapt the applications to use the IO systems routines - like command-line entry. That way I can launch MS Basic or EhBasic or anything else and the effort of modifying them to use my line entry rather than their own was minimal and I got all the nice line editing and history recall for free.

-Gordon