BeebSCSI issue with production New AP5

for bbc micro/electron hardware, peripherals & programming issues (NOT emulators!)
User avatar
hoglet
Posts: 6629
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol

BeebSCSI issue with production New AP5

Postby hoglet » Sun Sep 24, 2017 8:24 pm

We're seeing some issues with BeebSCSI and the production version of the AP5.

Simon, I'm wondering if you have any thoughts on this.

It looks like an issue related to reset.

The main symptom, after is BREAK is released:
- 80% of the time, ADFS works perfectly
- 20% of the time, ADFS will hang

In the case where it works, it then seems to work reliably until the next BREAK.

Here's a BeebSCSI log from a "works perfectly BREAK":

Code: Select all

SCSI Commands: CDB byte 0 decode: Command group 0 (6 bytes) opcode 1
SCSI Commands: Received command operand bytes: 1 1 1 1 1 1
File system: filesystemReset(): Resetting file system
File system: filesystemReset(): File system is flagged as mounted
File system: filesystemCheckLunImage(): Checking for (.dat) LUN image 0
File system: filesystemCheckLunImage(): LUN image found
File system: filesystemCheckLunImage(): LUN size in bytes (according to .dat) = 256241664
File system: filesystemCheckLunImage(): Checking for (.dsc) LUN descriptor 0
File system: filesystemCheckLunImage(): LUN descriptor found
File system: LUN Descriptor contents:
File system: Mode Select Parameter List:
File system:   Reserved (0) = 0
File system:   Reserved (0) = 0
File system:   Reserved (0) = 0
File system:   Length of Extent Descriptor List (8) = 8
File system: Extent Descriptor List:
File system:   Density code = 0
File system:   Reserved (0) = 0
File system:   Reserved (0) = 0
File system:   Reserved (0) = 0
File system:   Reserved (0) = 0
File system:   Block size = 256
File system: Drive Parameter List:
File system:   List format code = 1
File system:   Cylinder count = 3971
File system:   Data head count = 16
File system:   Reduced write current cylinder = 128
File system:   Write pre-compensation cylinder = 128
File system:   Landing zone position = 0
File system:   Step pulse output rate code = 1
File system: filesystemCheckLunImage(): LUN size in bytes (according to .dsc) = 536752128
File system: filesystemCheckLunImage(): WARNING: File size and DSC parameters are NOT consistent
File system: filesystemCheckLunImage(): Checking for (.ucd) LUN user code descriptor
File system: filesystemCheckLunImage(): LUN user code descriptor not found
File system: filesystemCheckLunImage(): Successful
SCSI State: Resetting SCSI emulation
SCSI State: Bus Free
SCSI State: Information transfer phase: Data out
SCSI State: Selected by host ID 1
SCSI State: Command phase
SCSI State: Information transfer phase: Command
SCSI Commands: CDB byte 0 decode: Command group 0 (6 bytes) opcode 8
SCSI Commands: Received command operand bytes: 8 0 0 2 5 0
SCSI Commands: READ command (0x08) received
SCSI Commands: Target LUN = 0, LBA = 2, Blocks = 5
SCSI State: Information transfer phase: Data in
File system: filesystemOpenLunForRead(): Successful
SCSI Commands: Transferring requested blocks to the host...
0 1 2 3 4
File system: filesystemCloseLunForRead(): Completed
SCSI Commands: Read6 command successful
SCSI State: Status.  Status byte = 0
SCSI State: Information transfer phase: Status
SCSI State: Message In.  Message byte = 0
SCSI State: Information transfer phase: Message in
SCSI State: Bus Free
SCSI State: Information transfer phase: Data out
SCSI State: Selected by host ID 1
SCSI State: Command phase
SCSI State: Information transfer phase: Command
SCSI Commands: CDB byte 0 decode: Command group 0 (6 bytes) opcode 8
SCSI Commands: Received command operand bytes: 8 0 0 0 2 0
SCSI Commands: READ command (0x08) received
SCSI Commands: Target LUN = 0, LBA = 0, Blocks = 2
SCSI State: Information transfer phase: Data in
File system: filesystemOpenLunForRead(): Successful
SCSI Commands: Transferring requested blocks to the host...
0 1
File system: filesystemCloseLunForRead(): Completed
SCSI Commands: Read6 command successful
SCSI State: Status.  Status byte = 0
SCSI State: Information transfer phase: Status
SCSI State: Message In.  Message byte = 0
SCSI State: Information transfer phase: Message in
SCSI State: Bus Free
SCSI State: Information transfer phase: Data out
SCSI State: Selected by host ID 1
SCSI State: Command phase
SCSI State: Information transfer phase: Command
SCSI Commands: CDB byte 0 decode: Command group 0 (6 bytes) opcode 8
SCSI Commands: Received command operand bytes: 8 0 0 2 5 0
SCSI Commands: READ command (0x08) received
SCSI Commands: Target LUN = 0, LBA = 2, Blocks = 5
SCSI State: Information transfer phase: Data in
File system: filesystemOpenLunForRead(): Successful
SCSI Commands: Transferring requested blocks to the host...
0 1 2 3 4
File system: filesystemCloseLunForRead(): Completed
SCSI Commands: Read6 command successful
SCSI State: Status.  Status byte = 0
SCSI State: Information transfer phase: Status
SCSI State: Message In.  Message byte = 0
SCSI State: Information transfer phase: Message in
SCSI State: Bus Free
SCSI State: Information transfer phase: Data out

Here's a BeebSCSI log from a "hangs after BREAK":

Code: Select all

