English Amiga Board


Go Back   English Amiga Board > Support > support.WinUAE

 
 
Thread Tools
Old 25 May 2017, 21:08   #21
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 43
Posts: 22,121
Ignore that confusing table. Check a2091.cpp/dmac8727_write_pcsd()
Toni Wilen is offline  
Old 25 May 2017, 21:19   #22
mark_k
Registered User
 
Join Date: Aug 2004
Location:
Posts: 2,967
Quote:
Originally Posted by Toni Wilen View Post
EDIT: ST-506 enable/disable option added. (note: default is disabled)
Default should probably be enabled, since as far as I could tell from looking at board pics, there's no jumper to control that?
mark_k is offline  
Old 25 May 2017, 22:02   #23
mark_k
Registered User
 
Join Date: Aug 2004
Location:
Posts: 2,967
Quote:
Originally Posted by Toni Wilen View Post
F command is also never used.
I haven't tested it in emulation yet, but looking at its code, the A-Max hddisk.amhd does issue command $0F.


Also, about FORMAT TRACK... do you put the last-accessed LBA in the command block status bytes when the command completes?
mark_k is offline  
Old 25 May 2017, 22:33   #24
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 43
Posts: 22,121
Quote:
Originally Posted by mark_k View Post
Default should probably be enabled, since as far as I could tell from looking at board pics, there's no jumper to control that?
Default is always empty checkbox and I don't like inverted options ("disable st-506" or something like that). Bit probably is set when some ST-506 related chip is removed. Or this is yet another feature that wasn't in final hardware...

Quote:
Originally Posted by mark_k View Post
I haven't tested it in emulation yet, but looking at its code, the A-Max hddisk.amhd does issue command $0F.
A-Max drivers are always good test cases, usually very very different than "native" drivers. Does it also have ST-506 bit check?

Quote:
Also, about FORMAT TRACK... do you put the last-accessed LBA in the command block status bytes when the command completes?
Yes (format, verify, seek, read, write)
Toni Wilen is offline  
Old 25 May 2017, 22:41   #25
mark_k
Registered User
 
Join Date: Aug 2004
Location:
Posts: 2,967
Quote:
Originally Posted by Toni Wilen View Post
Default is always empty checkbox and I don't like inverted options ("disable st-506" or something like that). Bit probably is set when some ST-506 related chip is removed. Or this is yet another feature that wasn't in final hardware...
Maybe Commodore intended to market a SCSI-only version of the board?

I did wonder whether (for example) a connected ST-506 drive pulls up one of the lines on the drive connector(s) and so the driver can easily detect whether any ST-506 drive is present. But nothing like that seems to be in the schematic.
Quote:
Originally Posted by Toni Wilen View Post
A-Max drivers are always good test cases, usually very very different than "native" drivers. Does it also have ST-506 bit check?
Don't know yet. But here's code around issuing command $0F:
Code:
	MOVEA.L	(IO_UNIT,A5),A0
	LEA	($4A,A0),A0	;Point to bad blocks list in unit structure
	CMPI.W	#$BAD1,(-8,A0)	;Should be $BAD1 signature 8 bytes before it
	BNE.B	.NoBadBlocksList

.CopyBadBlocksList
	MOVE.L	(A0)+,(A4)+	;Copy LBA of bad sector
	MOVE.L	(A0)+,(A4)+	;Copy LBA of replacement sector
	CMPI.L	#$7FFFFFFF,(-4,A4)	;Reached end?
	BNE.B	.CopyBadBlocksList

	SUBQ.W	#8,A4
