Amix and the ReAmiga 3000 board
 

Hello Amixians,

My brother bought an Amiga3000 UX for college when they were new and for sale. Lucky for me, he held on to it. I've got it now, and through the years, the mobo was damaged by that darn battery...

I worked a deal with Chucky to get the parts from the mobo transferred to a ReAmiga 3000. It's a beautiful thing and boots AmigaOS 3.2 perfectly. Unfortunately, it does not boot AMIX.

Here are the error messages during boot (full picture of the stuck boot here):

a3019: 0x49 1 0x70EADC4
a3091: 0x85 3 0x70EADC4


The a3091 is a reference to the onboard SCSI controller.

I've read there are issues with memory size and the SCSI drive memory mapping, so I've removed 8 MB of fast with no luck.

I've been working with Chucky, and he said the only change to the A3000 motherboard is the addition of a ZIP to SIMM adapter.

While working on this problem, I've been able to set up AMIX on WinUAE with both the original boot disk and the AmigaUnix boot image.

This problem is outside of my technical knowledge, but I was going to start by adding more debug to the a3091 driver to understand the error better. Using the amigaunix hardfile with WinUAE I attempted to rebuild the kernel, but the process failed. I've worked with C code some but never built the AMIX kernel. What I did was cd to "/usr/sys/amiga" and execute "make" with this result:

https://lh6.googleusercontent.com/kV...Wg-UIQoE=w2400


So here are my questions:

1) Does Anyone have a suggestion on what the error might be?
2) Has anyone successfully installed the ZIP->SIMM adapter on an A3000 and used it with Amix?
3) Using the amigaunix website boot image has anyone been able to rebuild the kernel?

Thanks for the support!
Bill "tekmage" Borsari

PS, you can fix the keymapping for the amigaunix website boot image using the /usr/amiga/bin/amixadm and change the keymap to usa01!

Wow, that is a nice project to work on... True vintage to play with!

I have never myself attempted to recompile the kernel itself and the error could mean anything to me from 'bad compiler version or install', 'wrong version of libraries', etc.

Maybe you can ask @Tahoe, I think he has quite some experience with AMIX and he also operates the 3000UX wiki...

edit:
Is the memory on the AA3000 board on the same addresses as on the original? I would think so but that would be the only think that comes to my mind. But it's a tricky OS and very tightly connected to the 3000 hardware, which is proven to be true again...

edit2:
Did some more reading and AMIX is not open source, I'm pretty sure you will not be able to compile the kernel - which is most likely why the 'make' command fails.

Progress!

I was able to clean install AMIX on WinUAE and add in all the supporting packages. With that, I do two things: 1) the fresh install image booted the ReAmiga3000 once, and 2) I can compile the kernel, so changes to the driver are possible.

Still working on the a3091.c driver as the error is still happening.

Thanks for all the support on this!
Bill "tekmage" Borsari

Ok, I extracted the a3091.c file from AMIX. I'm not sure how this works so I'm hoping someone can help me understand what's happening here.

First, there is a case statement with this switch line:

	switch (atab[istate][itab[ss]]) 

For that line, it looks like the first error "istate" = 1 and the ss = "0x49".

Here are the tables for itab and atab:

/*

 * Convert 3393A status code to input code for interrupt DFA.

 *	status	input	meaning

 *	------	-----	-------

 *	42	0	There is no device with the specified SCSI ID.

 *	-	1	Status is illegal or unsupported.

 *	21	2	A Save Data Pointers message has arrived.

 *	85	3	The target has temporarily disconnected.

 *	81	4	A target has reconnected.

 *	4F	5	A message, probably Restore Data Pointers, has arrived.

 *	20	6	The target is waiting for message acceptance.

 *	4B	7	Request status has arrived.

 *	16	8	Request has completed.

 */

static uchar itab[] = {

	1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1,

	1, 1, 1, 1, 1, 1, 8, 1, 1, 1, 1, 1, 1, 1, 1, 1,

	6, 2, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1,

	1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1,

	1, 1, 0, 1, 1, 1, 1, 1, 1, 1, 1, 7, 1, 1, 1, 5,

	1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1,

	1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1,

	1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1,

	1, 4, 1, 1, 1, 3, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1,

};

#define	NINPUT	9



/*

 * Given current DFA state and input, specify the action to be taken, which

 * will determine the new state.

 *	action	new state	meaning

 *	------	---------	-------

 *	0	IDLE,STARTING	Complete request, perhaps start new.

 *	1	DEAD		Report that driver has shut down.

 *	2	RESUMING,DEAD	Requeue request, perhaps resume other.

 *	3	RESUMING,DEAD	Perhaps resume request after reconnection.

 *	4	RESUMING	Resume request after 0x20.

 *	5	IDLE,STARTING	Abort request, perhaps start new.

 *	6	RESUMING	Save pointers, then resume.

 *	7	IDLE,STARTING	Disconnect request, perhaps start new.

 *	8	DEAD,MESSAGING	Perhaps read Restore Pointers.

 *	9	ENDING		Resume request, expecting completion.

 */