File system: filesystemReset(): Resetting file system
File system: filesystemReset(): File system is flagged as mounted
File system: filesystemCheckLunImage(): Checking for (.dat) LUN image 0
File system: filesystemCheckLunImage(): LUN image found
File system: filesystemCheckLunImage(): LUN size in bytes (according to .dat) = 256241664
File system: filesystemCheckLunImage(): Checking for (.dsc) LUN descriptor 0
File system: filesystemCheckLunImage(): LUN descriptor found
File system: LUN Descriptor contents:
File system: Mode Select Parameter List:
File system:   Reserved (0) = 0
File system:   Reserved (0) = 0
File system:   Reserved (0) = 0
File system:   Length of Extent Descriptor List (8) = 8
File system: Extent Descriptor List:
File system:   Density code = 0
File system:   Reserved (0) = 0
File system:   Reserved (0) = 0
File system:   Reserved (0) = 0
File system:   Reserved (0) = 0
File system:   Block size = 256
File system: Drive Parameter List:
File system:   List format code = 1
File system:   Cylinder count = 3971
File system:   Data head count = 16
File system:   Reduced write current cylinder = 128
File system:   Write pre-compensation cylinder = 128
File system:   Landing zone position = 0
File system:   Step pulse output rate code = 1
File system: filesystemCheckLunImage(): LUN size in bytes (according to .dsc) = 536752128
File system: filesystemCheckLunImage(): WARNING: File size and DSC parameters are NOT consistent
File system: filesystemCheckLunImage(): Checking for (.ucd) LUN user code descriptor
File system: filesystemCheckLunImage(): LUN user code descriptor not found
File system: filesystemCheckLunImage(): Successful
SCSI State: Resetting SCSI emulation
SCSI State: Bus Free
SCSI State: Information transfer phase: Data out
File system: filesystemReset(): Resetting file system
File system: filesystemReset(): File system is flagged as mounted
File system: filesystemCheckLunImage(): Checking for (.dat) LUN image 0
File system: filesystemCheckLunImage(): LUN image found
File system: filesystemCheckLunImage(): LUN size in bytes (according to .dat) = 256241664
File system: filesystemCheckLunImage(): Checking for (.dsc) LUN descriptor 0
File system: filesystemCheckLunImage(): LUN descriptor found
File system: LUN Descriptor contents:
File system: Mode Select Parameter List:
File system:   Reserved (0) = 0
File system:   Reserved (0) = 0
File system:   Reserved (0) = 0
File system:   Length of Extent Descriptor List (8) = 8
File system: Extent Descriptor List:
File system:   Density code = 0
File system:   Reserved (0) = 0
File system:   Reserved (0) = 0
File system:   Reserved (0) = 0
File system:   Reserved (0) = 0
File system:   Block size = 256
File system: Drive Parameter List:
File system:   List format code = 1
File system:   Cylinder count = 3971
File system:   Data head count = 16
File system:   Reduced write current cylinder = 128
File system:   Write pre-compensation cylinder = 128
File system:   Landing zone position = 0
File system:   Step pulse output rate code = 1
File system: filesystemCheckLunImage(): LUN size in bytes (according to .dsc) = 536752128
File system: filesystemCheckLunImage(): WARNING: File size and DSC parameters are NOT consistent
File system: filesystemCheckLunImage(): Checking for (.ucd) LUN user code descriptor
File system: filesystemCheckLunImage(): LUN user code descriptor not found
File system: filesystemCheckLunImage(): Successful
SCSI State: Resetting SCSI emulation
SCSI State: Bus Free
SCSI State: Information transfer phase: Data out
SCSI State: Selected by host ID 1
SCSI State: Command phase
SCSI State: Information transfer phase: Command

It seems to be hanging waiting for the first READ command. It looks like for some reason the host never sends this.

I'm not sure if it's significant or not, but in the second case BeebSCSI's reset sequence was triggered both when break was pressed, and when break was released.

I'm wondering if there is an issue here with multiple reset events causing things to get out of step?

The other reset related thing I have noticed is the rising edge of nRST is very very slow (about 400ns) on the Elk, and also very noisy.

Should BeebSCSI just be resetting just on the falling edge of nRST?

Can you see any problems that might be caused my spurious resets due to noise on the slow rising edge of nRST?

A couple of things I can't explain:
- connecting a Co Processor to the AP5 makes it fail a much higher proportion of the time
- even just connecting the Co Processor ribbon cable makes it fail a much higher proportion of the time
- my prototype AP5 seems to work flawlessly even with a Co Processor and I'm able to boot Panos off BeebSCSI and do real stuff

There is very little difference between the prototype and production AP5. The CPLD pinout changed slightly, but other than that the internal logic is almost identical.

My initial feeling is there is some cross-talk happening in certain circumstances that is upsetting things. I'll try to explore that a bit more over the next few days.

Dave

User avatar
hoglet
Posts: 6629
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol

Re: BeebSCSI issue with production New AP5

Postby hoglet » Wed Sep 27, 2017 4:07 pm

I've been looking into this a bit more. There are several factors at play here, but it's possible there is an issue in BeebSCSI. Specifically, the problem relates to the 1MHz bus data bus, and which edge of the 1MHz bus clock BeebSCSI uses to latch data on a write cycle.

There is a 1MHZ bus timing diagram on page 448 of the Advanced User Guide, reproduced below.

If you look at the window when write data is guaranteed to be stable:
- data is valid from 150ns after the rising edge of 1MHzE (t_dsw)
- data is valid until 50ns after the falling edge of 1MHzE (t_hw)

Given this, a device must latch data on the falling edge of 1MHzE.

Now, looking at BeebSCSI, the signal used to latch data is FC40_44WR:
https://github.com/simoninns/BeebSCSI/b ... ter.v#L174

Data is latched on the rising edge of FC40_44WR, which seems too early according to that timing diagram.

It does work in practice on the Beeb because data is provided much earlier than the timing diagram suggests, but this is implementation specific.

Here's a timing diagram to try to make this clearer:

Code: Select all

           ----+                +----------------+
1MHZE          |                |                |
               +----------------+                +----------
                                |                |
                 t_dsw=150ns   >|     |<        >|   |< t_dhw=50ns
                                      |              |
           --------------------------+ +------------+ +-----
DATA                                  X  DATA VALID  X
           --------------------------+ +------------+ +-----

                                 +----------------+
FC40_44WR                        |                |
           ----------------------+                +---------

        this edge currently used ^                ^
                                                  ^
                         this edge should be used ^

Simon, I'd be very interested in your take on this. It's possible I have mis-understood how things are working in BeebSCSI.

I've made a change to the BeebSCSI CPLD to try to test this. Specifically, use the inverse of FC40_44WR as the LE input:

Code: Select all

   assign nFC40_44WR = nFC40WR & nFC44WR;  // this line changed
   wire [7:0] dataInLatchQ;
   
   ttl74573 dataInLatch(
      .D(bbc_DATA_in),
      .LE(nFC40_44WR),                     // this line changed
      .Q(dataInLatchQ)
   );

This change really helped the stability of BeebSCSI on the AP5.

I do have an AP5-only fix for this, which is not to use the 1MHZ bus clock at all in the signal that enables the data bus buffers. This does make data available sooner, and is the way the data bus buffers work on the Model B. It might actually be better to go with this, which would not require any changes to BeebSCSI.

(The reason I'm only enabling the data bus buffers for the second half of the 1MHZ bus cycle is to avoid brief bus conflicts, as the AP5 is already very noisy)

At the end of the day this come down to what "spec" we choose to design 1MHz bus devices against:
- the actual implementation on the Model B
- Acorn App Note 003

Dave

User avatar
simoni
Posts: 330
Joined: Wed May 25, 2016 6:18 pm

Re: BeebSCSI issue with production New AP5

Postby simoni » Wed Sep 27, 2017 5:04 pm

Hi Dave

Great that you've found some evidence of the issue; and the results look interesting. I'm actually in an airport right now waiting for a flight, so it will be a few days before I can look into this in detail.

However; it's worth mentioning that the primary design aim of BeebSCSI was to emulate the Domesday set-up. This meant that I followed the physical properties of the SCSI host adapter board as closely as possible. As far as I remember, the data buffering should act just like the logic ICs on the original hardware. There is a chance that I messed this up (it does happen, and I'm always glad that others can view my source and diagnose potential issues!) but, if I didn't, it could mean that your proposed AP5 fix would break compatibility with real Winchester drives.

