stardot.org.uk

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...

I thought we were just checking whether or not a hooky chip can be unlocked with the test version where previously it couldn't.....? Indeed. That's all I was trying to test! I was just testing that the test EEP32 would still lock / unlock my EEPROM and started running into these issues. I suspect a...

The attached DFS ssd contains EEP32 Version 4.xx so if you Dave, and perhaps anyone else who can repeat the hooky chip no-unlock problem (?), could give it a try please..... Initial tests with EEPROM in banks 8 & 9: The first byte (&8000) of the lower bank seems to be getting screwed up again. I th...

There was a bug in the older EEP32 LOCK utility that would cause corruption of the image when trying to lock the EEPROM. This has been fixed in the latest version of the utilities. It was discussed in this thread: https://stardot.org.uk/forums/viewtopic.php?f=3&t=7393&hilit=eep32&start=330#p204290 H...

I don't have the interface parameter specifically set in my cfg file, and it works fine. According to the documentation, the default interface type is defined by Jumper JC (closed = IBM PC, open = Shugart). In my case JC is open, so the Shugart interface has been defined.

It may just be the angle that the photos been taken, and I'm not sure if it's physically possible to do, but the IDC connector looks like it's mis aligned by one row of pins? Are you sure it's plugged in correctly?

The Astec LPT44 is also a good replacement. I think it's pin compatible with the Meanwell.

@Ken : Are those address just general purpose (open-drain) I/O or is there a 6522? If you’re talking about a separate stand-alone project then it doesn’t matter how the bus is achieved but as per my discussion with Duncan, if we’re after commonality, for my I2C rom at least, any variance in the har...

streaks wrote: ↑

Sun Sep 23, 2018 9:29 pm

Like 5x3=15, so 2 bytes could store 5 colours with only one wasted bit.

Or better still, 3 bytes could store 8 pixels with no wasted bits!

Thoughts back....? Perhaps not directly related, but I'm looking to use an I2C RTC in my IntegraB redesign. The IntegraB uses memory mapped IO at addresses &FE38 and &FE3C to talk to the old RTC IC. I was considering using these addresses to implement the I2C protocol. Obviously I would need some a...

I voted for thru hole, because that's what I'm most comfortable with, but I have ventured into the SMT world occasionally.

jgharston wrote: ↑

Fri Sep 21, 2018 10:49 pm

What's all this millimetre nonsense? Standard 0.1 inch stripboard.

Oooh. That almost sounds like Brexit talk

1024MAK wrote: ↑

Sat Sep 22, 2018 5:58 am

Like UPURS

I need to find out a bit more about this UPURS that I hear a lot of people talking about.

I'm guessing it stands for User Port something or another, and I'm sure a search of these forums would reveal a lot.

Thanks Ken, all valuable information for the thread and much appreciated. (Nice micro-soldering too btw... =D> :) ) Haven't had much practice with SMD soldering, but that was fairly easy with a hot air gun and a steady hand. I didn't apply any new solder, just reused what was left on the pads, so m...