Over the past year my associate(cjb) and I have interfaced an IDE hard disk unit to the classic Synertek SYM-1 and written a DOS to maintain the files. It is entering the phase in it's development where it has become quite useful and I wondered if there was anyone out there who was interested in such a thing.

Certainly an adequately functional release package could be prepared very rapidly now so if anyone were to be in a position to want to try it then posting interest here would certainly motivate me to get it out there.

If anyone even has any academic interest at all about it I can post far more details.

I have named it Symbiosys and have made a mission objective that it be at least as good as CP/M and it very nearly is, certainly some aspects already exceed CP/M functionality.

Porting Symbiosys to other platforms & CPU's is also an intended objective.

A twitter stream has been established for real time communication for this project and the release information http://twitter.com/sym_biosys

we have been publishing our work at http://tinyurl.com/symdev but should anyone ever be interested in using it posts should be made as the final release package and explanations of it's installation and operation need to be made.

--
Yet Another House Harris initiative, carrying that implicit seal of high quality.

How large is your DOS?

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502

Symbiosys fits into the 4k bytes and sits in the $9000 - $9fff region marked for future expansion on the SYM-1, it is epromable. That kernel contains application accessible routines to read and write sectors to an IDE disk connected to a VIA port.

On top of that there are then calls to read and write arbitrary sized blocks of memory to any location on the disk and on top of those are calls that save files maintaining a directory and load files by their filename.

Then there are the file maintenance calls to find a file by name with wildcard matching/find next file matching/, delete a file and execute a file.

The kernel also includes, using those low level calls, a command line interface with a set of basic commands to list the directory of files, save and load any area of memory to disk with filename/date stamp and attribute and delete files.

The CLI has a full line editor with backspace/left right arrow/insert mode/delete char forward/got begin or end of line. This line editor is also an application callable utility so you could write application taking user input that maintain a uniform look'n-feel. it requires a VT100 terminal emulator, we developers use the xterm under linux. I plan to make loadable tables available for it for other terminals where possible.

It also includes the classic hex dump from the symphysis which is called from the CLI.

There is also a utility that searches through the directory and optionally execute application provided code on the files it finds matching the wild card search criteria. The CLI calls on this to do it's directory listings and file deletions. This makes it easy for applications to provide all the standard CLI functions to users directly, and even more commands.

In fact the commands in the CLI are called from the command line by use of a table making it entirely possible to load in entirely different user written commands residing anywhere in memory. Symbiosys is an extensible operating system.

In fact extensibility is a major design criteria, all of the low level basic disk operating system calls are made through a vector table, making it possible to vector away primarily the IDE read and write sector code to allow use of alternate sector drivers for other types of storage devices.

The whole kernel is written using the SYM resident assembler RAE, and as you can imagine Symbiosys was written so I could write Symbiosys on the sym with RAE so there is an raepatch that makes full use of all it's features.

You know I think I've just written the introduction section of the documentation, I have been trying to get motivated to do the documentation. "Part One, The Kernel"

and here are the details of how to wire the IDE disk to the AA connector on a SYM-1.
This was done by my associate on the Symbiosys project cjb, seen also on this forum with his parallel port data transfer system for connection the SYM to the lpt port on a linux machine, he also wrote the IDE device sector R/W driver in Symbiosys. So this is where the whole thing started a little less than a year ago now.

No additional hardware is necessary for the IDE interface.

Although it does require 14 bits of digital I/O. (The PP I/O project was started when I decided making latched 16-bits from the Commodore 8-bit user port 'was just too much hassle'.)

I have more details of 6522IDE here:
http://kildall.apana.org.au/~cjb/sym1/i ... e&mode=ret
AndI think an example of the 6502 assembly IDE driver is inside this shar archive:
http://kildall.apana.org.au/~cjb/sym1/i ... &downf=org

Whereas other micro-IDE interfaces I've seen muck about with address decoding and the like to make the drive controller memory-addressable for the CPU, I realized that bit-banging the IDE control lines (/CS0, A0-2, /R, /W, DATA0-7) wasn't too much of a penalty, and the '8 bit IDE mode' it uses actually made things a bit more practical with its 256 byte sectors (no-one cared that 20GB of a 40GB HDD was wasted on a 8-bit micro...) On the 1MHz SYM-1, it manages a "my god never seen that before" 14.5kB/sec reads.

