Tag: Cromemco

About Cromemco

Subscribe Feeds

Solid State Storage

Posted on by Graham

Cromix is really intended for operation with a hard disk.  I made it work with floppies, but it was always going to be a huge compromise.   In particular, it is common for software installations to add links and these links fail if they span physical volumes. And then there’s the general inconvenience of swapping floppy disks.

There were a few hard disk solutions offered in the 1980s, but these are largely unavailable now.  The closest that I thought I could get was a WDI II card and a hard disk emulator.  This would have been very expensive.

A little searching of the Cromemco google group yielded an alternative solution which did not seem to have a lot of discussion.  The S-100 community has created a lot of new board designs including a CF/IDE board designed by John Monahan.  This board has CP/M support but “out of the box” there is no Cromix support.  Fortunately, a talented chap, Damian Wildie up in Brisbane, has written a driver for Cromix.  I contacted him to see if he would help me to get a CF/IDE card up and running, and he agreed without hesitation.

That left me needing the card itself.  These cannot (as far as I know) be bought in an assembled or even kit state.  The PCB was available locally which was a bit of a fluke; not many S-100 boards are available in Australia.  I had already bought an extender card from the same seller.  The rest of the parts came from stock, element14, ebay and wherever I could find them.  Some of the parts are not easy to find here in Australia.

I built up the extender and the CF/IDE card and Damian came through with a disk image for the CF card and another for a boot floppy – the driver doesn’t allow for boot from the CF card but it can be the root filesystem.  Damian even customised it for my system which was above and beyond.

After some problems with the first image and a couple of mysteries with the card (one turned out to be a badly soldered artificial resistor pack) the other I’m not sure about.  I swapped out 54LS244s for 74F244s, and it got better – it may have been speed, but the sockets feel a little loose to me.

  • Does not support booting
  • The disks cannot be initialised from Cromix
  • Diskinfo does not seem to always work.

The size of the disks seems to cause some issues for my 512kB system eg dcheck and icheck don’t work.  This really means that the disk needs to be imaged regularly. (Resolved with increased memory – about 370k required to do the check!)

The major device number is 12.  The first partition on card A has a minor number of 0.  These need to be entered as the root device.

Damian has provided a customised gen directory at /usr/ide.  Regeneration works fine.

Installation of apps is now a lot easier.

The /etc/ttys has been edited to set the terminals to Televideo 925 (T925 in termcaps) which works with the IBM terminal.

Users Admin, Graham, User1, and User2 have been added.

Messages have been customised.  Damian (message is in ide_sysdef) and Vic have been acknowledged (/etc).

The help system works!

It is relatively easy to backup cards using dd even on Windows.  Writing seems to be easier with balenaEtcher.  I have bought some additional CF cards, but they seem to have some incompatibility.  I will try a different brand.

More Users and TUARTs

Posted on by Graham

Cromix Plus is a multiuser system, but to support more users requires more serial lines and terminals.

I had a Twin UART (TUART) card that would fit the bill and i’d purchased one more for another project, but it can be plugged into this rack for now. This would give a total of 5 users.

As for terminals – well they are hard to find so i have to be satisfied with a Windows machine with several serial ports and multiple instances of kermit.

The TUART is installed as TUART #1 as per the Cromix Plus Administrator’s Guide.  This puts the ports at 20h and 50h and makes them 2 and 5 in the sysdefs file.

Cromix has been regenerated to enable the two TUART serial ports as devices tty2 and tty3.  The disk controller serial port remains at tty1.

The TUARTs support interrupts, so the 16FDC no longer has the interrupt line to itself. Priority is established by a daisy chain that connects from the OUT on the 16FDC to the IN on the TUART. Just to mess with everyone’s heads, the IN and OUT positions on the TUART are the reverse of the 16FDC.

The serial ports can be configured as terminal ports by editing /etc/ttys:

Along the way, I stumbled on a Software Update Note for 20.14 that said:

This means that if no terminal is connected, the port should not be configured as a terminal port.

A second TUART was setup as TUART#2, but this clashed with the IDE card, so it was moved to TUART #3.  These are 8 and 9 in the sysdefs file used to rebuild cromix.

The second TUART also needed to join the interrupt priority chain: OUT from the first TUART to IN on the second TUART.

Here’s an example of multiple users (3) and multiple processes (9):

(This pic is from after i increased the memory.)

More Memory

Posted on by Graham

Wishing to be able to run the disk checks properly to be able to run lots of processes, and haunted by the thought that more memory failures can be expected on the 512MSU, i again turned to a modern solution.

This time it was a static memory board designed by John Monahan:

http://s100computers.com/My System Pages/16MG RAM Board/16MG RAM Board.htm

I could have gone for the full 16MB and filled the address space but i wanted to keep the 512MSU so i built an 8MB version. The existing memory could be moved just by changing some DIP switches on the MCU.

This project would probably still be pending but for a bare board being up for sale in South Australia.

If a generic memory board is used instead of the MCU/512MSU then:

  1. It must support a Phantom signal
  2. The 16FDC needs to be modified to provide a Phantom signal
  3. The Phantom signal needs to either be on a different pin from the normal 67 or the DPU needs to be modified to not use pin 67 eg by cutting pin 6 of IC 41.  It’s probably better to modify the new board to use pin 69 and be consistent with other group members.

https://groups.google.com/g/cromemco/c/T_eui2YJEQ0/m/FkrSFaYtBwAJ

I think it may still be possible to use the DPU as well if the memory card is 4MB or 8MB.  It just needs to be located after the new board.  It can’t go before because the board boundaries are not fine enough.

The SRAM is expensive at over $10 per MB.  In the end it was easier to get the 4MB parts and two are required so I built an 8MB variant.

This card will be located at 0000H-7FFFFH. The 512MSU will be at 8000H-87FFH and the DIP switch will need to 01000.

The biggest challenge with building the board is mounting the TSSOP packages.  I used paste and hot air and cleaned up the excess with solder wick.  There were some troublesome bridges one of which only cleared after reflowing with hot air.

I had a look at the PAL equations just to make sure they would work with 8MB.

GAL5:

/BOARD_SELECT  =  sINTA  + sINP  + sOUT  + /PHANTOM@

bsMEMR@ =       /bsMEMR

GAL6:

/S100_8_RD_OE@      =      /RD8@  * bA0   * BOARD_SEL * /pSYNC                  ;U19, 8 Bits to CPU, odd/high address
                         + /RD16@         * BOARD_SEL * /pSYNC                  ;Any 16 bit data Read
                         + /WR16@         * BOARD_SEL * /pSYNC                  ;Any 16 bit data Write

/S100_8X_RD_OE@      =     /RD8@  * /bA0  * BOARD_SEL * /pSYNC                  ;U31, 8 Bits to CPU even/low address

There seemed to be no interest in the address lines ie this board is selected regardless of the address (except for the phantom).  For a 16MB card that would be correct. And it doesn’t matter for writes as long as all of the address lines are in use at P101 – this should just cause a write to RAM that isn’t loaded. But it would cause a read contention with a board in the top 8MB eg where I want the old 512kB to be.

I think that for my situation GAL5 so that /BOARD_SELECT is asserted only when the for the first 8MB.

/BOARD_SELECT  =  sINTA  + sINP  + sOUT  + /PHANTOM@ + A23

I made the change.

It took hours to run the 68k RAM test in CDOS, but it was successful. 8.5MB of RAM was good to go.

cromix.sys had to be regenerated with an updated sysdef. After this there was abundant memory! There are a bunch of tweaks that i could do to take further advantage of the memory and i think a RAM disk could also be added.