.NoBadBlocksList
	CLR.L	(A4)+	;Replace the two $7FFFFFFF with 0
	CLR.L	(A4)+
	BSET	#31,D7	;So as to only issue command $0F once
	BNE.B	lbC0001F6

	MOVEA.L	A5,A1
	MOVE.W	#$10,(IO_COMMAND,A1)	;hddisk command 16...
	CLR.L	(IO_LENGTH,A1)
	LEA	(CommandBlock,PC),A2
	MOVE.L	A2,(IO_DATA,A1)
	MOVE.W	#$F00,(A2)	;Command $0F, Change Command Block
	LEA	(ChangeCmdBlockData-CommandBlock,A2),A0
	MOVE.L	A0,D0
	LSL.L	#8,D0
	MOVE.L	D0,(CommandBlockByte6-CommandBlock,A2)
	MOVE.L	#$1FE00,(A0)	;New command block address
	CLR.L	(IO_OFFSET,A1)
	JSR	(_LVODoIO,A6)
lbC0001F0
	MOVEA.L	A5,A1
	JSR	(_LVOCloseDevice,A6)

lbC0001F6
	ADDA.W	#14,A3
	DBRA	D7,lbC000154

	MOVE.B	($3F,A5),D0	;[MsgPort is immediately after IORequest]
	JSR	(_LVOFreeSignal,A6)
	ADDA.W	#$52,SP
	RTS
mark_k is offline  
Old 26 May 2017, 12:29   #26
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 43
Posts: 22,121
I guess some PAL chip probably must have something to do with ST-506 chip "detection", perhaps some Z80 or HDC pin state is checked. (grounded/+5v/floating). Or perhaps it needed different PAL chip(s) programming.

I also changed the GUI option, it probably is best to have annoying "Disable ST-506" if this configuration never existed (except by manually removing chips? Need real hardware testing.)

Hardware design is quite strange..

SCSI controller: driver code directly accesses 8727 DMAC and WD33C93. Very normal use case.

ST-506: This is the weird one. Driver code writes CDB (using almost SCSI-like commands + status info + DMA memory address), 16-byte 512-byte aligned memory region, strobes Z2 address to start Z80 code. Z80 reads the CDB, accesses 8727 DMAC and HD, triggers interrupt when processing is done.

Yes, it frees 68000 completely when accessing the (very slow) HD but was it really worth the trouble? (It required at least Z80 + RAM + extra ROM chip + probably lots of extra glue logic)
Toni Wilen is offline  
Old 26 May 2017, 16:21   #27
mark_k
Registered User
 
Join Date: Aug 2004
Location:
Posts: 2,967
The bit being in the ExpansionRom structure suggests it's hard-coded in the AutoConfig PAL(s), any SCSI-only variant would have a differently-programmed PAL. [Could that be the mysterious with-1MB-RAM product 514/2?]

Maybe the ST-506-side design is descended from a previous Commodore hard disk controller? Or maybe the hardware designers were more familiar with the Z80; having all intelligence on the Amiga side would require a different skill set. Or perhaps Commodore had a load of spare Z80s from all those C128s and C64 CP/M cartridges they didn't sell?

The Amiga driver has enough to deal with without very low-level considerations. It manages an internal cache (eight up-to-eight-sector runs) along with bad block management with lots of edge cases. E.g. filesystem requests a single-block read (are all OFS reads for one sector?), we're going to read the surrounding 8 sectors to cache them but there's a bad block in those 8 sectors. And remember it could be running from chip/slow RAM with a 4-plane high-res screen, so much worse hard-real-time response than an on-board CPU.


About FORMAT TRACK... to integrate with WinUAE's bad sector support (badblocks=... in .geo file) and better match the A2090 spec:
- The track is filled with $FF bytes (p.15 of A2090A tech data).
- The LBA and transfer length probably have to be track-aligned (i.e. transfer length = 1 track, LBA the first sector of a track), error $21 could be returned if not.
- For attempted read or write of a bad sector, error $13 or $14 could be returned. Or $10, $11, or $12 could apply with real hardware.

Last edited by mark_k; 27 May 2017 at 00:26.
mark_k is offline  
Old 26 May 2017, 18:25   #28
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 43
Posts: 22,121
Quote:
Originally Posted by mark_k View Post
The bit being in the ExpansionRom structure suggests it's hard-coded in the AutoConfig PAL(s), any SCSI-only variant would have a differently-programmed PAL. [Could that be the mysterious with-1MB-RAM product 514/2?]

