AMAX problems

[mark_k]

I tested A-Max 2.56 with GVP emulation using v1.6 of gvpscsi.amhd. A-Max should automatically detect the AMAX0 partition, and on booting the emulated Mac, the Mac should ask whether you want to format it.

On booting a System 6.0.8 floppy disk (A-Max format, extended ADF), the desktop appears and you get the do-you-want-to-format prompt for the RAM disk. But the system kind of hangs after that (you can still move the mouse pointer). Log output:

SCSI command EE, no direction specified!
UAEHF: unsupported scsi command 0xEE LUN=0
WD33C93 unimplemented/unknown command 03
scsi_send_data() without direction!

I have uploaded an archive (~2.7MB) containing:
- Bootable HDF with AMAX0 partition
- WinUAE configs, one 68000 the other 68030/MMU
- Extended ADF disk images for A-Max format Mac System 6.0.8 800K disks

hxxp://www.4!s!h!a!r!e!d.com/file/uDRcWUtDce/A-Max_GVPtar.html
[Change hxxp to http and remove ! from URL.]

Boot HDF, double-click A-Max Startup icon on Workbench. Click Hard Disk / SCSI Preferences. Check Mount next to AMAX0, then OK and Start A-Max II.

If you use the 68030 config, A-Max tries to use the MMU but that doesn't work correctly. Maybe an MMU emulation bug? On starting emulation, get red screen with this log output:

68030 MMU enabled. Page size = 8192
Illegal instruction: 05bc at 0080005A -> 00F80AD2
Illegal instruction: 05bc at 0080005A -> 00F80AD2
Illegal instruction: 05bc at 0080005A -> 00F80AD2
...

[Toni Wilen]

[moved from beta thread, mostly old WD33C93 emulation problems and similar stuff]

SCSI command EE, no direction specified!

Fixed. Some WD33C93 emulation bugs. (There is so many different ways to do the same thing with WD33C93..)