I will look into this further, but it would be an interesting starting point to look at the datasheets for the buffers on the Acorn SCSI boards.

One other thing which may affect this is that the 1MHZE is not the data latch signal (in the case of the SCSI boards). The NPGFC select combined with the 1MHZE is fed through a 'clean page select' logic and the result of this is combined with the address bus contents to cause a latch condition. This will mean that the position of the 1MHZE edge is not necessarily a good indicator and also there will be some propagation delay through the logic on a real board. None of this may be important, but since I'm unable to look in to it immediately, I wanted to offer some thoughts :)

/Simon

User avatar
hoglet
Posts: 6629
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol

Re: BeebSCSI issue with production New AP5

Postby hoglet » Wed Sep 27, 2017 6:00 pm

simoni wrote:However; it's worth mentioning that the primary design aim of BeebSCSI was to emulate the Domesday set-up. This meant that I followed the physical properties of the SCSI host adapter board as closely as possible. As far as I remember, the data buffering should act just like the logic ICs on the original hardware. There is a chance that I messed this up (it does happen, and I'm always glad that others can view my source and diagnose potential issues!) but, if I didn't, it could mean that your proposed AP5 fix would break compatibility with real Winchester drives.

Here's my current train of thought...

Looking at the host adapter schematic:
http://www.domesday86.com/?page_id=409#Schematic

there is an 74LS373 (IC2) octal transparent latch and the LE signal is an active high pulse (like I have drawn above).

The '373 is transparent when LE is high, so data is latched on the falling edge of this pulse.

As you have said in the comment in the Verilog, CPLDs don't do latches, so you instead use a register.

But it does seem you are latching data in the rising edge, which is much earlier than with the host adapter.

Dave

User avatar
simoni
Posts: 330
Joined: Wed May 25, 2016 6:18 pm

Re: BeebSCSI issue with production New AP5

Postby simoni » Wed Sep 27, 2017 6:17 pm

I'll take a look at the schematic and code this weekend and trace the signals back though the Verilog to be sure of what's happening. If you're correct then I'll happily patch the code. As I said before, if the CPLD isn't true to the original implementation then it should be fixed :) I'll get back to you as soon as possible. I appreciate the time you've spent looking into this!

User avatar
hoglet
Posts: 6629
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol

Re: BeebSCSI issue with production New AP5

Postby hoglet » Sat Sep 30, 2017 2:24 pm

A small update.

I've been doing some more stress testing of BeebSCSI and for comparison Data Centre.

The stress test I've been running is to boot Panos on the Matchbox Co Pro, and then try to compile the "hello world" c program, i.e. just:

Code: Select all

set dir panostests
cc cworld
link cworld c,pas
cworld


Here are the results:
- BBC Model B + ADFS 1.33 + Data Centre: test passes
- BBC Model B + ADFS 1.30 + BeebSCSI: test passes
- Electron + ADFS version "ELK103" + Data Centre: test passes
- Electron + ADFS version "ELK100" + BeebSCSI: system hangs during "cc cworld"

The BeebSCSI is as shipped.

The new AP5 has a slightly modified CPLD that removes the clock gating from 1MHz data bus buffer enable signal (otherwise BeebSCSI is very unreliable).

The hang is always in the same place:

Code: Select all

SCSI State: Selected by host ID 1
SCSI State: Command phase
SCSI State: Information transfer phase: Command
SCSI Commands: CDB byte 0 decode: Command group 0 (6 bytes) opcode 8
SCSI Commands: Received command operand bytes: 8 0 0 0 2 0
SCSI Commands: READ command (0x08) received
SCSI Commands: Target LUN = 0, LBA = 0, Blocks = 2
SCSI State: Information transfer phase: Data in
File system: filesystemOpenLunForRead(): Successful
SCSI Commands: Transferring requested blocks to the host...
0 1
File system: filesystemCloseLunForRead(): Completed
SCSI Commands: Read6 command successful
SCSI State: Status.  Status byte = 0
SCSI State: Information transfer phase: Status
SCSI State: Message In.  Message byte = 0
SCSI State: Information transfer phase: Message in
SCSI State: Bus Free
SCSI State: Information transfer phase: Data out


SCSI State: Selected by host ID 1
SCSI State: Command phase
SCSI State: Information transfer phase: Command
SCSI Commands: CDB byte 0 decode: Command group 0 (6 bytes) opcode 8
SCSI Commands: Received command operand bytes: 8 0 0 2 5 0
SCSI Commands: READ command (0x08) received
SCSI Commands: Target LUN = 0, LBA = 2, Blocks = 5
SCSI State: Information transfer phase: Data in
File system: filesystemOpenLunForRead(): Successful
SCSI Commands: Transferring requested blocks to the host...
0 1 2 3 4
File system: filesystemCloseLunForRead(): Completed
SCSI Commands: Read6 command successful
SCSI State: Status.  Status byte = 0
SCSI State: Information transfer phase: Status
SCSI State: Message In.  Message byte = 0
SCSI State: Information transfer phase: Message in
SCSI State: Bus Free
SCSI State: Information transfer phase: Data out


SCSI State: Selected by host ID 1
SCSI State: Command phase
SCSI State: Information transfer phase: Command
SCSI Commands: CDB byte 0 decode: Command group 0 (6 bytes) opcode 8
SCSI Commands: Received command operand bytes: 8 1 213 100 5 0
SCSI Commands: READ command (0x08) received
SCSI Commands: Target LUN = 0, LBA = 120164, Blocks = 5
SCSI State: Information transfer phase: Data in
File system: filesystemOpenLunForRead(): Successful
SCSI Commands: Transferring requested blocks to the host...
0 1 2 3 4
File system: filesystemCloseLunForRead(): Completed
SCSI Commands: Read6 command successful
SCSI State: Status.  Status byte = 0
SCSI State: Information transfer phase: Status
SCSI State: Message In.  Message byte = 0
SCSI State: Information transfer phase: Message in
SCSI State: Bus Free
SCSI State: Information transfer phase: Data out


