stardot.org.uk

aotta wrote: ↑

Thu Nov 08, 2018 10:37 pm

in my case it seems i have two inputs... it's not the wiring the fault

Ah. Ok. Is it possible that S21W is actually connected to more than one IC on the ROM / RAM board, or to more than one pin on IC1?

I don't have exactly the same card. However, I do have a WE 12 ROM board that has a similar S21 that has flying leads that connect to the Beeb motherboard. In the case of this ROM board, S21W is connected to IC4 pin 3, which is a 74LS32 output. S21E is connected to IC4 pin 2, which is a 74LS32 input...

But.. S21 West is connected to Pin 1 of IC1 (74ls00), that is an input to the first nand gate of ICs... and pin 3 in fact is not flat and waves... So, is W the input and E the output, or viceversa? i am confused... That does sound like it's the wrong way round! On the beeb motherboard S21 SE is nor...

Does the board need it's own 5v supply? Where does it pick that up from?

That's my user port freed up again! Thank you Martin

If you already have the DFS hardware (8271 or 1770) in your beeb, then I'd recommend the Gotek floppy emulator with FlashFloppy firmware. It plugs into the floppy port like a normal FDD, but has a USB interface to load .ssd & .dsd images instead of using physically floppy disks.

tricky wrote: ↑

Sat Nov 03, 2018 9:21 pm

Have you heard anything about single density meta data access via track 254?

I've not really been keeping abreast of the changes, but I've had a quick look through the recent change logs and the issues tracker and nothing jumps out.

For those who are interested, v0.11 has recently been release. No longer considered pre-release. Recent change logs: V0.11 Detect and report upside-down data ribbon cable FF.CFG: Configurable OLED brightness/contrast (oled-contrast=) FF.CFG: Configurable head settle time (head-settle-ms=) FF.CFG: Fi...

All I know is what's already been posted about the CC and Watford ROMs. I'll be implementing bank switching according to the known zones. When I looked at the info for the CC ROMs that's posted in this thread, I couldn't make sense of it. The PAL equations were making reference to pins on the PAL t...

Pernod wrote: ↑

Thu Oct 25, 2018 9:07 pm

Thanks for those, will take a look at emulating them in the coming weeks.

Do you know what the PAL equations are for these devices? Can you share?

I've found another version of SpellMaster! This one is a 2 x 64k EPROM version as opposed to the 1 x 128k version I posted earlier. The ROM image 'a' in the attached zip is from the '128K' EPROM, and ROM image 'b' is from the 'SPELL' EPROM. The PAL is hidden under the '128K' EPROM. Again, I've not t...

Here's a copy of the Computer Concepts SpellMaster EPROM, along with a couple of photos of the carrier board. Note that there's a wire link underneath the PAL. You can see the two thru holes for this wire link on the underside of the carrier board. I've not tried to decode the PAL, as it's registere...

I'm guessing it could also be the 6522 at IC8, which is providing the address strobe to the CMOS IC and is also tied into the nCE, but the first one to go for is definitely the 74LS259 at IC10.

Just tested V42B. Works fine on the Master, however, creates a ROM on the Electron :? Dave H :D I'll try and and find some time this weekend to look at the logic that results in this mis-reporting on the Electron. Unfortunately I don't have the necessary hardware to test myself so I'll be relying o...

I thought the time delay you recently added was to allow extra time for the unlock sequence to be accepted and actioned (?) since one of the two fixes in 4.2 was already to fix the first-byte corruption and that was fixed and working - until recently that is! (In fact, I'm sure you yourself confirm...

Hi Dave, Just tested Ken's EEP32C on the Electron - Unfortunately it failed - e.g. UNLOCK reported ROM. No corruption of the first byte, however! Dave H :D Definitely made some progress by removing the corruption of the first byte. The UNLOCK function reporting an EEPROM as a ROM is a different issu...

I'm not familiar with the AP6 ROM. Does it include the EEPxx code that Martin developed? If it does, then yes, it probably does need to be updated. Who maintains the AP6 ROM?

With Martins permission, I've updated EEP16 & EEP32 from V4.2A to V4.2B with the following 2 changes: Fix corruption that occurs on some EEPROMs when applying soft lock. Provide support for AT29C256 Flash memory. Discussion about the issues that led to these changes can be found in this thread: http...

So, with Martins permission, I've updated EEP16 & EEP32 from V4.2A to V4.2B with the following 2 changes: Fix corruption that occurs on some EEPROMs when applying soft lock. Provide support for AT29C256 Flash memory. Instructions for use remain unchanged, and can be found in this thread: https://sta...

Testing done, Master: EEP32 and EEP32A didn't work. EEP32B and EEP32C both work :D That's kinda expected. A & B were interim tests that disabled different parts of the existing EEP32 functionality to try and narrow down the issue. I would have expected A & C to both lock / unlock without corruption...

Question: Why do you think Softlock is useful? .... Just curious . . . I do recognise the limitations of the soft lock function in the beeb, but my thoughts for retaining the functionality are: I assume we need to keep and maintain the unlock function, just in case someone has an EEPROM that's prev...

It's good to hear that none of the issues reported in this thread actually appear to be related to substandard supply of EEPROMs - unless we consider the timing issues with the LOCK function being a quality issue with the EEPROMs. I'm not convinced that it is. @MartinB - You've indicated that you do...

daveejhitchins wrote: ↑

Fri Oct 05, 2018 5:40 pm

Original EEP32 LOCK 23 changes the byte at &8000 th &55

That's the same issue I was seeing. Would be worth trying the patched version I've posted to see if that also works for you.

This is weird. I've tried this with a couple of different EEPROMs. I think it might be a timing issue. Test 1 : With original unmodified EEP32 V4.2A >*EEP32 LOCK 89 Data at address &8000 changes from &00 to &55 Device remains unlocked Test 2 : With EEP32 V4.2A modified to bypass the code that checks...

I'm using ones similar to the one that's on the left of the photo. From ebay China They program & lock fine on my external programmer.

Thus, I have no idea what’s happening with your checks, it’s as if something is aborting the code before it has naturally completed it’s functions. (i.e. the read, invert, write occurs but not the restore.) I’m not of course claiming it’s impossible for there still to be an issue with the code but ...

The results of your *STATUS command looks a bit suspect. It looks like all the bits of each status parameter are set to logic 1. As others have indicated, this is very likely a faulty cmos.

Sorry if I'm dragging this thread off topic, but I think it might be related. I'm definitely still seeing an XOR &FF issue on lower bank address &8000 with v4.2A of EEP32. First lock seems to change the byte from &00 to &55 (one of the 'magic' bytes?). If I then do a lock again it then changes to &A...

Sorry. Not sure why it's doing that. The corruption of the first byte is very consistent in my setup. If I get the time tomorrow, I'll put the flash in a different machine to see if I get the same results.

Right. With 28C256 installed in banks 8 & 9: >*EEP32 UNLOCK 89 >*LOAD I2C20B 3000 >*EELOAD @ 8 If I then check bank 8 address &8000 it reports &00 >*EEP32 LOCK 89 If I then check bank 8 address &8000 it reports &55 and that's with V4.2A of the utilities! I thought I had check this before, and it was...