But it still does not boot (HDF is not bootable? I set HDF as bootable to get the SCSI error, didn't try adfs). I don't see any SCSI emulation problems, also it does not repeat the command anymore, it stops after first SCSI READ(6) command.

If you use the 68030 config, A-Max tries to use the MMU but that doesn't work correctly

Assumes 68030 has prefetched at least next word before executing current instruction. Switches on MMU, then executes JMP (A1) that must come from prefetch buffer because MMU switch on also unmapped memory where above two instructions were located.

I am not sure if this is worth the trouble yet..

EDIT: Biggest issue is 68030 design, cache is between execution unit and MMU (Cache caches logical addresses), 68040+ has cache after MMU (caches physical addresses)

MMU 68030 does emulate instruction cache (if more compatible set) but it is emulated like 68040, emulating it like 68030 would be much more complex because every cache access needs to go through MMU and you also need to have special handling for any prefetch MMU access faults, they only must trigger if prefetched data is actually needed by execution unit.

EDIT2: Fake very simple single-word prefetch emulation added that fetches and stores next opcode word only when MMU state changes. AMAX works now.

[mark_k]

Originally Posted by Toni Wilen

Fixed. Some WD33C93 emulation bugs. (There is so many different ways to do the same thing with WD33C93..)

But it still does not boot (HDF is not bootable? I set HDF as bootable to get the SCSI error, didn't try adfs). I don't see any SCSI emulation problems, also it does not repeat the command anymore, it stops after first SCSI READ(6) command.

The AMAX0 partition is unformatted/blank. You need to boot the emulated Mac from System 6.0.8 disk 1, then run the Installer to install the OS to the partition.

With the latest winuae.exe the Mac sees the HD partition and offers to initialise it. I'm running the 6.0.8 installer now (using a 68000 config, will test 68030 later).


About the 68030 MMU issue... reminds me of the way a soft reboot is done by RESET / JMP (An), with the prefetch having fetched the JMP opcode before memory goes away. I'll test A-Max with 68040 too, maybe it will work correctly there.


Edit: Installing the OS seemed to work fine. After shutting down the emulated Mac and restarting A-Max, booting from the HD partition starts then I get a "sad Mac" icon with 0F0003 underneath it. That happens with both 68000 and 68030. Not sure what the problem is. Maybe because I selected to install a system for any Macintosh as opposed to a specific model? Or maybe another WD SCSI bug?

Edit 2: Uploaded HDF after installing System 6.0.8 to hxxp://www.4!s!h!a!r!e!d.com/file/q71ytii2ba/GVP_A-Max_hardfile_installedSy.html

[Toni Wilen]

Originally Posted by mark_k

About the 68030 MMU issue... reminds me of the way a soft reboot is done by RESET / JMP (An), with the prefetch having fetched the JMP opcode before memory goes away. I'll test A-Max with 68040 too, maybe it will work correctly there.

This should work (at least without MMU) if more compatible is set.

Edit: Installing the OS seemed to work fine. After shutting down the emulated Mac and restarting A-Max, booting from the HD partition starts then I get a "sad Mac" icon with 0F0003 underneath it. That happens with both 68000 and 68030. Not sure what the problem is. Maybe because I selected to install a system for any Macintosh as opposed to a specific model? Or maybe another WD SCSI bug?

WD logging seems fine, it reads multiple different blocks which practically guarantees it is working, at least reads have to work.

[mark_k]

Stranger and stranger... I tested the HDF (with installed System 6.0.8 in AMAX0 partition) with A2091 instead of GVP, config attached. Can load A-Max, it automatically uses scsi.amhd. However on starting the Mac emulation I get a blue screen. There were no WD-related log messages after clicking Start A-Max.

[Toni Wilen]

It seems to think SCSI is A3000 built-in and hangs while waiting for A3000 WD to respond.

[mark_k]

I also tested the HDF with the Oktagon driver (copy oktagon.amhd from the Oktagon disk to DEVS: before running A-Max). With that, clicking Start A-Max II then OK seems to do nothing at all; can still move mouse pointer, no WD log output obviously since the Oktagon doesn't use a WD SCSI chip. However after a while the emulated machine locks up with this log output:

 step ignored drive 0, 125
 step ignored drive 0, 100
A-Trap A873 at 632E2004 -> 74696E67
Exception 3 (632e2006) at 632e2004 -> 28003f!
CPU halted: reason = 2

Edit to add: Strange about the A3000 issue. I tested the HDF with an A3000 config (using built-in SCSI) and A-Max gives a message about not being able to find a driver. I could manually enter DEVS:scsi.amhd and start emulation, but it didn't try to boot from the HD Mac partition. On booting from Mac floppy I got the prompt to eject/initialize the Mac partition though. Selecting initialize didn't seem to actually do anything. There were a few lines saying WD33C93 command 18 in the log.

[Toni Wilen]

Originally Posted by mark_k

I also tested the HDF with the Oktagon driver (copy oktagon.amhd from the Oktagon disk to DEVS: before running A-Max). With that, clicking Start A-Max II then OK seems to do nothing at all; can still move mouse pointer, no WD log output obviously since the Oktagon doesn't use a WD SCSI chip. However after a while the emulated machine locks up with this log output:

I modified my previous GVP config (changed only SCSI to Oktagon) and I can't duplicate this, same results, reads few HD blocks and dies with same 0F0003 error.

EDIT: and same with my A3000 config too. (Your A3000 config have A2091? Why?)

[mark_k]

I forgot to deselect the A2091 ROM in the A3000 config. After doing that it does boot to the sad Mac icon.

Still not sure what the issue with the Oktagon config is; I just tried again with the same result as before. Is it worth my trying to use the WinUAE debugger to get some kind of backtrace when it crashes/hangs.

[Toni Wilen]

Originally Posted by mark_k

I forgot to deselect the A2091 ROM in the A3000 config. After doing that it does boot to the sad Mac icon.

Still not sure what the issue with the Oktagon config is; I just tried again with the same result as before. Is it worth my trying to use the WinUAE debugger to get some kind of backtrace when it crashes/hangs.

Switching off NTSC fixes it. Code tries to find romtags from RAM but it finds nothing and keeps looking and things go wrong when it starts reading CIA and custom registers. (Bad crack? Too new rom image?)

[mark_k]

Could be an incompletely cracked version? I'm trying again with (what I assume is) uncracked A-Max 2.53 and A-Max cartridge emulation (amax_rom_file= entry in config file). In the HDF I uploaded, v2.53 uncracked is in the A-Max II drawer.

[It might be a good idea to document that amaxromfile should be amax_rom_file in config files; it's not mentioned in winuaechangelog.txt...]

I can't get A-Max to start booting the Mac OS (it gets to the initial screen with ? floppy disk icon). It seems there's some interaction between A-Max cartridge emulation and floppy drives. Boot the HDF with an A-Max hardware config (attached here). Notice that the DF0:???? icon on Workbench even though no disk is in the drive. If you insert an Amiga-formatted disk in DF0:, you need to DiskChange DF0: in order for the system to detect it, and similarly after ejecting. It seems disk changes not being detected affects A-Max too; it doesn't sense when an A-Max formatted disk is inserted, so can't boot.

I tested WinUAE 1.4.5, the first release with A-Max cartridge emulation and the problem was there too. Not sure why I didn't notice that at the time...

By the way, with logging enabled there are a huge number of lines like
disk write DMA started, drvmask=0 motormask=0
as A-Max reads the Mac ROM data.

[Toni Wilen]

Originally Posted by mark_k

It seems there's some interaction between A-Max cartridge emulation and floppy drives.

Should be fixed now. (It is normal that ROM reading appears to slow down the emulation, it abuses disk emulation..)

NTSC + Oktagon weird behavior seems to be gone when using original version.

EDIT: "disk write DMA.." message is logged because amax starts disk DMA write without any (real) drive selected. Amax uses it to increase ROM address counter by one.

[mark_k]

About scsi.amhd not working with A590/A2091...

This is the routine that scsi.amhd uses to detect the SCSI type; none, A3000 or A590/A2091. (scsi.amhd from AMAX256.DMS which is a cracked version.)

It looks a little strange. For A590/A2091, scsi.device has to not be in the system resident tag list for the check to work correctly. (Could the way A-Max resets into the Mac emulation cause the A590/A2091 ROM to not be initialised???)

Call FindResident("scsi.device"). If found, assume we're running on an A3000. Set SCSI_type to $FF.
Next is a check for the WD3393 base address. It uses either $DD2020 or $DD0041, depending on whether or not bits [7:5] of $DD203A.B are 101. Were different base addresses used in different A3000 revisions? Or could that be a chip type check (3393 vs 33C93A etc.)? It sets SCSI_type to 1 if using $DD2020 as base address.

lbC0000B6	LEA	(SDHD,PC),A5
		MOVE.L	A3,(lbL00001C-SDHD,A5)
		MOVEA.L	(4).W,A6
		LEA	(ScsiName,PC),A1
		JSR	(_LVOFindResident,A6)
		TST.L	D0
		SNE	(SCSI_type-SDHD,A5)
		BEQ.B	.NotA3000

		LEA	($DD2020).L,A0	;Possible WD3393 base address
		MOVE.B	($1A,A0),D0	;$DD203A
		ANDI.B	#%11100000,D0
		CMPI.B	#%10100000,D0
		BNE.B	lbC0000F2

		MOVE.W	#$FFFF,(lbW00008C-SDHD,A5)
		NEG.B	(SCSI_type-SDHD,A5)
		BRA.B	lbC000138

lbC0000F2	MOVEA.L	#$DD0041,A0	;WD3393 base address to use
		BRA.B	lbC000138

.NotA3000	LEA	(ExpansionName,PC),A1
		MOVEQ	#0,D0
		JSR	(_LVOOpenLibrary,A6)
		MOVEA.L	D0,A6
		SUBA.L	A0,A0
lbC000108	MOVEQ	#0,D0
		MOVE.W	(CBM_WestChester_mfr_ID-SDHD,A5),D0	;$202
		MOVEQ	#2,D1	;A590/A2091
		JSR	(_LVOFindConfigDev,A6)
		TST.L	D0
		BNE.B	.Found

		MOVEQ	#0,D0
		MOVE.W	(CBM_WestChester_mfr_ID-SDHD,A5),D0
		MOVEQ	#3,D1	;A590/A2091
		SUBA.L	A0,A0
		JSR	(_LVOFindConfigDev,A6)
		TST.L	D0
		BEQ.B	.NoSCSI

.Found		MOVEA.L	D0,A0
		DBRA	D7,lbC000108	;???

		MOVEA.L	(cd_BoardAddr,A0),A0
		ADDA.W	#$91,A0
lbC000138	MOVE.L	A0,(WD3393base???-SDHD,A5)
		MOVEQ	#0,D0
		RTS

.NoSCSI		MOVEQ	#-$50,D0
		RTS

[Toni Wilen]

Originally Posted by mark_k

It looks a little strange. For A590/A2091, scsi.device has to not be in the system resident tag list for the check to work correctly. (Could the way A-Max resets into the Mac emulation cause the A590/A2091 ROM to not be initialised???)

My guess is that it confuses IDE scsi.device as A3000 scsi.device. A590/A2091 scsi.device is not in resident list but IDE scsi.device is.

Next is a check for the WD3393 base address. It uses either $DD2020 or $DD0041, depending on whether or not bits [7:5] of $DD203A.B are 101. Were different base addresses used in different A3000 revisions? Or could that be a chip type check (3393 vs 33C93A etc.)? It sets SCSI_type to 1 if using $DD2020 as base address.

A3000 ROM driver only uses $dd0041. I have no idea what model uses $dd2020 (It is also A4000 built-in IDE address but A4000 came later and it does not work with IDE anyway)

Unless there was some different prototype A3000s or something.

[mark_k]

Ah, so with A500/2000 Kickstart 2.04 or earlier scsi.amhd should work correctly with A590/A2091.

I've attached a patched scsi.amhd which skips the A3000 check (so it won't for HDs connected to the A3000 SCSI controller). With that I can get the Mac OS to start booting from HD with A2091. But it gets stuck/hangs at the same point as the other SCSI controller types.

[mark_k]

Another curious thing about A-Max, which might relate to the recent 1mchipjumper option.

The A-Max 1.0 manual mentions a modification to allow use of 1MB contiguous memory for the emulated Mac. This was in the pre-ECS days. With the mod, the address of $C00000 RAM is moved to $080000. But then Kickstart thinks you have 1MB chip RAM (with OCS Agnus you don't), so ReadySoft provided a "KillChip" program to handle that.

Does the current 1mchipjumper option apply only when ECS Agnus is used?

11. HARDWARE MODIFICATION FOR THE A500/A2000

As an option for extremely advanced users, the information given here will allow 1 Mb Amiga 500 owners with Rev. 4 and above motherboards and Amiga 2000 owners with B2000 motherboards (not the original German A2000 motherboards) to make jumper changes to their motherboard that will improve their memory configurations so that it is more compatible with A-Max. By making this change, the second 512K of expansion memory can be made contiguous with the first 512K block memory, creating a single 1 Mb block that is nearly identical to the Mac Plus and SE memory map. The jumper change is the same as that needed when the Extended Chip Set is
installed (if you already have the new Agnus chip installed, you have no need to make the changes indicated here). The Extended Chip Set will be available from Commodore and improves the capabilities of the Amiga by increasing the amount of chip RAM to 1Mb, and supporting a 480 line non-interlaced video mode for use with multi-sync monitors.

The one disadvantage to making this change without installing ECS is that AmigaDOS will incorrectly assume you have 1 Mb of chip RAM in your machine, and attempt to use the memory as such. To stop this from happening you must insert a command into the startup-sequence of your Amiga boot disk(s) that corrects the memory type of the 512K expansion RAM. The command to do this is called "KillChip", and it can be found in the C directory of the "A-Max Program" disk. The "KillChip" command should be copied to all your Amiga boot disks and executed at the beginning of all your startup-sequences. A program called "CheckChipSet" is supplied in the A-Max directory of the "A-Max Program Disk" that, once run, will tell you if you have the new or old Agnus chip. If you have the new Agnus, you will not have to use the "KillChip" program. If you already have 1Mb of chip memory, your Amiga must already have and be setup for the new chip set and none of the following is necessary.

The jumper changes are given below. Do not attempt to make this modification unless you know what you are doing - ReadySoft cannot be responsible for any mishaps that might occur. Making the changes described here could void your warranty, so you may want your dealer to make the modifications.

A2000

J101:move jumper from 1-2 to 2-3

J500:open (this is normally soldered closed)

A500

The A500 change is much trickier than the A2000 change. As mentioned above, this change is only applicable to A500s with a motherboard revision number 4 and above. If you have a revision 3 motherboard, there is a different and more complicated method to move the memory which we suggest you contact your dealer about. Note that you must have the A501 512K memory expander for this change to work.

Before you begin, find the revision number and verify that it is 4 or higher. There are now two changes to the motherboard you must make, the first is a jumper you must desolder and then resolder to a different pad, and the second is a trace on the board you must cut.

Locate the CPU (large chip marked 68000) and the ROM beside it. Between these two chips are three jumper pads collectively called JP2. Looking closely will reveal that the bottom and center pads are connected and the top one is not. You must reverse the order by making one cut with an EXACTO knife to open the bottom from the center and then solder the top to the center with a small dab of solder.

Next locate the memory expansion connector marked CNX which runs vertically near the front right of the motherboard. Toward the end of the connector that is furtherest away from the front of the computer there are a number of traces on the board that run parallel to the connector. The one you must find is the third trace from the connector (be careful when counting because ther may be traces that are obscured by white silk-screening). This trace runs to a pad approximately one inch down from the end of the CNX connector (there are a group of pads at this point, the
one you want is the closest one to the connector). Use an EXACTO knife to cut this trace at any point within the area that it runs parallel to the connector.

[Toni Wilen]

Originally Posted by mark_k

Another curious thing about A-Max, which might relate to the recent 1mchipjumper option.

The A-Max 1.0 manual mentions a modification to allow use of 1MB contiguous memory for the emulated Mac. This was in the pre-ECS days. With the mod, the address of $C00000 RAM is moved to $080000. But then Kickstart thinks you have 1MB chip RAM (with OCS Agnus you don't), so ReadySoft provided a "KillChip" program to handle that.

Does the current 1mchipjumper option apply only when ECS Agnus is used?

Currently it is only available if ECS Agnus. But it can be used to emulate above effect too. (No update yet available, Yet Another Bitplane DMA Sequencing emulation rewrite in progress..)

Originally Posted by mark_k

Ah, so with A500/2000 Kickstart 2.04 or earlier scsi.amhd should work correctly with A590/A2091.

I've attached a patched scsi.amhd which skips the A3000 check (so it won't for HDs connected to the A3000 SCSI controller). With that I can get the Mac OS to start booting from HD with A2091. But it gets stuck/hangs at the same point as the other SCSI controller types.

It seems to crash because execution jumps to data area.

Jumps to address 60c8 in following weird data:

00006000 02AA 660E 2003 0680 0000 0080 A122 A023  ..f. ........".#
00006010 60E0 2050 91C0 D0FC 0080 A057 60D4 4E75  `. P.......W`.Nu
00006020 A920 3139 3833 2C20 3139 3834 2C20 3139  . 1983, 1984, 19
00006030 3835 2C20 3139 3836 2C20 3139 3837 2C20  85, 1986, 1987,
00006040 3139 3838 2C20 3139 3839 2C20 3139 3930  1988, 1989, 1990
00006050 2041 7070 6C65 2043 6F6D 7075 7465 7220   Apple Computer
00006060 496E 632E 0D41 6C6C 2052 6967 6874 7320  Inc..All Rights
00006070 5265 7365 7276 6564 2E0D 0D48 656C 7021  Reserved...Help!
00006080 2048 656C 7021 2057 65D5 7265 2062 6569   Help! We.re bei
00006090 6E67 2068 656C 6420 7072 6973 6F6E 6572  ng held prisoner
000060A0 2069 6E20 6120 7379 7374 656D 2073 6F66   in a system sof
000060B0 7477 6172 6520 6661 6374 6F72 7921 0D00  tware factory!..
000060C0 8A00 0012 0000 0080 000A 8001 8001 7FFF  ................
000060D0 7FFF 8000 0012 0000 0094 000A 0000 0000  ................
000060E0 0200 0280 8000 0436 0000 0088 FFFF FFFF  .......6........
000060F0 FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF  ................
00006100 FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF  ................
00006110 FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF  ................

[mark_k]

Since it seems like all .amhd drivers (well GVP, A2091 and Oktagon anyway) have the same problem... I wonder if there could be some timing issue/bug with the Mac OS and/or A-Max, which causes a problem if the hard drive is too fast.

If I boot from floppy, I can access the HD partition with no problems (as far as I can tell); it's just booting that breaks.

[Toni Wilen]

Originally Posted by mark_k

Since it seems like all .amhd drivers (well GVP, A2091 and Oktagon anyway) have the same problem... I wonder if there could be some timing issue/bug with the Mac OS and/or A-Max, which causes a problem if the hard drive is too fast.

If I boot from floppy, I can access the HD partition with no problems (as far as I can tell); it's just booting that breaks.

I don't think it is SCSI emulation problem, Oktagon uses very different chip than GVP and A2091/A590.

Does Amax have any ide driver(s)?

[Retro1234]

Sorry to but in -Still intrested in the old Amax - especially the 2.x versions that work on 68000
Ive got a little confused did you guys get in Working?
as far as I know there are no AMHD IDE drivers - Well none that would work on my A600