BBC Master grumpy sideways RAM detection

for bbc micro/electron hardware, peripherals & programming issues (NOT emulators!)
User avatar
danielj
Posts: 7629
Joined: Thu Oct 02, 2008 4:51 pm
Location: Manchester
Contact:

Re: BBC Master grumpy sideways RAM detection

Post by danielj » Mon Jan 14, 2019 12:08 pm

Do you see that hang even if adfs is the chosen filing system?

I'll try the other tests this evening!

d.

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

Re: BBC Master grumpy sideways RAM detection

Post by hoglet » Mon Jan 14, 2019 12:20 pm

danielj wrote:
Mon Jan 14, 2019 12:08 pm
Do you see that hang even if adfs is the chosen filing system?
Yup.

Edit: but again, it's a stall that lasts ~50 seconds, then the reset sequence completes normally.

It's somewhat surprising that this behaviour has only now been discovered.

It will be Master specific though.

Dave
Last edited by hoglet on Mon Jan 14, 2019 12:22 pm, edited 2 times in total.

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

Re: BBC Master grumpy sideways RAM detection

Post by hoglet » Mon Jan 14, 2019 1:21 pm

I was intrigued enough to connect up the 6502 decoder.

Here's the start of the "hang":

Code: Select all

86A3 : A9 20    : LDA #20        : 2 : A=20 X=82 Y=01 SP=EF N=0 V=0 D=0 I=1 Z=0 C=1
86A5 : 2C A1 FE : BIT FEA1       : 4 : A=20 X=82 Y=01 SP=EF N=0 V=0 D=0 I=1 Z=1 C=1
86A8 : D0 5E    : BNE 8708       : 2 : A=20 X=82 Y=01 SP=EF N=0 V=0 D=0 I=1 Z=1 C=1
86AA : A9 FD    : LDA #FD        : 2 : A=FD X=82 Y=01 SP=EF N=1 V=0 D=0 I=1 Z=0 C=1
86AC : 48       : PHA            : 3 : A=FD X=82 Y=01 SP=EE N=1 V=0 D=0 I=1 Z=0 C=1
86AD : A9 06    : LDA #06        : 2 : A=06 X=82 Y=01 SP=EE N=0 V=0 D=0 I=1 Z=0 C=1
86AF : 8D 3F 0D : STA 0D3F       : 4 : A=06 X=82 Y=01 SP=EE N=0 V=0 D=0 I=1 Z=0 C=1
86B2 : A9 00    : LDA #00        : 2 : A=00 X=82 Y=01 SP=EE N=0 V=0 D=0 I=1 Z=1 C=1
86B4 : 8D 41 0D : STA 0D41       : 4 : A=00 X=82 Y=01 SP=EE N=0 V=0 D=0 I=1 Z=1 C=1
86B7 : 48       : PHA            : 3 : A=00 X=82 Y=01 SP=ED N=0 V=0 D=0 I=1 Z=1 C=1
86B8 : 48       : PHA            : 3 : A=00 X=82 Y=01 SP=EC N=0 V=0 D=0 I=1 Z=1 C=1
86B9 : A0 E7    : LDY #E7        : 2 : A=00 X=82 Y=E7 SP=EC N=1 V=0 D=0 I=1 Z=0 C=1

86BB : 08       : PHP            : 3 : A=00 X=82 Y=E7 SP=EB N=1 V=0 D=0 I=1 Z=0 C=1
86BC : 78       : SEI            : 2 : A=00 X=82 Y=E7 SP=EB N=1 V=0 D=0 I=1 Z=0 C=1
86BD : A9 40    : LDA #40        : 2 : A=40 X=82 Y=E7 SP=EB N=0 V=0 D=0 I=1 Z=0 C=1
86BF : 8D 1C 0D : STA 0D1C       : 4 : A=40 X=82 Y=E7 SP=EB N=0 V=0 D=0 I=1 Z=0 C=1
86C2 : 2C 38 FE : BIT FE38       : 4 : A=40 X=82 Y=E7 SP=EB N=0 V=0 D=0 I=1 Z=1 C=1
86C5 : A9 04    : LDA #04        : 2 : A=04 X=82 Y=E7 SP=EB N=0 V=0 D=0 I=1 Z=0 C=1
86C7 : 2C A1 FE : BIT FEA1       : 4 : A=04 X=82 Y=E7 SP=EB N=0 V=0 D=0 I=1 Z=1 C=1
86CA : F0 11    : BEQ 86DD       : 3 : A=04 X=82 Y=E7 SP=EB N=0 V=0 D=0 I=1 Z=1 C=1
86DD : A9 2C    : LDA #2C        : 2 : A=2C X=82 Y=E7 SP=EB N=0 V=0 D=0 I=1 Z=0 C=1
86DF : 8D 1C 0D : STA 0D1C       : 4 : A=2C X=82 Y=E7 SP=EB N=0 V=0 D=0 I=1 Z=0 C=1
86E2 : 2C 3C FE : BIT FE3C       : 4 : A=2C X=82 Y=E7 SP=EB N=0 V=0 D=0 I=1 Z=1 C=1
86E5 : 28       : PLP            : 4 : A=2C X=82 Y=E7 SP=EC N=1 V=0 D=0 I=1 Z=0 C=1
86E6 : BA       : TSX            : 2 : A=2C X=EC Y=E7 SP=EC N=1 V=0 D=0 I=1 Z=0 C=1
86E7 : FE 01 01 : INC 0101,X     : 7 : A=2C X=EC Y=E7 SP=EC N=0 V=0 D=0 I=1 Z=0 C=1
86EA : D0 CF    : BNE 86BB       : 3 : A=2C X=EC Y=E7 SP=EC N=0 V=0 D=0 I=1 Z=0 C=1
The BIT FEA1 is the first read of the 68B54 in the reset sequence. If bit 5 (Data Carrier Detect) is zero, then it loops around the second section for 0x30000 iterations before bailing. This takes ~5 seconds.

