Perplexing 64 addressing finding

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Perplexing 64 addressing finding

Jim Brain

Trying to help some folks with issues related to an EasyFlash-derived design, I have been debugging the circuit and I'm momentarily stumped on the issue.

  • The design is exactly the same as the stock EF1 design, with 1 change.  Instead of 2 FLASH ROMs (one in $8000 and one at $a000), I put a single FLASH ROM on the PCB and wired ROMH and ROML through a 74'08 to !CE
  • With all HCT parts, the unit will not flash on non 250469 boards.
  • With all HCT parts but the '08 (74ls08), the same unit will flash correctly on non 250469 boards (at least a few I have tried).

SO, my hyposthesis was that the ROMH and ROML signals need some settling time before being applied to !CE.

However, when I remove the '08 from the circuit and hardwire the !CE line of the FLASH ROM to ROML, the unit works on non 250469 boards.  That would indicate either 1 of two things:

  • Faster than HCT (no latency) is required (or lots of LS latency)
  • The interaction of the ROMH and ROML signals is causing glitches.

I don't see the glitches yet, but I continue to test.  What I wonder is how other systems handled sharing a ROM between ROMH and ROML.  THe '08 seemed a logical choice (no pun intended), but possibly some other idea is better.  I tried gating the CE signal with PHI2, but that did not help.

Any thoughts are appreciated. 

Jim

-- 
Jim Brain
[hidden email] 
www.jbrain.com
Reply | Threaded
Open this post in threaded view
|

RE: Perplexing 64 addressing finding

Baltissen, GJPAA (Ruud)
Hallo Jim,


What does the circuit when you only connect ROMH?

Another question, what do you mean with "unit will not flash"?
  - nothing has been written at all
  - complete wrong data has been written
  - only a few bytes are wrong

Regarding the "few bytes", if that is the case, you probably ran into the same problem I had with my IDE interface 25 years ago: the circuit is too fast i.e. it is picking up data or the address of the extended VIC cycle. Because this is not the case when using ROML alone, it could be happening when ROMH is asserted. Therefore my first question.


Met vriendelijke groet / With kind regards, Ruud Baltissen

www.Baltissen.org



De informatie in dit e-mailbericht is vertrouwelijk en uitsluitend bestemd voor de
geadresseerde. Wanneer u dit bericht per abuis ontvangt, verzoeken wij u contact op te
nemen met de afzender per kerende e-mail. Verder verzoeken wij u in dat geval dit
e-mailbericht te vernietigen en de inhoud ervan aan niemand openbaar te maken.
Wij aanvaarden geen aansprakelijkheid voor onjuiste, onvolledige dan wel ontijdige
overbrenging van de inhoud van een verzonden e-mailbericht, noch voor daarbij
overgebrachte virussen.

APG Groep N.V. is gevestigd te Heerlen en is ingeschreven in het
handelsregister van de Kamer van Koophandel Limburg onder nummer 14099617


The information contained in this e-mail is confidential and may be privileged.
It may be read, copied and used only by the intended recipient.
If you have received it in error, please contact the sender immediately by
return e-mail; please delete in this case the e-mail and do not disclose its
contents to any person. We don't accept liability for any errors, omissions,
delays of receipt or viruses in the contents of this message which arise as a
result of e-mail transmission.

APG Groep N.V. is registered in the trade register of the Chamber
of Commerce Limburg, The Netherlands, registration number: 14099617
1�,j�j���a�����^q��i��ɚ�X��X��
Reply | Threaded
Open this post in threaded view
|

Re: Perplexing 64 addressing finding

Jim Brain
On 8/9/2017 12:45 AM, Baltissen, GJPAA (Ruud) wrote:
> Hallo Jim,
>
>
> What does the circuit when you only connect ROMH?
If I change the app to send flash commands to $a000, and move the jumper
to ROMH, the same bahevior is seen (it works)
>
> Another question, what do you mean with "unit will not flash"?
>    - nothing has been written at all
Nothing gets written at all.
Jim


       Message was sent through the cbm-hackers mailing list
Reply | Threaded
Open this post in threaded view
|

RE: Perplexing 64 addressing finding

Baltissen, GJPAA (Ruud)
Hallo Jim,


> Nothing gets written at all.

For those not familiar with writing data tot a FlashRAM: first a set of bytes has to be written to the FRAM to tell it it is going to be written. If one byte goes wrong, you can forget the rest as well.

Just my thoughts so far:
The 250469 is the first short board with a MMU, this big 64-pins IC, and separate color RAM. On a later version the color RAM has been incorporated into this MMU. Did you try such a board as well? If things work here out fine as well then the only thing I can think of is how the older PLA interacts with HCT ICs. If that is troublesome in one or another way, you have the cause of your problem.


Met vriendelijke groet / With kind regards, Ruud Baltissen

www.Baltissen.org





