Amiga.org
Amiga computer related discussion => Amiga Hardware Issues and discussion => Topic started by: kamiga on January 06, 2014, 05:07:17 PM
-
Some of you might know that I'm designing (designed?) a new A501 replacement memory card using SRAM instead of DRAM.
I have some custom logic that glues the RAS/CASs to the CE of the SRAM chip.
The prototype PCB has been produced, and I've done literally billions(!) of test-accesses using both my own assembly routines, and normal off-the-shelf memory software available from aminet. These tests all pass without error! (which I'm pretty happy about)
The one issue that remains is that on startup, the amiga hangs on a WHITE screen. Occasionally(say, 1 in 5 cold starts), the amiga boots fine, recognizes the new memory card, and all is kosher.
If I temporarily disable the memory card, boot, re-enable the card, use the "addmem" command, then everything is also kosher.
Now I've looked at the descriptions of the POST, and even looked at the EXEC disassembly that's available online. Nothing jumps out at me --- normal accesses to the few locations (slightly under every 256k block during detection phase) should function fine. I've provably tested that reads/writes to these exact locations pass with flying colors.
I'm doing proper filtering on the +5v power supply(10uf), and decouple at each IC (.1uf). I doubt it's noise because there's billions of reads/writes done back to back (including interleaving with internal memory reads/writes) without an issue. I'm aware of the heavy duty factory shielding and other DIY attempts that have required such shielding to function --- but it's my firm belief that a (non-RF) design that requires shielding to operate normally hasn't been designed very well. Now for FCC certification, this is another matter.
As most of you probably know, the internal memory and my new SRAM card share the databus, and if my SRAM is active at ANY TIME the internal memory is, it will cause a conflict, and the 68K will latch corrupted data. I haven't spent much time yet looking at this, but that's my current plan for detecting the corruption.
My hopes is that the hanging white screen is a tell-tale symptom that someone recognizes. Note that this isn't simply a failure to recognize the memory --- this is characterized by the machine booting, but no fast ram being inserted into the memory pool. There are also things that can cause a guru crash, but that's not happening either.
Any help would be appreciated.
Thanks
P.S. This project is detailed at http://techtravels.org , and is completely open source/hardware.
-
Nice design! Probably obvious but have you tried it on different A500's, different models of motherboard, etc.?
-
You know, I haven't done this. :)
I tested this on a Rev 5, serial number 380xxx.
I have limited access to any other A500s -- the other one I have needs cleaned up, and tested before it would be worthwhile to use.
I could use another one or two that were in decent operating order.
Thanks
kamiga
-
Try posting where you're located? Maybe someone else local to you would be willing to help test with their machine? Just a thought! :)
-
Southwestern Pennsylvania, USA.
-
The one thing you didn't mention anything about was how your custom logic handles a refresh cycle (which it should properly ignore). Also, does your custom logic use multiplexed or non-multiplexed address decoding?
-
The one thing you didn't mention anything about was how your custom logic handles a refresh cycle (which it should properly ignore). Also, does your custom logic use multiplexed or non-multiplexed address decoding?
Thanks for the question.
The RAS-only refreshes are handled and ignored.
The board must see RAS1 (pin 38) low and one of the CASs low, and then it will assert /CE to the SRAM. If CAS goes high (as it does at the end of a cycle), then /CE is disabled.
If RAS1 goes low with no associated CAS (whenever a refresh occurs), /CE isn't brought active.
I've checked the timing (and propagation delays) and watched the amiga's latches in relation to make sure that the card is behaving as it should. (ie made sure data is stable and held for the appropriate durations)
Regarding the addressing, the SRAM uses a full address bus, but the one coming from the amiga is multiplexed. So, I latch the row address (first 9 bits) upon a falling edge of /RAS1, and latch the second 9 bits on a falling edge of either CAS.
I know I glossed over this earlier. Don't forget I've done billions of error free memory accesses in a row without even a single error. :)
Thanks
-
The one issue that remains is that on startup, the amiga hangs on a WHITE screen. Occasionally(say, 1 in 5 cold starts), the amiga boots fine, recognizes the new memory card, and all is kosher.
If I temporarily disable the memory card, boot, re-enable the card, use the "addmem" command, then everything is also kosher.
If this problem is only happening during cold boot as you say, it may be an issue with startup time of the SRAM. All of these devices have a specified time between when power is first applied and the device is ready for use. See what the SRAM datasheet says. It may be that the Amiga chip memory write/read tests are in progress just as the SRAM is entering a ready to use state.
Shouldn't be too hard to test the theory; just make a small RC type of circuit that holds the reset line low for 600ms or so at power on. If required you could build this into your final design as I'm fairly sure the _RST line is available at the A500 expansion connector. Note that you'll need to use an open collector drive onto the reset line. e.g. A 555 timer IC would be ideal.
I'm aware of the heavy duty factory shielding and other DIY attempts that have required such shielding to function --- but it's my firm belief that a (non-RF) design that requires shielding to operate normally hasn't been designed very well.
The type of shielding you describe is to minimise radiated emissions. You're right that it shouldn't affect your design. Keep in mind that every circuit operating at a radio frequency (e.g. microprocessor based) will emit some degree of the fundamental operating frequency and its harmonics as radiated emissions from PCB tracks, ICs themselves and as conducted emissions through connecting cables. I'm an RF/electronics design engineer and do this kind of stuff for a living.
To elaborate, at very fast clock speeds the shielding on a circuit or a cable can be required for it to operate because at higher radio frequencies a section of copper track or wire changes from a simple conductor into a complex transmission line where impedance, lengths and termination suddenly become critical. Often a section of shielding can play a role in the impedance of a transmission line, a typical example would be in the construction of coaxial cable or even a high speed USB cable. It's often more to do with the laws of physics than necessarily being a bad design.
Sensitive circuits can require shielding to reduce noise/interference from other emissions such as nearby radio transmissions, EM fields from transformers and motors, etc.
But at the lower speeds the A500 is operating at, of course this won't be an issue for you. Obviously the metal shielding used on these computers were to satisfy EMC standards for radiated emissions as opposed to having any affect on the circuit operation.
-
My hopes is that the hanging white screen is a tell-tale symptom that someone recognizes.
In my experience, memory problems trigger a guru.
Do you know if kickstart has disabled the rom at $0 when it dies?
You might want to patch a copy of kickstart to output more of an indication where it's up to.
-
If this problem is only happening during cold boot as you say, it may be an issue with startup time of the SRAM. All of these devices have a specified time between when power is first applied and the device is ready for use. See what the SRAM datasheet says. It may be that the Amiga chip memory write/read tests are in progress just as the SRAM is entering a ready to use state.
Thanks much for replying. I definitely value your input.
It was a good idea to check the SRAM datasheet[1] for a startup time, but heck if I can find one on there. It looks like stable voltage on OE(grounded permanently) and CE might be the deciding factor?
I checked the datasheet for the actual SHARP chips used in the amiga, and they are 500us + 8 refresh cycles.
Surely the SRAM would be faster than this?
Last but not least, the RAS-before-CAS time difference is around 180ns+, and so the chip should be ready by the time the CAS triggers my logic to drop /CE.
I've already looked at the propagation delays on my CAS-to-/CE --- there is plenty of access time while CAS is still low to fetch the data. (and for the amiga to latch it)
I've gotta get my logic analyzer hooked up again and start really watching that startup.
Thanks
kamiga
[1] I'm using IS61C25616AS-25TI. Datasheet is here http://www.issi.com/WW/pdf/61-64C25616AL-AS.pdf
-
In my experience, memory problems trigger a guru.
Do you know if kickstart has disabled the rom at $0 when it dies?
You might want to patch a copy of kickstart to output more of an indication where it's up to.
My amiga is hanging on a white screen. Resetting the amiga just brings it back to a white screen.
How can I tell? How would I patch kickstart? Burn a new rom chip? I Don't currently have that capability.
Thanks
-
It was a good idea to check the SRAM datasheet[1] for a startup time, but heck if I can find one on there. It looks like stable voltage on OE(grounded permanently) and CE might be the deciding factor?
I checked the datasheet for the actual SHARP chips used in the amiga, and they are 500us + 8 refresh cycles.
Surely the SRAM would be faster than this?
I don't see the power up time mentioned on that datasheet either. While you'd certainly expect the SRAM to power up in plenty of time, it's bad practice to make bold assumptions. I've seen some modern devices that take an eternity to become usable after power up in comparison to what you'd normally expect.
Another potential problem is the +5V supply line to the SRAM taking a while to stabilise. Most of these modern devices have in-built brownout detection where the device is internally held in a reset state until the supply is fully stable. Use a digital storage scope on the V+ supply pin of the SRAM to look at the rise time and check for any significant overshoot or ringing. The problem with using logic analysers is that they usually won't show this level of detail, unless they include mixed signal (analogue) capability.
How's this for a quick idea that won't cost you any time or money:
1. Find any convenient access to the A500 reset line (_RST) and manually short it to ground using a pair of tweesers, this is 100% safe to do as the line is not actively driven high at any time.
2. Power on the A500 normally.
3. After a second or so, remove the tweesers and see if the machine always boots reliably or you still get the white screen thing.
If that works, there's probably an issue with supply settling time or device power up durations. If it makes no difference, ignore my suggestions.
Do you know if kickstart has disabled the rom at $0 when it dies?
You might want to patch a copy of kickstart to output more of an indication where it's up to.
To answer your other question, this poster is talking about the fact that soon after power up, the system changes the ROM address (location) in the system memory map. At power on it's located at 0x000000, then early on during startup it gets moved to 0xF00000 - if I recall correctly. Or is it 0xF80000? Whatever. When this happens, the Overlay line (OVL) which is an output from CIA U7 (in the A500) pin 2 which goes either high or low (can't remember which direction), which then connects to the system address decoder (Gary) to change the _ROMEN address generation. This happens before the chip memory boundary tests are done, so it's a good suggestion to see if your white screen issues are before or after this event.
Failing that, it might be worthwhile finding out exactly where in the A500 ROM the screen is set to white. I think it may be when exec is started (don't quote me on that), which is after the chip memory tests are complete. Keep in mind that the chip memory test is NOT a thorough test, it only writes a longword every 16kB and checks it can be read back and isn't mirrored at address 0x000000.
I have a description of the ROM boot procedure detail here (http://amiga.serveftp.net/A3000_HardwareGuide/booting-problems.html), see the bottom of the page.
Yes, you'd have to change the ROM to make it give you any better detail. If you're able to configure your logic analyser to trigger on specific address words, I can send you an A4000 ROM image which has this level of debugging. Normally it's used with some special hardware I developed which captures special debugging data sent out on the address bus, but you may be able to do bits of this with your logic analyser. While it would fail at some point because the A4000 ROM won't run properly on A500 hardware, all of the initial stuff should work. But again that requires you to be able to write a ROM image into something and boot from that, so probably not so helpful.
-
I've got some results but heck if I know exactly what to make of it, yet.
Holding /RESET low (I was using pin 18 on the 68k) and tieing it to ground (I used pin 16 on the 68k) had some positive effect, but nothing super reproducible. It didn't make a huge difference.
I was trying to make it fail, and of course murphy's law kicked in, and it was working nearly 100% of the time!@# Now I couldn't make it fail any longer.
Long story short is that having the logic analyzer attached to the address leads and ground, and the thing boots 100% of the time. As soon as I remove the ground, it refuses to boot. If I replace the ground, but remove the address leads, it also refuses to boot.
If I place all address leads back on the jumpers, and place the ground connection back where I had it, it boots nearly 100% of the time.
I've gotta figure out what's going on.
Thanks Castellen and others for the help
P.S. I've read about logic analyzer probes loading the circuit, and it affecting by increasing or slowing the rise times. I'm using mostly 74ACT logic here, but the amiga is primarily 74LS based. I swear I've read that the rise times can be too fast, and older logic could have problems with it.
-
If I place all address leads back on the jumpers, and place the ground connection back where I had it, it boots nearly 100% of the time.
P.S. I've read about logic analyzer probes loading the circuit, and it affecting by increasing or slowing the rise times. I'm using mostly 74ACT logic here, but the amiga is primarily 74LS based. I swear I've read that the rise times can be too fast, and older logic could have problems with it.
Given that clue it certainly points more towards a rise time issue than it does a startup timing issue. Though that doesn't fully explain why it's only a problem during power up. Or it could be a combination of both of these issues.
Have you had a look at any of the data or address lines using a high speed (100MHz+) digital storage scope? Preferably connecting with a high impedance differental probe so that connecting the probe doesn't hide the issue you're looking for. That'll provide a much clearer answer of what's going on.
Could you post a link to your design schematic?
In comparison, you'll see the A501 (http://amiga.serveftp.net/Schematics/A500_schematics/A501MemExp-RTC.jpg) has 27 Ohm series resistors to slow edge rates which limits overshoot and ringing. Does your design include something similar?
Connecting the analyser probes will add a small parallel resistance and will of course have an effect on edge rates.
-
Have you had a look at any of the data or address lines using a high speed (100MHz+) digital storage scope?
Not yet, but I can do that. Am I looking for overshooting and ringing? And generally healthy square waves?
Preferably connecting with a high impedance differental probe so that connecting the probe doesn't hide the issue you're looking for.
I don't own any differential probes. I'm pretty sure they are fairly expensive, especially for a hobbyist. Any idea how much decent ones cost?
Could you post a link to your design schematic?
I'll see what I can do. The current schematics aren't 100% up to date, given minor problems seen in the prototype.
In comparison, you'll see the A501 (http://amiga.serveftp.net/Schematics/A500_schematics/A501MemExp-RTC.jpg) has 27 Ohm series resistors to slow edge rates which limits overshoot and ringing. Does your design include something similar?
Yes, I've included 33-ohm series resistors on the data lines, but not on the address or control lines.
Thanks
-
Thanks for the question.
The RAS-only refreshes are handled and ignored.
The board must see RAS1 (pin 38) low and one of the CASs low, and then it will assert /CE to the SRAM. If CAS goes high (as it does at the end of a cycle), then /CE is disabled.
If RAS1 goes low with no associated CAS (whenever a refresh occurs), /CE isn't brought active.
I've checked the timing (and propagation delays) and watched the amiga's latches in relation to make sure that the card is behaving as it should. (ie made sure data is stable and held for the appropriate durations)
Regarding the addressing, the SRAM uses a full address bus, but the one coming from the amiga is multiplexed. So, I latch the row address (first 9 bits) upon a falling edge of /RAS1, and latch the second 9 bits on a falling edge of either CAS.
I know I glossed over this earlier. Don't forget I've done billions of error free memory accesses in a row without even a single error. :)
Thanks
I wasn't aware that Fat Agnus was performing a RAS only refresh. Did you confirm this with your logic analyzer?
Since your de-multiplexing the address' then you need to delay your SRAM CE long enough for the SRAM address inputs to be stable.
The normal time it takes to reset a 7 MHz 68000 and then execute some Kickstart code before a Chipmem access should be more than enough time to meet the start-up time requirements of the slowest SRAM.
The ROM overlay function should not be a problem as long a your circuit properly ignores the refresh cycle (That's why I mentioned it).
Logic probe loading may correct a problem with address' (or data) being stable at latching time. Some low value in-series resistors or high value pull downs may help here but a delay in latch timing may also solve the problem. So you might want to check your SRAM CE timing again.
-
I wasn't aware that Fat Agnus was performing a RAS only refresh. Did you confirm this with your logic analyzer?
Yeah, definitely. Take a look at my main project page where I include logic analyzer traces.
http://www.techtravels.org/amiga/amigablog/?page_id=942
Look at the top diagram. You can see the RAS only pulses, one for both the internal memory and external memory, with constantly increasing row addresses.
This is Agnus refreshing each row of the DRAMs.
There's no pin-1 refresh available on these chips and I've definitely not seen CAS-before-RAS in any of my work so far.
Since your de-multiplexing the address' then you need to delay your SRAM CE long enough for the SRAM address inputs to be stable.
The setup time for reading appears to be 0ns with the hold time being 3ns. For writing, the setup time is specified as 0ns and hold time is 0ns.
There was a chance I was asserting CE BEFORE the latch outputs stabilized on the input, so I slowed the gate-logic down by switching from ACT to LS on the chip responsible, and now I'm measuring 9ns timing margin between address stabilization and falling edge of CE. This should be sufficient given the datasheet.
The normal time it takes to reset a 7 MHz 68000 and then execute some Kickstart code before a Chipmem access should be more than enough time to meet the start-up time requirements of the slowest SRAM.
Yup, my thoughts were that there's plenty of time for the SRAM to come online before it needs to start performing.
Logic probe loading may correct a problem with address' (or data) being stable at latching time. Some low value in-series resistors or high value pull downs may help here but a delay in latch timing may also solve the problem. So you might want to check your SRAM CE timing again.
I'm going to take a look at the lines on a DSO today. I do have series resistors on the data lines. I can always delay the /CE more, but I think that if I consistently measure 9ns setup and the actual setup time requirement is 0ns, then I'm probably safe here.
Thanks
kamiga
-
Failing that, it might be worthwhile finding out exactly where in the A500 ROM the screen is set to white.
White screen makes me think it's 1.2/1.3, I don't remember the later versions changing to white screen.
It also might not be trying to make the screen white, the cpu could be crashing and store a stack frame in chip reg space or some bus corruption.
Tracing POST issues is hard on Amiga without an eprom programmer.
-
I tried it on another good known-working amiga, and it boots up fine without error.
I also managed to check a much larger portion of the memory than I've been able to before, and all of those pass without error as well!
Thanks for the help.
-
Also, for what it's worth, I've got to continue to the testing on more amigas. I have very few data points: it works on one, but not on another. Not exactly a convincing argument!
-
Keep testing, glad you got it working on the one! It's a bit of a drive but check out the thread on here about our Baltimore/Washington meetup group, if you were ever able to come down I could bring at least my A500 for you to test on (it's pretty heavily expanded, so might make a good test platform). Good work!
-
Keep testing, glad you got it working on the one! It's a bit of a drive but check out the thread on here about our Baltimore/Washington meetup group, if you were ever able to come down I could bring at least my A500 for you to test on (it's pretty heavily expanded, so might make a good test platform). Good work!
Thanks much OM!
For what it's worth, I've also identified the problems with the first Amiga I had tested with. I had a test fixture on Agnus, and while I wasn't using it, it definitely affected something.
Here's my associated blog post about it.
http://www.techtravels.org/amiga/amigablog/?p=1251
If it was well attended, Baltimore isn't too far for me to come now and again. Let me know the next time the meetup is happening.
Thanks