SCSI State: Selected by host ID 1
SCSI State: Command phase
SCSI State: Information transfer phase: Command
SCSI Commands: CDB byte 0 decode: Command group 0 (6 bytes) opcode 8
SCSI Commands: Received command operand bytes: 8 1 215 189 5 0
SCSI Commands: READ command (0x08) received
SCSI Commands: Target LUN = 0, LBA = 120765, Blocks = 5
SCSI State: Information transfer phase: Data in
File system: filesystemOpenLunForRead(): Successful
SCSI Commands: Transferring requested blocks to the host...
0 1 2 3 4
File system: filesystemCloseLunForRead(): Completed
SCSI Commands: Read6 command successful
SCSI State: Status.  Status byte = 0
SCSI State: Information transfer phase: Status
SCSI State: Message In.  Message byte = 0
SCSI State: Information transfer phase: Message in
SCSI State: Bus Free
SCSI State: Information transfer phase: Data out


SCSI State: Selected by host ID 1
SCSI State: Command phase
SCSI State: Information transfer phase: Command
SCSI Commands: CDB byte 0 decode: Command group 0 (6 bytes) opcode 8
SCSI Commands: Received command operand bytes: 8 1 213 100 5 0
SCSI Commands: READ command (0x08) received
SCSI Commands: Target LUN = 0, LBA = 120164, Blocks = 5
SCSI State: Information transfer phase: Data in
File system: filesystemOpenLunForRead(): Successful
SCSI Commands: Transferring requested blocks to the host...
0 1 2 3 4
File system: filesystemCloseLunForRead(): Completed
SCSI Commands: Read6 command successful
SCSI State: Status.  Status byte = 0
SCSI State: Information transfer phase: Status
SCSI State: Message In.  Message byte = 0
SCSI State: Information transfer phase: Message in
SCSI State: Bus Free
SCSI State: Information transfer phase: Data out


SCSI State: Selected by host ID 1
SCSI State: Command phase
SCSI State: Information transfer phase: Command
SCSI Commands: CDB byte 0 decode: Command group 0 (6 bytes) opcode 8
SCSI Commands: Received command operand bytes: 8 1 213 110 5 0
SCSI Commands: READ command (0x08) received
SCSI Commands: Target LUN = 0, LBA = 120174, Blocks = 5
SCSI State: Information transfer phase: Data in
File system: filesystemOpenLunForRead(): Successful
SCSI Commands: Transferring requested blocks to the host...
0 1 2 3 4
File system: filesystemCloseLunForRead(): Completed
SCSI Commands: Read6 command successful
SCSI State: Status.  Status byte = 0
SCSI State: Information transfer phase: Status
SCSI State: Message In.  Message byte = 0
SCSI State: Information transfer phase: Message in
SCSI State: Bus Free
SCSI State: Information transfer phase: Data out


SCSI State: Selected by host ID 1
SCSI State: Command phase
SCSI State: Information transfer phase: Command
SCSI Commands: CDB byte 0 decode: Command group 0 (6 bytes) opcode 8
SCSI Commands: Received command operand bytes: 8 1 230 189 77 0
SCSI Commands: READ command (0x08) received
SCSI Commands: Target LUN = 0, LBA = 124605, Blocks = 77
SCSI State: Information transfer phase: Data in
File system: filesystemOpenLunForRead(): Successful
SCSI Commands: Transferring requested blocks to the host...
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76
File system: filesystemCloseLunForRead(): Completed
SCSI Commands: Read6 command successful
SCSI State: Status.  Status byte = 0
SCSI State: Information transfer phase: Status
SCSI State: Message In.  Message byte = 0
SCSI State: Information transfer phase: Message in
SCSI State: Bus Free
SCSI State: Information transfer phase: Data out


SCSI State: Selected by host ID 1
SCSI State: Command phase
SCSI State: Information transfer phase: Command
SCSI Commands: CDB byte 0 decode: Command group 0 (6 bytes) opcode 8
SCSI Commands: Received command operand bytes: 8 1 231 10 1 0
SCSI Commands: READ command (0x08) received
SCSI Commands: Target LUN = 0, LBA = 124682, Blocks = 1
SCSI State: Information transfer phase: Data in
File system: filesystemOpenLunForRead(): Successful
SCSI Commands: Transferring requested blocks to the host...
0
File system: filesystemCloseLunForRead(): Completed
SCSI Commands: Read6 command successful
SCSI State: Status.  Status byte = 0
SCSI State: Information transfer phase: Status
SCSI State: Message In.  Message byte = 0
SCSI State: Information transfer phase: Message in
SCSI State: Bus Free
SCSI State: Information transfer phase: Data out


SCSI State: Selected by host ID 1
SCSI State: Command phase
SCSI State: Information transfer phase: Command
SCSI Commands: CDB byte 0 decode: Command group 0 (6 bytes) opcode 8
SCSI Commands: Received command operand bytes: 8 0 0 0 2 0
SCSI Commands: READ command (0x08) received
SCSI Commands: Target LUN = 0, LBA = 0, Blocks = 2
SCSI State: Information transfer phase: Data in
File system: filesystemOpenLunForRead(): Successful
SCSI Commands: Transferring requested blocks to the host...
0 1
File system: filesystemCloseLunForRead(): Completed
SCSI Commands: Read6 command successful
SCSI State: Status.  Status byte = 0
SCSI State: Information transfer phase: Status
SCSI State: Message In.  Message byte = 0
SCSI State: Information transfer phase: Message in
SCSI State: Bus Free
SCSI State: Information transfer phase: Data out


SCSI State: Selected by host ID 1
SCSI State: Command phase
SCSI State: Information transfer phase: Command
SCSI Commands: CDB byte 0 decode: Command group 0 (6 bytes) opcode 8
SCSI Commands: Received command operand bytes: 8 0 0 2 5 0
SCSI Commands: READ command (0x08) received
SCSI Commands: Target LUN = 0, LBA = 2, Blocks = 5
SCSI State: Information transfer phase: Data in
File system: filesystemOpenLunForRead(): Successful
SCSI Commands: Transferring requested blocks to the host...
0 1 2 3 4
File system: filesystemCloseLunForRead(): Completed
SCSI Commands: Read6 command successful
SCSI State: Status.  Status byte = 0
SCSI State: Information transfer phase: Status
SCSI State: Message In.  Message byte = 0
SCSI State: Information transfer phase: Message in
SCSI State: Bus Free
SCSI State: Information transfer phase: Data out


SCSI State: Selected by host ID 1
SCSI State: Command phase
SCSI State: Information transfer phase: Command
SCSI Commands: CDB byte 0 decode: Command group 0 (6 bytes) opcode 8
SCSI Commands: Received command operand bytes: 8 1 213 105 5 0
SCSI Commands: READ command (0x08) received
SCSI Commands: Target LUN = 0, LBA = 120169, Blocks = 5
SCSI State: Information transfer phase: Data in
File system: filesystemOpenLunForRead(): Successful
SCSI Commands: Transferring requested blocks to the host...
0 1 2 3 4
File system: filesystemCloseLunForRead(): Completed
SCSI Commands: Read6 command successful
SCSI State: Status.  Status byte = 0
SCSI State: Information transfer phase: Status
SCSI State: Message In.  Message byte = 0
SCSI State: Information transfer phase: Message in
SCSI State: Bus Free
SCSI State: Information transfer phase: Data out


