PDA

View Full Version : Booting Cromix on a Cromemco System One - help needed!



MattisLind
September 20th, 2015, 06:31 AM
I have worked a little bit with a Cromemco System One lately, XPU card, 2 Mbyte of memory, 5,25 inch floppy and a hard drive.

Today I used IMD to create two bootable floppies. One from David Dunfields collection, C2063D1.IMD and one from the collection of Marcus Bennett, 621CR167.IMD.

The first one gave this result rather quickly:


Preparing to boot, ESC to abort

Standby
Cannot boot CROMIX


The latter was stepping around on the floppy reading things but finally stopped.


Preparing to boot, ESC to abort

Standby

There are quite many different boot disks. Which one is suitable for a 68010 based XPU system? If something is broken, how can I do some kind of diagnosis? Which processor is printing the words "Standby" (what does it mean?) and "Cannot boot CROMIX" ? Is it the Z80 or the 68010?

Comparing with the manual, the next step shall be a memory test. But that never happened. I waited at least a minute.

I am now going to pull out all cards except XPU, Memory and the floppy controller to see if there would make any difference.

Advice, please!

MattisLind
September 20th, 2015, 07:11 AM
An update:

No, pulling cards didn't make any difference.

However I tried to study the behavior:

1. It accesses the floppy and prints "Standby".
2. There is a few head movements on the floppy drive.
3. It prints a CR /LF on the terminal
4. The green light on the XPU board goes out.
5. Yet a few more head movements on the floppy drive.
6. Then the red light on the floppy goes out.

From the schematic I get that the green led is controlled by the 68/-Z80 signal. It seems to light in Z80 mode and go out in 68k mode. It appears that switching to 68 k mode is not a very happy moment, although it seems to do a few floppy accesses. Maybe it is not finding the correct boot disk? Or cannot read it. It is not very informative, unfortunately.

amouse
September 20th, 2015, 09:52 AM
Hello there.

So pleased you are reviving another Cromemco system.

Well the disk 621 IMD image is a bootable 68010 image suitable for an XPU, i.e. not suitable for a Z80 system or a 68020 CPU system.

It should work!

I think in order of boot testing

First start RDOS and press escape. Then the T and TZ commands to test some memory etc

can you do at the RDOS level

a;;; set to small disk a
s20 seek to track 20


Assuming you can seek the disks then I'd try booting the following in order of complexity

a) disks 005, 009 for a CDOS boot

b) disk 200, which is a Z80 cromix 11.27 boot

c) disks 610 or 621 to boot a 68010 operating system

Regards Marcus

billdeg
September 20th, 2015, 03:25 PM
disk 200, which is a Z80 cromix 11.27 boot

What is the full file name? C200????.IMD

Thanks

Bill