Maybe the ST-506-side design is descended from a previous Commodore hard disk controller? Or maybe the hardware designers were more familiar with the Z80; having all intelligence on the Amiga side would require a different skill set. Or perhaps Commodore had a load of spare Z80s from all those C128s and C64 CP/M cartridges they didn't sell?
That would make more sense

Schematics are quite interesting, 8727 does not have internal address counter but uses external counters (3xPALs) that 8727 clocks or sets. (Those LDx lines which probably directly map to lowest 3 bits of PCSS which explains the odd way of setting DMA start address.)

Quote:
About FORMAT TRACK... to integrate with WinUAE's bad sector support (badblocks=... in .geo file) and better match the A2090 spec:
This can wait. Possibly very long time..
Toni Wilen is offline  
Old 28 May 2017, 20:29   #29
mark_k
Registered User
 
Join Date: Aug 2004
Location:
Posts: 2,967
More about FORMAT TRACK...

From the log output above, Prep issues FORMAT TRACK with the number of sectors/track in the transfer length field (command block byte 4):
SCSIEMU HD 0: 06.00.00.55.11.00.00.00.00.00.00.00 CMDLEN=6 DATA=0F917E08

But the actual amount of data transferred from Amiga to HDC for that command should be 1 sector (512 bytes). See p.13-14 of A2090A tech data.


Also, in git commit 4021cbf83db928447f62ea0edad8ff68ef00a367 you did:
wd->cdmac.c8727_st506_cb = (ccba[1] << 16) | (ccba[2] << 8) | (ccba[3] << 0);

