DFS 2.26 & B+ detection & EEPROM

[cmorley]

Hi All,

A chap who has one of my EEPROM boards reported that the machine (model B) would not boot if DFS 2.26 was programmed into the EEPROM. In fact it would only boot with the 16kB EPROM he has.

I got a Model B (not B+) recently from ebay with the 1770 fitted (fixed it) and had a go myself.

• It will boot and work with a 16kB EPROM.
• It will boot then crash on enter with a 64kB EPROM (not EE) programmed BASIC,DFS,EXMON2,ADT. (I tried without ADT too)
• It will short beep then hang with flashing cursor and no banner if DFS is in EEPROM.

My conclusion is that DFS 2.26 detects B/B+ at some point and uses shadow RAM and/or different OS entry points. Does anyone know how DFS detects the B+? I would like to know why the EPROM & EE have different (crashing) behaviour.

Does anyone have a commented dissasembly of 2.26 - Google couldn't find me one?

Putting a 16kB DFS ROM in a higher slot than the EEPROM (when loaded with DFS 2.26) allows it to boot so it is something to do with executing from EE. Has anyone had success with DFS 2.26 in EEPROM?

Indeed has anyone had success/problem with putting DFS 2.26 in an 64kB EPROM with other images?

Thanks
Chris

[MartinB]

Sounds perhaps like an eeprom write-protect issue? i.e. if it's not protected, you can get the 'offline' effect with certain roms and crash the Beeb. Just a thought.....

[cmorley]

Sounds perhaps like an eeprom write-protect issue? i.e. if it's not protected, you can get the 'offline' effect with certain roms and crash the Beeb. Just a thought.....

Thoughts are welcome. I use the greenliant part which has software write protect enabled. You need a JEDEC sequence to enable normal byte programming, erase or page write.

What is the mechanism for the offline effect?

[MartinB]

Unless eeproms are physically write-protected, i.e. RnW tied high, any sniff of a write, irrespective of timing or soft-lock, will make the eeprom go high impedance on the bus for a few ms and I've found that this often crashes a Beeb during reset or power-on. Although it's not a guaranteed issue, the only sure way to prevent the problem is a physical write-protect after programming. I discussed it at length in my eeprom 'Holy Grail' thread.

This may not of course be your problem but perhaps worth a try...?

[cmorley]

Unless eeproms are physically write-protected, i.e. RnW tied high, any sniff of a write, irrespective of timing or soft-lock, will make the eeprom go high impedance on the bus for a few ms and I've found that this often crashes a Beeb during reset or power-on. Although it's not a guaranteed issue, the only sure way to prevent the problem is a physical write-protect after programming. I discussed it at length in my eeprom 'Holy Grail' thread.

This may not of course be your problem but perhaps worth a try...?

I'll find that thread and read through.

I just tested it:

Code: Select all

<snip>
  190   sta &BFFF
  210   ldy &BFFF:ldx &BFFF
<snip>


And the two reads are different. A "ldx#n,.loop,dex,bne loop" delay after the write is enough to get a correct read so it is a few hundred us. probably the same timeout for the JEDEC unlock...

So that explains the crash executing from EEPROM. Any ROM that tries to detect if it is running in SRAM (antipiracy) will likely crash then. I'll have to change my boards and put a hardware write lock. That's annoying.

Any thoughts on the 27C512 EPROM crash - because of B+ detection...? No EEPROM in the system at all.

[MartinB]

Yes, I thought it sounded familiar. I couldn't always though track it down to a ram-testing self-write which is why I was more general about the problem and it does vary between machine types. In the end, I stopped investigating and just opted for a mandatory hardware write protect switch and dishing out the cautionary advice to others.....

Not sure on your other issue I'm afraid....

[cmorley]

More testing with EPROMs.

I put a BASIC ROM in F and it boots. So it seems to be it doesn't like executing BASIC and DFS 2.26 from the same ROM. I overwrote BASIC with 0s in the EPROM and it works fine from from any socket with BASIC in any other socket.

So it just seems to crash if BASIC is in the same EPROM. Odd.

[sweh]

And the two reads are different. A "ldx#n,.loop,dex,bne loop" delay after the write is enough to get a correct read so it is a few hundred us. probably the same timeout for the JEDEC unlock...

Yeah, I hit this with the IFEL Flash/RAM/ROM board and my Manager ROM. My ROM was misdetecting FLASH as RAM because a write was cached and would be read back, even though it never actually got written.

Code: Select all

\ FLASH RAM chips aren't sideways RAM; they require a special command
\ sequence to cause them to enter WRITE mode.  But they can "buffer"
\ results, so a write to the chip may be read back again and the written
\ value returned, even though it never made it to the FLASH storage.
\ But if we pause for long enough (200us?) then the cache is cleared
\ and stuff works as normal
\ Through experimentation a loop value of #&50 is too low; #&80 seems to
\ work.  Let's double that.

