OSI memories

Restored from original incarnation of the forum. Restoration in progress. . .
Post Reply
__Danny S.
Posts: 2
Joined: Mon Dec 05, 2011 2:02 am

OSI memories

Post by __Danny S. »

Hi all, I just found this site, as well as the OSI emulator software, and they bring back a lot of memories.

My first computer was an OSI C1P, and I learned a lot with it. I later got a C2-8P DF and worked at an OSI dealership in New York. We dealt with everything from the C1P to the C3-B, the 74 MB behemoth, and were home to the user group known as OSUNY (Ohio Scientific Users of New York), a name which later became infamous due to the bulletin board (BBS) system we set up somehow morphing into a "phone freak" board.

But back when OSUNY meant what its initials stood for, we met initially at Polk's Hobby Shop, later at Intechnology, the computer store on 23rd St. where I worked. Mike Bassman, who wrote the "Vampire Castle Adventure" included with WinOSI, was also a member.

The owner of the store was Hal Pollenz, who had formerly worked at the OSI factory. The store was also affiliated somehow with Dwo Quong Fok Lok Sow, makers of the WP6502 word processor, and I wound up writing the 65U file interface (called WPEXEC) for version 1.3a of that program.
DQFLS also had a program called DQ Secretary, written by another OSUNY member named Mike Cohen, that turned OS-65D into a "real" operating system that could create (and rename and delete) files and get directory listings "on the fly" without losing your current program.

Anyway, I no longer have my OSI systems, but I do have a few old C1P diskettes sitting around in a drawer that I would like to convert into emulator files, if anyone is able to do this. BTW, does anyone have docs on the file format used by the WinOSI disk images, in particular how the variable lengths and numbers of sectors on each track are handled?
__Mark
Posts: 2
Joined: Mon Dec 05, 2011 1:50 am

Emulator disk layout

Post by __Mark »

Hi Danny S., Thanks for sharing the memories.

The disk layout is documented in the source code (disk_io.cpp) I'll try to add that here. Basically the format is a raw dump from a real OSI disk image with any noise bytes that happen to be on the disk. The dump program waits for the index hole and reads until the next index hole or $900 (5.25) or $E00 (8") bytes have been read. Given the low density of OSI drives, that amount of space should hold the data from any floppy. The data is stored as 8 bit bytes even though the OSI uses 11bits/bytes. OS65D stores data using an ACIA set at 8E1.

I'm able to dump floppies if you like.

I've also started working on the emulator again. Hopefully I'll have an updated version in the not too distant future. I'll at least put up the current version if I get distracted again.
-Mark

Here is the data:

/* OSI OS65D disk image */

------------------------------------------------------------------------------
Physical Disk specs

5.25" disk, 40 tracks, 8 sector/track, 256 bytes/sector, 11 bits/byte (8E1) =80K/disk
OSI 65D uses 8E1 to give a max unformatted capacity of 2272 bytes per track (see below)
However other bit encodings (8N1) could give up to 2500 bytes/track

