Greetings: We need to locate whatever installation software is necessary to permit Apple UCSD Pascal 1.1 to recognize the Pascal volumes on a Sider drive; standard Pascal 1.1 booted from floppy doesn't recognize the drive although a boot track writer program for the Xebec (XBOOT.COM.CODE) will write the boot track to the HOME volume from standard floppy- booted Pascal. If one boots Pascal from the Sider, the running system expects the root volume to be on the floppy which was the root volume when creating the boot track (instead of the Sider's root volume) and of course the running system doesn't recognize the Sider's Pascal volumes. There must have been a custom loader or other patches to permit Pascal to use the drive. All replies much appreciated. Regards, Michael Grigoni Cybertheque Museum Michael Grigoni wrote: > Greetings: > > We need to locate whatever installation software is necessary > to permit Apple UCSD Pascal 1.1 to recognize the Pascal > volumes on a Sider drive; standard Pascal 1.1 booted from > floppy doesn't recognize the drive although a boot track > writer program for the Xebec (XBOOT.COM.CODE) will write > the boot track to the HOME volume from standard floppy- > booted Pascal. > > If one boots Pascal from the Sider, the running system > expects the root volume to be on the floppy which was > the root volume when creating the boot track (instead of the > Sider's root volume) and of course the running system > doesn't recognize the Sider's Pascal volumes. > > There must have been a custom loader or other patches > to permit Pascal to use the drive. I was under the impression that the Siderware Pascal utilities were suposed to do just that. Do you have a Sider manual that covers the Pascal installation process? The later manuals seemed to have skipped this even though the software shipped with the drive. The utilities you can download from my site at http://homepage.mac.com/wayne_stewart They're under manuals -> sider I didn't name the disk images since I assumed all six would be downloaded. The Sider D4 manual there doesn't mention Pascal. If you need the Pascal installation and utilities instructions I can get those from an earlier manual. Wayne Thanks Wayne for your help. > > > > We need to locate whatever installation software is necessary > > to permit Apple UCSD Pascal 1.1 to recognize the Pascal > > volumes on a Sider drive > > If you need the Pascal installation and > utilities instructions I can get those from an earlier manual. > I would really appreciate getting the earlier Pascal instructions; there is nothing on the D4 diskettes (from your site) which describes or controls the installation of Pascal onto the drive. One can set up the Pascal partition and format (zero) the four volumes (with either your D4 software or our earlier Xebec V2 software but I didn't find a program to 'patch' Pascal 1.1 to permit it to recognize the drive. The Pascal 'backup' diskette (number 5 in your set) contains Pascal 1.3 versions of SYSTEM.APPLE SYSTEM.PASCAL SYSTEM.LIBRARY and a SYSTEM.STARTUP which is a backup/restore utility for Sider firmware versions newer than what we have. This program will run on our system but declares the firmware too old and shows no Sider on line; the menu describes vanilla backup and restore operations and doesn't give a clue as to whether a 'restore' would 'patch' Pascal to recognize the Sider volumes. Our hope is to restore a collection of software rescued from a failing 20MB drive onto a new drive (for a high-end graphics workstation ca. 1984); all files from the old drive's DOS3.3 and four PASCAL volumes were saved to floppies. I would like to salvage the Pascal boot loader from the old drive; anyone have a sector editor which would work on the Sider? I tried connecting the drive to an IBM-PC/SCSI system with a SCSI low level inspection program; not having access to our SASI specifications at the moment I can't say why but only one-quarter of the total logical blocks on the drive are visible to the inspector. Note that the D4 Sider software refers to SCSI and not SASI drives. Anyone have any earlier 'Siderware'? Regards, Michael Grigoni Cybertheque Museum remove "REMOVETHIS" from the email address to reply. Thanks again Wayne for your efforts! According to your D2 manual pages, stock Apple Pascal 1.1 should recognize the Sider's Pascal volumes when the floppy is booted from the Main Menu; I had expected this behavior on our system but this is where the problem lies. Floppy booted Pascal, whether cold or warm booted fails to recognize the volumes. This is of course using the early version of the Xebec software which we rescued from the original hard drive. This system is part of a high-end CAD workstation; all of the Xebec code is dated 1981 through 1984. The Xebec HBA and bridge controller are OEM; the utilities on the original drive are recognizable as components of Siderware, although there is no reference to the drive by that name and all company references are to Xebec and Datamac. There must have been some additional installation code to prep the Pascal volumes in some way to make them appear on-line to Apple Pascal. The OEM utility to create the volumes (names them and zeros them) succeeds; the OEM utility to change Pascal unit numbers also works. There is an OEM Pascal program 'XBOOT.COM.CODE' which successfully creates the Pascal boot loader on the drive so that 'SYSTEM.APPLE' is loaded from the drive; however the 'HOME' volume never appears on-line so Pascal looks to the floppy to complete the boot. After booting, no hard disk volumes appear on-line in Filer. I will start fresh with your version of Siderware as an experiment; if the firmware compatibility remains an issue, I'll appreciate getting the binary you offered and I'll burn a new prom. Michael Wayne Stewart wrote: > > I scanned all the parts of the D2 manual that seemed relevant. You > can find them at http://www3.telus.net/waynes/Sider_D2/ > > The software that came with the D2 I have here seems to have the same > part number as the software for my D4, I'll check and see if it is > actually the same. I have another Sider stored at another location that > may have different software but I won't be able to get by there for a > few days. > > One option if the software doesn't work with the ROM version on your > card might be to try a later ROM. If you're able to burn one I can > forward the binary file or if not then I can email you a copy. > > Wayne "John B. Matthews" wrote: >In article <40C1576B.E24A585C@REMOVETHIScybertheque.org>, > msg wrote: > >> Thanks again Wayne for your efforts! >> >> [...] >> >> There must have been some additional installation code to prep >> the Pascal volumes in some way to make them appear on-line to >> Apple Pascal. > >I seem to recall a utility named SYSTEM.ATTACH that was used to >bind drivers to unit numbers. I used it with a RAM disk driver >and OKS Cache Card Pascal driver. It appeared on the volume >named APPLE4: with Pascal 1.3. Previously it had been sold by >Call-APPLE. Sadly, I can't find the docs, but it might be the >missing piece. > If you want doc's on system.attach, look at the book by Randy Hide: http://www.cs.ucr.edu/~rhyde/psource.htm A large appendix contains the official document on attaching devices. Not specific about the Sider though. The book further explains a lot about UCSD and the Apple Pascal implementation. It's often available on amazon.com Hans, http://www.hansotten.com Hans Otten wrote: In Randell Hydes cv I read he developed drivers for xebec: Xebec 1981 Consultant Designed device drivers for UCSD/Apple Pascal system for Xebec hard disk. http://www.cs.ucr.edu/~rhyde/resume.htm Maybe he could help! Hans, http://www.hansotten.com John, Thanks much for your reply. > I seem to recall a utility named SYSTEM.ATTACH that was used to > bind drivers to unit numbers. I used it with a RAM disk driver > and OKS Cache Card Pascal driver. It appeared on the volume > named APPLE4: with Pascal 1.3. Previously it had been sold by > Call-APPLE. Sadly, I can't find the docs, but it might be the > missing piece. > Sadly, we don't have any Apple Pascal printed documentation; we're extrapolating from IBM UCSD P-system materials. I now know that there was dynamic device driver support available for versions of Apple Pascal; this excerpt is from a Technote: The Boot Process The boot code (contained in blocks 0 and 1 of the boot disk) is loaded into memory by the Autostart ROM. It checks for the P-machine file and loads it into RAM. The P-machine, in turn, brings in and initializes the Run-time operating system. (In the case of a two-stage boot, the message "Insert boot disk with SYSTEM.PASCAL on it, then press RETURN" appears after the P-machine has been loaded. The user should then insert the second-stage boot disk and press the Return key, which results in the operating system being loaded and initialized.) The first noteworthy action taken by the operating system is to execute SYSTEM.ATTACH, if that utility program is available on the Vendor Product Disk. Remember that SYSTEM.ATTACH must not be present on the Vendor Product Disk unless special, low-level I/O drivers must be bound into the system. As explained more fully in Apple II Pascal Device and Interrupt Support Tools, SYSTEM.ATTACH uses two special data files and will fail if these files are not present on the boot disk. However, there is no file 'SYSTEM.ATTACH' or its data files on the root volume (or any volume) of the original hard disk, yet the original system boots properly and recognizes the Xebec Pascal volumes. Curiously, there also is no 'SYSTEM.ATTACH' as a directory entry on any of the Siderware disks from Wayne's site, and the contents of disk4 is a bit bizarre: it contains a single 2 block program called 'QUIT.CODE', however upon inspecting the remaining unused area on the disk one finds a great deal of code with imbedded strings containing references to 'SYSTEM.ATTACH' and I/O primitives, snippets of Assembler and Pascal source, and a menu for backup and restore operations. Unfortunately, running 'QUIT.CODE' on our system merely corrupts and screen and exits to the monitor. Unless there is some 'hidden file' mechanism at work on our original disk, there must have been some installation program which statically linked Xebec drivers into the P-system somehow. Anyone have any Xebec support tools from about 1981 to 1983? Michael In article <40C20313.9338ABD3@REMOVETHIScybertheque.org>, msg wrote: > John, Thanks much for your reply. > > > > I seem to recall a utility named SYSTEM.ATTACH that was used to > > bind drivers to unit numbers. I used it with a RAM disk driver > > and OKS Cache Card Pascal driver. It appeared on the volume > > named APPLE4: with Pascal 1.3. Previously it had been sold by > > Call-APPLE. Sadly, I can't find the docs, but it might be the > > missing piece. > > > > Sadly, we don't have any Apple Pascal printed documentation; we're > extrapolating from IBM UCSD P-system materials. I now know > that there was dynamic device driver support available for > versions of Apple Pascal; this excerpt is from a Technote: > > The Boot Process > > The boot code (contained in blocks 0 and 1 of the boot disk) is > loaded into memory by the Autostart ROM. It checks for the > P-machine file and loads it into RAM. The P-machine, in turn, > brings in and initializes the Run-time operating system. > (In the case of a two-stage boot, the message "Insert boot disk with > SYSTEM.PASCAL on it, then press RETURN" appears after the P-machine > has been loaded. The user should then insert the second-stage boot > disk and press the Return key, which results in the operating system > being loaded and initialized.) The first noteworthy action taken by > the operating system is to execute SYSTEM.ATTACH, if that utility > program is available on the Vendor Product Disk. Remember that > SYSTEM.ATTACH must not be present on the Vendor Product Disk unless > special, low-level I/O drivers must be bound into the system. As > explained more fully in Apple II Pascal Device and Interrupt Support > Tools, > SYSTEM.ATTACH uses two special data files and will fail if these files > are not present on the boot disk. > > However, there is no file 'SYSTEM.ATTACH' or its data files on the > root volume (or any volume) of the original hard disk, yet the original > system boots properly and recognizes the Xebec Pascal volumes. > > Curiously, there also is no 'SYSTEM.ATTACH' as a directory entry on > any of the Siderware disks from Wayne's site, and the contents of > disk4 is a bit bizarre: it contains a single 2 block program called > 'QUIT.CODE', however upon inspecting the remaining unused area on > the disk one finds a great deal of code with imbedded strings > containing references to 'SYSTEM.ATTACH' and I/O primitives, snippets > of Assembler and Pascal source, and a menu for backup and restore > operations. Unfortunately, running 'QUIT.CODE' on our system merely > corrupts and screen and exits to the monitor. > > Unless there is some 'hidden file' mechanism at work on our original > disk, there must have been some installation program which statically > linked Xebec drivers into the P-system somehow. > > Anyone have any Xebec support tools from about 1981 to 1983? > > Michael Here's an example of a simple driver using system.attach, attach.drivers and attach.data: http://web.pdx.edu/~heiss/technotes/pasc/tn.pasc.16.html BTW, I erred above: The disk is named "ATTACH:", not "APPLE4:". It's available here: http://store.syndicomm.com/product_info.php?cPath=2_23_27_29&prod ucts_id=55 Of course, Xebec may not have used this approach to bind their driver. John ---- jmatthews at wright dot edu www dot wright dot edu/~john.matthews/ Progress made; I can now access the Sider volumes from a floppy-booted system. I found that 'disk4' contained the drivers as purged files and after recovering those and copying 'SYSTEM.ATTACH', 'ATTACH.DRIVERS', and 'ATTACH.DATA' to the boot floppy (there are versions for 1.1, 1.2 and 1.3), the hard disk volumes are on-line. > > Curiously, there also is no 'SYSTEM.ATTACH' as a directory entry on > any of the Siderware disks from Wayne's site, and the contents of > disk4 is a bit bizarre: it contains a single 2 block program called > 'QUIT.CODE'... Still, these were absent (purhaps purged?) from our working original system. > Unless there is some 'hidden file' mechanism at work on our original > disk, there must have been some installation program which statically > linked Xebec drivers into the P-system somehow. As a test I will purge these files from the working boot floppy and see what happens. Michael Note: our work involves Xebec software V2.2 and firmware V3.1. > Progress made; I can now access the Sider volumes from a floppy-booted > system. In summary: After setup of the Pascal partitions and volumes using "INSTALL PT#4", create a Pascal 1.1 boot floppy which contains the 'SYSTEM.ATTACH' and the proper 'ATTACH.DRIVERS' and 'ATTACH.DATA'; boot from this floppy to access the Sider volumes. One may now copy files from floppy to the hard disk's volumes. Problems remain in creating the proper Pascal boot area on the Sider. The program 'XBOOT.COM.CODE' will write a copy of the running system (including the bound hard disk drivers) to the boot area; however when this system is cold booted, it expects volume #4 to be in floppy drive A regardless of what unit numbers are assigned to the hard disk volumes (using the Xebec utility for that purpose -- resident on the DOS3.3 VOL001). This boot area is evidently separate and distinct from the root volume boot sectors which are unused. The only file referenced on the floppy (unit #4) is 'SYSTEM.PASCAL'; there is no need for the driver 'attach' files to reside on the floppy or on the 'root' hard disk volume; this explains their absence from our original hard disk. If one could change the assignment of the root volume after booting from floppy, from #4 to (say) #9, and then write the boot area, the cold boot process should work. Can anyone help with this? Or perhaps someone versed in the internals could advise where to look in memory or in the written system image for the root volume parameters, and how to patch them. Regards, Michael In article <40C3EFFA.B5AE5BAF@REMOVETHIScybertheque.org>, msg wrote: > Note: our work involves Xebec software V2.2 and firmware V3.1. > > > Progress made; I can now access the Sider volumes from a floppy-booted > > system. > > In summary: After setup of the Pascal partitions and volumes using > "INSTALL PT#4", create a Pascal 1.1 boot floppy which contains the > 'SYSTEM.ATTACH' and the proper 'ATTACH.DRIVERS' and 'ATTACH.DATA'; > boot from this floppy to access the Sider volumes. > > One may now copy files from floppy to the hard disk's volumes. > > Problems remain in creating the proper Pascal boot area on the > Sider. The program 'XBOOT.COM.CODE' will write a copy of the > running system (including the bound hard disk drivers) to the > boot area; however when this system is cold booted, it expects > volume #4 to be in floppy drive A regardless of what unit numbers > are assigned to the hard disk volumes (using the Xebec utility > for that purpose -- resident on the DOS3.3 VOL001). This boot > area is evidently separate and distinct from the root volume > boot sectors which are unused. > > The only file referenced on the floppy (unit #4) is 'SYSTEM.PASCAL'; > there is no need for the driver 'attach' files to reside on > the floppy or on the 'root' hard disk volume; this explains > their absence from our original hard disk. Would this suggest that the ATTACHed driver was only needed to get files on to the hard drive in the first place? Could Xebec be using firmware for subsequent operation? > If one could change the assignment of the root volume after > booting from floppy, from #4 to (say) #9, and then write the > boot area, the cold boot process should work. This is how ATTACH itself works. It manipulates entried in a user driver jump vector table, pointed to by $E8/E9. In 1.1, this points to $FE80, and maps to the last block of SYSTEM.APPLE. This table is followed by the unit table at $FEB0. Presumably Xebec is patching the table on disk to mount selected volumes at boot time. The volume named ATTACH: has a utility named ATTACHUD.CODE to create new ATTACH.DATA files, and I see a utility named SHOWAD.CODE that looks like it might list the contents of your existing ATTACH.DATA file. > Can anyone help with this? Or perhaps someone versed in the > internals could advise where to look in memory or in the > written system image for the root volume parameters, > and how to patch them. The references already mentioned (Randy Hyde's book "p-Source", and Barry Hynes "Attach-Bios" paper) will only tell you how a system might be built. That might enable you to reverse engineer the Xebec setup. > Regards, > > Michael John ---- jmatthews at wright dot edu www dot wright dot edu/~john.matthews/ Thanks much John for your reply; you've shown me the path. I apologize for failing to study Barry's paper more carefully; I was distracted by the cold-boot issue and this reference in his paper diverted my attention: Since these drivers are configured into the system after the operating system starts to run, this method will not work for configuring drivers for devices that the system must cold boot from. Some of supporting code in the RSP, boot and Bios may make the task of bringing up boot drivers easier though. > > If one could change the assignment of the root volume after > > booting from floppy, from #4 to (say) #9, and then write the > > boot area, the cold boot process should work. > > This is how ATTACH itself works. It manipulates entries in a > user driver jump vector table, pointed to by $E8/E9. In 1.1, > this points to $FE80, and maps to the last block of > SYSTEM.APPLE. This table is followed by the unit table at > $FEB0. Presumably Xebec is patching the table on disk to mount > selected volumes at boot time. It appears that I should try to generate an ATTACH.DATA which specifies units 4,5,11, and 12 and boot with this as the next experiment. The existing ATTACH.DATA contents: 0000 4d 53 43 39 37 30 30 20 00 00 00 00 30 1e 00 00 MSC9700 ....0... 0010 00 a0 I have ATTACHUD.CODE but not the source so deciphering the above would probably require creating some ATTACH.DATA examples with various values and examining the differences for clues. In the alternative, if you don't mind us getting a disk image of that ATTACH: volume with SHOWAD.CODE, things would go a bit faster. The driver name is obviously MSC9700. > > The volume named ATTACH: has a utility named ATTACHUD.CODE to > create new ATTACH.DATA files, and I see a utility named > SHOWAD.CODE that looks like it might list the contents of your > existing ATTACH.DATA file. > Fortunately, the cold boot process involves loading a snapshot of the last running system (which will contain the bound drivers) and the attach process at that point is not needed. The program XBOOT.COM.CODE writes the boot area; if the running system doesn't reference the floppy for the root vol. the booted system won't either. Regards, Michael