MattisLind
September 20th, 2015, 10:42 PM
Check out Marcus huge repository (http://maben.homeip.net/static/S100/index.html) of S100 stuff and other things. This is the Cromemco (http://maben.homeip.net/static/S100/cromemco/code/disks/index.html) directory. Disk 200 is 200C1127.IMD (http://maben.homeip.net/static/S100/cromemco/code/disks/200C1127.IMD).

MattisLind
September 20th, 2015, 11:01 PM
Hello there.

So pleased you are reviving another Cromemco system.


Thanks! Your effort to preserve all the contents stored at your site is just amazing!


Well the disk 621 IMD image is a bootable 68010 image suitable for an XPU, i.e. not suitable for a Z80 system or a 68020 CPU system.

It should work!

I think in order of boot testing

First start RDOS and press escape. Then the T and TZ commands to test some memory etc

can you do at the RDOS level

a;;; set to small disk a
s20 seek to track 20


I ran the T command. And that looked fine:



Preparing to boot, ESC to abort
^[
^[
;^[
;
;T

Bank 0 > 0 1 2 3 4 5 6 7 8 9 A B C D E F
^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^
Type (F, H) F
Drive (A-D) A
Size (L, S) S
Speed (F, S) S

Seek Tests
01 OK 02 OK 03 OK 04 OK 05 OK
06 OK 07 OK 08 OK 09 OK 00 OK
27 OK 10 OK 20 OK 00 OK 01 OK
Restore OK
27 OK
Read/Write Tests
Data Read OK
Write Test MAY DESTROY Data
CR=Proceed ESC=Abort
Pattern Write OK
Pattern Read OK
Pattern Compare OK
Data Write OK

A;;;

;


Seek works as well.

So with this in place I am now going to look into creating a few new disks to try to boot from. Need to dig out the old disk copying PC again.


Assuming you can seek the disks then I'd try booting the following in order of complexity

a) disks 005, 009 for a CDOS boot

b) disk 200, which is a Z80 cromix 11.27 boot

c) disks 610 or 621 to boot a 68010 operating system

Regards Marcus


BTW, the machine is equipped with: XPU, two 1024KZ, BIART, OCTART, STDC and 64FDC. It is all documented here (http://www.datormuseum.se/computers/others/cromemco-system-one). Is this configuration compatible with Z80 CROMIX? I didn't fully understand all of it but it looked like the 1024KZ cards were not Z80 CROMIX compatible. While possibly the 256KZ cards can be configured to be compatible.

I saw a number of disks, 275-278 and 295, 296, that are labeled diagnostics in your repository. These are Z80 diagnostics, right? Are there any similar disks to be used in 68k mode?

billdeg
September 21st, 2015, 04:17 AM
Check out Marcus huge repository (http://maben.homeip.net/static/S100/index.html) of S100 stuff and other things. This is the Cromemco (http://maben.homeip.net/static/S100/cromemco/code/disks/index.html) directory. Disk 200 is 200C1127.IMD (http://maben.homeip.net/static/S100/cromemco/code/disks/200C1127.IMD).

thank you, I had missed that one.
b

MattisLind
April 23rd, 2017, 09:36 AM
One and a half year later and back to the same project...

Thanks to amouse and David Gesswein and his updated software to the amazing MFM emulator I was now able to read and decode the entire disk in the Cromemco System One. So now I have a copy of it in case the disk go south. Since amouse told me that the disk contents was a Cromix 31.62 system I tried to find a suitable boot disk, but there appear only to be boot disks for 8 inch drives with 31.62, not 5.25 as in this System One.

I then tried to boot the 621CR167 (https://maben.homeip.net/static/S100/cromemco/code/disks/621CR167.IMD) disk in amouse amazing disk repository. It booted! But the when telling it to use root at the STDC and minor 0 it indeed accesses the hard disk for a while and then just stops.

http://i.imgur.com/QZri5kr.jpg

WILLOWBROOK COMPUTERS !?

Anyway. I tried the 610CR167.IMD with similar result. I think that this has to do with the fact that the system on the disk is not the same as the one I try to boot.
Next attempt was to set the floppy as root and now I got further.

http://i.imgur.com/Xn5mqtE.png

It took a while to understand that during the boot it switched from 300bps to 9600bps but I got login prompt. Now what? Well I wasn't able to get shell access that was for sure.

So I thought I better find a disk which is a release disk. According to the ref manual a release disk would give you a shell prompt. After some searching in the vast repository I found disk 211 which is a Cromix 20.63 and that one booted and gave me shell access!

Then I did a check on the /dev/std0 disk and it all checked just fine! Next thing was to mount the disk and after a while I understood how mounting was done in Cromix and had the hard disk mounted from my floppy. I was able to access the disk and read files!

But my main problem persist. How to boot directly onto the hard disk using a boot floppy and set the hard disk as root? I cannot find a 5.25 inch disk with Cromix v31.62. I might be able to connect a 8 inch drive temporarily to have it booting. But how does one generate a boot disk in Cromix?

I tried to read the manuals but failed to find it from there. EDIT - Need to read better. Section 1.7 of the System Administrator guide tell you how: initflop, then makfs, followed by wboot to write boot sectors and the copy cromix.sys onto the new floppy.
But how to do this with just one floppy? Maybe I can fiddle in a second floppy. But are the tools on the Cromix V20.63 release floppy? Would they write a correct V31.62 bootstrap? I should be able to copy the cromix.sys from the hard disk when mounted tough.

MikeS
April 23rd, 2017, 11:11 AM
Assuming the FDC is a 64FDC, what version is the RDOS? 3.12 will boot directly from the hard disk if the 64FDC switches are set correctly (2 & 5 on?) and the HD is in fact bootable. You might also want to turn off auto-booting to avoid the 300/9600 baud issue; you'll have to hit RETURN a few times to start (and set the baud rate).

20 Series Cromix was the first 68000 version and is pretty slow; 30 Series is Cromix+ and much improved.

Note that 5.25"HD (and certain 3.5"HD) diskette drives can be used instead of an 8" drive by adding one jumper on the 64FDC (if it's not already there). Instructions can be found on Marcus' site.

WBOOT will make a disk bootable; the actual boot file to be written does not have to be on the active disk(ette) but must of course match the OS version on the disk you're making bootable.

So,

If your RDOS is V3.12 and the HD is bootable it may merely be a matter of correctly setting the FDC switches to boot the HD.

Failing that, boot your 167 diskette, mount the HD and find the version of the OS on the HD with the VERSION command.

Try logging in as SYSTEM instead of root or user.

Shouldn't be too difficult to get it running; looks like you're close.

m

MattisLind
April 23rd, 2017, 11:51 AM
Assuming the FDC is a 64FDC, what version is the RDOS? 3.12 will boot directly from the hard disk if the 64FDC switches are set correctly (2 & 5 on?) and the HD is in fact bootable. You might also want to turn off auto-booting to avoid the 300/9600 baud issue; you'll have to hit RETURN a few times to start (and set the baud rate).


It is 3.08. So I am out of luck there.



20 Series Cromix was the first 68000 version and is pretty slow; 30 Series is Cromix+ and much improved.

Note that 5.25"HD (and certain 3.5"HD) diskette drives can be used instead of an 8" drive by adding one jumper on the 64FDC (if it's not already there). Instructions can be found on Marcus' site.


That is a good point! Bring out a standard 1.2 meg drive and use that one to boot the system.



WBOOT will make a disk bootable; the actual boot file to be written does not have to be on the active disk(ette) but must of course match the OS version on the disk you're making bootable.


Can you elaborate this a bit more. Where is the boot file to be written to the floppy located in the first place? In the root of the HD there is the cromix.sys file which I had an idea of copying onto the new disk.



So,

If your RDOS is V3.12 and the HD is bootable it may merely be a matter of correctly setting the FDC switches to boot the HD.

Failing that, boot your 167 diskette, mount the HD and find the version of the OS on the HD with the VERSION command.

Try logging in as SYSTEM instead of root or user.

Shouldn't be too difficult to get it running; looks like you're close.

m

Yes. I happened to boot a 167 diskette (prior to reading this), I was able to login and it had all the utilities needed, initflop, makfs, and wboot so that should work. From information I got from amouse it is a Cromix v31.62 system, I haven't checked myself though.

Now if I have two floppy drives attached to the system I can boot and use the floppy as a root. Then I mount the hard disk. I can then do initflop on the second floppy drive and then makfs. Then I should do wboot. How can I make sure that the correct boot-file matching my v31.62 system is written onto the floppy?

Finally I then transfer the cromix.sys file from the mounted hard disk to the second floppy.

Does that sound like a plan?

MikeS
April 23rd, 2017, 01:41 PM
It is 3.08. So I am out of luck there.
No problem if you have or know someone with an EPROM programmer, or can talk someone into sending you a programmed EPROM. 3.08 is the version that can boot the IMI/WDI-II drives.


That is a good point! Bring out a standard 1.2 meg drive and use that one to boot the system.
Usually easier to find than a 'real' 8" drive and large enough to hold most/all of the system.

Can you elaborate this a bit more. Where is the boot file to be written to the floppy located in the first place? In the root of the HD there is the cromix.sys file which I had an idea of copying onto the new disk.
I may not have explained very well; making the hard disk bootable with WBOOT is pointless if you don't have RDOS 3.12; you will have to boot from the floppy first.

But FYI the boot files are in the /etc directory, called FDBOOT,SFDBOOT,HDBOOT or STDCBOOT, as appropriate for the disk in question.

So,
Boot from a working bootable floppy (e.g. the 167 version) and MOUNT STD0 into an empty file (not a directory), eg. /stx.
You should be able to LS -AL /stx and see a version of Cromix.sys there.
Then try BOOT /stx/cromix; that should boot whatever version is on the hard disk.

m
----------

Yes. I happened to boot a 167 diskette (prior to reading this), I was able to login and it had all the utilities needed, initflop, makfs, and wboot so that should work. From information I got from amouse it is a Cromix v31.62 system, I haven't checked myself though. 167 is Cromix+ 31.67.


Now if I have two floppy drives attached to the system I can boot and use the floppy as a root. Then I mount the hard disk. I can then do initflop on the second floppy drive and then makfs. Then I should do wboot. How can I make sure that the correct boot-file matching my v31.62 system is written onto the floppy?By default WBOOT <devname> without an optional filename will write the boot file from the root disk.

I'm not sure what you're doing here though; why the second floppy *and* the hard disk? Be careful that you don't disturb the files on the hard disk since they all have to belong to the same version of Cromix. Like I said, don't worry about WBOOTing the hard disk, that's only for RDOS 3.12


Finally I then transfer the cromix.sys file from the mounted hard disk to the second floppy.

Does that sound like a plan?
Hopefully you will be able to just BOOT <mountname>/CROMIX on the hard disk when it's mounted on the (first) floppy; after that you should be able to make a new boot floppy on the same floppy drive while rooted on the hard disk to avoid any incompatibilities.

MattisLind
April 23rd, 2017, 11:03 PM
No problem if you have or know someone with an EPROM programmer, or can talk someone into sending you a programmed EPROM. 3.08 is the version that can boot the IMI/WDI-II drives.


I do have a EPROM programmer so that can be fixed. But I am not sure that the hard disk is boot able. But from what I understand it would be possible to make it bootable using the wboot command provided that the correct files are under /etc/ on the hard disk. I was thinking of starting with floppy boot not to risk to destroy the contents of the hard disk.

Do you know where to find the 3.12 RDOS?



Usually easier to find than a 'real' 8" drive and large enough to hold most/all of the system.


I have a dual sided 8 inch Shugart 851 so that can be done but simpler approaches are appreciated.



I may not have explained very well; making the hard disk bootable with WBOOT is pointless if you don't have RDOS 3.12; you will have to boot from the floppy first.

But FYI the boot files are in the /etc directory, called FDBOOT,SFDBOOT,HDBOOT or STDCBOOT, as appropriate for the disk in question.


Thanks. That was the info I was looking for.



So,
Boot from a working bootable floppy (e.g. the 167 version) and MOUNT STD0 into an empty file (not a directory), eg. /stx.
You should be able to LS -AL /stx and see a version of Cromix.sys there.
Then try BOOT /stx/cromix; that should boot whatever version is on the hard disk.

m
----------
167 is Cromix+ 31.67.


OK. By 167 I meant disk 167 from the repository of amouse. It has a v30.79 Cromix on it. But in any case I have managed to mount the hard disk (yes, it took some time to understand that mounting is towards a ordinary file not a directory...). This was the only disk I could find that I could log into.

Ahh. So I can boot a floppy with a completely different Cromix version and the do BOOT to start the system living on the hard disk. Didn't know that.



By default WBOOT <devname> without an optional filename will write the boot file from the root disk.

I'm not sure what you're doing here though; why the second floppy *and* the hard disk? Be careful that you don't disturb the files on the hard disk since they all have to belong to the same version of Cromix. Like I said, don't worry about WBOOTing the hard disk, that's only for RDOS 3.12


Hopefully you will be able to just BOOT <mountname>/CROMIX on the hard disk when it's mounted on the (first) floppy; after that you should be able to make a new boot floppy on the same floppy drive while rooted on the hard disk to avoid any incompatibilities.

The idea with two floppies was to boot the 30.79, then from that floppy create a boot floppy with the contents of the hard disk as source for the /etc/sfdboot file and cromix.sys but if it is possible boot the hard disk from the floppy using the boot command then a single floppy would be enough. I will try this.

Thanks for all useful information!

MikeS
April 24th, 2017, 04:51 AM
I do have a EPROM programmer so that can be fixed. But I am not sure that the hard disk is boot able. But from what I understand it would be possible to make it bootable using the wboot command provided that the correct files are under /etc/ on the hard disk. I was thinking of starting with floppy boot not to risk to destroy the contents of the hard disk.

Do you know where to find the 3.12 RDOS?
37960
37959


Ahh. So I can boot a floppy with a completely different Cromix version and the do BOOT to start the system living on the hard disk. Didn't know that.
Yes, that should work. Trying to boot the floppy with the Cromix.sys from the HD might not work since the Cromix.sys may assume that the rest of the files are on the root disk.

Hope you're up and running on the HD when you read this ;-)

m

MikeS
April 24th, 2017, 05:28 AM
Just looked at your excellent web site/writeup; a few observations:

- I wouldn't call it primarily a UNIX system; most if not all System Ones were sold with either a Z80 ZPU or dual Z80/68000 DPU running Cromix or CDOS, while UNIX was mainly installed on the System One's successor, the CS-100 (or 200, 300, or 400). As you suggest, your system would not be able to run UNIX anyway, without an MMU and with such a small hard disk. Also note that the XPU originally came with a 68000, later ones like yours with a 68010.

- A fully loaded System One could easily overheat the backplane power connector and even burn the PCB, so soldering the wires directly to the pins was not unusual, either as a preventive measure or to replace a damaged connector.

- You're right, the interrupt priority chain must be continuous so it does indeed look like a card was removed; you will probably have to move the jumpers over by one card to remove that gap.

Have FUN!

m

MattisLind
April 24th, 2017, 06:31 AM
Just looked at your excellent web site/writeup; a few observations:

- I wouldn't call it primarily a UNIX system; most if not all System Ones were sold with either a Z80 ZPU or dual Z80/68000 DPU running Cromix or CDOS, while UNIX was mainly installed on the System One's successor, the CS-100 (or 200, 300, or 400). As you suggest, your system would not be able to run UNIX anyway, without an MMU and with such a small hard disk. Also note that the XPU originally came with a 68000, later ones like yours with a 68010.


You're right. It is not UNIX, it is Cromix (which is somewhat UNIX like). I'll change that.




- A fully loaded System One could easily overheat the backplane power connector and even burn the PCB, so soldering the wires directly to the pins was not unusual, either as a preventive measure or to replace a damaged connector.

- You're right, the interrupt priority chain must be continuous so it does indeed look like a card was removed; you will probably have to move the jumpers over by one card to remove that gap.

Have FUN!

m

One more question though: What is the best way to remove the password on a Cromix system so I'll be able to log in to it when I have WARM-booted it using the BOOT command? I suspect that the system installed on the hard drive has passwords set.

MikeS
April 24th, 2017, 07:47 AM
One more question though: What is the best way to remove the password on a Cromix system so I'll be able to log in to it when I have WARM-booted it using the BOOT command? I suspect that the system installed on the hard drive has passwords set.
When booted from the floppy you should be able to rename /etc/passwd on the hard disk to something else (in case you need a list of users for some reason) and replace it with the one from the floppy.

m

new_castle_j
April 24th, 2017, 09:23 AM
Thanks to amouse and David Gesswein and his updated software to the amazing MFM emulator I was now able to read and decode the entire disk in the Cromemco System One

This is a very interesting thread since I have a z80 System One with Cromemco terminal on the shelf waiting for a second chance. I've got David Gesswein's MFM emulator, what version of the software is necessary to work with the Cromemco Hard Disk?

MattisLind
April 24th, 2017, 11:14 AM
This is a very interesting thread since I have a z80 System One with Cromemco terminal on the shelf waiting for a second chance. I've got David Gesswein's MFM emulator, what version of the software is necessary to work with the Cromemco Hard Disk?

I am just using the latest software from Davids web page. Nothing special.

MattisLind
April 24th, 2017, 11:30 AM
Well. Booting onto the hard drive was not an immediate success.

The first time it started booting but then got stuck. Waited 10 minutes and no difference. No response at the terminal. Tried different speeds.

http://i.imgur.com/yAeZcKS.png

Then I thought maybe this kernel was linked with certain drivers and now when those drivers weren't present all went south somehow!?

So I pushed in all cards in the machine.

http://i.imgur.com/GBAoGWI.png

I now started to get unexpected interrupts. In some news group I found through google Marcus Bennett commenting on this as a problem in the interrupt priority chain suggesting that the in and out of the FDC was maybe reversed. The markings on the 64FDC board was not of great in clearly mark the in and out. I simply switched in and of the connector and now the probability of getting this was lower. Haven't got it since the switch.

http://i.imgur.com/HwhPHlv.png

Now it booted for a while, then was silent a few minutes until it showed a number of timeout messages which ended with a shutdown message and no response from the terminal.

So what is the next step to test? If the problem is for example a missing board in the configuration and thus it won't boot, how can I then create a kernel that is bootable on my system?

Is the octcmd indicate it has to do with the octart, right? Is there a way to diagnose the board? Diagnostic software that could be run from the RDOS prompt?

MikeS
April 24th, 2017, 12:50 PM
Yes, the FDC in/out pins are the opposite of the rest. Did you move the priority cable connections to get rid of that gap, i.e that there are no empty connections except past the STDC?

What is the sequence and pin locations of the cable connections?

I'm not aware of any Octart diagnostics that could run without an OS, but removing it should not shut down the system.

MikeS
April 24th, 2017, 12:55 PM
This is a very interesting thread since I have a z80 System One with Cromemco terminal on the shelf waiting for a second chance. I've got David Gesswein's MFM emulator, what version of the software is necessary to work with the Cromemco Hard Disk?Which make/model hard disk & controller?

new_castle_j
April 24th, 2017, 02:40 PM
Which make/model hard disk & controller?

My hard disk controller has an EPROM on it labeled STDC 1.20 and the disk is an IMI 5018H

MikeS
April 24th, 2017, 04:04 PM
My hard disk controller has an EPROM on it labeled STDC 1.20 and the disk is an IMI 5018H

Should be the same as Mattis; not sure what the difference is between a 5018 and a 5021 although I suspect one was an original IMI interface upgraded to the standard ST-412/506.

So, what's the story? Does the system boot? What cards are in it?

Curious minds need to know ;-)

new_castle_j
April 24th, 2017, 06:00 PM
So, what's the story? Does the system boot? What cards are in it?

Curious minds need to know ;-)