De informatie in dit e-mailbericht is vertrouwelijk en uitsluitend bestemd voor de
geadresseerde. Wanneer u dit bericht per abuis ontvangt, verzoeken wij u contact op te
nemen met de afzender per kerende e-mail. Verder verzoeken wij u in dat geval dit
e-mailbericht te vernietigen en de inhoud ervan aan niemand openbaar te maken.
Wij aanvaarden geen aansprakelijkheid voor onjuiste, onvolledige dan wel ontijdige
overbrenging van de inhoud van een verzonden e-mailbericht, noch voor daarbij
overgebrachte virussen.

APG Groep N.V. is gevestigd te Heerlen en is ingeschreven in het
handelsregister van de Kamer van Koophandel Limburg onder nummer 14099617


The information contained in this e-mail is confidential and may be privileged.
It may be read, copied and used only by the intended recipient.
If you have received it in error, please contact the sender immediately by
return e-mail; please delete in this case the e-mail and do not disclose its
contents to any person. We don't accept liability for any errors, omissions,
delays of receipt or viruses in the contents of this message which arise as a
result of e-mail transmission.

APG Groep N.V. is registered in the trade register of the Chamber
of Commerce Limburg, The Netherlands, registration number: 14099617
1�,j�j���a�����^q��i��ɚ�X��X��
Reply | Threaded
Open this post in threaded view
|

Re: Perplexing 64 addressing finding

Francesco Messineo
In reply to this post by Jim Brain
Hi,
according to the datasheets, HCT08 is a few ns SLOWER than an LS08.
Are all unused inputs of the '08 tied to a supply rail?
HTH
Frank  IZ8DWF

On Wed, Aug 9, 2017 at 6:49 AM, Jim Brain <[hidden email]> wrote:

> Trying to help some folks with issues related to an EasyFlash-derived
> design, I have been debugging the circuit and I'm momentarily stumped on the
> issue.
>
> The design is exactly the same as the stock EF1 design, with 1 change.
> Instead of 2 FLASH ROMs (one in $8000 and one at $a000), I put a single
> FLASH ROM on the PCB and wired ROMH and ROML through a 74'08 to !CE
> With all HCT parts, the unit will not flash on non 250469 boards.
> With all HCT parts but the '08 (74ls08), the same unit will flash correctly
> on non 250469 boards (at least a few I have tried).
>
> SO, my hyposthesis was that the ROMH and ROML signals need some settling
> time before being applied to !CE.
>
> However, when I remove the '08 from the circuit and hardwire the !CE line of
> the FLASH ROM to ROML, the unit works on non 250469 boards.  That would
> indicate either 1 of two things:
>
> Faster than HCT (no latency) is required (or lots of LS latency)
> The interaction of the ROMH and ROML signals is causing glitches.
>
> I don't see the glitches yet, but I continue to test.  What I wonder is how
> other systems handled sharing a ROM between ROMH and ROML.  THe '08 seemed a
> logical choice (no pun intended), but possibly some other idea is better.  I
> tried gating the CE signal with PHI2, but that did not help.
>
> Any thoughts are appreciated.
>
> Jim
>
> --
> Jim Brain
> [hidden email]
> www.jbrain.com

       Message was sent through the cbm-hackers mailing list
Reply | Threaded
Open this post in threaded view
|

Re: Perplexing 64 addressing finding

Jim Brain
On 8/9/2017 2:38 AM, Francesco Messineo wrote:
> Hi,
> according to the datasheets, HCT08 is a few ns SLOWER than an LS08.
Sigh.  Thanks Francesco.  I need to hand in my credentials.  I read the
sheets backwards (I read LS as 34nS, and HCT as 17, when they were both
open in the window.)
> Are all unused inputs of the '08 tied to a supply rail?
Yep, but the above makes everything line up.  LS worked, wire works, but
HCT (being slower yet), does not.

Jim

       Message was sent through the cbm-hackers mailing list
Reply | Threaded
Open this post in threaded view
|

Re: Perplexing 64 addressing finding

André Fachat


Am 9. August 2017 3:56:40 PM schrieb Jim Brain <[hidden email]>:

> Yep, but the above makes everything line up.  LS worked, wire works, but
> HCT (being slower yet), does not.

I have been using ALS types as LS replacements. Is that an alternative?

Regards
André



       Message was sent through the cbm-hackers mailing list
Reply | Threaded
Open this post in threaded view
|

Re: Perplexing 64 addressing finding

Francesco Messineo
ALS is surely faster than LS, but I wouldn't use them in place of LS
parts, faster logic requires better decoupling (has faster edges and
larger current drive capabilities) and can disrupt any intentional
delay that was part of a design. I tend not to use a different family
when doing a repair (unless I know what I'm doing). On a new
(old-school) design, I prefer HC or AHC logic when speed isn't a
problem. AC family is very fast but requires great care in decoupling
due to the high speed toggling.

On Wed, Aug 9, 2017 at 8:23 PM, André Fachat <[hidden email]> wrote:

>
>
> Am 9. August 2017 3:56:40 PM schrieb Jim Brain <[hidden email]>:
>
>> Yep, but the above makes everything line up.  LS worked, wire works, but
>> HCT (being slower yet), does not.
>
>
> I have been using ALS types as LS replacements. Is that an alternative?
>
> Regards
> André
>
>
>
>       Message was sent through the cbm-hackers mailing list

       Message was sent through the cbm-hackers mailing list