SCSI State: Selected by host ID 1
SCSI State: Command phase
SCSI State: Information transfer phase: Command
SCSI Commands: CDB byte 0 decode: Command group 0 (6 bytes) opcode 8
SCSI Commands: Received command operand bytes: 8 1 233 38 5 0
SCSI Commands: READ command (0x08) received
SCSI Commands: Target LUN = 0, LBA = 125222, Blocks = 5
SCSI State: Information transfer phase: Data in
File system: filesystemOpenLunForRead(): Successful
SCSI Commands: Transferring requested blocks to the host...
0 1 2 3 4
File system: filesystemCloseLunForRead(): Completed
SCSI Commands: Read6 command successful
SCSI State: Status.  Status byte = 0
SCSI State: Information transfer phase: Status
SCSI State: Message In.  Message byte = 0
SCSI State: Information transfer phase: Message in
SCSI State: Bus Free
SCSI State: Information transfer phase: Data out


SCSI State: Selected by host ID 1
SCSI State: Command phase
SCSI State: Information transfer phase: Command
SCSI Commands: CDB byte 0 decode: Command group 0 (6 bytes) opcode 8
SCSI Commands: Received command operand bytes: 8 0 0 0 2 0
SCSI Commands: READ command (0x08) received
SCSI Commands: Target LUN = 0, LBA = 0, Blocks = 2
SCSI State: Information transfer phase: Data in
File system: filesystemOpenLunForRead(): Successful
SCSI Commands: Transferring requested blocks to the host...
0 1
File system: filesystemCloseLunForRead(): Completed
SCSI Commands: Read6 command successful
SCSI State: Status.  Status byte = 0
SCSI State: Information transfer phase: Status
SCSI State: Message In.  Message byte = 0
SCSI State: Information transfer phase: Message in
SCSI State: Bus Free
SCSI State: Information transfer phase: Data out


SCSI State: Selected by host ID 1
SCSI State: Command phase
SCSI State: Information transfer phase: Command
SCSI Commands: CDB byte 0 decode: Command group 0 (6 bytes) opcode 8
SCSI Commands: Received command operand bytes: 8 1 213 110 5 0
SCSI Commands: READ command (0x08) received
SCSI Commands: Target LUN = 0, LBA = 120174, Blocks = 5
SCSI State: Information transfer phase: Data in
File system: filesystemOpenLunForRead(): Successful
SCSI Commands: Transferring requested blocks to the host...
0 1 2 3 4
File system: filesystemCloseLunForRead(): Completed
SCSI Commands: Read6 command successful
SCSI State: Status.  Status byte = 0
SCSI State: Information transfer phase: Status
SCSI State: Message In.  Message byte = 0
SCSI State: Information transfer phase: Message in
SCSI State: Bus Free
SCSI State: Information transfer phase: Data out


SCSI State: Selected by host ID 1
SCSI State: Command phase
SCSI State: Information transfer phase: Command
SCSI Commands: CDB byte 0 decode: Command group 0 (6 bytes) opcode 8
SCSI Commands: Received command operand bytes: 8 1 231 11 255 0
SCSI Commands: READ command (0x08) received
SCSI Commands: Target LUN = 0, LBA = 124683, Blocks = 255
SCSI State: Information transfer phase: Data in
File system: filesystemOpenLunForRead(): Successful
SCSI Commands: Transferring requested blocks to the host...
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254
File system: filesystemCloseLunForRead(): Completed
SCSI Commands: Read6 command successful
SCSI State: Status.  Status byte = 0
SCSI State: Information transfer phase: Status
SCSI State: Message In.  Message byte = 0
SCSI State: Information transfer phase: Message in
SCSI State: Bus Free
SCSI State: Information transfer phase: Data out


SCSI State: Selected by host ID 1
SCSI State: Command phase
SCSI State: Information transfer phase: Command
SCSI Commands: CDB byte 0 decode: Command group 0 (6 bytes) opcode 8
SCSI Commands: Received command operand bytes: 8 1 232 10 115 0
SCSI Commands: READ command (0x08) received
SCSI Commands: Target LUN = 0, LBA = 124938, Blocks = 115
SCSI State: Information transfer phase: Data in
File system: filesystemOpenLunForRead(): Successful
SCSI Commands: Transferring requested blocks to the host...
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114
File system: filesystemCloseLunForRead(): Completed
SCSI Commands: Read6 command successful
SCSI State: Status.  Status byte = 0
SCSI State: Information transfer phase: Status
SCSI State: Message In.  Message byte = 0
SCSI State: Information transfer phase: Message in
SCSI State: Bus Free
SCSI State: Information transfer phase: Data out


SCSI State: Selected by host ID 1
SCSI State: Command phase
SCSI State: Information transfer phase: Command
SCSI Commands: CDB byte 0 decode: Command group 0 (6 bytes) opcode 8
SCSI Commands: Received command operand bytes: 8 1 232 125 1 0
SCSI Commands: READ command (0x08) received
SCSI Commands: Target LUN = 0, LBA = 125053, Blocks = 1
SCSI State: Information transfer phase: Data in
File system: filesystemOpenLunForRead(): Successful
SCSI Commands: Transferring requested blocks to the host...
0
File system: filesystemCloseLunForRead(): Completed
SCSI Commands: Read6 command successful
SCSI State: Status.  Status byte = 0
SCSI State: Information transfer phase: Status
SCSI State: Message In.  Message byte = 0
SCSI State: Information transfer phase: Message in
SCSI State: Bus Free
SCSI State: Information transfer phase: Data out


SCSI State: Selected by host ID 1
SCSI State: Command phase
SCSI State: Information transfer phase: Command
SCSI Commands: CDB byte 0 decode: Command group 0 (6 bytes) opcode 8
SCSI Commands: Received command operand bytes: 8 0 0 0 2 0
SCSI Commands: READ command (0x08) received
SCSI Commands: Target LUN = 0, LBA = 0, Blocks = 2
SCSI State: Information transfer phase: Data in
File system: filesystemOpenLunForRead(): Successful
SCSI Commands: Transferring requested blocks to the host...
0 1
File system: filesystemCloseLunForRead(): Completed
SCSI Commands: Read6 command successful
SCSI State: Status.  Status byte = 0
SCSI State: Information transfer phase: Status
SCSI State: Message In.  Message byte = 0
SCSI State: Information transfer phase: Message in
SCSI State: Bus Free
SCSI State: Information transfer phase: Data out