It has a ZPU, 64FDC, STDC, TUART, and memory (I think 256KZ)
I've never attempted to boot it, I was told that it was retired from a Canadian BBS, Canada Remote Systems. What purpose it served there, I don't know. There is a 5.25 floppy disk that came with, labeled Cromix. That's all the info I've got on it.

MattisLind
April 24th, 2017, 11:28 PM
Yes, the FDC in/out pins are the opposite of the rest. Did you move the priority cable connections to get rid of that gap, i.e that there are no empty connections except past the STDC?

What is the sequence and pin locations of the cable connections?



I include a photo.

http://i.imgur.com/vTGdLBI.jpg

It starts off at the left pin of the 64FDC in the bottom, then to the left pin of the STDC next board from the bottom. From the STDC right pin, tohen the OCTART board to the right and from the right pin of the OCTART into the left pin of the BIART board. Then there is a loose hanging output from the BIART right pin. Supposedly this extra jumper is for a missing board that has been removed from the system. But I know very little about the origin of the system.

From looking into the dump of the disk I did it seems include an application KAS/ADB which might been used to administrate subsidies to unemployed people at a government organisation. One file mention that there a might have been a tape drive included in the setup. Maybe this tape drive card have been removed and that is why a card is missing.

Looking further it mentions INFORMIX Version 3.20.01 which makes me remember a summer intern job in early nineties where I did reports in Informix 4GL...