This all happens a total of about 10 times, stalling the reset sequence by ~50 seconds.

I think this is trying to send the Bridge Query frame:

Code: Select all

ABF3  82           .     DB &82                            ; Moved to &C0 --> Control byte = &82: WhatNet?
ABF4  9C           .     DB &9C                            ; Moved to &C1 --> Port number = &9C: BridgeQuery
ABD5  FF           .     DB &FF                            ; Moved to &C2 --> &FF
ABD6  FF           .     DB &FF                            ; Moved to &C3 --> &FF
ABF7  42 52 49     BRI   DB 'BRIDGE'                       ; Moved to &C4 --> BRIDGE
ABFA  44 47 45     DGE
ABFD  9C           .     DB &9C                            ; Moved to &CA --> Reply port = &9C
ABFE  00           .     DB &00                            ; Moved to &CB --> &00
ABFF  7F           .     DB &7F                            ;
When there is no 68B54 present, the value read back from &FEA1 depends on the screen mode. In Mode 7 it is typically &20 (space). In the other modes it is typically &00. This explains why we see a difference between the modes.

But in all cases, it does look like ANFS is not doing a proper check for the 68B54. Maybe this is the best that they could do, given all the 68B45 control registers are write-only.

Dave
Last edited by hoglet on Mon Jan 14, 2019 1:36 pm, edited 1 time in total.

User avatar
kieranhj
Posts: 831
Joined: Sat Sep 19, 2015 10:11 pm
Location: Farnham, Surrey, UK
Contact:

Re: BBC Master grumpy sideways RAM detection

Post by kieranhj » Mon Jan 14, 2019 1:22 pm

hoglet wrote:
Mon Jan 14, 2019 11:48 am
I've also just tried the BitShifter's BeebStep demo, and most of the time it correctly detected banks 4,5,6,7 as RAM. But very occasionally (maybe 1 in 10 tries) it wrongly detects bank 2 as RAM, and ends up using 2,4,5,6 (which then causes a crash). So it does seem the test is not robust enough.

I've written a small test program that repeatedly reads location &8008 from slot 2 (the cartridge port) and the results do vary. I think what is actually being read back is the last byte of video data, floating on the data bus. In Mode 7 it's usually &20. In Mode 0 it's usually &00. This is actually pretty interesting, and also could explain the mode sensitivity you are seeing with the ANFS issue.
Thanks Dave - this is very helpful! Would it be advisable to include a short delay before reading the result back then, as per sweh's implementation?
Bitshifters Collective | Retro Code & Demos for BBC Micro & Acorn computers | https://bitshifters.github.io/

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

Re: BBC Master grumpy sideways RAM detection

Post by hoglet » Mon Jan 14, 2019 1:45 pm

kieranhj wrote:
Mon Jan 14, 2019 1:22 pm
Thanks Dave - this is very helpful! Would it be advisable to include a short delay before reading the result back then, as per sweh's implementation?
I don't think a delay will help in this case, because the video data is present in the first half of every bus cycle (so it's a different mechanism than what Stephen was dealing with).

I think you need a slighty more complex test.

I would do two things:
1. Change the EOR #&AA to EOR #&FF (i.e. flip all the bits)
2. Test two successive locations (ideally Write 8008, Write 8009, Read 8008, Read 8009)

It may be that doing (1) is sufficient, but if you have the space then (2) would be good as well.