The standard speed for mini-floppy drives (5") is 300 rpm. Thus one
rotation of the disk is 200 mS.

Stated baud-rate is 125k or 125000 bits/sec and one serial byte is 11 bits
(1 start, 8 data, 1 parity, 1 stop).

So the theoretical absolute maximum storage per track is -
(125000 x 0.2) / 11 = 2272 bytes or 8.8 pages

OS-65D loses a bit more because it doesn't write until 10 mS after the
index pulse, so -
(125000 x 0.19) / 11 = 2159 bytes or 8.4 pages
and this doesn't even allow for the length of the index pulse (a few mS)?
and the speed variation between drives.

Data clocked out at 125000 bps, 11 bit word =11363 cps. 1Mhz clk = 88 cycles
per character or 176 at 2Mhz

---------------------------------------------------------------------------

8" disk, 77 tracks, 12 sectors/track, 256 bytes/sector, 11 bits/byte (8E1) = 231K/disk
OSI 65D uses 8E1 to give a max unformatted capacity of 3772 bytes/track (see below)
However other bit encodings (8N1) could give up to 3900 bytes/track

The standard speed for 8" floppy dives is 360 rpm. Thus one rotation of
the disk is 166.6ms

Stated baud rate is 250K or 250000 bits/sec and one serial byte is 11 bits
(1 start, 8 data, 1 parity, 1 stop).

So the theoretical absolute maximum storage per track is -
(250000 x 0.166 ) / 11 = 3772 or 14.7 pages

OS-65D loses a bit more because it doesn't write until 10 mS after the
index pulse, so -
(250000 x 0.156) / 11 = 3545 bytes or 13.8 pages
and this doesn't even allow for the length of the index pulse (a few mS)?
and the speed variation between drives. *Note OS65U has tracks of 3584 bytes (or more?)

Data clocked out at 250000 bps, 11 bit word =22727 cps. 1Mhz clk = 44 cycles
per character or 88 at 2Mhz
---------------------------------------------------------------------------
OSI Track 0 format
10 millisecond delay after index hole
0,1 load address of the track in hi,lo form
2, page count of how much data is written on track 0, usually 8 for 5.25, 12 for 8"
3+ data

Track 1-n Format (OS65D)
10 ms delay after index hole
0,1 -a 2 byte start code $43, $57
2, -BCD track number
3, -track type code (always $58)
(sector data follows)

There can be any mixture of various length sectors. The total page count can not
exceed 8 pages (8*256) if more than one sector is on a track
Each sector is written in the following format:
-previous sector length (4 if none before) times 800 microseconds of delay
-sector start code $76
-sector number in binary
-sector length (#pages) in binary
-sector data
-(end of sector mark? $47, $53 ? )

Directory Format
2 sectors (1 & 2) on track 12 (8 for 8") hold the directory information.
Each entry requires 8 bytes. There are a total of 64 entries. The entries are
formatted as follows:
0-5 ASCII 6 character filename
6 BCD first track of file
7 BCD Last track of file

------------------------------------------------------------------------------

OS65U sector size is 3584, one sector per track on 8" floppy
(information incomplete)

------------------------------------------------------------------------------
OSI emulator disk layout

5.25"
40 tracks (0-39)
each track is 0x0900 (2304) bytes
each disk is 0x16800 (92160) bytes long (#track * track length)
up to 8 sectors of (256) bytes can be present

8"
77 tracks (0-76)
each track is 0x0e00 (3584) bytes long
each disk is 0x43600 (275968) bytes long
up to 12 sectors per track


Note the 8" disk layout may need to be changed to accomodate OS65U data


So lets look at OS65D3.3 directory track. This image was dumped using the
OSIDUMP programs on a real OSI, so there can be extra garbage in the disk layout
where the disk head was turned on or shut off.

Directory track is track 12. (0x0C) 0x0C * 0x900 = 0x6C00
Loading up the image we see:

006C00 43 57 12 58 76 01 01 4F-53 36 35 44 33 00 13 42 CW?Xv??OS65D3 ?B
006C10 45 58 45 43 2A 14 16 43-4F 50 49 45 52 17 18 43 EXEC*??COPIER??C
006C20 48 41 4E 47 45 19 20 43-52 45 41 54 45 21 22 44 HANGE? CREATE!"D
006C30 45 4C 45 54 45 23 23 44-49 52 20 20 20 24 24 52 ELETE##DIR $$R
006C40 41 4E 4C 53 54 25 26 52-45 4E 41 4D 45 27 27 53 ANLST%&RENAME''S
006C50 45 43 44 49 52 28 28 53-45 51 4C 53 54 29 30 54 ECDIR((SEQLST)0T
006C60 52 41 43 45 20 31 31 5A-45 52 4F 20 20 32 33 41 RACE 11ZERO 23A
006C70 53 41 4D 50 4C 34 34 41-54 4E 45 4E 42 35 35 43 SAMPL44ATNENB55C
006C80 4F 4C 4F 52 53 36 36 4D-4F 44 45 4D 20 37 38 43 OLORS66MODEM 78C
006C90 4F 4D 50 41 52 39 39 23-23 23 23 23 23 00 00 23 OMPAR99###### #
006CA0 23 23 23 23 23 00 00 23-23 23 23 23 23 00 00 23 ##### ###### #
006CB0 23 23 23 23 23 00 00 23-23 23 23 23 23 00 00 23 ##### ###### #
006CC0 23 23 23 23 23 00 00 23-23 23 23 23 23 00 00 23 ##### ###### #
006CD0 23 23 23 23 23 00 00 23-23 23 23 23 23 00 00 23 ##### ###### #
006CE0 23 23 23 23 23 00 00 23-23 23 23 23 23 00 00 23 ##### ###### #
006CF0 23 23 23 23 23 00 00 23-23 23 23 23 23 00 00 23 ##### ###### #
006D00 23 23 23 23 23 00 00 47-53 76 02 01 23 23 23 23 ##### GSv??####
006D10 23 23 00 00 23 23 23 23-23 23 00 00 23 23 23 23 ## ###### ####
006D20 23 23 00 00 23 23 23 23-23 23 00 00 23 23 23 23 ## ###### ####
006D30 23 23 00 00 23 23 23 23-23 23 00 00 23 23 23 23 ## ###### ####
006D40 23 23 00 00 23 23 23 23-23 23 00 00 23 23 23 23 ## ###### ####
006D50 23 23 00 00 23 23 23 23-23 23 00 00 23 23 23 23 ## ###### ####
006D60 23 23 00 00 23 23 23 23-23 23 00 00 23 23 23 23 ## ###### ####
006D70 23 23 00 00 23 23 23 23-23 23 00 00 23 23 23 23 ## ###### ####

Starting with 43, 57 is the start of track marker, then the track code in BCD (12)
Next the track type code $58 and the sector data

The sector starts with $76, the sector number $01, the number of sector pages (01)
and then the sector data, which happens to be a directory listing.
The end of sector marker appears to be $47, $53, at which point another sector may
be found. Note: Sometimes there are garbage bytes between sectors or between the start of track and the first sector, so reader code must account for that.

Code: Select all

/* OSI OS65D disk image */

------------------------------------------------------------------------------
Physical Disk specs

 5.25" disk, 40 tracks, 8  sector/track,  256 bytes/sector, 11 bits/byte (8E1) =80K/disk
 OSI 65D uses 8E1 to give a max unformatted capacity of 2272 bytes per track (see below)
 However other bit encodings  (8N1) could give up to 2500 bytes/track 

 The standard speed for mini-floppy drives (5") is 300 rpm. Thus one 
 rotation of the disk is 200 mS.

 Stated baud-rate is 125k or 125000 bits/sec and one serial byte is 11 bits 
 (1 start, 8 data, 1 parity, 1 stop).

 So the theoretical absolute maximum storage per track is -
    (125000 x 0.2) / 11  =  2272 bytes  or 8.8 pages

 OS-65D loses a bit more because it doesn't write until 10 mS after the 
 index pulse, so -
    (125000 x 0.19) / 11  =  2159 bytes  or 8.4 pages
 and this doesn't even allow for the length of the index pulse (a few mS)? 
 and the speed variation between drives.

 Data clocked out at 125000 bps, 11 bit word =11363 cps. 1Mhz clk = 88 cycles
 per character or 176 at 2Mhz

---------------------------------------------------------------------------

8" disk, 77 tracks, 12 sectors/track, 256 bytes/sector, 11 bits/byte (8E1) = 231K/disk
 OSI 65D uses 8E1 to give a max unformatted capacity of 3772 bytes/track (see below)
 However other bit encodings (8N1) could give up to 3900 bytes/track

 The standard speed for 8" floppy dives is 360 rpm. Thus one rotation of 
 the disk is 166.6ms

 Stated baud rate is 250K or 250000 bits/sec and one serial byte is 11 bits
 (1 start, 8 data, 1 parity, 1 stop).

 So the theoretical absolute maximum storage per track is -
    (250000 x 0.166 ) / 11 = 	3772 or 14.7 pages

 OS-65D loses a bit more because it doesn't write until 10 mS after the 
 index pulse, so -
    (250000 x 0.156) / 11  =  3545 bytes  or 13.8 pages
 and this doesn't even allow for the length of the index pulse (a few mS)? 
 and the speed variation between drives. *Note OS65U has tracks of 3584 bytes (or more?)
 
 Data clocked out at 250000 bps, 11 bit word =22727 cps. 1Mhz clk = 44 cycles
 per character or 88 at 2Mhz
---------------------------------------------------------------------------
 OSI Track 0 format
 10 millisecond delay after index hole
 0,1 load address of the track in hi,lo form
 2, page count of how much data is written on track 0, usually 8 for 5.25, 12 for 8"
 3+ data
 
 Track 1-n Format (OS65D)
 10 ms delay after index hole
 0,1 -a 2 byte start code $43, $57
 2,  -BCD track number
 3,  -track type code (always $58)
 (sector data follows)

 There can be any mixture of various length sectors. The total page count can not
 exceed 8 pages (8*256) if more than one sector is on a track
 Each sector is written in the following format:
 -previous sector length (4 if none before) times 800 microseconds of delay
 -sector start code $76
 -sector number in binary
 -sector length (#pages) in binary
 -sector data
 -(end of sector mark? $47, $53 ? )

 Directory Format
 2 sectors (1 & 2) on track 12 (8 for 8") hold the directory information.
 Each entry requires 8 bytes. There are a total of 64 entries. The entries are
 formatted as follows:
 0-5 ASCII 6 character filename
 6 BCD first track of file
 7 BCD Last track of file

------------------------------------------------------------------------------

 OS65U sector size is 3584, one sector per track on 8" floppy 
 (information incomplete)

------------------------------------------------------------------------------
OSI emulator disk layout

5.25" 
	40 tracks (0-39)
	each track is 0x0900 (2304) bytes 
	each disk is  0x16800 (92160) bytes long (#track * track length)
	up to 8 sectors of (256) bytes can be present

8"
	77 tracks (0-76)
	each track is 0x0e00 (3584) bytes long
	each disk is  0x43600 (275968) bytes long
	up to 12 sectors per track


Note the 8" disk layout may need to be changed to accomodate OS65U data


So lets look at OS65D3.3 directory track. This image was dumped using the
OSIDUMP programs on a real OSI, so there can be extra garbage in the disk layout
where the disk head was turned on or shut off.

Directory track is track 12. (0x0C) 0x0C * 0x900 = 0x6C00
Loading up the image we see:

006C00  43 57 12 58 76 01 01 4F-53 36 35 44 33 00 13 42  CW?Xv??OS65D3 ?B
006C10  45 58 45 43 2A 14 16 43-4F 50 49 45 52 17 18 43  EXEC*??COPIER??C
006C20  48 41 4E 47 45 19 20 43-52 45 41 54 45 21 22 44  HANGE? CREATE!"D
006C30  45 4C 45 54 45 23 23 44-49 52 20 20 20 24 24 52  ELETE##DIR   $$R
006C40  41 4E 4C 53 54 25 26 52-45 4E 41 4D 45 27 27 53  ANLST%&RENAME''S
006C50  45 43 44 49 52 28 28 53-45 51 4C 53 54 29 30 54  ECDIR((SEQLST)0T
006C60  52 41 43 45 20 31 31 5A-45 52 4F 20 20 32 33 41  RACE 11ZERO  23A
006C70  53 41 4D 50 4C 34 34 41-54 4E 45 4E 42 35 35 43  SAMPL44ATNENB55C
006C80  4F 4C 4F 52 53 36 36 4D-4F 44 45 4D 20 37 38 43  OLORS66MODEM 78C
006C90  4F 4D 50 41 52 39 39 23-23 23 23 23 23 00 00 23  OMPAR99######  #
006CA0  23 23 23 23 23 00 00 23-23 23 23 23 23 00 00 23  #####  ######  #
006CB0  23 23 23 23 23 00 00 23-23 23 23 23 23 00 00 23  #####  ######  #
006CC0  23 23 23 23 23 00 00 23-23 23 23 23 23 00 00 23  #####  ######  #
006CD0  23 23 23 23 23 00 00 23-23 23 23 23 23 00 00 23  #####  ######  #
006CE0  23 23 23 23 23 00 00 23-23 23 23 23 23 00 00 23  #####  ######  #
006CF0  23 23 23 23 23 00 00 23-23 23 23 23 23 00 00 23  #####  ######  #
006D00  23 23 23 23 23 00 00 47-53 76 02 01 23 23 23 23  #####  GSv??####
006D10  23 23 00 00 23 23 23 23-23 23 00 00 23 23 23 23  ##  ######  ####
006D20  23 23 00 00 23 23 23 23-23 23 00 00 23 23 23 23  ##  ######  ####
006D30  23 23 00 00 23 23 23 23-23 23 00 00 23 23 23 23  ##  ######  ####
006D40  23 23 00 00 23 23 23 23-23 23 00 00 23 23 23 23  ##  ######  ####
006D50  23 23 00 00 23 23 23 23-23 23 00 00 23 23 23 23  ##  ######  ####
006D60  23 23 00 00 23 23 23 23-23 23 00 00 23 23 23 23  ##  ######  ####
006D70  23 23 00 00 23 23 23 23-23 23 00 00 23 23 23 23  ##  ######  ####

Starting with 43, 57 is the start of track marker, then the track code in BCD (12)
Next the track type code $58 and the sector data

The sector starts with $76, the sector number $01, the number of sector pages (01)
and then the sector data, which happens to be a directory listing.
The end of sector marker appears to be $47, $53, at which point another sector may
be found. Note: Sometimes there are garbage bytes between sectors or between the start of track and the first sector, so reader code must account for that.
__Danny S.
Posts: 2
Joined: Mon Dec 05, 2011 2:02 am

Re: OSI memories

Post by __Danny S. »

Thanks for the info about the diskettes and diskette images. I guess I should have realized that, if the OS code that looks for sector headers, etc. is really being executed by the emulator, then the disk images would have to really mimic the raw layout of the disk tracks.

BTW, OS-65U did use 8N1 format for the ACIA, but that is all I can tell you about the differences in how the disk hardware was programmed between 65D and 65U. Probably the 65D EXAM command could dump a 65U track successfully.
__scowl
Posts: 1
Joined: Mon Dec 05, 2011 1:58 am

Re: OSI memories

Post by __scowl »

Here are my good and bad childhood memories of my first computer, the C1P:
  • Getting the 6502 up to a blazing 2 Mhz. Man, that was one super fast CPU. OK, not really.
  • Buying tons of expensive 2114's and burning my fingers soldering them. Some of them even worked. There was one absolute rule: you could never have enough capacitors. Bad data in the memory? Need more capacitors. Eventually they came out with single chips that had 32K of static ram, were twice as fast as a 2114 and used less power. Wow, did the future look bright or what?
  • The garbage collection bug in BASIC. The first, but no where near the last Microsoft bug to make my life hell..
  • Figuring out how to get the serial port to talk RS-232 without a 12V power supply (fortunately some devices would take +-5V).
  • Replacing the OSI power supply with a "switching" power supply. Amazing how that tiny little thing put out more juice than the heavy sizzling power supply screwed onto the case and it didn't even need a fan.
  • Building a parallel printer interface. I think it was just an addressable 8 bit latch plus another chip to make the strobe long enough for the printer to see there was a byte on the port. I don't remember how the printer kept the CPU from overlowing its buffer but I do remember this being one of the rare times I built something and it immediately worked.
  • Getting the 6502 assembler/disassembler. I could finally write some "real code". It had the feature to "relocate" 6502 code to a different base address by changing all the absolute addresses it found in the code... or whatever it thought was code. It also cheerfully changed any data that it thought was 6502 code, scrambling it in ways you could not predict.
  • Loading Sargon from tape. Speaking of scrambled data. This chess program was great, but not my copy. There was a click of noise on the tape that corrupted it. But how was it possible for me to still load it since the checksum should fail? Well, I learned that if you're really lucky/unlucky, corruption can cause bad data to have [i:1327fc9277]the same checksum[/i:1327fc9277] as the correct data. That's what was happening.
  • Video mod kits. How many were there? I know there was one to decrease the overscan so you could get 32x32 characters but I also did some other hack to get 32x64 characters. It mostly involved piggy-backing chips onto chips on the board. It took me forever to get it to work but I was only ten years old at the time. I learned all about how video displays worked (horizontal retrace, vertical blanking and so on).
  • Trying to use standard floppy drives. Apparently OSI didn't want us to do this. What was the deal with that data separator circuit which so many of us built? I swear it had a potentiometer that you adjusted to get proper data/clock separation. I felt very secure about my data knowing it's going through a circuit I had to tune with a screwdriver. And there wasn't a disk controller chip -- just a PIA and a serial chip and the rest was software. I think I bought a used five inch floppy for $400. Of course that will get you half a terabyte of hard disk now.
I actually used my 32x64 C1P as a terminal to a Unix machine at school in the 80's. I wrote a terminal program that used nonstandard control sequences (^A is up, ^B is down and so on) and wrote a termcap entry for it. And it worked! I could even use "screen" and the crude character windowing programs with it. I did lots of class work on that thing with a 2400 baud modem.
Post Reply