BTW. Is there some kind of description to be found somewhere on how the filesystem is built? It seems that the entire first track, 10240 bytes is some kind of boot. I assume ity is written by wboot. Then there a some kind of table with 128byte sized record. The 16 bit integer at byte offset 14-15 seems to be some kind of index. Incrementing from 0001 to 1608 hex. Then at disk offset b2c00 there seems to be the root-directory. Each record seems to be 32 bytes in size.



I'm not aware of any Octart diagnostics that could run without an OS, but removing it should not shut down the system.

Would it be possible to install a new cromix.sys file from floppy disk? Supposedly I need a cromix.sys for version 31.62. What could be the reason for the machine to hang during bootup? If I had a extender board I could have tried to use my logic analyzer to see what is going on.

MikeS
April 25th, 2017, 08:16 AM
...It starts off at the left pin of the 64FDC in the bottom, then to the left pin of the STDC next board from the bottom. From the STDC right pin, tohen the OCTART board to the right and from the right pin of the OCTART into the left pin of the BIART board. Then there is a loose hanging output from the BIART right pin.Depending on revision level the STDC must/should be the last (lowest) in the chain. Try:
FDC-L to OCT-L
OCT-R to BIART-L
BIART-R to STD-L

You might also try removing the Octart and Biart and just connecting FDC-L to STDC-L