Dave
Last edited by hoglet on Mon Jan 14, 2019 1:46 pm, edited 1 time in total.

User avatar
sweh
Posts: 2102
Joined: Sat Mar 10, 2012 12:05 pm
Location: New York, New York
Contact:

Re: BBC Master grumpy sideways RAM detection

Post by sweh » Mon Jan 14, 2019 2:08 pm

hoglet wrote:
Mon Jan 14, 2019 11:48 am
I've written a small test program that repeatedly reads location &8008 from slot 2 (the cartridge port) and the results do vary. I think what is actually being read back is the last byte of video data, floating on the data bus. In Mode 7 it's usually &20. In Mode 0 it's usually &00.
Showing my hardware ignorance... Could this be because there's nothing responding to drive the data bus on that read, and so we're seeing an "echo" of what last went over it?

Seems odd we've never seen this before!
Rgds
Stephen

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

Re: BBC Master grumpy sideways RAM detection

Post by hoglet » Mon Jan 14, 2019 3:31 pm

sweh wrote:
Mon Jan 14, 2019 2:08 pm
Showing my hardware ignorance... Could this be because there's nothing responding to drive the data bus on that read, and so we're seeing an "echo" of what last went over it?
That's exactly it.

The data bus has a fair amount of capacitance (because it connects to lots of devices), so values will linger for a couple of microseconds if nothing else is driving it.

On the Model B the data bus is split slightly differently. So the CPU never sees the video data. A read of an unmapped IO location typically returns the high byte of the address, since that's that last byte of the opcode.

Dave

User avatar
danielj
Posts: 7629
Joined: Thu Oct 02, 2008 4:51 pm
Location: Manchester
Contact:

Re: BBC Master grumpy sideways RAM detection

Post by danielj » Mon Jan 14, 2019 3:35 pm

Excellent - so, I'm fairly confident that my master's actually fine now, but I'm pleased this turned out to be quite interesting in a completely nerdy kinda fashion! :D

User avatar
kieranhj
Posts: 831
Joined: Sat Sep 19, 2015 10:11 pm
Location: Farnham, Surrey, UK
Contact:

Re: BBC Master grumpy sideways RAM detection

Post by kieranhj » Mon Jan 14, 2019 4:17 pm

Yes indeed, all very interesting. I had similar problems before with empty cartridge ports being falsely reported as RAM but thought this had gone away when switching to the EOR #&AA method. Thanks for the recommendations hoglet - I will add these to the code and republish.

It's also a reason for testing more frequently on real hardware as the emulators will always return what you expect, not what's floating around on the data bus!
Bitshifters Collective | Retro Code & Demos for BBC Micro & Acorn computers | https://bitshifters.github.io/

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

Re: BBC Master grumpy sideways RAM detection

Post by 1024MAK » Mon Jan 14, 2019 5:03 pm

sweh wrote:
Mon Jan 14, 2019 2:08 pm
Showing my hardware ignorance... Could this be because there's nothing responding to drive the data bus on that read, and so we're seeing an "echo" of what last went over it?

Seems odd we've never seen this before!
This “affect” is actually fairly common in microprocessor systems where part of the memory or IO map is not occupied with memory or IO devices that respond to a read.

There are two reasons:
  1. There is another device using the data bus or part of it (typically the video system, DMA or similar),
  2. With nothing driving the data bus, all connected devices apart from the processor (which will be in read mode, also a fairly high impedance) will have their outputs in the high impedance tri-state mode. So unless there are low value resistors to drive the bus to a defined logic level quickly, the last value on the bus will be temporary held for a short time due to the stray capacitance present. With each data line decaying it’s voltage at a slightly different rate. Note that some systems do have pull-up or pull-down resistors connected to the data bus, but often the value is too high to discharge the voltage levels of the stray capacitance quickly enough for the processor to get a consistent value.
I can’t remember exactly, but I have seen a program for one system actually make use effect #2 to the extent that you can see the values on a buffered section of a bus gradually decay each time a read is performed.
And some programmers on the 16k/48k/128k/+2 (grey) ZX Spectrum made use of the #1 effect to work out when the video system was “drawing” the screen. This effect is known in the Spectrum world as the “floating bus”.

For processors that use the data bus as part of the address bus (multiplexed bus), or where instructions put a value on the data bus that a programmer may not expect (which may or may not be documented), it’s not uncommon to read back strange data.

So whenever a program reads from any memory or IO that may not be present, you should always take account of strange results. Especially if you have just written a value to that memory or IO device address.

Mark
Last edited by 1024MAK on Mon Jan 14, 2019 5:08 pm, edited 3 times in total.

Post Reply