Since bit 0 is either must-be-0 or ignored (maybe someone with real hardware can check, or maybe I'll get around to disassembling the Z80 code someday?), should that be:
wd->cdmac.c8727_st506_cb = (ccba[1] << 16) | (ccba[2] << 8) | (ccba[3] << 0) & ~1;

Last edited by mark_k; 28 May 2017 at 20:34.
mark_k is offline  
Old 28 May 2017, 21:36   #30
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 43
Posts: 22,121
Quote:
Originally Posted by mark_k View Post
More about FORMAT TRACK...

From the log output above, Prep issues FORMAT TRACK with the number of sectors/track in the transfer length field (command block byte 4):
SCSIEMU HD 0: 06.00.00.55.11.00.00.00.00.00.00.00 CMDLEN=6 DATA=0F917E08

But the actual amount of data transferred from Amiga to HDC for that command should be 1 sector (512 bytes). See p.13-14 of A2090A tech data.
Currently FORMAT TRACK does nothing. I thought it didn't receive any data and it was drive job to generate the data. Is there actual ancient SCSI spec somewhere (or SASI or whatever where it was implemented) that documents this?

EDIT: Found it in WD1002-SHD_OEM_Manual_Aug1984. "The command writes 6C Hex into all data fields specified." so this is "official" command..

When PREP calls FORMAT TRACK, CDB DMA pointer points to 17 sectors of generated data so 512 bytes don't seem to be correct.

Quote:
Also, in git commit 4021cbf83db928447f62ea0edad8ff68ef00a367 you did:
wd->cdmac.c8727_st506_cb = (ccba[1] << 16) | (ccba[2] << 8) | (ccba[3] << 0);

Since bit 0 is either must-be-0 or ignored (maybe someone with real hardware can check, or maybe I'll get around to disassembling the Z80 code someday?), should that be:
wd->cdmac.c8727_st506_cb = (ccba[1] << 16) | (ccba[2] << 8) | (ccba[3] << 0) & ~1;
Maybe but I am not adding restrictions until this is confirmed. Z80 code may have workarounds..

Last edited by Toni Wilen; 28 May 2017 at 21:51.
Toni Wilen is offline  
Old 28 May 2017, 22:54   #31
mark_k
Registered User
 
Join Date: Aug 2004
Location:
Posts: 2,967
Quote:
Originally Posted by Toni Wilen View Post
Currently FORMAT TRACK does nothing. I thought it didn't receive any data and it was drive job to generate the data. Is there actual ancient SCSI spec somewhere (or SASI or whatever where it was implemented) that documents this?

EDIT: Found it in WD1002-SHD_OEM_Manual_Aug1984. "The command writes 6C Hex into all data fields specified." so this is "official" command..
I don't think there was one official definition of what command $06 does, so it varied from controller to controller. If emulating the A2090 you probably want to do as it does though.
Quote:
Originally Posted by Toni Wilen View Post
When PREP calls FORMAT TRACK, CDB DMA pointer points to 17 sectors of generated data so 512 bytes don't seem to be correct.
The TD_FORMAT code in hddisk.device uses a 32KB track buffer, but FORMAT TRACK doesn't use it all, only 2×sectors/track. TD_FORMAT issues FORMAT TRACK, then writes and reads the track several times. Those writes/reads use more of the transfer buffer of course.

Here's part of the TD_FORMAT code:
Code:
	MOVEA.L	(Mem8DA1-Mem8DA1,A6),A1	;Command block

	LEA	(ThirtyTwoKBTransferBuffer-Mem8284,A2),A0
	MOVE.L	A0,D0
	MOVE.B	D0,(8,A1)
	ROR.L	#8,D0
	MOVE.B	D0,(7,A1)
	ROR.L	#8,D0
	MOVE.B	D0,(6,A1)

	BCLR	#6,(lbB00AB25-Unit,A3)
	BCLR	#7,(lbB00AB25-Unit,A3)
	BCLR	#5,(lbB00AB25-Unit,A3)

.Next	BSR.W	FormatTrack	; See disassembly below

	MOVE.L	#$6DB6DB6D,D5
	BSR.W	FillTrackBufferWithD5
	BSR.W	WriteTrack
	BSR.W	ReadTrack

	MOVE.L	#$DB6DB6DB,D5
	BSR.W	FillTrackBufferWithD5
	BSR.W	WriteTrack
	BSR.W	ReadTrack

	MOVE.L	#$B6DB6DB6,D5
	BSR.W	FillTrackBufferWithD5
	BSR.W	WriteTrack
	BSR.W	ReadTrack

	BTST	#6,(lbB00AB25-Unit,A3)	;Was a sector marked as bad?
	BEQ.B	.TrackOK

	BSR.W	FormatTrack
	BCLR	#6,(lbB00AB25-Unit,A3)
	TST.B	D0
	BEQ.B	.TrackOK

	MOVE.B	D0,(IO_ERROR,A4)
	BRA.B	lbC001586

.TrackOK	ADDQ.L	#1,D2	;Number of the next track
	SUBQ.L	#1,D3	;Number of tracks remaining
	BNE.B	.Next

Code:
; D2: track number(?)
FormatTrack	MOVEM.L	D2-D7/A2/A4,-(SP)
	LEA	(ThirtyTwoKBTransferBuffer-Mem8284,A2),A4
	CLR.L	D3
	MOVE.W	(SectorsPerTrack-Unit,A3),D3
	MOVE.L	D3,D7	;Sectors/track
	MOVE.L	D2,D4	;Track number
	MULU.W	D3,D4	;*sectors/track to get LBA of first sector in track
	MOVE.L	D4,D5	;LBA of first sector in track
	MOVE.L	D2,D6	;Track number
	SUBQ.W	#1,D3	;Sectors/track - 1 for DBF
	CLR.L	D2
	MOVE.B	(NumHeads-Unit,A3),D2
	DIVU.W	D2,D6	;(Track number)/(number of heads)
	CLR.W	D6
	SWAP	D6	;So head number in D6???
.Loop	MOVE.L	D5,D1	;LBA of first sector in track
	ADD.L	D6,D1	;Add head number???
	BSR.W	FindReplacementLBAInTable
	BEQ.B	.BlockBad

	CLR.B	(A4)+
	BRA.B	.Continue

.BlockBad	MOVE.B	#$80,(A4)+

.Continue	MOVE.B	D6,(A4)+
	ADDQ.B	#1,D6
	DIVU.W	D7,D6	;Divide by sectors/track
	CLR.W	D6
	SWAP	D6
	DBRA	D3,.Loop

	MOVEA.L	(Mem8DA1-Mem8DA1,A6),A1	;Point to (512-byte-aligned) command block
	MOVE.B	#6,(0,A1)	;FORMAT TRACK opcode
	MOVE.W	D5,(2,A1)
	SWAP	D5
	OR.B	(DriveNumOrSCSIIDInBits7to5-Unit,A3),D5
	MOVE.B	D5,(1,A1)
	MOVE.B	D7,(4,A1)	;Number of sectors/track in transfer length field
	MOVE.B	#$FF,(12,A1)
	BSR.W	DoLowLevelCommand???
	MOVEA.L	(Mem8DA1-Mem8DA1,A6),A1	;Point to (512-byte-aligned) command block
	MOVE.B	(12,A1),D0	;First byte of "sense data"
	BSR.W	IsHardError???
	MOVEM.L	(SP)+,D2-D7/A2/A4
	RTS
mark_k is offline  
Old 29 May 2017, 20:26   #32
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 43
Posts: 22,121
Quote:
Originally Posted by mark_k View Post
I don't think there was one official definition of what command $06 does, so it varied from controller to controller. If emulating the A2090 you probably want to do as it does though.
The TD_FORMAT code in hddisk.device uses a 32KB track buffer, but FORMAT TRACK doesn't use it all, only 2×sectors/track. TD_FORMAT issues FORMAT TRACK, then writes and reads the track several times. Those writes/reads use more of the transfer buffer of course.
I don't see anything updating the buffer in FORMAT_TRACK function. It seems it really does what WD spec says. (and the 6DB6DB6D data was really meant for normal writes, not for FORMAT_TRACK, this explains why the first FORMAT_TRACK buffer was mostly empty)
Toni Wilen is offline  
Old 29 May 2017, 21:30   #33
mark_k
Registered User
 
Join Date: Aug 2004
Location:
Posts: 2,967
See between .Loop and DBRA D3,.Loop in the disassembly above. It seems to be setting up the data specifying sector order (interleave) as described in section 6.2.5.1 of the A2090 tech data. I don't fully understand that yet, but it probably implements the interleaving across head boundaries shown in Table 6-4 (p.14).

I've started to look at the Z80 code. Not much to report so far, but $04 seems to be a valid opcode (FORMAT UNIT in SCSI). Not sure what that command does. Also $CA is valid, and $CB is kind of. "Kind of" because based on my examination so far, $CB is at the end of the valid-opcodes table, and there isn't a corresponding entry for it in the following jump table...

Last edited by mark_k; 29 May 2017 at 21:38.
mark_k is offline  
Old 29 May 2017, 21:37   #34
mark_k
Registered User
 
Join Date: Aug 2004
Location:
Posts: 2,967
Quote:
Originally Posted by Toni Wilen View Post
Ignore that confusing table. Check a2091.cpp/dmac8727_write_pcsd()
Thanks. From reading that... does that mean you could, say, set the upper, middle and lower DMA address latches to 0 by using 8727 command $F8?
mark_k is offline  
Old 29 May 2017, 22:17   #35
mark_k
Registered User
 
Join Date: Aug 2004
Location:
Posts: 2,967
Quote:
Originally Posted by Toni Wilen View Post
Maybe but I am not adding restrictions until this is confirmed. Z80 code may have workarounds..
It seems the low bit of the 4-bytes CHANGE COMMAND BLOCK data is ignored. This is part of the Z80 code:
Code:
CHANGE_COMMAND_BLOCK_routine?:          ; DATA XREF: ROM:0148o
ROM:01CA                 ld      c, 4
ROM:01CC                 call    sub_537         ; Returns DMA address bytes from command block in hlb (b=a), points de to unk_2287
ROM:01CF                 ld      hl, unk_2288
ROM:01D2                 ld      d, (hl)         ; Get High order DMA Byte
ROM:01D3                 inc     hl
ROM:01D4                 ld      e, (hl)         ; Get Mid Order DMA Byte
ROM:01D5                 srl     d
ROM:01D7                 rr      e
ROM:01D9                 ld      (CommandBlockDMAAddress), de ; Amiga address shifted right 1 bit
ROM:01DD                 inc     hl
ROM:01DE                 ld      a, (hl)         ; Get Low Order DMA Byte
ROM:01DF                 rr      a
ROM:01E1                 ld      (CommandBlockDMAAddressLowByte), a ; (Low byte of) Amiga address shifted right 1 bit
ROM:01E4                 jp      SetErrorCodeTo0_Jump_word_23A1
ROM:01E4 ; End of function CHANGE_COMMAND_BLOCK_routine?
mark_k is offline  
Old 30 May 2017, 16:26   #36
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 43
Posts: 22,121
Quote:
Originally Posted by mark_k View Post
Thanks. From reading that... does that mean you could, say, set the upper, middle and lower DMA address latches to 0 by using 8727 command $F8?
Yeah, I am sure low 3 bits are directly connected to LD0-2 pins that are used to reload each 8-bit DMA counter PAL chip.

"Command" is imho wrong word in documented, it is simple bitmask, each bit does something when zero (active low).
Toni Wilen is offline  
Old 31 May 2017, 23:29   #37
mark_k
Registered User
 
Join Date: Aug 2004
Location:
Posts: 2,967
Testing with 3.5.0b10 now. I used Prep to define a small boot partition and rebooted (with the A2090 reinstall disk still in DF0:). Then I double-clicked FormatHD.

Formatting proceeds but at the end the Amiga hangs, looking like it was just about to show a requester. Screenshot at
Code:
http://www.media!fire.com/view/0r4tnxxr824ewov/HangAtEndOfFormat.png
The last lines in the log were:
Code:
ST-506 CMD 00C0D800 0a.00.07.a3.11.00 23.4b.54
SCSIEMU HD 0: 0A.00.07.A3.11.00.00.00.00.00.00.00 CMDLEN=6 DATA=0000000006848D40
-> DATAOUT=8704 ST=0 SENSELEN=0 REPLYLEN=0
ST-506 CMD 00C0D800 08.00.07.a3.11.00 23.4b.54
SCSIEMU HD 0: 08.00.07.A3.11.00.00.00.00.00.00.00 CMDLEN=6 DATA=0000000006848D40
-> DATAOUT=8704 ST=0 SENSELEN=0 REPLYLEN=0
ST-506 CMD 00C0D800 0a.00.07.70.44.00 01.89.08
SCSIEMU HD 0: 0A.00.07.70.44.00.00.00.00.00.00.00 CMDLEN=6 DATA=0000000006848D40
-> DATAOUT=34816 ST=0 SENSELEN=0 REPLYLEN=0
ST-506 CMD 00C0D800 08.00.07.70.44.00 01.89.08
SCSIEMU HD 0: 08.00.07.70.44.00.00.00.00.00.00.00 CMDLEN=6 DATA=0000000006848D40
-> DATAOUT=34816 ST=0 SENSELEN=0 REPLYLEN=0
ST-506 CMD 00C0D800 0a.00.04.1e.02.00 01.89.08
SCSIEMU HD 0: 0A.00.04.1E.02.00.00.00.00.00.00.00 CMDLEN=6 DATA=0000000006848D40
-> DATAOUT=1024 ST=0 SENSELEN=0 REPLYLEN=0
ST-506 CMD 00C0D800 0a.00.00.88.01.00 01.89.08
SCSIEMU HD 0: 0A.00.00.88.01.00.00.00.00.00.00.00 CMDLEN=6 DATA=0000000006848D40
-> DATAOUT=512 ST=0 SENSELEN=0 REPLYLEN=0
ST-506 CMD 00C0D800 08.00.00.88.08.00 c0.d8.c0
SCSIEMU HD 0: 08.00.00.88.08.00.00.00.00.00.00.00 CMDLEN=6 DATA=0000000006848D40
-> DATAOUT=4096 ST=0 SENSELEN=0 REPLYLEN=0
ST-506 CMD 00C0D800 08.00.04.18.08.00 c0.e8.d4
SCSIEMU HD 0: 08.00.04.18.08.00.00.00.00.00.00.00 CMDLEN=6 DATA=0000000006848D40
-> DATAOUT=4096 ST=0 SENSELEN=0 REPLYLEN=0
mark_k is offline  
Old 01 June 2017, 19:09   #38
mark_k
Registered User
 
Join Date: Aug 2004
Location:
Posts: 2,967
Quote:
Originally Posted by mark_k View Post
Another mystery... the driver contains code to check for product 514/2. If found, it tests the longword at BoardAddr+1MB. If it seems to be RAM, it adds 1MB of memory starting there to the system list. What product would that be for? It would seemingly require the board occupy 2MB in the $200000 region, wasting almost 1MB address space.
Commodore's ShowConfig command has entries for product 514/2 and 514/3 which are both described as "A590/A2091 HD controller".

I wonder if some early/prototype version of what was to become the A590/2091 was A2090-like (maybe SCSI-only?) with 1MB on-board RAM???
mark_k is offline  
Old 01 June 2017, 20:13   #39
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 43
Posts: 22,121
Quote:
Originally Posted by mark_k View Post
Commodore's ShowConfig command has entries for product 514/2 and 514/3 which are both described as "A590/A2091 HD controller".

I wonder if some early/prototype version of what was to become the A590/2091 was A2090-like (maybe SCSI-only?) with 1MB on-board RAM???
I don't know. A2090 is autoconfig so why have non-autoconfig RAM?

Quote:
Originally Posted by mark_k View Post
Testing with 3.5.0b10 now. I used Prep to define a small boot partition and rebooted (with the A2090 reinstall disk still in DF0. Then I double-clicked FormatHD.
I also got crash but decided it is bug in prep (or some odd requirement) because log messages look normal and also drive worked fine after reboot.
Toni Wilen is offline  
Old 01 June 2017, 20:38   #40
mark_k
Registered User
 
Join Date: Aug 2004
Location:
Posts: 2,967
Quote:
Originally Posted by Toni Wilen View Post
I don't know. A2090 is autoconfig so why have non-autoconfig RAM?
Maybe that never-released board had AutoConfig size 2MB but the 1MB on-board RAM was optional?
Quote:
Originally Posted by Toni Wilen View Post
I also got crash but decided it is bug in prep (or some odd requirement) because log messages look normal and also drive worked fine after reboot.
It won't be a bug in Prep. FormatHD is just a script which runs System/Format to DOS-format the partitions. You can run Format from the CLI and get the same result. I wondered if it could be some timing issue with hddisk.device, not handling a too-fast drive? But Format seems to almost complete, it's just at the end you get the hang.
mark_k is offline  
 


Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
Thread Tools

Similar Threads
Thread Thread Starter Forum Replies Last Post
Guide to setting up A2090a with SCSI2SD RobTurbo support.Hardware 33 03 February 2017 21:17
D3D point/bilinear setting trouble Ami_GFX support.WinUAE 4 10 December 2014 21:23
Trouble Setting up Transcend 4GB IDE Flash Disk mfletcher support.Hardware 15 07 January 2014 12:22
For Sale: A2090a SCSI HD and ST 506 Controller (Zorro2) Zetr0 MarketPlace 5 02 September 2009 11:43
Trouble setting up SCSI CD RW with CSMK3 CU_AMiGA support.Hardware 3 05 August 2008 17:51

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +2. The time now is 05:59.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2018, vBulletin Solutions Inc.
Page generated in 0.09104 seconds with 13 queries