SCSI State: Selected by host ID 1
SCSI State: Command phase
SCSI State: Information transfer phase: Command
SCSI Commands: CDB byte 0 decode: Command group 0 (6 bytes) opcode 8
SCSI Commands: Received command operand bytes: 8 1 233 38 5 0
SCSI Commands: READ command (0x08) received
SCSI Commands: Target LUN = 0, LBA = 125222, Blocks = 5
SCSI State: Information transfer phase: Data in
File system: filesystemOpenLunForRead(): Successful
SCSI Commands: Transferring requested blocks to the host...
0 1 2 3 4
File system: filesystemCloseLunForRead(): Completed
SCSI Commands: Read6 command successful
SCSI State: Status.  Status byte = 0
SCSI State: Information transfer phase: Status
SCSI State: Message In.  Message byte = 0
SCSI State: Information transfer phase: Message in
SCSI State: Bus Free
SCSI State: Information transfer phase: Data out


SCSI State: Selected by host ID 1
SCSI State: Command phase
SCSI State: Information transfer phase: Command
SCSI Commands: CDB byte 0 decode: Command group 0 (6 bytes) opcode 8
SCSI Commands: Received command operand bytes: 8 1 233 43 1 0
SCSI Commands: READ command (0x08) received
SCSI Commands: Target LUN = 0, LBA = 125227, Blocks = 1
SCSI State: Information transfer phase: Data in
File system: filesystemOpenLunForRead(): Successful
SCSI Commands: Transferring requested blocks to the host...
0
File system: filesystemCloseLunForRead(): Completed
SCSI Commands: Read6 command successful
SCSI State: Status.  Status byte = 0
SCSI State: Information transfer phase: Status
SCSI State: Message In.  Message byte = 0
SCSI State: Information transfer phase: Message in
SCSI State: Bus Free
SCSI State: Information transfer phase: Data out


SCSI State: Selected by host ID 1
SCSI State: Command phase
SCSI State: Information transfer phase: Command
SCSI Commands: CDB byte 0 decode: Command group 0 (6 bytes) opcode 8
SCSI Commands: Received command operand bytes: 8 1 213 105 5 0
SCSI Commands: READ command (0x08) received
SCSI Commands: Target LUN = 0, LBA = 120169, Blocks = 5
SCSI State: Information transfer phase: Data in
File system: filesystemOpenLunForRead(): Successful
SCSI Commands: Transferring requested blocks to the host...
0 1 2 3 4
File system: filesystemCloseLunForRead(): Completed
SCSI Commands: Read6 command successful
SCSI State: Status.  Status byte = 0
SCSI State: Information transfer phase: Status
SCSI State: Message In.  Message byte = 0
SCSI State: Information transfer phase: Message in
SCSI State: Bus Free
SCSI State: Information transfer phase: Data out


SCSI State: Selected by host ID 1
SCSI State: Command phase
SCSI State: Information transfer phase: Command
SCSI Commands: CDB byte 0 decode: Command group 0 (6 bytes) opcode 8
SCSI Commands: Received command operand bytes: 8 1 225 233 5 0
SCSI Commands: READ command (0x08) received
SCSI Commands: Target LUN = 0, LBA = 123369, Blocks = 5
SCSI State: Information transfer phase: Data in
File system: filesystemOpenLunForRead(): Successful
SCSI Commands: Transferring requested blocks to the host...
0 1 2 3 4
File system: filesystemCloseLunForRead(): Completed
SCSI Commands: Read6 command successful
SCSI State: Status.  Status byte = 0
SCSI State: Information transfer phase: Status
SCSI State: Message In.  Message byte = 0
SCSI State: Information transfer phase: Message in
SCSI State: Bus Free
SCSI State: Information transfer phase: Data out


SCSI State: Selected by host ID 1
SCSI State: Command phase
SCSI State: Information transfer phase: Command
SCSI Commands: CDB byte 0 decode: Command group 0 (6 bytes) opcode 8
SCSI Commands: Received command operand bytes: 8 2 93 59 1 0
SCSI Commands: READ command (0x08) received
SCSI Commands: Target LUN = 0, LBA = 154939, Blocks = 1
SCSI State: Information transfer phase: Data in
File system: filesystemOpenLunForRead(): Successful
SCSI Commands: Transferring requested blocks to the host...
0
File system: filesystemCloseLunForRead(): Completed
SCSI Commands: Read6 command successful
SCSI State: Status.  Status byte = 0
SCSI State: Information transfer phase: Status
SCSI State: Message In.  Message byte = 0
SCSI State: Information transfer phase: Message in
SCSI State: Bus Free
SCSI State: Information transfer phase: Data out


SCSI State: Selected by host ID 1
SCSI State: Command phase
SCSI State: Information transfer phase: Command
SCSI Commands: CDB byte 0 decode: Command group 0 (6 bytes) opcode 10
SCSI Commands: Received command operand bytes: 10 2 93 59 1 0
SCSI Commands: WRITE command (0x0A) received
SCSI Commands: Target LUN = 0, LBA = 154939, Blocks = 1
SCSI State: Information transfer phase: Data out
File system: filesystemOpenLunForWrite(): Successful
SCSI Commands: Transferring requested blocks from the host...
0
File system: filesystemCloseLunForWrite(): Completed
SCSI Commands: Write6 command successful
SCSI State: Status.  Status byte = 0
SCSI State: Information transfer phase: Status

This seems to be the first time the WRITE command is used.

I can think of two possible causes:
- the communication between the Elk and BeebSCSI is still somewhat unreliable
- there is a bug in my Elk back-port of ADFS 1.30 that only affects the SCSI version (ELK100) and not the IDE version (ELK103).

I did wonder if all writes were failing, but that seems not to be the case. I was able to run BAS32 and save and load small basic programs, which also uses the same SCSI command.

I'm don't currently have a plan for how to debug this.

Dave

User avatar
simoni
Posts: 330
Joined: Wed May 25, 2016 6:18 pm

Re: BeebSCSI issue with production New AP5

Postby simoni » Sat Sep 30, 2017 4:19 pm

I can think of two possible causes:
- the communication between the Elk and BeebSCSI is still somewhat unreliable
- there is a bug in my Elk back-port of ADFS 1.30 that only affects the SCSI version (ELK100) and not the IDE version (ELK103).


The log file indicates that BeebSCSI was happily communicating with the Elk and doing all the correct things. The hang happens after a write6 SCSI command was successfully processed; the host requests a block, BeebSCSI enters DMA transfer (also clocked in by the host) and then switches to the status state at which point the host disappears. I would strongly suspect that this is an issue on the host side as BeebSCSI does exactly what it should. Of course it's possible that the hang is down to a communication failure, but it's unlikely since all of the high-speed DMA communication worked fine just before the hang.

I'm hoping to find some time tomorrow to look at the code and analyse the timing issue (I've raised an issue report for the problem on the github repo so it can be tracked).

User avatar
hoglet
Posts: 6629
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol

Re: BeebSCSI issue with production New AP5