static uchar atab[][NINPUT] = {

	1,  1,  1,  1,  3,  1,  1,  1,  1,

	5,  1,  6,  7,  2,  8,  1,  9,  0,

	1,  1,  6,  7,  1,  8,  1,  9,  0,

	1,  1,  1,  1,  1,  1,  1,  1,  1,

	1,  1,  1,  1,  1,  1,  4,  1,  1,

	1,  1,  1,  1,  1,  1,  1,  1,  0,

};

Given those inputs, I cannot figure out which case is selected. For completeness, here is the full case statement:

a3091intr( )

{

	volatile struct unit	*up;

	volatile struct sdcom	*cp;

	uint		ss;



	unless ((device)

	and (device->istr & 1<<4))

		return;

	cipwait( );

	ss = reg( SS);

	switch (atab[istate][itab[ss]]) {

	case 0:

		stopdma( );

		up = curunitp;

		cp = up->comhead;

		if (reg( CP) == 0x60) {

			cp->okay = TRUE;

			cp->status = reg( TS);

		}

		if (up->comhead = cp->next)

			uqueue( up);

		(*cp->intr)( cp);

		istate = IDLE;

		startany( );

		break;

	case 1:

		istate = badhardware( ss);

		break;

	case 2:

		stopdma( );

		uqueue( curunitp);

	case 3:

		up = &units[reg( SI)&SDUNITS-1];

		unless (cp = up->comhead) {

			istate = badhardware( ss);

			break;

		}

		setreg( TL, 0);

		setreg( CP, 0x44);

		startdma( up);

		if (cp->reading)

			setreg( DI, cp->unit|DPD);

		else

			setreg( DI, cp->unit);

		setreg( CON, DM2|EDI|IDI);

		curunitp = up;

		istate = RESUMING;

		setreg( COM, startcom);

		break;

	case 4:

		setreg( CP, 0x45);

		setreg( TC+0, curunitp->tc0);

		setreg( TC+1, curunitp->tc1);

		setreg( TC+2, curunitp->tc2);

		istate = RESUMING;

		setreg( COM, startcom);

		break;

	case 5:

		stopdma( );

		up = curunitp;

		cp = up->comhead;

		if (up->comhead = cp->next)

			uqueue( up);

		(*cp->intr)( cp);

		istate = IDLE;

		startany( );

		break;

	case 6:

		curunitp->tc0 = reg( TC+0);

		curunitp->tc1 = reg( TC+1);

		curunitp->tc2 = reg( TC+2);

		setreg( CON, DM2|EDI|IDI);

		istate = RESUMING;

		setreg( COM, startcom);

		break;

	case 7:

		stopdma( );

		istate = IDLE;

		startany( );

		break;

	case 8:

		setreg( COM, 0xA0);

		until (reg( AS) & DBR)

			;

		if (reg( DR) == 0x03)

			istate = MESSAGING;

		else

			istate = badhardware( ss);

		break;

	case 9:

		setreg( TC+0, 0);

		setreg( TC+1, 0);

		setreg( TC+2, 0);

		setreg( CP, 0x46);

		setreg( CON, DM2|EDI|IDI);

		istate = ENDING;

		setreg( COM, startcom);

	}

}

I've also looked at the Western Digital Chip documentation and don't see what 0x49 even means :p

Feedback welcome!

Are you absolutely sure your SCSI termination is all good? Do you have any SCSI issues in Workbench? I would do some torture tests in Workbench - copying files and checking for corruption before going down the AMIX driver debugging path.

What is your SCSI setup (HDD type, termination setup etc)?

Have you tried with 3.1 roms?

Shot in the dark here,but a zip to simm adapter will treat simms as FPM ram,and the UX came with SC zips(static column) originally...zip part # ends in 402,i wouldn't think it would care,but it may possibly?

assuming that check the term power diode is correct on the new board and you have +5(or close) to the scsi,without this no terminators will work.

Amix expects the drives to be at specific device numbers,are they correct?

I seriously doubt it will work with anything but 3.1 roms..

Possibly - though I think unlikely as I would expect AMIX to do the same static column check as exec does. AMIX works on e.g. A2620/30 which one wouldn't expect to necessarily use static column RAM.

SCSI interrupt status register (0x17) content.

0x49 = "0100 1MC0 Unexpected information phase was expected". Unexpected errors are usually caused by hardware problems.

0x85 = "1000 0101 Disconnected has occurred."

Thanks Toni! I should have mentioned I decoded that part using the chip docs. It's a phase change before the transfer count is zero or an unexpected phase sequence during the select and transfer command. The error indicates this is happening Data In Phase.

What I meant is how does that switch statement interpret 0x49 to look up the response? Does it seek to element 73 in the table?

Cheers!
Bill

itab translates the device status 0x49 into DFA input code 1 ("Status is illegal or unsupported.")

atab then translates that input code to DFA action code 1 ("DEAD Report that driver has shut down."), which is then implemented in the "case 1:" clause.

I have a ReAmiga 3000 I recently finished, running the full 16MB FastRAM. I had installed AMIX from tape years ago, on my original A3000, and found the hard disk with AMIX still on it. After several fsck runs, it boots just fine. I think it's because the date puts the last fs checks far, far in the past, but it will take a very long time.

I do remember that AMIX was *very* intolerant of SCSI termination issues. Have you got proper. terminators on both ends of the chain?


Doc