BTW. Is there some kind of description to be found somewhere on how the filesystem is built? It seems that the entire first track, 10240 bytes is some kind of boot. I assume ity is written by wboot. Then there a some kind of table with 128byte sized record. The 16 bit integer at byte offset 14-15 seems to be some kind of index. Incrementing from 0001 to 1608 hex. Then at disk offset b2c00 there seems to be the root-directory. Each record seems to be 32 bytes in size.Section 4 of the Programmer's Reference Manual


Would it be possible to install a new cromix.sys file from floppy disk? Supposedly I need a cromix.sys for version 31.62. What could be the reason for the machine to hang during bootup? If I had a extender board I could have tried to use my logic analyzer to see what is going on.Yes, if you have a running 162 on the floppy you could Crogen a new Cromix.sys and copy it to the hard disk. /Gen/sysdef is the normal configuration file; the usual custom was to copy that and edit it, so you may find several versions on the hard disk.

I don't know why your system is hanging; I also don't know what Octcmd is, unless it's a program that's on the Octart itself.

So, I'd correct the Interrupt priority cable, and if that doesn't get you running bring it down to the minimum configuration without the Octart and Biart; missing cards should just give an error but not halt the system.

MikeS
April 25th, 2017, 08:26 AM
It has a ZPU, 64FDC, STDC, TUART, and memory (I think 256KZ)
I've never attempted to boot it, I was told that it was retired from a Canadian BBS, Canada Remote Systems. What purpose it served there, I don't know. There is a 5.25 floppy disk that came with, labeled Cromix. That's all the info I've got on it.