Postby hoglet » Sat Sep 30, 2017 4:20 pm

hoglet wrote:Here are the results:
- BBC Model B + ADFS 1.33 + Data Centre: test passes
- BBC Model B + ADFS 1.30 + BeebSCSI: test passes
- Electron + ADFS version "ELK103" + Data Centre: test passes
- Electron + ADFS version "ELK100" + BeebSCSI: system hangs during "cc cworld"
...
I'm don't currently have a plan for how to debug this.

I've had a go at debugging this with ICE-T65, which for some reason seems to be behaving a bit erratically in the Elk (I'll come back to this at some point). All I was trying to find out is where the host was looping in ADFS.

The few times I did manage to catch it, it seemed to be executing some interrupt handler code in ROM C (the Plus 1 Support ROM version 1.30). That code was reading/writing FC64/FC65 which I think is reserved for the serial port on the Elk.... which makes no sense at all.

Anyway, I decided to *UNPLUG the Plus 1 Support ROM, and rather surprisingly that seems to have fixed the issue with "cc cworld" hanging.

So possibly for the first time ever we have an Elk, with a SCSI hard drive, running Panos and compiling a C program.

I'm rather perplexed by this, for many reasons, but mostly why the issue only happens with the SCSI version of ADFS (ELK100) and not with the IDE version (ELK103). All I can imagine is that it's some kind of conflict over the use of zero page locations between the Plus 1 support ROM and ELK100 (my backport of the Beeb ADFS 1.30).

Dave

User avatar
simoni
Posts: 330
Joined: Wed May 25, 2016 6:18 pm

Re: BeebSCSI issue with production New AP5

Postby simoni » Sat Sep 30, 2017 4:35 pm

So possibly for the first time ever we have an Elk, with a SCSI hard drive, running Panos and compiling a C program.


You should take that little comment out and surround it with the flashing lights it deserves... it's a pretty cool thing to have done :D Nice work!

User avatar
hoglet
Posts: 6629
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol

Re: BeebSCSI issue with production New AP5

Postby hoglet » Sat Sep 30, 2017 5:07 pm

simoni wrote:You should take that little comment out and surround it with the flashing lights it deserves... it's a pretty cool thing to have done :D Nice work!

Yes, it is pretty amazing.

I've been thinking about this some more and I have a theory now as to what's happening.

It's based a few assumptions:
- the original SCSI drivers in ADFS sometimes make use of interrupts
- JGH's IDE patch doesn't

The theory is that the +1 support ROM is swallowing SCSI interrupts, because it is incorrectly identifying them as Serial interrupts.

I did some single stepping with ICE-T65, and saw the following sequence in the +1 support ROM being executed:

Code: Select all

16.764409: 8175 : BIT 0D68   
16.764413: 8178 : BNE 8188   
16.764415: 817A : LDA FC65   
16.764419: 817D : AND 0D6A   
16.764423: 8180 : BMI 818B   
16.764426: 818B : LDA #04     
16.764428: 818D : BIT FC64   
16.764432: 8190 : BNE 8195   
16.764435: 8195 : JMP 8118   
16.764438: 8118 : LDX F4     
16.764441: 811A : PLA         
16.764445: 811B : LDA #00     
16.764447: 811D : RTS

Notice it ends by zeroing the accumulator, which prevents the interrupt being passed down to lower priority ROMs.

Here's the corresponding source code:
http://mdfs.net/Software/BBC/SROM/Plus1/AP1v130.src

Code: Select all

\ SERVICE 5 - Interrupt
\ =====================
.L81A6
LDA #&02
BIT &0D68:BNE L81BB     :\ If IRQ Ignore, exit
LDA &FC65:AND &0D6A     :\ Mask Serial IRQ with ORQ mask
BMI L81BE               :\ Input port changed (RTS)
LSR A:BCS L81CB         :\ TxRDY
LSR A:BCS L8206         :\ RxRDY
.L81BB
JMP L80CC

.L81BE
LDA #&04
BIT &FC64:BNE L81C8
JSR L85AA
.L81C8
JMP L80D1
...
.L80CC:LDX &F4          :\ Restore registers and return
.L80CD:PLA:RTS          :\ Restore A and return
.L80D0:STA &F0          :\ Pass A to returned X
.L80D1
LDX &F4                 :\ Restore ROM to X
PLA:LDA #&00:RTS        :\ Claim call and return

The first check is serial interrupts are disabled (testing bit 1 in &D68). Rather than unplugging the +1 ROM, if I simply set this bit then it also fixes the issue.

I think the root cause of this confusion is that when no serial port is present, a read of &FC65 returns &FC (i.e. the high byte of the address) due to data bus capacitance. This is sufficient to make the +1 ROM think there has been a a serial interrupt.

What's surprising is that the effects of this bug seem subtle, in that most things you do with ADFS seem to work. Maybe most of the time ADFS actually operates by polling, and it's only occasionally that interrupts are criticial. This is just a guess.

Maybe Jonathan will have some thoughts on this.

Dave

Edit: I guess that if ADFS were in a higher priority ROM slot than the Plus 1 ROM, then this would also cause things to work.

User avatar
simoni
Posts: 330
Joined: Wed May 25, 2016 6:18 pm

Re: BeebSCSI issue with production New AP5

Postby simoni » Sat Sep 30, 2017 5:21 pm

What's surprising is that the effects of this bug seem subtle, in that most things you do with ADFS seem to work. Maybe most of the time ADFS actually operates by polling, and it's only occasionally that interrupts are criticial. This is just a guess.


It's a good guess :) Most operations are polling. Only random access commands such as *SPOOL seem to trigger the use of interrupts. There is some text around the subject in the tubby SCSI documents if I remember correctly. I know that, during BeebSCSI development, this caught me out; and I then had a specific test case for the regression testing to ensure that it worked. It's a left-over from very old SCSI hardware which could spend a very long time seeking.

I believe your are also correct about the IDE implementation. Since IDE drives are so much faster, there's no need to use interrupts (and I don't think there is any support in the 1MHZ bus <-> IDE adaptors for it either (there is a specific flag in the SCSI host adapters)).

User avatar
jgharston
Posts: 2764
Joined: Thu Sep 24, 2009 11:22 am
Location: Whitby/Sheffield

Re: BeebSCSI issue with production New AP5

Postby jgharston » Sat Sep 30, 2017 8:18 pm

hoglet wrote:Maybe Jonathan will have some thoughts on this.

Looks like a correct diagnosis. My initial thought is an interupt service routine should never return claimed, as it doesn't know that somebody else is waiting for an interupt to be serviced. If a Plus1 serial interface was present and it generated an interupt at the same time as the SCSI generated an interupt, you'd see the same effect.

Looks like all paths through Service5 should exit via L80CC not via L80D1.

Code: Select all

