Hello Af-members,
it seems i am forced to replace a harddisk within a Vulcan harddisk system.
It seems the drive from Seagate has been patched with special information
within the track zero for use with the Vulcan controller by the people at
Applied engineering. The regular software itself won´t accept any other
drive from Seagate ( remark from software after attempt to write new partition:
"i don´t recognize this disk" ) from general market.
So the conclusion is that the guys at AE must have marked up the track 0
of the drives used in their system in special way that the controller would
recognize only drives with that patched track zero.
If anybody has replaced such a drive within tha last years with another harddisk
( not from another Vulcan system ) i would appreciate information on that exchange.
Otherwise i will be forced to enter after more then 30 years again back to
that "handy tools" like Locksmith, Copy II+ 9.1, and Merlin as well as the old
disassemblers ( probably first starting by searching that good old container
with the ORCA set of manuals and program related to the assembler there....
and after that all collected together start picking up the track zero from the
availiable drive and starting to analyze and debug that disk.
As for quite a lot parts of that age my drive has a damaged bad block in the
beginning of the disk and therefor refuses the updates, change or repartitioning....
and doing a low level format would be a very bad idea because that would delete
the precious information from the track 0 and the next track used by the AE engineers
containing the information required for smooth work with the firmware in the controller....
At the other hand just plugging in another IDE drive with 40 MB or 100 MB or even 200 MB
freshly just low-level formatted and not partitioned or formatted by anything else
doesn´t work... ( see reply from software mentioned above )......due to missing infos from patched track
ao unless the information patched by the guys from AE to the disk isn´t also patched with updated data
(according to the actual drive => amount of tracks, amount of sectors, amount of sectors i.e. blocks,
translationtable to VTOC and to proDOS as well as the initial proDOS heading of that drive and a kind of AE-ID byte ) to the replacement drive the controller won´t ccoperate and accept the drive for working,
partitioning and formatting....
any kind of information from cracks who entered that task -
or former employees from AE who have documentation to this topic are welcome ......
i even guess that the guys at AE had a disk within the company containing taht initial formatting programm that permitted just to enter the drive data with cylinders, heads and amount of sectors and the formatting programm
then writting this "special track" to the disk ready for use with the controller....
it might be a great deed to the public, after stopping the support of the Vulcan Harddisk system and releasing
the material to the public at the "Applied Engineering Repository" at http://ae.applearchives.com/
to release there the documents or the image of that disk to enable the Users of a Vulcan Harddisk System
and thereby granting them the chance to replace a drive, if that turned bad by age or damage....
sincerely speedyG
Don't discount the possibility that they instead used a custom string in the firmware of the drive, much like Apple did with SCSI drives.
Hello Dr.Webster,
thanks a lot for that reminder!
but unless i don´t analyze the track zero i can´t make proof of that....
and at least at SCSI that can be overcome with a trick....:
If i take another card like the RAMfast SCSI i may partition and format the SCSI-drive
and it might than be plugged to the Apple fast SCSI controller and will work....
i am hoping that similar procedure might also be used with IDE drives at the Vulcan system....
I bear in mind that this also might work if another ( non Vulcan drive ) IDE drive is plugged to the
older CFFA2 that still has the regular IDEport "onboard" and that - if the drives are partitioned
in a manner that Vulcan system might accept it - it would work at the Vulcan system if
the track zero contain the correct data for the access ( depending to the content of the controller
and its translationtable ).....
at least worth an examination.....before rejecting the controller or waiting for months for a
AE drive to come up at fleabay with the risks that it might turn out to be bad too...
sincerely speedyG
I don't know what kind of volume AE had, but I am personally doubtful judging from the quantity (and lack thereof) of Vulcan for sale over the years.
It might be easier to take apart the Vulcan utility and/or ROM than trying to find an intact MBR. I am inclined to think it should not be difficult, as some people purportedly have used CF cards with Vulcan HBA before.
If an antique Vulcan HD mechanism is available, I would suggest using a modern platform (think Linux) to extract the block, as the Vulcan HBA could block access to the MBR from non AE utilities.
just to avoid further useless replies, allthough i guessed the fact to be recogized by my initial posting:
1. I have a original harddisk from Vulcan system with mistake behind the MBR
2. but it´s still readable within the first gtoup of blocks - the disk error is behind the MBR and behind the first
couple of kilobytes....
3. I have extracted the track zero by hooking the original Harddisk from Vulcan system to CFFA2 and
i verified the content of that zero track after connecting back the harddisk to the Vulcan system
3. I have allready tried to connect a normal 40 MB, 100 MB and 200 MB Seagate IDE Harddisk resulting the error
explained above....
all the facts explained above would have not been availiable to me if i would have not solved
the tasks and obtained the results explained above....
so of couse i don´t need any explenation how to attempt information that i allready have accessed...
so i state here now:
i´m not hunting for diagnosis nor for hints how to attempt diagnosis.....
i have verified the most of the needed information ....
I´m therefor only looking for somebody who has really solved this task of decoding the content of the MBR of the vulcan system by himself and
who therefor realy knows by himself which kind of translation has been used in that system for translating the tracks and sectors to blocknumbers
and who realy knows which kind of technic the guys from AE have used to make the drives recognized by their controller....
or who has really detailed documentation beyond the manuals...
nothing else....
thanks
sincerely speedyG
*
Hello sfahey,
that is that far easy to be researched within several forums....
allthough the list is rather short only listing 2 "replacement drives"
there also is the following information availiable:
"It appears that the Gold upgrade allows more Cylinders, but still limits the heads to 4.
I tried some drives in the 125 meg range with 8 and 16 heads,no go. Also a 5 head drive would not work."
according to this statement i have updated the list of the useable drives to this list:
MODEL...........SIZE......CYL.....HDS.......SECT..........LZONE
Conner
CP3021..........20 MB.....615.....4.........17............615
CP3024..........20 MB.....615.....4.........17............615
CP30084.........80 MB.....903.....4.........46............903
CP3104..........100 MB....1547....4.........33............1547
CP30061G........60 MB.....762.....4.........39............762
CP30064.........60 MB.....762.....4.........39............762
CP30084E........85 MB.....903.....4.........46............903
Western Digital
WD93028-A.......21 MB.....615.....4.........17............616
WD95028-A.......21 MB.....615.....4.........17............616
WD93028-AD......21 MB.....615.....4.........17............616
WD95028-AD......21 MB.....615.....4.........17............616
WD93024-A.......21 MB.....615.....4.........17............616
WD90524-A.......21 MB.....615.....4.........17............616
WD93024-X.......21 MB.....615.....4.........17............616
WD95028-X.......21 MB.....615.....4.........17............616
WD95024-X.......21 MB.....615.....4.........17............616
Seagate
ST325AX.........21 MB.....615.....4.........17............0
ST125A..........25 MB.....615.....4.........17............0
ST9051A.........42 MB.....654.....4.........32............0
ST9080A.........64 MB.....823.....4.........38............0
but bear in mind that there are 2 keyissues:
in former days when harddisks entered the market there was always a problem by translating the amount
of sectors ( in DOS ) or blocks ( in proDOS ) to be used by the operation system.
This also resulted in those days to the large amount of "homebrew" patches to larger floppy disks
( with 640 kB ).....
one of the clues out of that habits was : THAT THE KEY TO ACCESS THE CORRECT AMOUNT OF BLOCKs at ProDOS WASN´T THE CONTROLLER - BUT RATHER MORE THE CONTENT WITHIN THE PARTITIONTABLE AND THE INITIAL TRACK 0 CONTENT telling the SYSTEM how many blocks have been availiable!
The fact that the amount of heads seem to be limited is a point rather more related to the content within the EPROM - it seems that there is a limitation made by the fear to excced limits of the results while performing the math to amount of sectors = amount of cylinders x amount of sectors per track !
and just to keep this ( because i know it and have tried it ) for the rest of this thread also off ...:
" I will explain how to use this undocumented feature for those of
you who haven't had the problem (yet?). Maybe it will save you a call
to the AE Customer Service. *WARNING* - this will destroy the
contents of your hard drive, so have a very current backup.
1) Boot the Partition Manager from a floppy (not the original,
would you really like to lose everything if something else
goes wrong?).
2) At the main menu, type "AE". I can't remember if you should
press return or not, so be careful.
3) When the program asks you if you want to save the BAD BLOCK
file, type "Y".
4) The computer will then take off and scan the hard drive for
bad blocks, informing you on the screen as it finds them.
Then the software will save the addresses of the bad blocks
to the hard drive.
5) Using the instructions that came with the drive, FORMAT the
partition(s) on the hard drive.
6) Using the instructions that came with the drive, RESTORE the
partition(s) on the hard drive.
7) Cold boot the computer."
this will of couse force me to also debug and disassemble the EPROM too
to find out where the limitaion has been made and why that limitation has been made....
in fact within proDOS other systems are able to handle sizes up to 1 GB and more just
by partitioning and by limiting the partitions to 32 MB !
Up to the moment there is no other reason that will explain this difference except that AE
was not aware of the fact that through larger amount of heads -
ProDOS would be able to handle that larger amount of space....
and yes i have read the Book "Beneath ProDOS" and several other books related to the Topic.....
and yes i have detailed knowledge about different Disk Operation Systems like UCSD, CPM and UNIX too...
so please don´t repeat anything out of such sources....
but it also forces ( after i did checkout partitioning a drive at the CFFA and formatting it there and
then plugging it to the Vulcan Gold and the controller refusing to accept that drive ) that the rejection
was forced by the limitation to only accept drives with 4 heads....
and that AE probably had used a own kind of "translation table" resulting from the interaction of the
EPROM with the provided software....
so back again to the point:
If i want to use a drive NOT from the list above, i seem to be forced to analyze the EPROM and the
way AE performed the writing of the track zero to harddisk by the provided software.....
and i´m searching if anybody has performed such attempt before and has results from such a research somewhere in the desktrayer...... that would shorten the task by cutting off the part of the task that has allready been performed....
I hope this also clears up, why i´m not searching for any kind of hints or suggestions...
unless you have not really performed a task of disassembling the EPROM or the track zero
THERE WILL BE NOTHING NEW THAT YOU CAN TELL ME !
... and i´d like to keep this thread short and precise
- without additional guessing around in space or nirwana...
sincerely speedyG
Hello AF-members,
according to the above made statement that the VULCAN GOLD should be able to support any drive with up to 4 heads
i´ve examined all my archived parameterlists for harddrives and updated the list from above to a new list now
containing all drives from all manufacturers that fullfill this condition. This is the new list of all drives with up to 4 heads:
MODEL SIZE CYL HDS SECT LZONE
Conner
CP3021 20 MB 615 4 17 615
CP3024 20 MB 615 4 17 615
CP3044 40 MB 1047 2 41 1047
CP4044 40 MB 1105 2 34 1105
CP30084 80 MB 903 4 46 903
CP3104 100 MB 1547 4 33 1547
CP30061G 60 MB 762 4 39 762
CP30064 60 MB 762 4 39 762
CP30084E 85 MB 903 4 46 903
CP30104 120 MB 1522 4 39 1522
Fujitsu
M2611T 45 MB 1334 2 17 1334
M2612T 90 MB 1334 4 17 1334
M2616T 124 MB 1542 4 33 1524
M2617T 124 MB 2010 2 40-64 2010
M2618T 248 MB 2010 4 40-64 2010
MAXTOR
7040A 50MB 1170 2 36 1170
7060A 76 MB 1402 2 36 1402
7080A 101 MB 1170 4 36 1170
7120A 153 MB 1516 4 42 1516
NEC
D3735 56 MB 1084 2 41 1084
D3755 130 MB 1250 4 41 1250
D3756 104MB 1251 4 41 1251
QUANTUM
GoDrvLPS52AT 52 MB 1219 2 17 1219
GoDrv-80AT 76 MB 1024 4 17 1024
GoDrvLPS105A 105 MB 1219 4 17 1219
GoDrvLPS120AT 120 MB 814 4 53 814
Seagate
ST325AX 21 MB 615 4 17 0
SR351A/x 51 MB 820 4 17 820
ST125A 25 MB 615 4 17 0
ST1057A 57 MB 940 3 34 1024
ST9051A 42 MB 654 4 32 0
ST9080A 64 MB 823 4 38 0
SR9096A 96 MB 1024 4 35 1024
ST3057A 57 MB 940 3 34 1024
ST3096A 96 MB 1024 3 35 1024
ST3120A 120 MB 1024 3 17 1024
ST3144A 130 MB 1001 3 17 1024
ST3283A 245 MB 978 3 35 1024
Western Digital
WD93028-A 21 MB 615 4 17 616
WD95028-A 21 MB 615 4 17 616
WD93028-AD 21 MB 615 4 17 616
WD95028-AD 21 MB 615 4 17 616
WD93024-A 21 MB 615 4 17 616
WD90524-A 21 MB 615 4 17 616
WD93024-X 21 MB 615 4 17 616
WD93048xx 48 MB 782 4 27 782
WD95028-X 21 MB 615 4 17 616
WD95024-X 21 MB 615 4 17 616
WDAC28 85 MB 1082 4 39 1082
WDAP2100 100 MB 1582 4 27 1582
OTHERS
SAMSUNG SH124 47 MB 820 4 28 820
SONY SRD3040 42MB 822 2 51 822
SONY SRD3080 85MB 844 4 51 822
TEAC SD-340A 43 MB 1050 2 40 1148
TEAC SD-380AT 86 MB 1050 4 40 1148
Toshiba MK-1122FC 43MB 1027 2 34 1032
sure replacement listed bold model no. - other drives may be used if limitation beyond 1024 cylinders is removed...
conclusion: due to the fact that the original 100MB drive from Seagate in the Vulcam Gold system
has 1024 cylinders it can be assumed that up to 1024 cylinders every drive should be able to be used as replacement within the Vulcan Gold system.....
as far up till now there is a statement that there seems to be a kind of restiction to the amount of tracks
( i.e. cylinders ) so that up till now, drives with more than 1024 cylinders might make trouble unless this hasn´t been verified to be wrong....
up till now there is the pure disassembly ( not yet analyzed ) of the Vulcan Gold Eprom availiable.
unfortunately this editor does not realy support forrmated text containing TABs....
therefor pick up the text from this page:
http://www.harrowalsh.de/Upload/VulcanGoldEpromdisassembledFormatted.txt
UPDATE:
for those members at AF fritter that dare to enter the deep dark dungeons of Assembler...
in the meantime i´m starting to pick apart the code of the EPROM.... first step by marking startpoints and endpoints of loops and marking up the subroutines.....
this is not completed yet but needed to be done before analysis can be performed....
i´ve uploaded the file in the current status and the progress might be a good exercise for those members to followup the progress, if that members want to learn some stuff about machinecode and assembler....
the file can be viewed with the following linjk as pdf in the current status:
http://www.harrowalsh.de/Upload/EpromAnalysis1.pdf
the file can be downloaded in curent status:
http://www.harrowalsh.de/Upload/EpromAnalysis1.doc
that´s results up to the moment......
sincerely speedyG
Hello to all AF-members out there.....
without comment:
sincerely speedyG
Hello to all AF-members...
in the meantime the analysis of the ROM from the Vulcan Gold Card has made some progress ......
the file containing the partialy analyzed code may be downloaded from:
http://www.harrowalsh.de/Upload/EpromAnalysis1.doc
or viewed by clicking to the link:
http://www.harrowalsh.de/Upload/EpromAnalysis1.pdf
and viewing the pdf file from that document....
sincerely speedyG
Hello to those AF-members
following up this thread and the task...
at this point a short explenation of the executed processes:
At the beginning i just picked the first 4 kB of the Eprom, because that´s the part that will be used by the
access to the harddisk. But in fact the entire EPROM has size of 16 kB and after formatting the first 4 kB
of the code i added the additional 12 kB to the disassembling listing.
This additional 12 kB contain the part that is loaded to the RAM while executing tasks from the programs on disk....
For example if you call the program partmanager.bas from the disk it only contains the menus of the
partitionmanager, but the real accessing part of the programm is loaded from the additional 12 kB to the
RAM and "added" by load to the menu ( as level below of the menu ) and very specially also the part of
the program, that is invoked if the Option is chosen by the hidden "AE"-command, which will check the disk
for bad blocks and add that list of bad blocks to the disk aiming to exclude this blocks from being used
by the software or the operationsystem and the part of the program that performs the low-level format of the disk.
This part of the Eprom has for example parts, that contain commends to execute to subroutines within fixed
adresses within RAM-space.... but unless later the "Loader-programm" isn´t examined, you can´t determine which
part of the Eprom will be loaded to which part in RAM and you therefor can´t determine which part of subroutines
is performed within the "Eprom-space" and which will be invoked within the RAM-space.....
anyhow it´s a quite timeeating process to disassemble that additional 12 kB too and to analyze where that parts
of the program will be loaded to.... so it might take another 2 or 3 updatings of the files ( behind the links given
above ) till the entire formatting for better readability and better analysis of the structure will be completed....
at the moment i guess that the entire formatting and marking up of the structure commands will be completed up
till monday or tuesday.... taking every 2 days a view to the given links will show the progress in the task.....
and besides it also shows, how to make an attempt to such a task and therefor learning some special things about assembly language...
like preparation of memoryspace ,
move of program from EPROM to RAM within the small availiable window of the interface card,
interaction of the interface picking an entire track from harddisk and
moving that track to RAM,
examining that track,
modifying a entire track,
writing such a entire track to harddisk
and verifying a written track with the content in RAM and so on....
in further postings i will add additional information with advancing progress of the task
and pointing to special routines within the assembler code .....
sincerely speedyG
Hello to the AF-members
following this thread.....
in the meantime i have started analyzing the loops within the program and
breaking them down to smaller functions..... the current status can be viewed by the link:
http://www.harrowalsh.de/Upload/EpromAnalysis1.pdf
this contains the status up to now ( little more than half of the disassembled code .... )
i guess that tommorow the rest of the code will be teared apart to it´s smaller loopings within the code....
next step will be then on tuesday to allocate all adressing calls and jumps to adressing within the proDOS-code
to identify the parts related to the passover of parameters to proDOS.....
following the steps performed up till now shows how the process of disassembing the code
and identifying the different smaller codeblocks helps to identify the relations of the code within the code
to the internal parts of the code......
this also shows that, if somebody wants to reenginmeer a interfacecard, the most work is not related
to the analysis of the hardware - but rather more to the software within the EPROM or the related program
if no sourcecode in Applesoft is availiable.... it´s plenty more work to analyze machinecode....
sincerely speedyG
Hello to the AF-members
following up this thread.... allthough i´ve complete the analysis of the loopings in the code,
i´ll delay the update of the pdf-file at the moment....
the reason is that i now will enter back to the days 25 years ago and refresh my knowledge about the MLI
of ProDOS. This will be required to uncover the access to the harddisk, because in level of machinecode
there are 3 different components of machineccode present in memory...:
Prodos and it´s MLI ( Machine Language Interface ) and
it´s "global page" which contains the "entry-points"
to access the codeparts used by ProDOS,
the code from the EPROM which contains the access to the harddisk
by a kind of device-driver also in Machinecode,
and the programs from disk like the partition manager, that also
is resident in memory as Machinecode....
- and besides the point that there is quite intense switching between the languagecard
( containing parts of ProDOS )
and the slot with the Vulcan Gold Interface card with the EPROM
and the code inside and the "normal memory" with the program present....
not to fotget the zeropage used by
the Apple itself and ProDOS and partially also by Applesoft....
turning "back to the roots" is demanded, because all parts mentioned above make "calls"
by JSR commands in Assembler
to such fixed adresses and then perform specific tasks
and by refreshing my knowledge will help me to identify that specific tasks.....
accesses to the MLI for example might contain parameters which specify subroutines withing the general command
routines....
and this will be requested knowledge for further identification of program and/or EPROM routines....
i´ll issue notice when the documentation will be updated and the analysis will be continued....
sincerely speedyG
SpeedyG,
TRULY, you're a wild-man! Lots of work here. I'm sure other watchers of this thread agree.
I wish I had the time and dedication. Maybe in about 6 years when I decide to retire!
Hello macnoyd,
to get that far in the stuff would require at least several months and seriously studying the
"Beneath ProDOS" book from Don Worth and Pieter Lechner and serious attempt the programming with assembly language....
i could have saved several weeks if one of the 2 guys from AE would be here at AF:
Phil Montoya and Bob Cedarlof have written the code for the Vulcan Gold Interface
and getting in touch with the original source code of that ROM would permit immediate modifications, instead of forcing me to disassemble the entire code and analyzing it to locate
the point where modifications must be made for updating that code....
i really would have appreciated if one of that two former employees from AE would have
joined this thread and have given me some support....
but that seems to be just a wish to be saved for Santa Claus... and i guess i´ll be finished before his arrival...
sincerely speedyG
Speedy, I used to fit these and we sourced some replacement drives once as we had some failures, we tried loads of drive we had in the service department but none would work, then one day a compaq or something turned up and one of the old guys low level formatted it and stuck it in a Vulcan and it worked, we ordered about 10 of these parts using the OEM number and about 3 different drives turned up any only 4 of them were the same an also worked.
What is the exact part number of the original drive, maybe we can see if we can find one for you to try ?
*
Hello Clint,
unfortunatly i can´t tell any partnumber....
but i have performed excesive search about the topic and found that there only seem to be 2 limitations:
maximum 4 heads and maximun 1024 cylinders.... i marked that drives with bold writing...
if the drive fullfills that 2 conditions it seems that i should lowlevel format that drive
with maxllf.exe ( which i have ) to remove any former partitions and the regular track zero
written to the replacement drive and then connect the drive to the Vulcan Gold Controller ...
there after i should activate with the "AE" key the option to "write block 2" and thereafter
the Vulcan Gold will perform a second low level format and add bad blocks to it´s "internal homebrew" drivelist...
then i might be able to partition and format the drive with the regular Vulcan Gold Utilities.....
by the given limitations i have created a list of drives that full fill at least
the 1st spec. ( 4 heads maximum )
and then within the list we can assume all drives with up to 1024 cylinders to be "safe choice"...
model no. witten bold
those with more than 1024 cylinders must be assumed at the moment to be "not safe choice"....
model no. written normal
if you have any drive listed with this limitations from the listing above i will be happy to test it...
the decoding of the firmware has been started to locate the 1024 limitation and
if starting with that task it makes sense to also search for the location of the limitation to 4 heads too....
that would enable at later point to update the Vulcan Gold controller with new EPROM and the feature
to handle other drives too ( like those with larger amount of cylinders beyond 1024 ....
and probably if also code is located with more than 4 heads... )
- there will be anyhow the limitation left that with the Vulcan Gold controller only the first 2 partitions
will be formatted with "regular" utilities and the later partitions must be treated with the DAVEX utilities .....
- at least unless the program on the Vulcan Gold disk isn´t modified and patched...
sincerely speedyG
just repeating stuff from above ??? see posting no. 6......
i thought that i have mentioned above that the thread should be kept clean from entries without new information...
There is no need for this behavior; sfahey was just trying to help.
Hello Dr. Webster,
the point is - if you would have viewed the postings above ( including the first one from sfahey,
and my reply ( posting no. 6 ) that i replied first time very polite....
i´d at least expect him to read the reply ....
in that reply the point he now again just repeated was mentioned by me....
in my polite reply i also mentioned that only replies would be expected by persons,
that have seriously taken closer view to the problem and that no repeatings from
googled results or repeatings from books would bring me ahead.....
and that therefor i would be gratefull to keep this thread short and precise...
therefor i would at least expect him not to add further repeating to this thread....
he didn´t respect that....
therefor my short reply and rejecting posting to mention him to at least read replies before adding
wasted posts....
it seems he doesn´t like to react to polite replies and demands for "clear words"...
besides we have met in several threads and he should have recognized that i´m not a newbie...
and he therfor shouldn´t treat me like one...
and by such postings we´re filling this thread with crap.... a thing i wanted to avoid...
next time he runs for the admin, i think it would be good idea to check the accuses ...
and it would be nice to waste a few minutes to the reply... maybe the reply reminds to own behaviour ?
sometimes it´s just not enough to only read the last postings....
at least if someone want´s to get the entire story....
up to my understanding the sense of threads is still exchange of information and not just adding posting with
"so called info" of things mentioned allready before in the same thread just few postings before....
sometimes i guess some poeple just show up presence to yell:" hello i´m here! " regardless of the previous postings
why should they read the previous postings ... it´s not usefull to view what has been mentioned before ???
that isn´t polite at all.... why wasting space for redundancy ??? reading same stuff again and again ?
that really doesn´t bring anybody ahead... it´s just wasting space...
sincerely speedyG
For the record, I didn't complain to anyone. There wasn't any need to.
I won't waste any more of your time. If you're involved in a thread, I'll just steer clear.
Hello AF-members,
in the meantime i have updated the entire PDF-file....
next step will be to identify similar groups of commands.....
a view to page 96 will be usefull for the explenation.....
i´ve marked up there a group of 3 JSR-commands as "macroroutine"
this group appears in more than a dozend pages only differing by the final fourth command....
that fourth command differs though being a JSR- command at most of the pages by the adress to
that JSR differing nearly each time by exactly hex 100 .... that indicates that each time the following code
has length of hex 100 ....
there are several kind of macros with similar attributes...
locating them will uncover larger similar commands from the source coding...
for example: the read, write or modify track commands
allways use same group of commands to collect the total amount bytes of sectors from disk to memory
or from memory to disk and
assembling the contents of the sectors to a complete track
before the following command determines,
if that entire block of bytes resulting from the track
shall be read, written or altered...
so the markup of such macros will be the next step of detecting structures in the disassemled code....
sincerely speedyG
It would work at the Vulcan system if the track zero contain the correct data for the access.