Small world; CRS was a major BBS right here in Toronto and as a matter of fact I was a member and very slightly involved in admin, although I don't remember the Cromemco system; must have been before or after my time.

So, where do you want to go with your CS-1H? Most people recommend testing and reforming the big power supply caps before turning it on:
http://www.badcaps.net/forum/showthread.php?t=50530

I'd also make sure the main backplane power connector is clean and free of any oxidation and does not heat up.

MattisLind
April 25th, 2017, 12:05 PM
Depending on revision level the STDC must/should be the last (lowest) in the chain. Try:
FDC-L to OCT-L
OCT-R to BIART-L
BIART-R to STD-L


No difference. Complains about octcmd timeout and then shutdown.



You might also try removing the Octart and Biart and just connecting FDC-L to STDC-L


No. Difference. It is stuck. Waited 5 minutes. Tested different terminal speeds nothing happens what so ever...




Section 4 of the Programmer's Reference Manual


Thanks! I'll check that.




Yes, if you have a running 162 on the floppy you could Crogen a new Cromix.sys and copy it to the hard disk. /Gen/sysdef is the normal configuration file; the usual custom was to copy that and edit it, so you may find several versions on the hard disk.



Unfortunately it seems that 162 is only on 8 inch floppies. I have an 8 inch drive around so it could be done. Can you elaborate on the crogen procedure? Can I do that on the floppy and then copy it? Does this require a release floppy?

MikeS
April 25th, 2017, 11:14 PM
No difference. Complains about octcmd timeout and then shutdown.
Even with the Octart removed it still complains about octcmd? Guess I'll have to fire up an XPU system and see if it's on there.

Unfortunately it seems that 162 is only on 8 inch floppies. I have an 8 inch drive around so it could be done. Can you elaborate on the crogen procedure? Can I do that on the floppy and then copy it? Does this require a release floppy?
Crogen creates a new Cromix.sys file configured according to the sysdef file, a plain text file that can be read and edited. Have a look around on the hard disk and look at any sysdef files you find in addition to the one in /gen, and maybe also any Cromix.sys files with a similar date in case there's a minimal version somewhere.

I suppose you could try copying the existing floppy Cromix.sys to the hard drive but yes, I don't see why you can't crogen a new Cromix.sys on the floppy (with a different temporary name to avoid replacing the version on the floppy). A release floppy would have the necessary files; at a minimum I think you need a Cromix.sys, sysdef and link68.

Remember that you can use a 5.25HD drive instead of an 8"drive if you add the /READY signal jumper.

Shouldn't be this difficult; wonder what's hanging the system.

MattisLind
April 26th, 2017, 01:20 AM
Even with the Octart removed it still complains about octcmd? Guess I'll have to fire up an XPU system and see if it's on there.


No, I meant it was the same as the last time I used the same setup. I.e. no complaints about octcmd but it is just stuck after printing the Cromix banner. Waited 10 minutes.



Crogen creates a new Cromix.sys file configured according to the sysdef file, a plain text file that can be read and edited. Have a look around on the hard disk and look at any sysdef files you find in addition to the one in /gen, and maybe also any Cromix.sys files with a similar date in case there's a minimal version somewhere.