May I point you to my 8-bit IDE interface for the 1541 drive? Just three IC's needed (with short lines just one) and a connector.

Regarding the speed, I never measured it because the drive <-> computer link was the bottleneck, not the IDE interface. But at least 50 KB/sec should be possible IMHO.

Because there is no bitbanging needed anymore, less instructions are needed (hence the higher speed). This would mean that your 4 KB of code could became smaller i.e. you have more room for other features.

_________________

This interests me

Nice! How did you arrive at that 14.5K figure? Is there any way to test write speeds?

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502

Rather than "6522IDE", maybe I should call it "The Zero-IC IDE interface", so maybe people get the point of why we liked it so much. It's simple and can be made at home, and it reduces the interface to being just a software issue. As it was, the core interface routines fit into about a page of memory, and reading/Writing the IDE registers became a ~40cycle/32byte routine.

The 14.5kB/sec was without any premature optimizations as well (loop unrolling..) It was running on a 1MHz system, and I had other subprojects to take care of, so getting something that worked was sufficient. It took about 2 nights to make the interface cable from scratch, 1 night to write the code, and 1 night to get it working.

Certainly it's the simplicity approach with the whole kernel, and the solution used was the most direct and quick way to get there. But it's designed so if you write the sector read and write routines for any interface you want it will patch into the operating system and manage a file system on it. Even block mode parallel port transfers would be able to represent a disk.

I'd like to see a USB driver for it, that would open up a lot of possibilities.

I wondered if some session screen capture and code might amuse folks. Here is a typical user session using the ls command and explaining the CLI code that generates it.






thus you can see how that coud could be added to any application to give it it's own file list procedure .

If I'm making any sense, I'm never sure......

Having nothing else to do this night I will continue on with another installment of the operating system demonstration showing the standard basic command to delete files,





And this is the code that is built onto the previous explanatory posting that makes it happen




it requires these defines into the kernel

I'm certainly interested and I'm sure others are.

At the risk of veering off topic: I had a quick look at your site, and glanced at the bootstrap code. I see it's just over the 256 byte mark. You might be amused to see an earlier thread, where Bruce came up with a tiny pre-bootstrap: intended to be suitable for in-CPLD implementation, to load a 253-byte bootstrap. That could make for a ROMless design.

By the way: welcome!

Cheers
Ed

oh no thats ok, I'm open to suggestions always and will review the forum topic you linked for further ideas. Symbiosys could easily load completely from disk with just a simple boot loader in rom, in fact roming it was last very much a late development. On my development system I have 64k of nonvolatile ram and it runs in that, traditionally I would load it in paper tape format over the serial line (still have to do that when I accidentally destroy the image in nvram).

The trick is though the whole thing itself is basically a very enhanced boot loader. It has it's little resident command line interface with a few basic commands, and it's minimalist file system code and sector driver. All the files system calls, the sector driver, and the intrinsic commands are called via a vector table. This gives the ability use the dos in it's 4k of rom to load in from disk entirely different sector drivers for any conceivable hardware device and then on top of that you can load in entirely different file system handling drivers and expanded commands packs.

So thats the basic design concept, it will boot up from rom and give you a little operating system native to the machine which can remain diskless if need be (though without a disk it wouldn't do too much). It is a complete operating system at that stage But from there it can be seen also as a boot loader and unified function calling mechanism for a much larger operating system.

So it's a real attempt to be all things to all men.

and thank you for the welcoming words.

Yes and on quickly looking over the thread you've pointed me to, indeed it could be done that way, and theres a lot to be said for the idea. It would still require that I have some romed code on the board though with at least sector reading code for the disk, then that could just load in a boot sector with the kernel on it off the hard disk unit and execute it. This is certainly the conventional wisdom for operating system kernels to operate in such a manner.

It is a method I could easily make available as an option, but if I have to have any rom on the board I may as well have the whole thing as mentioned above. It would be something to do if it was imperative to have as little as possible rom on the board. It is an idea I will keep in mind.