$ bbcbasic
PDP11 BBC BASIC IV Version 0.25
(C) Copyright J.G.Harston 1989,2005-2015
>_

User avatar
hoglet
Posts: 6629
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol

Re: BeebSCSI issue with production New AP5

Postby hoglet » Sat Sep 30, 2017 8:43 pm

jgharston wrote:My initial thought is an interupt service routine should never return claimed, as it doesn't know that somebody else is waiting for an interupt to be serviced.

True, but there would be quite a performance overhead to this, as all non-MOS interrupts would be passed to all ROMs, and then onto the user via IRQ2 vector. I do think if a ROM can accurately detect that one of the devices it is responsible for is interrupting, then it should handle this and return claimed.

I don't think this would cause a different interrupt to be lost, because that device would still be pulling IRQ low, and so the MOS would immediately re-enter the IRQ handler and try again.

The problem here is the +1 Support ROM is struggling to accurately detect whether the SCC2681 is interrupting. So it ends up claiming an interrupt that wasn't it's in the first place.
jgharston wrote:Looks like all paths through Service5 should exit via L80CC not via L80D1.

Inspite of all the above I do agree this would work, and given the rarity of Elk serial boards this may be the best fix.

How tight is space in the +1 ROM for something more comprehensive?

Dave

User avatar
hoglet
Posts: 6629
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol

Re: BeebSCSI issue with production New AP5

Postby hoglet » Sat Sep 30, 2017 9:07 pm

I think modifying the serial port init code might work, if there is 10 bytes free:

Code: Select all

.L8567
JSR L85A4             :\

LDA #&00:STA &0D6A    :\ DMB: disable interrupts until we are sure the hardware is present
 
LDA #&93:STA &FC60    :\
LDA #&07:STA &FC60    :\

CMP &FC60:BNE L8597   :\ DMB: readback MR2A to test that hardware is present, exit otherwise
 
LDA #&8F:STA &FC64    :\ Set AuxControl to Baud Rate 2, IRQs on
LDA &0D69:BCC L8580   :\ Get current baud settig
LDA #&BB              :\ Default baud rate=9600
.L8580
STA &0D69:STA &FC61   :\ Set baud register and RAM copy
JSR L8598           :\ 8586 20 98 85   ..
JSR L859C           :\ 8589 20 9C 85   ..
JSR L85A0           :\ 858C 20 A0 85    .
LDA #&80            :\ 858F A9 80     ).
STA &0D6A           :\ 8591 8D 6A 0D  .j.
STA &FC65           :\ 8594 8D 65 FC  .e|
.L8597
RTS                 :\ 8597 60

User avatar
simoni
Posts: 330
Joined: Wed May 25, 2016 6:18 pm

Re: BeebSCSI issue with production New AP5

Postby simoni » Sat Sep 30, 2017 9:22 pm

As an aside to this (and back on the original topic) I agree about the latch implementation, it's definitely latching on the wrong signal edge. I've modified the ttl74573.v module in the Verilog and everything compiles fine. I just need to do some regression testing (on the Master and Model B) and then I'll make a new release of the BeebSCSI code if everything works properly. The modification changes both the data-in latch and the status-out latch. I'm hoping to get this done tomorrow and I'll let you know when the new code is ready.

User avatar
jgharston
Posts: 2764
Joined: Thu Sep 24, 2009 11:22 am
Location: Whitby/Sheffield

Re: BeebSCSI issue with production New AP5

Postby jgharston » Sun Oct 01, 2017 1:02 am

hoglet wrote:I think modifying the serial port init code might work, if there is 10 bytes free:

The BBC MOS checks to see if the serial hardware is present and sets the serial mask to &00 if absent to ignore anything coming from the non-existant hardware, I'm surprised the Plus1 doesn't do similarly. I'll add an update to the Plus1 code when I have a chance to juggle machines around and get my Electron set up.

Code: Select all

$ bbcbasic
PDP11 BBC BASIC IV Version 0.25
(C) Copyright J.G.Harston 1989,2005-2015
>_

User avatar
simoni
Posts: 330
Joined: Wed May 25, 2016 6:18 pm

Re: BeebSCSI issue with production New AP5

Postby simoni » Sun Oct 01, 2017 8:05 am

I've just pushed a new release (2.1) of the BeebSCSI code to github. Please reprogram the CPLD on your BeebSCSI and let me know the result - it all seems to check out fine on my dev machine (with both internal VFS and external ADFS BeebSCSI boards):

https://github.com/simoninns/BeebSCSI/releases

User avatar
hoglet
Posts: 6629
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol

Re: BeebSCSI issue with production New AP5

Postby hoglet » Sun Oct 01, 2017 8:27 am

Simon,
simoni wrote:I've just pushed a new release (2.1) of the BeebSCSI code to github.

You've probably thought carefully about this, but just in case....

There was a second use of the 573 in host adapter:
https://github.com/simoninns/BeebSCSI/b ... ter.v#L221

At the very least, the comment above this is now incorrect, as it still refers to the positive edge.

But won't latching statusByte on the negative edge of FC41RD introduce one additional cycle of read latency accessing the status?

Possibly this won't matter, but it might have a small impact on performance, or result in reading back stale status?

Dave

User avatar
simoni
Posts: 330
Joined: Wed May 25, 2016 6:18 pm

Re: BeebSCSI issue with production New AP5

Postby simoni » Sun Oct 01, 2017 8:33 am

You've probably thought carefully about this, but just in case....


Doesn't seem to be the case :) I think you're right; I swapped both since it was more 'correct' to fix the 573 module... but the original is a 373; so I should 'uninvert' the status.

Well, well... let me update it again :)

User avatar
simoni
Posts: 330
Joined: Wed May 25, 2016 6:18 pm

Re: BeebSCSI issue with production New AP5

Postby simoni » Sun Oct 01, 2017 8:50 am

Try again :) This is what I get for being in a rush... Sorry about that; I've swapped the status register back.

Basically I've left the 573 module latching on the negative edge (as it should) and changed the status register definition to pass the LE without inverting it first. That should fix it. My Master is happy with both VFS and ADFS too. I've deleted the previous 2.1 release and added a new one with an update zip file of the compiled code.

User avatar
1024MAK
Posts: 6798
Joined: Mon Apr 18, 2011 4:46 pm
Location: Looking forward to summer in Somerset, UK...

Re: BeebSCSI issue with production New AP5

Postby 1024MAK » Mon Oct 02, 2017 10:34 pm

Note that the problems with trying to detect RAM have been moved to a new thread "Electron - Memory Detection Issues with the AP6" here :wink:

Mark
For a "Complete BBC Games Archive" visit www.bbcmicro.co.uk NOW!
BeebWiki‬ - for answers to many questions...


Return to “hardware”

Who is online

Users browsing this forum: Google [Bot] and 11 guests