I suppose you could try copying the existing floppy Cromix.sys to the hard drive but yes, I don't see why you can't crogen a new Cromix.sys on the floppy (with a different temporary name to avoid replacing the version on the floppy). A release floppy would have the necessary files; at a minimum I think you need a Cromix.sys, sysdef and link68.

Remember that you can use a 5.25HD drive instead of an 8"drive if you add the /READY signal jumper.

Shouldn't be this difficult; wonder what's hanging the system.

Thanks for the info on the crogen process. Actually, as of now all my 1.2 meg drives are broken but I have a 8 inch that works perfectly...

I did look into the cromix file system a bit, trying to understand the super block. The information in chapter 4 is good but not complete as far as I can see. Are there any header files around somewhere to explain the details?

http://i.imgur.com/VhFe13r.png

RED is the Block Free pointers preceded by the GREEN counter value. PINK is the inode free pointers preceded by the BLUE counter value. The ORANGE is matching the number maximum inode number found.

But what is the rest which is marked as BLACK?

MikeS
April 26th, 2017, 06:59 AM
Sorry, I can't help with any more superblock details than what you found in the manual; it's been many years since I poked around at that low level, and even then it was mainly manually repairing inodes or trying to repair fatal read errors.

Looks like the octcmd errors are probably not the main issue.

I would check the hard disk drive integrity with icheck and dcheck; then I would study any sysdef files to try to determine where it might be hanging. There are usually a number of messages as the system is initialized before any user input is requested, but I suppose it could still be as simple as waiting for input from an inactive port; are you monitoring both the FDC console and at least port 1 of the Octart?

MattisLind
April 26th, 2017, 07:35 AM
Sorry, I can't help with any more superblock details than what you found in the manual; it's been many years since I poked around at that low level, and even then it was mainly manually repairing inodes or trying to repair fatal read errors.


I did some more fiddling with this and managed to read files of the dumped filesystem. Right now I cannot deduce if an inode is a directory or not.

http://i.imgur.com/o66WIsM.png

The pointers are in RED but the first block pointer is marked in GREEN. BLUE is the size of the file. But what is marking the inode as a directory? Still not sure about that. This is the root directory.



Looks like the octcmd errors are probably not the main issue.

I would check the hard disk drive integrity with icheck and dcheck; then I would study any sysdef files to try to determine where it might be hanging. There are usually a number of messages as the system is initialized before any user input is requested, but I suppose it could still be as simple as waiting for input from an inactive port; are you monitoring both the FDC console and at least port 1 of the Octart?

Maybe not an octcmd problam. But with the octart installed, the final message is "System shutdown complete" which makes me think it will not respond anywhere. On the other hand without the octart it just sits after the Cromix banner. But then there are no other serial ports to connect through.

I did a check on the fs before starting to try to boot it and that looked fine as far as I understand these tools. But it might be a good time to do another round of checking before proceeding with other alternatives.

MikeS
April 26th, 2017, 08:27 AM
Not sure what you're after by looking at the low-level file system; can't help you with that.

In addition to the sysdef file(s) I'd also look at /etc/startup.cmd and /etc/iostartup.cmd to see what they're trying to do; maybe rename it/them if that makes sense.

Might as well also update the RDOS to 3.12 while you're at it.

MattisLind
April 26th, 2017, 12:06 PM
Not sure what you're after by looking at the low-level file system; can't help you with that.


Well, I thought it would be nice that be able to copy out the actual contents from the drive in a simpler way than over a slow serial port. And possibly manipulate the drive-image - add software etc to it, and write it back to the actual hard drive using Davids MFM emulator.



In addition to the sysdef file(s) I'd also look at /etc/startup.cmd and /etc/iostartup.cmd to see what they're trying to do; maybe rename it/them if that makes sense.

Might as well also update the RDOS to 3.12 while you're at it.

Hooray!

That did the trick. It was probably the iostartup that tried to load custom firmware into the octart. I am not sure why it made everything fail or halt but with the file removed it boots happily!

http://i.imgur.com/6Xes4ro.png

It seems like that the last time it was active was almost 20 years ago.

Thanks a lot MikeS!

Pity that the octart board seems to be toast somehow, though - would have been interesting to have the feel of it running as a multiuser system.

MikeS
April 26th, 2017, 02:50 PM
Well, I thought it would be nice that be able to copy out the actual contents from the drive in a simpler way than over a slow serial port. And possibly manipulate the drive-image - add software etc to it, and write it back to the actual hard drive using Davids MFM emulator.
The serial port way is indeed pretty slow, although straightforward; another way is to use a 5.25" HD drive, which would be compatible with both the Cromemco and a PC (or a 'real 8" drive, but that's a little harder to interface to the PC). IIRC either the TAR or the FTAR file format is even compatible with PKZIP.

There is also software that lets Cromix+ read and write 'standard' 360K MS-DOS diskettes; look for CScopy on Marcus' site.

Hooray!

That did the trick. It was probably the iostartup that tried to load custom firmware into the octart. I am not sure why it made everything fail or halt but with the file removed it boots happily!Hooray indeed!