.delay_swr_write
        JSR SWR_write
        LDX #0
.delaylp
        DEX
        BNE delaylp
        RTS


[dp11]

Just out of interested how big is the buffer? Can you write to another location and read back the first instead of the delay?

[MartinB]

Not quite sure what approach or implementation problem we're discussing here but my flash programming utilities don't use delays at all since modern flash chips have one or two built-in write-status reporting algorithms on which you can predicate your own programming method. (i.e. you can explicitly determine when a given write is complete.)

[sweh]

Not quite sure what approach or implementation problem we're discussing here but my flash programming utilities don't use delays at all since modern flash chips have one or two built-in write-status reporting algorithms on which you can predicate your own programming method. (i.e. you can explicitly determine when a given write is complete.)

It's the accidental "STA &8000" type code that's the problem, not a deliberate "program".

Some (all?) FLASH chips will (for a short period) let you read back the value that was written. This means a standard "is this a RAM bank" test, such as

Code: Select all

LDA &8007
PHA
EOR #&FF
STA &8007
CMP &8007
BNE notram
PLA
STA &8007


ends up with a false-positive because the read is "wrong". Adding a delay between the write/read circumvents this.

[MartinB]

Some (all?) FLASH chips will (for a short period) let you read back the value that was written.

No, definitely not all - here's the code I use for device-type detection in EELOAD which works with ram and eeprom. For this device test only, I intentionally do use a delay because since you don't know what device is there, you can't assume write-status responses. Anyway, this unambiguously detects ram, rom (or eprom), eeprom, and locked eeprom where the eeprom is an AT28C256 (or large family thereof) and it also works for the MGC AM29F032B.

The formatting of code in posts is abysmal...

I give up, that's as good as I can get it without shortening my life...

A picture speaks a thousand words as they say.....

[sweh]

Yeah, that's the sort of test that fails with things like the Winbond W29C020 Flash memory chip; the "STA ; CMP" will succeed and your code will treat it as RAM. That's why I needed a loop between the STA and the CMP. I'm not sure if there's a single solution that'd work for everything!

[MartinB]

I've never used that chip, I wrote my code for the eeproms we're using in Beebs and it works well with all those so I'll avoid any that don't have the newer predictable interface - presumably that's an older chip?

Edit : Yeah, that Winbond chip is relatively old in flash terms so I'm happy that my detection method will work well with all the more modern types. As I said earlier, assuming we're using a modern JEDEC type of eeprom, my code will happily determine viable eeprom, locked eeprom, ram or rom.

[sweh]

The datasheet appears to be dated 1998. It has write protection, end-of-write detection and so on.

Writing to the chip is a two stage process, internally. In step 1, data is written to a 128byte buffer (the page size on this chip). It no writes are done within 200uS then the chip switches to step 2 and commits the buffer via an internal write to the flash cells.

My guess, based purely on what I've observed (I don't see this addressed in the datasheet), is that writing to the buffer still works even if the chip has protection enabled and that reads may be satisfied by the buffer. So even with write protection enabled, STA/CMP will appear to succeed. But letting the chip switch to stage 2 (which then fails due to enabled protection) by having a delay of 200uS causes the buffer to become invalidated and the read now returns the real value.

So _reprogramming_ the chip (disable protection, send 128 bytes of data, wait for write complete detection, send next chunk.... re-enable protection) is nice and predictable. It's the unplanned write to a protection enabled chip that causes odd results.

[MartinB]

Sorry Stephen, I edited my post as you were posting. I think that what has importantly moved on is the writing characteristic that means, irrespective of protection whether hard or soft, you can no longer instantly read back what you've just written allowing device detection code like mine to work well.

[Coeus]

Did you ever get to the bottom of why it would not work running in EPROM alongside the other ROMs in the 64K device?

If you check out the service routine code in DFS 2.26 there is a daisy chain of three different bits of code - there is some code to do memory sizing and alter the startup message, the sideway RAM utilites (SRAM 1.05) and the DFS code itself. You could try a patched ROM that executes these in various combinations - singly, pairs etc. and see which one is causing the crash.

[cmorley]

Did you ever get to the bottom of why it would not work running in EPROM alongside the other ROMs in the 64K device?

If you check out the service routine code in DFS 2.26 there is a daisy chain of three different bits of code - there is some code to do memory sizing and alter the startup message, the sideway RAM utilites (SRAM 1.05) and the DFS code itself. You could try a patched ROM that executes these in various combinations - singly, pairs etc. and see which one is causing the crash.

No, I don't have a disassembly for 2.26 and Google couldn't find me one reasonably quickly. It might have been a problem with the EPROM or finger trouble. The BBC with 1770 is in a pile of old computers which need cleaning and selling so I might have a quick look again in the future...

[jgharston]

No, I don't have a disassembly for 2.26 and Google couldn't find me one reasonably quickly.

http://mdfs.net/Info/Comp/BBC/DFS