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.
Symbiosys, a disk operating system for SYM-1
-
HouseHarris
- Posts: 48
- Joined: 28 Nov 2010
- Location: Newcastle Australia
-
ElEctric_EyE
- Posts: 3260
- Joined: 02 Mar 2009
- Location: OH, USA
-
HouseHarris
- Posts: 48
- Joined: 28 Nov 2010
- Location: Newcastle Australia
Symbiosys, Part One The Kernel
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"
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"
-
HouseHarris
- Posts: 48
- Joined: 28 Nov 2010
- Location: Newcastle Australia
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.
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.
Code: Select all
Connecting a 6522 VIA to an ATA IDE bus
---------------------------------------
Designed for a Synertek SYM-1, and its AA Expansion connector.
PORTB0-7 maps to DATA0-7 on IDE
PORTA0 = ADDR0
PORTA1 = ADDR1
PORTA2 = ADDR2
PORTA3 = /RD
PORTA4 = /WR
PORTA5 = /CS0
AA-pin AAname* IDE
1 GND 2,19,22,24,26,30,40,Power-
3 A1 15 (DATA1)
7 B5 37 (/CS0)
8 B3 25 (/RD)
9 B1 33 (ADDR1)
10 A7 3 (DATA7)
11 A5 7 (DATA5)
12 A3 11 (DATA3)
13 RESET 1 (jumpered)
A Vcc Power+
C A2 13 (DATA2)
D A0 17 (DATA0)
J B4 23 (/WR)
K B2 36 (ADDR2)
L B0 35 (ADDR0)
M A6 5 (DATA6)
N A4 9 (DATA4)
27 (IORDY) - tie low 10kR
29 (DMACK) - tie high 1kR
38 (/CS1) - tie high 1kR
39 (DASP) - LED+180R to Vcc
*: as I discovered when debugging the code, what
the SYM1 calls PORT A on its AA expansion bus, is
actually PORTB to the 6522. The pinout is no different,
since I ended up changing the code to suit.
--
Chris Baird,, <cjb@brushtail.apana.org.au> Feb2010.
Corrected IORDY and DASP: 2010-Jul-31
HouseHarris wrote:
[...]No additional hardware is necessary for the IDE interface.
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.
cjb wrote:
Although it does require 14 bits of digital I/O. .... it manages a "my god never seen that before" 14.5kB/sec reads.
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.
Code: Select all
___
/ __|__
/ / |_/ Groetjes, Ruud
\ \__|_\
\___| URL: www.baltissen.org
-
HouseHarris
- Posts: 48
- Joined: 28 Nov 2010
- Location: Newcastle Australia
Symbiosys, a disk operating system for SYM-1
This interests me
-
ElEctric_EyE
- Posts: 3260
- Joined: 02 Mar 2009
- Location: OH, USA
Quote:
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
needed (hence the higher speed). This would mean that your 4 KB of code
could became smaller
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.
-
HouseHarris
- Posts: 48
- Joined: 28 Nov 2010
- Location: Newcastle Australia
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'd like to see a USB driver for it, that would open up a lot of possibilities.
-
HouseHarris
- Posts: 48
- Joined: 28 Nov 2010
- Location: Newcastle Australia
Kernel calls and CLI code
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......
Code: Select all
.
.
.g 9000
Symbiosys Ver.IV
Oct. MMX
# date
date 01-12-2010 19:31:59 est
# ls commands*
ls
13-10-2010 23:59:24 2000 2264 31 :commands-vIV.experimental.rae
20-10-2010 02:27:41 2000 22B6 3C :commands-vIV.I.rae
14-11-2010 23:03:42 2000 230F 0F :commands-vIV.II.rae
16-11-2010 01:13:52 2000 24D0 14 :commands-vIV.III.rae
01-12-2010 19:28:21 2000 2506 15 :commands-vIV.IV.rae
# rae
rae
2000-5FFF 1000-1FFC 0F00
4506 17F1
Given these defines into the kernel ....
0330 zargc .de $4f
0340 zargv[0] .de $50 for the command line argument
0350 zargv[1] .de $52
0680 dir.prnt .de $9025 print directory entry buffer
0690 istr.prnt .de $9028 for printing inline strings
0720 proc.flist .de $9031 the batch file processor
>pr 4600 5000
4600 ;
4601 !!!batchpr .md (execd.code) and this macro ..
4602 lda #l,execd.code
4603 sta ivmp.addr
4604 lda #h,execd.code
4605 sta ivmp.addr+1
4606 jmp call.flist
4607 .me
4608 ;
4610 call.flist lda argc and this common code to pick up the command line parameter
4620 cmp #2
4630 beq cfl.begin
4640 jsr istr.prnt
4650 .by 'fn' $00
4660 rts
4670 cfl.begin zargcpy (zargv[1] pattern) copies the arg to the pattern buffer
4680 jmp proc.flist and call the kernel file list processor
4690 ;
then the actual code needed to make an ls commend becomes
this is the user supplied subroutine to be given to the batch processor to be executed on every matching file, in the case of ls all it does is print the file details and returns
4740 proc.ls jsr dir.prnt this is the kernel call to print the entry in the
4750 rts directory buffer
4760 ;
cmnd.ls is the calling point for the ls command
4780 cmnd.ls setosfl (readfrwrd) sets the os to read the directory forward
4790 batchpr (proc.ls) then the batch file list is called with a pointer to
4800 ; the code to be called when a match is encountered
If I'm making any sense, I'm never sure......
-
HouseHarris
- Posts: 48
- Joined: 28 Nov 2010
- Location: Newcastle Australia
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
Code: Select all
first a quick list of every rae patch source file
# ls *patch*
ls
28-08-2010 00:15:53 2000 11A5 08 :raepatch-v2.0.rae
13-09-2010 19:03:20 25BC 11BD 6D :raepatch.vIII.temp.rae
29-09-2010 21:34:02 3000 1223 11 :raepatch.vIII.I.rae
29-09-2010 21:42:49 F000 0220 13 *bin/raepatch-vIII
07-10-2010 15:53:56 2000 039B 20 :supermon.patch.rae
11-10-2010 23:31:36 F000 0220 28 *bin/raepatch-vIV
11-10-2010 23:33:10 2000 1208 29 :raepatch.vIV.rae
16-10-2010 23:57:01 2000 15EF 37 :raepatch.vIV.II.rae
17-10-2010 00:37:25 2000 15F0 38 :raepatch.vIV.III.rae
17-10-2010 21:12:52 2000 19D7 39 :raepatch.vIV.V.rae
18-10-2010 16:10:03 2000 199A 3A :raepatch.vIV.exp.rae
19-10-2010 19:42:57 2000 1ACA 3E :raepatch.vIV.VI.rae
19-10-2010 19:40:32 F000 01F1 41 *bin/raepatch.IV
then the wildcard specification on the delete command (rm) focusing on only the version 4 files only
# rm raepat*vIV*
the operating system then presents each file matching for verification
rm
rm ? 19-10-2010 19:42:57 2000 1ACA 3E :raepatch.vIV.VI.rae
rm ? 18-10-2010 16:10:03 2000 199A 3A :raepatch.vIV.exp.rae
rm ? 17-10-2010 21:12:52 2000 19D7 39 :raepatch.vIV.V.rae
tab key skips over files not to be deleted then the return key commits to delete the following files
rm ? 17-10-2010 00:37:25 2000 15F0 38 :raepatch.vIV.III.rae
17-10-2010 00:37:25 2000 15F0 38 :raepatch.vIV.III.rae
rm ? 16-10-2010 23:57:01 2000 15EF 37 :raepatch.vIV.II.rae
16-10-2010 23:57:01 2000 15EF 37 :raepatch.vIV.II.rae
rm ? 11-10-2010 23:33:10 2000 1208 29 :raepatch.vIV.rae
11-10-2010 23:33:10 2000 1208 29 :raepatch.vIV.rae
and then a listing to show the files deleted ..
# ls raepat*vIV*
ls
17-10-2010 21:12:52 2000 19D7 39 :raepatch.vIV.V.rae
18-10-2010 16:10:03 2000 199A 3A :raepatch.vIV.exp.rae
19-10-2010 19:42:57 2000 1ACA 3E :raepatch.vIV.VI.rae
# date
date 03-12-2010 21:18:15 est
#
Code: Select all
# rae
rae
2000-5FFF 1000-1FFC 0F00
4506 17F1
>lo comm* (notice loading files into RAE allows wildcards
necessary with the 30 charachter long filenmaes)
rae ? 01-12-2010 21:10:43 2000 2506 15 :commands-vIV.IV.rae (which it verifies
same as rm because it uses the same
kernel routines for the purpose)
**00***************************************************************************************************
****************************************01******02******03******04******05******06******07******08
******09******0A******0B******0C******0D******0E******0F******10******11******12******13****
**14******15******16******17******18******19******1A******1B******1C******1D******1E******1F*
*****20******21******22******23******24******25**** (shows progress also switchable
with the osflags variable)
>pr 4800 4900
4800 ;
4840 proc.rm jsr dir.prnt prints out dierectory entry buffer
4850 bdos (delfile) then calls the kernel to delete the file
4860 rts
4870 ; Much the same as ls works rm
4880 cmnd.rm setosfl (verifymode) sets verify mode first
4890 batchpr (proc.rm) then passes the file delete procedure
4900 ; to the batch file processor
//
it requires these defines into the kernel
Code: Select all
0440 call.bdos .de $9006 ; Call BDOS, function held in reg x
0570 delfile .de $18 ;delete file from directory
and this macro for calling all bdos functions
2020 ;
2030 !!!bdos .md (funct)
2040 ldx #funct
2050 jsr call.bdos
2060 .me
2070 ;
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
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
-
HouseHarris
- Posts: 48
- Joined: 28 Nov 2010
- Location: Newcastle Australia
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.
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.
-
HouseHarris
- Posts: 48
- Joined: 28 Nov 2010
- Location: Newcastle Australia
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.
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.