Thanks a lot MikeS!Glad I could help.


Pity that the octart board seems to be toast somehow, though - would have been interesting to have the feel of it running as a multiuser system.
I wouldn't count it out yet; the normal way to configure it is with octload, so maybe you just need to tweak the startup and sysdef files.

Anyway, lots to play with now; congratulations, and have FUN!

mike

MattisLind
April 27th, 2017, 01:55 AM
I wouldn't count it out yet; the normal way to configure it is with octload, so maybe you just need to tweak the startup and sysdef files.

Anyway, lots to play with now; congratulations, and have FUN!

mike

I will look into the octart a bit more to see what is wrong now when I have the system up. But getting timeouts makes me think that the download fails due to board not responding properly. I will try a bit more then I think I maybe will need a extender board to run it with a logic analyzer.

Any hints on where to find S100 extender boards?

On the subject of disk archeology I did find the header inode.h (https://amaus.net/static/S100/cromemco/code/disks/097%20Cromix%20162%20disk4/usr/include/inode.h)


/*
@(#)inode.h 1.2 (9/28/86)
Inode definition
*/


typedef struct _ino {
struct _ino *in_back; /* backward pointer */
struct _ino *in_forw; /* forward pointer */
unsigned short in_devn; /* inode device number */
unsigned short in_inum; /* inode number */
unsigned short in_ucnt; /* usage count */
short in_flags; /* inode flags */

unsigned short in_owner; /* file owner's user id */
unsigned short in_group; /* file owner's group id */

unsigned char in_aowner; /* owner access */
unsigned char in_agroup; /* group access */
unsigned char in_aother; /* other access */
unsigned char in_stat; /* inode status */

unsigned char in_nlinks; /* number of links to inode */
unsigned char in_filler; /* filler */
unsigned long in_size; /* file total size in bytes */
unsigned short in_inode; /* this inode number */

unsigned short in_parent; /* parent inode (dir only) */
unsigned short in_dcount; /* number of entries in dir */
unsigned long in_usage; /* number of blocks used */
time in_tcreate; /* time created */
time in_tmodify; /* time last modified */
time in_taccess; /* time last accessed */
time in_tdumped; /* time last dumped */
unsigned long in_index[20]; /* block pointers */
} ino;



/*
Bit assignement for in_flags
*/

#define IN_LOCK 00001 /* inode locked */
#define IN_WANT 00002 /* inode wanted */
#define IN_MODF 00004 /* inode modified */
#define IN_READ 00010 /* inode is read-only */



/*
Bit assignement for in_stat
and values of in_stat&IN_TYPE
*/

#define IN_TYPE 0x07 /* File type (mask) */
#define IN_STEXT 0x08 /* Shared text */
#define IN_ALLOC 0x80 /* Inode allocated */

#define is_ordin 0 /* ordinary file */
#define is_direct 1 /* directory file */
#define is_char 2 /* character device */
#define is_block 3 /* block device */
#define is_pipe 4 /* pipe file */



#define in_begin in_owner /* start of inode on disk */
#define in_sdevn in_dcount /* special device number */

/* IMPORTANT !!! Size starting from in_begin must be inodesize */

This is the in-memory structure for the inode, but the format from in_owner matches the content on disk.

Here is the definition of the superblock in super.h (https://amaus.net/static/S100/cromemco/code/disks/097%20Cromix%20162%20disk4/usr/include/super.h).

time structure is a not a 32 bit in cromix but six byte format defined in syslib.h (https://amaus.net/static/S100/cromemco/code/disks/097%20Cromix%20162%20disk4/usr/include/syslib.h). It is not Y2K compliant... Maybe one reason for this system to be closed down in 1997.

MikeS
April 27th, 2017, 03:49 AM
...
time structure is a not a 32 bit in cromix but six byte format defined in syslib.h (https://amaus.net/static/S100/cromemco/code/disks/097%20Cromix%20162%20disk4/usr/include/syslib.h). It is not Y2K compliant... Maybe one reason for this system to be closed down in 1997.
Apparently V 167 is Y2K compliant:
https://majzel.blogspot.ca/2016/09/cromemco-millennium-bug.html

MikeS
April 27th, 2017, 07:14 AM
Here are the startup and iostartup files from one of my XPU systems (168 ), as well as a default sysdef. Note the Y2K date at the bottom of the startup.cmd printout.

BTW, I said octload, but it's ioload.

37983

MattisLind
April 27th, 2017, 11:26 AM
Here are the startup and iostartup files from one of my XPU systems (168 ), as well as a default sysdef. Note the Y2K date at the bottom of the startup.cmd printout.

BTW, I said octload, but it's ioload.

37983

Yes. ioload. Unfortunately my machine with octart installed never gets that far regardless of the removed startup file.

http://i.imgur.com/bKBdPDU.png

I could try to exercise the octart board from RDOS, see if it responds. I reseated all socketed chips. Check the DIP-switch for continuity.

MikeS
April 28th, 2017, 07:40 AM
I'm curious: does that 3-digit year Y2K trick work as far back as V 162?