Re: [M100] SPAM-LOW: Re: New member - question on 'half' alive Model 100

[Fugu ME100]

That’s great.   Pleased to hear you tracked it down - another 100 survives  :)  
Now you have two and that’s how it all starts….

If you want to build RAM modules for the M100 I have two RAM PCBs on OSH Park: 
SMD Version and DIP version.   The design is based on the old NEC modules.
https://oshpark.com/shared_projects/V0tpeuMg
https://oshpark.com/shared_projects/Ra3VwoJo

There are a few different options to add pins to the PCBs for mounting.

From: M100 
<m100-boun...@lists.bitchin100.com<mailto:m100-boun...@lists.bitchin100.com>> 
on behalf of Jeffrey Birt <bir...@soigeneris.com<mailto:bir...@soigeneris.com>>
Reply-To: <m...@bitchin100.com<mailto:m...@bitchin100.com>>
Date: Sunday, May 13, 2018 at 6:52 PM
To: <m...@bitchin100.com<mailto:m...@bitchin100.com>>
Subject: Re: [M100] SPAM-LOW: Re: New member - question on 'half' alive Model 
100

Update…

It was the RAM module. After thinking about it after Fugu’s email the other day 
it occurred to me I had done a capture of the standard RAM bank select lines 
(and I happened to dave it) and after looking at it again it looked fine. This 
evening I pulled the standard RAM module out, split apart a 30 pin DIP socket 
to make two 15 pin SIPs and plugged in of the option RAMs. AND…nothing. Sigh…

Then I noticed I had not plugged the ROM back in after cleaning the flux from 
the board. So, the ROM was installed, and STRL-BRK done on power up and…It’s 
ALIVE! Bwa-ha-ha-ha! It’s ALIVE!

I tried reflowing the original standard RAM module and it still did not work. I 
could ohm out each line to each individual RAM chip and maybe get lucky and 
find one open trace, but I would guess that a bad RAM chip is more likely. I’ll 
look into making some more RAM module or buying a few, for now I have 16K.

As luck would have it the second M100 I bought from across the state arrived 
yesterday, I still have not opened it yet. It is supposed to work, got it from 
the original owner who seemed like a nice guy. A grand total of $61 including 
shipping. Now I’ll put together an order for enough caps to finish recapping 
the first M100 and re-cap the 2nd one while I’m at it. I also need to try and 
calculate a super-cap size that will at least match the original NiCad battery.

Thanks again everyone (especially Fugu) for your help.

Jeff

Re: [M100] SPAM-LOW: Re: New member - question on 'half' alive Model 100

[John Gardner]

You're not going to find a supercap that'll

a)  Keep RAM alive as long as a healthy NiCd will,  and

2)  Fit inside the case.  Or inside your trunk,  probably...

But what you can do is

1)  Use Eneloop "Low Self-Discharge" AAs,  which if your RAM
 is healthy (not drawing much stand-by current)  will keep memory
 alive for many years,  fully charged.

b)  Use a 3 or 5F supercap,  which will keep healthy RAM alive for
 weeks;  plenty of time to recharge or replace your Eneloops.

Why?  Eneloops don't leak.  Supercaps don't leak.  NiCds do.



On 5/13/18, Jeffrey Birt <bir...@soigeneris.com> wrote:
> Update…
>
>
>
> It was the RAM module. After thinking about it after Fugu’s email the other
> day it occurred to me I had done a capture of the standard RAM bank select
> lines (and I happened to dave it) and after looking at it again it looked
> fine. This evening I pulled the standard RAM module out, split apart a 30
> pin DIP socket to make two 15 pin SIPs and plugged in of the option RAMs.
> AND…nothing. Sigh…
>
>
>
> Then I noticed I had not plugged the ROM back in after cleaning the flux
> from the board. So, the ROM was installed, and STRL-BRK done on power up
> and…It’s ALIVE! Bwa-ha-ha-ha! It’s ALIVE!
>
>
>
> I tried reflowing the original standard RAM module and it still did not
> work. I could ohm out each line to each individual RAM chip and maybe get
> lucky and find one open trace, but I would guess that a bad RAM chip is more
> likely. I’ll look into making some more RAM module or buying a few, for now
> I have 16K.
>
>
>
> As luck would have it the second M100 I bought from across the state arrived
> yesterday, I still have not opened it yet. It is supposed to work, got it
> from the original owner who seemed like a nice guy. A grand total of $61
> including shipping. Now I’ll put together an order for enough caps to finish
> recapping the first M100 and re-cap the 2nd one while I’m at it. I also need
> to try and calculate a super-cap size that will at least match the original
> NiCad battery.
>
>
>
> Thanks again everyone (especially Fugu) for your help.
>
>
>
> Jeff
>
>
>
>
>
> From: M100 <m100-boun...@lists.bitchin100.com> On Behalf Of Fugu ME100
> Sent: Thursday, May 10, 2018 10:06 AM
> To: m...@bitchin100.com
> Subject: Re: [M100] SPAM-LOW: Re: New member - question on 'half' alive
> Model 100
>
>
>
> The address could be stuck internally on the RAM so the address line would
> appear OK externally.  The fact the ROM runs correctly with the shared
> Address line would indicate the address lines are generally OK.  It could be
> floating on the module as you suggest,  look to see if there is any
> corrosion on the module and the pins to the module are in good condition.
> Perhaps try reflowing each of the module pins to make sure there are no dry
> joints?
>
>
>
> I am currently looking into producing some sort of test harness for the
> model T however the lack of socket for the 8085 makes it hard to add in a
> test fixture.  Even trying to tri-state the 8085 appears difficult as it
> does not tri-state the ALE, all the other lines are OK.  Another option
> would be to try and monitor what it does with something that plugs into the
> RAM socket.  That way at least there would be a trace showing the bus
> activity.   Being able to single step the 8085 might be another option with
> a known ROM in the socket.
>
>
>
>

Re: [M100] SPAM-LOW: Re: New member - question on 'half' alive Model 100

[Jeffrey Birt]

Update…

 

It was the RAM module. After thinking about it after Fugu’s email the other day 
it occurred to me I had done a capture of the standard RAM bank select lines 
(and I happened to dave it) and after looking at it again it looked fine. This 
evening I pulled the standard RAM module out, split apart a 30 pin DIP socket 
to make two 15 pin SIPs and plugged in of the option RAMs. AND…nothing. Sigh…

 

Then I noticed I had not plugged the ROM back in after cleaning the flux from 
the board. So, the ROM was installed, and STRL-BRK done on power up and…It’s 
ALIVE! Bwa-ha-ha-ha! It’s ALIVE! 

 

I tried reflowing the original standard RAM module and it still did not work. I 
could ohm out each line to each individual RAM chip and maybe get lucky and 
find one open trace, but I would guess that a bad RAM chip is more likely. I’ll 
look into making some more RAM module or buying a few, for now I have 16K.

 

As luck would have it the second M100 I bought from across the state arrived 
yesterday, I still have not opened it yet. It is supposed to work, got it from 
the original owner who seemed like a nice guy. A grand total of $61 including 
shipping. Now I’ll put together an order for enough caps to finish recapping 
the first M100 and re-cap the 2nd one while I’m at it. I also need to try and 
calculate a super-cap size that will at least match the original NiCad battery.

 

Thanks again everyone (especially Fugu) for your help.

 

Jeff

 

 

From: M100 <m100-boun...@lists.bitchin100.com> On Behalf Of Fugu ME100
Sent: Thursday, May 10, 2018 10:06 AM
To: m...@bitchin100.com
Subject: Re: [M100] SPAM-LOW: Re: New member - question on 'half' alive Model 
100

 

The address could be stuck internally on the RAM so the address line would 
appear OK externally.  The fact the ROM runs correctly with the shared Address 
line would indicate the address lines are generally OK.  It could be floating 
on the module as you suggest,  look to see if there is any corrosion on the 
module and the pins to the module are in good condition.  Perhaps try reflowing 
each of the module pins to make sure there are no dry joints?

 

I am currently looking into producing some sort of test harness for the model T 
however the lack of socket for the 8085 makes it hard to add in a test fixture. 
 Even trying to tri-state the 8085 appears difficult as it does not tri-state 
the ALE, all the other lines are OK.  Another option would be to try and 
monitor what it does with something that plugs into the RAM socket.  That way 
at least there would be a trace showing the bus activity.   Being able to 
single step the 8085 might be another option with a known ROM in the socket.  

 

Re: [M100] SPAM-LOW: Re: New member - question on 'half' alive Model 100

[Fugu ME100]

The address could be stuck internally on the RAM so the address line would 
appear OK externally.  The fact the ROM runs correctly with the shared Address 
line would indicate the address lines are generally OK.  It could be floating 
on the module as you suggest,  look to see if there is any corrosion on the 
module and the pins to the module are in good condition.  Perhaps try reflowing 
each of the module pins to make sure there are no dry joints?

I am currently looking into producing some sort of test harness for the model T 
however the lack of socket for the 8085 makes it hard to add in a test fixture. 
 Even trying to tri-state the 8085 appears difficult as it does not tri-state 
the ALE, all the other lines are OK.  Another option would be to try and 
monitor what it does with something that plugs into the RAM socket.  That way 
at least there would be a trace showing the bus activity.   Being able to 
single step the 8085 might be another option with a known ROM in the socket.

From: M100 
<m100-boun...@lists.bitchin100.com<mailto:m100-boun...@lists.bitchin100.com>> 
on behalf of Jeffrey Birt <bir...@soigeneris.com<mailto:bir...@soigeneris.com>>
Reply-To: <m...@bitchin100.com<mailto:m...@bitchin100.com>>
Date: Thursday, May 10, 2018 at 7:13 AM
To: <m...@bitchin100.com<mailto:m...@bitchin100.com>>
Subject: Re: [M100] SPAM-LOW: Re: New member - question on 'half' alive Model 
100

Very good observation. I believe that I did check that all address lines were 
toggling at the RAM module, but I will check again. Perhaps A4 is floating? 
Yes, a RAM test would be nice. I think a diagnostic ROM could be made to do 
that, just start out by testing the standard RAM (without any stack operations) 
There is a diagnostic cartridge for the C64 that does that, of course if the 
address decoding is not working then the results of such a test are bogus 

Thanks,
Jeff

Re: [M100] SPAM-LOW: Re: New member - question on 'half' alive Model 100

[Jeffrey Birt]

Very good observation. I believe that I did check that all address lines were 
toggling at the RAM module, but I will check again. Perhaps A4 is floating? 
Yes, a RAM test would be nice. I think a diagnostic ROM could be made to do 
that, just start out by testing the standard RAM (without any stack operations) 
There is a diagnostic cartridge for the C64 that does that, of course if the 
address decoding is not working then the results of such a test are bogus 

 

Thanks,

Jeff

 

From: M100 <m100-boun...@lists.bitchin100.com> On Behalf Of Fugu ME100
Sent: Thursday, May 10, 2018 8:25 AM
To: m...@bitchin100.com
Subject: Re: [M100] SPAM-LOW: Re: New member - question on 'half' alive Model 
100

 

If A4 is stuck at 0 (or 1) then the SP and copy location would overlap, eg 
F5F0H would become F5E0H and overwrite the stack area - at least 6 bytes of it. 
 The RAM modules are made up of 4 ICs so it it possible that only the top most 
RAM has a fault the others could be fine. If the RAM operation occurs in the 
other 3 RAM ICs then there would not be a problem.  The other CALL 7EE1H works 
because there are no other RAM ops that could damage the stack.  

 

As the Address lines are shared with the ROM and it seems to work fine it 
really only leaves the RAM module or decoder IC.   I am tending towards the RAM 
module.  Would be nice to somehow run a RAM test :)

 

 

F5F0H,  0101 111? B   start of RAM copy destination

F690H,  0110 1001 B   end of RAM copy destination

F5E6H,  0101 111? 0110B   start of stack, grows down.  

   

Re: [M100] SPAM-LOW: Re: New member - question on 'half' alive Model 100

[Fugu ME100]

If A4 is stuck at 0 (or 1) then the SP and copy location would overlap, eg 
F5F0H would become F5E0H and overwrite the stack area - at least 6 bytes of it. 
 The RAM modules are made up of 4 ICs so it it possible that only the top most 
RAM has a fault the others could be fine. If the RAM operation occurs in the 
other 3 RAM ICs then there would not be a problem.  The other CALL 7EE1H works 
because there are no other RAM ops that could damage the stack.

As the Address lines are shared with the ROM and it seems to work fine it 
really only leaves the RAM module or decoder IC.   I am tending towards the RAM 
module.  Would be nice to somehow run a RAM test :)


F5F0H,  0101 111? B   start of RAM copy destination
F690H,  0110 1001 B   end of RAM copy destination
F5E6H,  0101 111? 0110B   start of stack, grows down.

Re: [M100] SPAM-LOW: Re: New member - question on 'half' alive Model 100

[Jeffrey Birt]

Yeah, about at that point. I’m not sure if I can deduce anything else from 
further measurements at this point.

 

Thanks,

Jeff

 

From: M100 <m100-boun...@lists.bitchin100.com> On Behalf Of Josh Malone
Sent: Thursday, May 10, 2018 6:09 AM
To: m...@bitchin100.com
Subject: Re: [M100] SPAM-LOW: Re: New member - question on 'half' alive Model 
100

 

I would move on to swapping RAM and decoder chips. As I said before, the 
decoder chip in my 102 failed last year some time; kept one of the RAM chips 
from ever being enabled.

 

On Thu, May 10, 2018, 12:43 AM Fugu ME100 <b4me...@hotmail.com 
<mailto:b4me...@hotmail.com> > wrote:

Does it only execute the loop once and get stuck for the first time at 2574H?   

 

The 49H in the data dump is most likely the C9H for the RET.  The next two byte 
are the return address from the stack.  They could be 0A57H, 0AD7H, 8A57, 8AD7H 
or  other permutations.  As this routine is writing to the RAM it is quite 
possible it is trashing the stack and destroying the return address - could be 
a bad RAM chip or decoder.  

 

There are at least two different versions of the M100 motherboard one has 
700mil RAM modules and the other 750mil.  Not sure if there are any ROM 
differences or other hardware differences. 

Re: [M100] SPAM-LOW: Re: New member - question on 'half' alive Model 100

[Jeffrey Birt]

No, it executes all 143 loops writing all 144 bytes. In fact I was so tired 
last evening I started counting loop iterations before it occurred to me to 
find the difference in line numbers between first and last loops and divide by 
lines per loop. 

 

Thinking out loud here…

 

The start of the cold boot routine sets the stack pointer thusly:

7DE7H  (31H) LXI SP,F5E6H   ; Load the SP with Cold Boot location

 

And stack grown downward. 

 

The 144 bytes is being copied into RAM at F5F0H, F5F0H + 90H = F690H. 

 

The 8K boundaries of each RAM bank are H-E000H, DFFFH-C000H, BFFFH-A000H, 
9FFFH-8000H.

 

Both the stack and location being copied to are in the same bank but do not 
overlap. Only A0-A10 routed to RAM, noted by spaces below.

 

F5F0H,  0  101  B   start of RAM copy destination

F690H,  0  110 1001 B   end of RAM copy destination

F5E6H,  0  101 1110 0110B   start of stack, grows down.  

 

I think the RAM module has four chips which would be 2K each.

H-F800H, F7FFH-F000, EFFFH-E800, E7FFH-E000

 

So, the address range in question is all on the same chip. It would seem odd 
that the bank decoding would work correctly for only some addresses in this 
same bank, i.e. A11-A15 are not changing. But this is possible. It could be in 
the RAM itself, perhaps it is bad at that particular offset into the stack?

 

This PCB is the early style with the odd Sharp ROM pinout. I believe the 
standard RAM module is the same footprint as the option RAMs, of which I have 
two. I guess M4/M5 are the easiest to swap out and try to pull and test.

 

Thanks for all your help,

Jeff

 

 

 

 

From: M100 <m100-boun...@lists.bitchin100.com> On Behalf Of Fugu ME100
Sent: Wednesday, May 9, 2018 11:43 PM
To: m...@bitchin100.com
Subject: Re: [M100] SPAM-LOW: Re: New member - question on 'half' alive Model 
100

 

Does it only execute the loop once and get stuck for the first time at 2574H?   

 

The 49H in the data dump is most likely the C9H for the RET.  The next two byte 
are the return address from the stack.  They could be 0A57H, 0AD7H, 8A57, 8AD7H 
or  other permutations.  As this routine is writing to the RAM it is quite 
possible it is trashing the stack and destroying the return address - could be 
a bad RAM chip or decoder.  

 

There are at least two different versions of the M100 motherboard one has 
700mil RAM modules and the other 750mil.  Not sure if there are any ROM 
differences or other hardware differences. 

Re: [M100] SPAM-LOW: Re: New member - question on 'half' alive Model 100

[Josh Malone]

I would move on to swapping RAM and decoder chips. As I said before, the
decoder chip in my 102 failed last year some time; kept one of the RAM
chips from ever being enabled.

On Thu, May 10, 2018, 12:43 AM Fugu ME100  wrote:

> Does it only execute the loop once and get stuck for the first time at
> 2574H?
>
> The 49H in the data dump is most likely the C9H for the RET.  The next two
> byte are the return address from the stack.  They could be 0A57H, 0AD7H,
> 8A57, 8AD7H or  other permutations.  As this routine is writing to the RAM
> it is quite possible it is trashing the stack and destroying the return
> address - could be a bad RAM chip or decoder.
>
> There are at least two different versions of the M100 motherboard one has
> 700mil RAM modules and the other 750mil.  Not sure if there are any ROM
> differences or other hardware differences.
>

Re: [M100] SPAM-LOW: Re: New member - question on 'half' alive Model 100

[Fugu ME100]

Does it only execute the loop once and get stuck for the first time at 2574H?

The 49H in the data dump is most likely the C9H for the RET.  The next two byte 
are the return address from the stack.  They could be 0A57H, 0AD7H, 8A57, 8AD7H 
or  other permutations.  As this routine is writing to the RAM it is quite 
possible it is trashing the stack and destroying the return address - could be 
a bad RAM chip or decoder.

There are at least two different versions of the M100 motherboard one has 
700mil RAM modules and the other 750mil.  Not sure if there are any ROM 
differences or other hardware differences.

Re: [M100] SPAM-LOW: Re: New member - question on 'half' alive Model 100

[Jeffrey Birt]

I did do a capture of the data bus while holding CTRL-BRK. It does force it
to go to the cold boot routine and it goes to 7DF5H as shown below:

 

; ==

; Cold boot routine

; ==

7DE7H  (31H) LXI SP,F5E6H   ; Load the SP with Cold Boot location

7DEAH  (CDH) CALL 7EE1H ; Calculate physical RAM available

7DEDH  (06H) MVI B,90H  ; Prepare to copy 90H bytes of code to RAM

7DEFH  (11H) LXI D,F5F0H; Active system signature -- Warm vs Cold boot

7DF2H  (21H) LXI H,035AH; Initialization image loaded to F5F0H

->> Does this call  7DF5H  (CDH) CALL 2542H ; Move B bytes from M to
(DE) - hooks & signatures

7DF8H  (CDH) CALL 7EC6H ; Initialize RST 38H RAM vector table

7DFBH  (3EH) MVI A,0CH

7DFDH  (32H) STA F930H

 

It goes through copy all 144 (90H) bytes to RAM

; ==

; Move B bytes from M to (DE)

; ==

2542H  (7EH) MOV A,M

2543H  (12H) STAX D

2544H  (23H) INX H

2545H  (13H) INX D

2546H  (05H) DCR B

->> it gets to here 2547H  (C2H) JNZ 2542H  ; Move B bytes from M to
(DE)

254AH  (C9H) RET

 

It does not do the return it seems. Below is the last of the data bus
capture with source annotation added in by hand. Notice that the data values
on the bus are going up (more or less) one by one. Also recall I'm only
capturing the bits 0-6 as bit 7 is on the /RD* and used as a clock to decode
the parallel data in the logic analyzer software, this is not perfect, but
it is close enough to work.

 

0.10008687500,0x007E Source 2542H  (7EH) MOV A,M

0.10008975000,0x0012 Source 2543H  (12H) STAX D

0.10009262500,0x0023 Source 2544H  (23H) INX H

0.1000950,0x0013 Source 2545H  (13H) INX D

0.1000975,0x0005 Source 2546H  (05H) DCR B

0.10009912500,0x0042 C2 Source 2547H  (C2H) JNZ 2542H  ; Move B
bytes from M to (DE)

0.10010075000,0x0042

0.10010187500,0x0049 should this be 25H?? or is this the return?

0.1001035,0x0057

0.10010475000,0x000A

0.1001060,0x0057

0.10010762500,0x0058

0.10010925000,0x0059

0.10011087500,0x005A

0.1001125,0x005B

0.10011412500,0x005C

0.10011575000,0x005D

0.10011737500,0x005E

0.1001190,0x0020

0.10012025000,0x005F

0.10012187500,0x0060

0.1001235,0x0061

0.10012512500,0x0062

0.10012675000,0x0063

0.10012837500,0x0064

0.1001300,0x0065

 

 

Based on what I have seen before in the captured data when a RET is
encountered the next two bytes on the data bus is the return address, for
example:

 

0.0977375,0x0049 C9 Source 7F00H  (C9H) RET

0.09773912500,0x006D ED return address

0.09774037500,0x007D retrun address

 

But what I see above is garbage and I have repeated the capture 3 more times
and get the same result. Does this indicate a bad ROM? It seems odd that it
would read the ROM fine up until this point. It always stops here which is
right at the 100ms mark from the release of the reset button, not sure if
the time is important or not.

 

As luck would have it I found another Model 100 on the other side of
Missouri on Craig's list (from original owner with original box). And, it
works! Just got an email from him saying it was shipped out today and it
should be here by Saturday (only about 200 miles away). At the very least if
it is the same motherboard revision I can take the same capture on it and
compare, and perhaps even swap the ROM over.

 

Otherwise I am out of ideas at this point. Maybe with a good night's sleep
something else will come to me.

 

Jeff

 

 

Re: [M100] SPAM-LOW: Re: New member - question on 'half' alive Model 100

[Jeffrey Birt]

address used by system

0.09776562500,0x0040 C0

0.09776675000,0x007A FA

0.0977705,0x0049 C9 Source 7F00H (C9H) RET

0.09777212500,0x0068 RET address?

0.09777325000,0x007D RET address?

0.0977745,0x003A BA Source 7D68H (BAH) CMP D   ; Test if more or
less RAM than last boot-up

0.09777612500,0x0042 C2 Source 7D69H (C2H) JNZ 7DE7H   ; Jump to Cold
boot routine if RAM size changed

0.0975000,0x0067 E7

 ,0x007D was missing

0.0977790,0x004D CD Source 7D6CH (CDH) CALL F605H  ; Call RAM
routine to Detect Option ROM (copied to RAM by cold-boot)

0.0977815,0x0005 

0.09778262500,0x0076 F6

 

From: M100 <m100-boun...@lists.bitchin100.com> On Behalf Of Fugu ME100
Sent: Sunday, May 6, 2018 9:51 PM
To: m...@bitchin100.com
Subject: Re: [M100] SPAM-LOW: Re: New member - question on 'half' alive
Model 100

 

Yes quite possible a bad 81C55, M15 or keyboard would cause an issue.  Try
putting in one of the RAM modules see if that helps.  Unfortunately the
81C55 also controls the LCD.  

 

 

I should try and see if it is actually reading the ctrl-brk, what if there
is a problem with the keyboard or key decoding?  Looking at the source it
looks like it will trigger a cold boot when it senses a change in memory
size or a new option ROM being installed to.

Re: [M100] SPAM-LOW: Re: New member - question on 'half' alive Model 100

[Jeffrey Birt]

I just did an online chat with them and the person I was chatting with said he 
would check with an engineer and they would email me back.

Jeff

-Original Message-
From: M100 <m100-boun...@lists.bitchin100.com> On Behalf Of John Gardner
Sent: Monday, May 7, 2018 9:09 AM
To: m...@bitchin100.com
Subject: Re: [M100] SPAM-LOW: Re: New member - question on 'half' alive Model 
100

Jeff - You might try contacting Saleae directly.  They're pretty responsive,

the times I've had questions...

Re: [M100] SPAM-LOW: Re: New member - question on 'half' alive Model 100

[John Gardner]

Jeff - You might try contacting Saleae directly.  They're pretty responsive,

the times I've had questions...

Re: [M100] SPAM-LOW: Re: New member - question on 'half' alive Model 100

[Josh Malone]

I've never imported captures - only created them on my Rigol. Well, best of
luck!

On Mon, May 7, 2018 at 9:45 AM, Jeffrey Birt  wrote:

> I downloaded it sigrok/pulseview and exported my already captured data in
> both vcd and csv and with vcd it starts importing and crashes and with CSV
> it just hangs and crashes. I could not find any real usage documentation
> either, but that is typical of open source SW. When I get home, I might
> attempt to capture with it. It is worth investigating further.
>
>
>
> I also realized that I can invert the CLK and NAND that with the /RD* and
> should get a high going signal about ½ clock after /RD* goes low. That
> might let me use the Saleae SW which at least does not crash [image: ]
>
>
>
> Thanks,
>
> Jeff
>

Re: [M100] SPAM-LOW: Re: New member - question on 'half' alive Model 100

[Jeffrey Birt]

I downloaded it sigrok/pulseview and exported my already captured data in both 
vcd and csv and with vcd it starts importing and crashes and with CSV it just 
hangs and crashes. I could not find any real usage documentation either, but 
that is typical of open source SW. When I get home, I might attempt to capture 
with it. It is worth investigating further.

 

I also realized that I can invert the CLK and NAND that with the /RD* and 
should get a high going signal about ½ clock after /RD* goes low. That might 
let me use the Saleae SW which at least does not crash 

 

Thanks,

Jeff

 

From: M100 <m100-boun...@lists.bitchin100.com> On Behalf Of Josh Malone
Sent: Monday, May 7, 2018 5:34 AM
To: m...@bitchin100.com
Subject: Re: [M100] SPAM-LOW: Re: New member - question on 'half' alive Model 
100

 

The open source sigrok software supports the Saleae device. 

On Sun, May 6, 2018, 10:45 PM Jeffrey Birt <bir...@soigeneris.com 
<mailto:bir...@soigeneris.com> > wrote:

 

The silly LA software will only do parallel decoding based on the edge and it 
wont work properly with the /RD* signal alone as the clk source. The LA 
software’s built in ‘simple parallel’ decoder looks at the state of the other 
channels when the channel designated as clock changes state and gives you a 
dump of the hex value of the bus at that time. It is a bit frustrating really 
how limiting the software is.

Re: [M100] SPAM-LOW: Re: New member - question on 'half' alive Model 100

[Josh Malone]

The open source sigrok software supports the Saleae device.

On Sun, May 6, 2018, 10:45 PM Jeffrey Birt  wrote:

>
> The silly LA software will only do parallel decoding based on the edge and
> it wont work properly with the /RD* signal alone as the clk source. The LA
> software’s built in ‘simple parallel’ decoder looks at the state of the
> other channels when the channel designated as clock changes state and gives
> you a dump of the hex value of the bus at that time. It is a bit
> frustrating really how limiting the software is.
>

Re: [M100] SPAM-LOW: Re: New member - question on 'half' alive Model 100

[Fugu ME100]

Yes quite possible a bad 81C55, M15 or keyboard would cause an issue.  Try 
putting in one of the RAM modules see if that helps.  Unfortunately the 81C55 
also controls the LCD.



I should try and see if it is actually reading the ctrl-brk, what if there is a 
problem with the keyboard or key decoding?  Looking at the source it looks like 
it will trigger a cold boot when it senses a change in memory size or a new 
option ROM being installed to.

Re: [M100] SPAM-LOW: Re: New member - question on 'half' alive Model 100

[Jeffrey Birt]

I should try and see if it is actually reading the ctrl-brk, what if there
is a problem with the keyboard or key decoding?  Looking at the source it
looks like it will trigger a cold boot when it senses a change in memory
size or a new option ROM being installed to. 

 

The silly LA software will only do parallel decoding based on the edge and
it wont work properly with the /RD* signal alone as the clk source. The LA
software's built in 'simple parallel' decoder looks at the state of the
other channels when the channel designated as clock changes state and gives
you a dump of the hex value of the bus at that time. It is a bit frustrating
really how limiting the software is.

 

Thanks,

Jeff

 

From: M100 <m100-boun...@lists.bitchin100.com> On Behalf Of Fugu ME100
Sent: Sunday, May 6, 2018 9:18 PM
To: m...@bitchin100.com
Subject: Re: [M100] SPAM-LOW: Re: New member - question on 'half' alive
Model 100

 

Yes that is sequence.  

 

It does retain it but there is the potential for random data to be in the
RAM on each power cycle without the ctrl-break.  With the NiCd on board the
memory would be in the same state as setup during the clean boot.  

 

So far everything you have done looks good.  

 

  _  

From: M100 <m100-boun...@lists.bitchin100.com
<mailto:m100-boun...@lists.bitchin100.com> > on behalf of Jeffrey Birt
<bir...@soigeneris.com <mailto:bir...@soigeneris.com> >
Sent: Monday, May 7, 2018 03:12
To: m...@bitchin100.com <mailto:m...@bitchin100.com> 
Subject: Re: [M100] SPAM-LOW: Re: New member - question on 'half' alive
Model 100 

 

The NiCad only powers the RAM when there is no other power source available.
When you have AA's installed or a power adapter plugged in then that is what
is powering the memory, even when the power switch is off. My first tests
were done with the NiCad removed but AA's installed so the RAM was always
powered. It was rather inconvenient though thus I installed the temporary
battery and lifted one leg of the diode so it would not be trying to charge
the lithium battery.

 

I did try a CTRL-BRK + reset several times with no apparent difference in
results. Just to make sure I'm not misunderstanding this key sequence it is
the CTRL key in the low left, BRK on top row of function keys and the reset
button on the back?

 

Thanks again,

Jeff

 

From: M100 <m100-boun...@lists.bitchin100.com
<mailto:m100-boun...@lists.bitchin100.com> > On Behalf Of Fugu ME100
Sent: Sunday, May 6, 2018 8:40 PM
To: m...@bitchin100.com <mailto:m...@bitchin100.com> 
Subject: Re: [M100] SPAM-LOW: Re: New member - question on 'half' alive
Model 100

 

Agreed the lack of NiCd might be having more impact than expected on a
machine that expects data to be retained in RAM during power off. 

 

From: M100 <m100-boun...@lists.bitchin100.com
<mailto:m100-boun...@lists.bitchin100.com> > on behalf of "John R.
Hogerhuis" <jho...@pobox.com <mailto:jho...@pobox.com> >
Reply-To: <m...@bitchin100.com <mailto:m...@bitchin100.com> >
Date: Sunday, May 6, 2018 at 5:49 PM
To: <m...@bitchin100.com <mailto:m...@bitchin100.com> >
Subject: Re: [M100] SPAM-LOW: Re: New member - question on 'half' alive
Model 100

 

Now that you're applying a voltage in place of the removed NiCd have you
attempted a cold start? 

 

-- John.

Re: [M100] SPAM-LOW: Re: New member - question on 'half' alive Model 100

[Fugu ME100]

Yes that is sequence.


It does retain it but there is the potential for random data to be in the RAM 
on each power cycle without the ctrl-break.  With the NiCd on board the memory 
would be in the same state as setup during the clean boot.


So far everything you have done looks good.



From: M100 <m100-boun...@lists.bitchin100.com> on behalf of Jeffrey Birt 
<bir...@soigeneris.com>
Sent: Monday, May 7, 2018 03:12
To: m...@bitchin100.com
Subject: Re: [M100] SPAM-LOW: Re: New member - question on 'half' alive Model 
100


The NiCad only powers the RAM when there is no other power source available. 
When you have AA’s installed or a power adapter plugged in then that is what is 
powering the memory, even when the power switch is off. My first tests were 
done with the NiCad removed but AA’s installed so the RAM was always powered. 
It was rather inconvenient though thus I installed the temporary battery and 
lifted one leg of the diode so it would not be trying to charge the lithium 
battery.



I did try a CTRL-BRK + reset several times with no apparent difference in 
results. Just to make sure I’m not misunderstanding this key sequence it is the 
CTRL key in the low left, BRK on top row of function keys and the reset button 
on the back?



Thanks again,

Jeff



From: M100 <m100-boun...@lists.bitchin100.com> On Behalf Of Fugu ME100
Sent: Sunday, May 6, 2018 8:40 PM
To: m...@bitchin100.com
Subject: Re: [M100] SPAM-LOW: Re: New member - question on 'half' alive Model 
100



Agreed the lack of NiCd might be having more impact than expected on a machine 
that expects data to be retained in RAM during power off.



From: M100 
<m100-boun...@lists.bitchin100.com<mailto:m100-boun...@lists.bitchin100.com>> 
on behalf of "John R. Hogerhuis" <jho...@pobox.com<mailto:jho...@pobox.com>>
Reply-To: <m...@bitchin100.com<mailto:m...@bitchin100.com>>
Date: Sunday, May 6, 2018 at 5:49 PM
To: <m...@bitchin100.com<mailto:m...@bitchin100.com>>
Subject: Re: [M100] SPAM-LOW: Re: New member - question on 'half' alive Model 
100



Now that you're applying a voltage in place of the removed NiCd have you 
attempted a cold start?



-- John.

Re: [M100] SPAM-LOW: Re: New member - question on 'half' alive Model 100

[Jeffrey Birt]

The NiCad only powers the RAM when there is no other power source available.
When you have AA's installed or a power adapter plugged in then that is what
is powering the memory, even when the power switch is off. My first tests
were done with the NiCad removed but AA's installed so the RAM was always
powered. It was rather inconvenient though thus I installed the temporary
battery and lifted one leg of the diode so it would not be trying to charge
the lithium battery.

 

I did try a CTRL-BRK + reset several times with no apparent difference in
results. Just to make sure I'm not misunderstanding this key sequence it is
the CTRL key in the low left, BRK on top row of function keys and the reset
button on the back?

 

Thanks again,

Jeff

 

From: M100 <m100-boun...@lists.bitchin100.com> On Behalf Of Fugu ME100
Sent: Sunday, May 6, 2018 8:40 PM
To: m...@bitchin100.com
Subject: Re: [M100] SPAM-LOW: Re: New member - question on 'half' alive
Model 100

 

Agreed the lack of NiCd might be having more impact than expected on a
machine that expects data to be retained in RAM during power off. 

 

From: M100 <m100-boun...@lists.bitchin100.com
<mailto:m100-boun...@lists.bitchin100.com> > on behalf of "John R.
Hogerhuis" <jho...@pobox.com <mailto:jho...@pobox.com> >
Reply-To: <m...@bitchin100.com <mailto:m...@bitchin100.com> >
Date: Sunday, May 6, 2018 at 5:49 PM
To: <m...@bitchin100.com <mailto:m...@bitchin100.com> >
Subject: Re: [M100] SPAM-LOW: Re: New member - question on 'half' alive
Model 100

 

Now that you're applying a voltage in place of the removed NiCd have you
attempted a cold start? 

 

-- John.

Re: [M100] SPAM-LOW: Re: New member - question on 'half' alive Model 100

[Jeffrey Birt]

Thanks for the information about the data latching. I can reconfigure the LA
software to re-evaluate the captures I have already saved. 

 

Thanks again,

Jeff

 

From: M100 <m100-boun...@lists.bitchin100.com> On Behalf Of Fugu ME100
Sent: Sunday, May 6, 2018 8:39 PM
To: m...@bitchin100.com
Subject: Re: [M100] SPAM-LOW: Re: New member - question on 'half' alive
Model 100

 

It is the rising edge of RD that is used to latch the data into the 8085.
The ROM has from the falling edge to rising edge to deliver the data.  The
decoder is level sensitive not edge, so the rising edge will not only
disable the ROM but also latch in the ROM data.  That looks like it is
working as expected.  

 

The fact the CE is sort of random probably means there is random data in the
RAM,  it could be heading off to another RAM bank because of this after the
IO operations.   I just wonder if the missing NiCD is causing some problems.
The Model T family is somewhat unique for its day in that it expects the RAM
to retain the data between power cycles.  

Re: [M100] SPAM-LOW: Re: New member - question on 'half' alive Model 100

[Fugu ME100]

Agreed the lack of NiCd might be having more impact than expected on a machine 
that expects data to be retained in RAM during power off.

From: M100 
<m100-boun...@lists.bitchin100.com<mailto:m100-boun...@lists.bitchin100.com>> 
on behalf of "John R. Hogerhuis" <jho...@pobox.com<mailto:jho...@pobox.com>>
Reply-To: <m...@bitchin100.com<mailto:m...@bitchin100.com>>
Date: Sunday, May 6, 2018 at 5:49 PM
To: <m...@bitchin100.com<mailto:m...@bitchin100.com>>
Subject: Re: [M100] SPAM-LOW: Re: New member - question on 'half' alive Model 
100

Now that you're applying a voltage in place of the removed NiCd have you 
attempted a cold start?

-- John.

Re: [M100] SPAM-LOW: Re: New member - question on 'half' alive Model 100

[Fugu ME100]

It is the rising edge of RD that is used to latch the data into the 8085.  The 
ROM has from the falling edge to rising edge to deliver the data.  The decoder 
is level sensitive not edge, so the rising edge will not only disable the ROM 
but also latch in the ROM data.  That looks like it is working as expected.

The fact the CE is sort of random probably means there is random data in the 
RAM,  it could be heading off to another RAM bank because of this after the IO 
operations.   I just wonder if the missing NiCD is causing some problems.  The 
Model T family is somewhat unique for its day in that it expects the RAM to 
retain the data between power cycles.

Re: [M100] SPAM-LOW: Re: New member - question on 'half' alive Model 100

[John R. Hogerhuis]

Now that you're applying a voltage in place of the removed NiCd have you
attempted a cold start?

-- John.

Re: [M100] SPAM-LOW: Re: New member - question on 'half' alive Model 100

[John Gardner]

...the memory battery only protects the RAM when changing the AA’s...

That's why I recommend using Eneloops along with a supercap. The

very low self-discharge of the Eneloops could conceivably keep RAM

alive  the supercap charged for years.

 ...


On 5/6/18, Jeffrey Birt <bir...@soigeneris.com> wrote:
> I just peeked at the CE signals (on M4) for the RAM (only std RAM module is
> installed). All /CE signals toggle but it is not consistent from reset to
> reset. I guess I should have checked they were getting to the RAM as well.
> I
> looked and at the input signal sot M4 and they all toggle happily after
> reset as well.
>
>
>
> One thing that has been bothering me is the /RD* timing when reading from
> the ROM. Take a look at the screen capture from my LA here:
>
>
>
> https://1drv.ms/u/s!AtH4vpaZnzX7j8BykM3nU_zsOHq5iA
>
>
>
> Channel 7 here is the /RD* signal and is being used as a clock for the
> simple parallel decoder. Notice that as /RD* goes low the data line state
> is
> just changing. I would expect the data to already be valid here.well.
> Thinking again that would not make sense. The 80C85 would set /RD and would
> have to give the ROM a chance to preset the data to the data bus and then
> read it on the falling edge of the next clock. So, the issue I have here is
> that the simple parallel decoder is not looking at the falling edge of the
> next clock but rather the falling edge of the /RD*.
>
>
>
> O, back to the RAM. I do see all the /CE signals but as I said what I see
> is
> not consistent with each reset. Sometimes the M100 seems to keep running
> for
> just over a second before stopping and while it does this I see quite a lot
> of activity on the RAM /CE lines (some more than others).
>
>
>
> One other ting I did today was to lift the anode of D11 (diode which
> prevents the memory battery from back feeding the whole machine) and
> soldered in a 3.6V lithium primary cell. This did no good of course, but it
> will keep what ever content of RAM consistent at least. Once I get the M100
> running I'll take some current measurements so see what is drawn from the
> memory battery when the AA's are not present. The way it looks the memory
> battery only protects the RAM when changing the AA's. By knowing what is
> drawn from the battery I hope to size a suitable super cap replacement.
>
>
>
> I guess for further work I can check that the signals from M4 are getting
> to
> the RAM module and check that it seems to output data. After that I am
> stuck
> again. If I can resolve the issue with the LA software so it will decode
> the
> collected parallel data correctly I might have a better chance of knowing
> how far it gets in the boot process. I'm wondering if it gets to a point
> where it tried to talk to some I/O device which causes a problem.
>
>
>
> Thanks again for your help!
>
>
>
> Jeff
>
>
>
> From: M100 <m100-boun...@lists.bitchin100.com> On Behalf Of Fugu ME100
> Sent: Sunday, May 6, 2018 2:11 AM
> To: m...@bitchin100.com
> Subject: Re: [M100] SPAM-LOW: Re: New member - question on 'half' alive
> Model 100
>
>
>
> I would say your CPU looks good :)  The ROM seems to be working as are all
> the buffers and ROM decoding, the code is executing correctly to the point
> of failure.  The IO is still a possible source of error but as there are
> multiple accesses  it looks like it performs the operations correctly.
>
>
>
> Did you check the CE- on the RAM module?  Just after that IN op RAM
> accesses
> start to happen.  Without the NiCd the RAM might always start up with
> garbage which could cause some oddness.
>
>
>
> Interrupts are disabled so that should not cause problems.
>
>
>
> Looks like the RAM is the next target to investigate.
>
>
>
>

Re: [M100] SPAM-LOW: Re: New member - question on 'half' alive Model 100

[Jeffrey Birt]

I just peeked at the CE signals (on M4) for the RAM (only std RAM module is
installed). All /CE signals toggle but it is not consistent from reset to
reset. I guess I should have checked they were getting to the RAM as well. I
looked and at the input signal sot M4 and they all toggle happily after
reset as well.

 

One thing that has been bothering me is the /RD* timing when reading from
the ROM. Take a look at the screen capture from my LA here: 

 

https://1drv.ms/u/s!AtH4vpaZnzX7j8BykM3nU_zsOHq5iA 

 

Channel 7 here is the /RD* signal and is being used as a clock for the
simple parallel decoder. Notice that as /RD* goes low the data line state is
just changing. I would expect the data to already be valid here.well.
Thinking again that would not make sense. The 80C85 would set /RD and would
have to give the ROM a chance to preset the data to the data bus and then
read it on the falling edge of the next clock. So, the issue I have here is
that the simple parallel decoder is not looking at the falling edge of the
next clock but rather the falling edge of the /RD*.

 

O, back to the RAM. I do see all the /CE signals but as I said what I see is
not consistent with each reset. Sometimes the M100 seems to keep running for
just over a second before stopping and while it does this I see quite a lot
of activity on the RAM /CE lines (some more than others).

 

One other ting I did today was to lift the anode of D11 (diode which
prevents the memory battery from back feeding the whole machine) and
soldered in a 3.6V lithium primary cell. This did no good of course, but it
will keep what ever content of RAM consistent at least. Once I get the M100
running I'll take some current measurements so see what is drawn from the
memory battery when the AA's are not present. The way it looks the memory
battery only protects the RAM when changing the AA's. By knowing what is
drawn from the battery I hope to size a suitable super cap replacement. 

 

I guess for further work I can check that the signals from M4 are getting to
the RAM module and check that it seems to output data. After that I am stuck
again. If I can resolve the issue with the LA software so it will decode the
collected parallel data correctly I might have a better chance of knowing
how far it gets in the boot process. I'm wondering if it gets to a point
where it tried to talk to some I/O device which causes a problem.

 

Thanks again for your help!

 

Jeff

 

From: M100 <m100-boun...@lists.bitchin100.com> On Behalf Of Fugu ME100
Sent: Sunday, May 6, 2018 2:11 AM
To: m...@bitchin100.com
Subject: Re: [M100] SPAM-LOW: Re: New member - question on 'half' alive
Model 100

 

I would say your CPU looks good :)  The ROM seems to be working as are all
the buffers and ROM decoding, the code is executing correctly to the point
of failure.  The IO is still a possible source of error but as there are
multiple accesses  it looks like it performs the operations correctly. 

 

Did you check the CE- on the RAM module?  Just after that IN op RAM accesses
start to happen.  Without the NiCd the RAM might always start up with
garbage which could cause some oddness.  

 

Interrupts are disabled so that should not cause problems.  

 

Looks like the RAM is the next target to investigate.  

 

Re: [M100] SPAM-LOW: Re: New member - question on 'half' alive Model 100

[Fugu ME100]

I would say your CPU looks good :)  The ROM seems to be working as are all the 
buffers and ROM decoding, the code is executing correctly to the point of 
failure.  The IO is still a possible source of error but as there are multiple 
accesses  it looks like it performs the operations correctly.

Did you check the CE- on the RAM module?  Just after that IN op RAM accesses 
start to happen.  Without the NiCd the RAM might always start up with garbage 
which could cause some oddness.

Interrupts are disabled so that should not cause problems.

Looks like the RAM is the next target to investigate.

From: M100 
<m100-boun...@lists.bitchin100.com<mailto:m100-boun...@lists.bitchin100.com>> 
on behalf of Jeffrey Birt <bir...@soigeneris.com<mailto:bir...@soigeneris.com>>
Reply-To: <m...@bitchin100.com<mailto:m...@bitchin100.com>>
Date: Saturday, May 5, 2018 at 4:02 PM
To: <m...@bitchin100.com<mailto:m...@bitchin100.com>>
Subject: Re: [M100] SPAM-LOW: Re: New member - question on 'half' alive Model 
100

Well, I know more…but I’m not sure what I know. I was able to capture the data 
bus (well the first 7 bits, used my 8th channel on the /RD* for the CLK input). 
I saved the output as a text file and taking account for the msb always being 
zero I was able to trace program execution to around here

7D4CH  (DBH) IN E8H ; Scan Keyboard to test for CTRL-BREAK (cold boot 
indicator)

where is goes wonky. I then put the LA on the IO/M line and was able to see it 
go high when reset held in and then go low, 5 short blips (for 5 in/out 
commands including the line above.) Then it is low for a short while and goes 
back high and stays there.

By this point I’m bleary eyed from staring at the screen so much. One other bit 
of strangeness to note is that the modem relay was clicking on/off with the 
reset for a while and by the time I got a probe on M16-13 (Y2) it had quit.

As I recall I did the same tests with and without the LCD/KB connected. I just 
noticed now that One gate of M20is shown down by the LCD connector in the 
schematic. It is buffering the output of a gate on M17 which is connected to 
the E pin of the LCD. I’m not sure what this is doing. Time for more research.

I welcome any thoughts.

Thanks,
Jeff

Re: [M100] SPAM-LOW: Re: New member - question on 'half' alive Model 100

[Jeffrey Birt]

Well, I know more.but I'm not sure what I know. I was able to capture the
data bus (well the first 7 bits, used my 8th channel on the /RD* for the CLK
input). I saved the output as a text file and taking account for the msb
always being zero I was able to trace program execution to around here

 

7D4CH  (DBH) IN E8H ; Scan Keyboard to test for CTRL-BREAK (cold
boot indicator)

 

where is goes wonky. I then put the LA on the IO/M line and was able to see
it go high when reset held in and then go low, 5 short blips (for 5 in/out
commands including the line above.) Then it is low for a short while and
goes back high and stays there.

 

By this point I'm bleary eyed from staring at the screen so much. One other
bit of strangeness to note is that the modem relay was clicking on/off with
the reset for a while and by the time I got a probe on M16-13 (Y2) it had
quit. 

 

As I recall I did the same tests with and without the LCD/KB connected. I
just noticed now that One gate of M20is shown down by the LCD connector in
the schematic. It is buffering the output of a gate on M17 which is
connected to the E pin of the LCD. I'm not sure what this is doing. Time for
more research.

 

I welcome any thoughts.

 

Thanks,

Jeff

 

From: M100 <m100-boun...@lists.bitchin100.com> On Behalf Of Fugu ME100
Sent: Friday, May 4, 2018 9:39 AM
To: m...@bitchin100.com
Subject: Re: [M100] SPAM-LOW: Re: New member - question on 'half' alive
Model 100

 

If the 80C85 is seeing 00H (NOP) it could quite easily run without
generating an IO/M- line high.  Although with NOP it should just keep going
forever with incrementing addresses.  

 

If there was contention on the RD Cycle one or more of the data lines would
look very bad, possibly sitting in between the threshold levels depending on
who won the fight. 

 

From: M100 <m100-boun...@lists.bitchin100.com
<mailto:m100-boun...@lists.bitchin100.com> > on behalf of Jeffrey Birt
<bir...@soigeneris.com <mailto:bir...@soigeneris.com> >
Reply-To: <m...@bitchin100.com <mailto:m...@bitchin100.com> >
Date: Friday, May 4, 2018 at 7:20 AM
To: <m...@bitchin100.com <mailto:m...@bitchin100.com> >
Subject: Re: [M100] SPAM-LOW: Re: New member - question on 'half' alive
Model 100

 

Re: [M100] SPAM-LOW: Re: New member - question on 'half' alive Model 100

[Fugu ME100]

If the 80C85 is seeing 00H (NOP) it could quite easily run without generating 
an IO/M- line high.  Although with NOP it should just keep going forever with 
incrementing addresses.

If there was contention on the RD Cycle one or more of the data lines would 
look very bad, possibly sitting in between the threshold levels depending on 
who won the fight.

From: M100 
<m100-boun...@lists.bitchin100.com<mailto:m100-boun...@lists.bitchin100.com>> 
on behalf of Jeffrey Birt <bir...@soigeneris.com<mailto:bir...@soigeneris.com>>
Reply-To: <m...@bitchin100.com<mailto:m...@bitchin100.com>>
Date: Friday, May 4, 2018 at 7:20 AM
To: <m...@bitchin100.com<mailto:m...@bitchin100.com>>
Subject: Re: [M100] SPAM-LOW: Re: New member - question on 'half' alive Model 
100

Re: [M100] SPAM-LOW: Re: New member - question on 'half' alive Model 100

[Jeffrey Birt]

Answering in line below. 

 

Thanks for your help.

Jeff

 

From: M100 <m100-boun...@lists.bitchin100.com> On Behalf Of Fugu ME100
Sent: Friday, May 4, 2018 8:38 AM
To: m...@bitchin100.com
Subject: Re: [M100] SPAM-LOW: Re: New member - question on 'half' alive
Model 100

 

>>Are the RD*, WR* and IO/M* signals OK?  They go through a buffer M20
before being used.  The ROM CS- only relies on A15, STROM- & IO/M-, if IO/M-
is stuck at 0, then CS would work, but the I/O ports would not be accessed.
Holding the 80C85 is reset should allow the outputs of M20 to go high, the
inputs have pull-ups. 

 

The RD*, WR* and IO/M* all change states. But, IO/M only toggles states at
reset. I do believe it is stuck low. 

 

 

>>If the '245 M2 data bus buffer direction is not changed by RD* then the
processor might be reading garbage from the data bus.  All of the Address
Decoding is done on the upper 8 Address bits so the chip selects do not
depend on AD0-AD7 buffers. 

 

I know that the /RD* signal is getting to M2. I was seeing a bit of the same
'oddness' which corresponded with the /ALE so I'm guessing that is normal.
I'm going to have to think some about how to determine of the direction is
being correctly changed. I'm guessing that I would be seeing much more
'oddness' if it were not. Maybe looking at the /RD* and AD0 (on both sides)
would work. I'm guessing that if I don't see the same signal on both sides
of one A/D line that would indicate bus contention?

 

>>On boot there is a 10,000 cycle loop (approx 100ms delay) before there is
I/O activity setting up the 81C55.  This might be the 'The ROM /CS is also
toggling for a while after reset' state you are observing, any idea how long
the activity lasts?  After that the IO/M- line should start to toggle as the
81C55 is set up and the keyboard read.   

 

I'll attempt to determine how long the activity lasts. On random occasions
it will 'run' after reset but the IO/M never toggles. It seems off that even
if it is running garbage code that the IO/M would never toggle. It does
change states on reset so it is not shorted low.

 

 

>>The first RAM access occurs after all the I/O is configured and the
keyboard scanned.  If you see no IO/M* activity after the short delay then
the processor could be reading invalid data and just not executing any
IN/OUT operations.There could be a few reasons for this:  faulty buffer
M20, faulty M2, address conflict another CS/CE line could be low at the same
time, bad ROM socket or failing ROM.  Check that all the CE- lines (M4 only
one RAM module present)  are high and none are low, also check that none of
the I/O port enables (M16) are low during the ROM CS-.   Might want to make
sure these chips also have VDD present.

 

>>I would read the ROM in situ.  If you can clip onto M2 it should be
possible to check that the 80C85 is really getting the data from the ROM.   

 

I was checking the A/D line (well all line) on the ROM by touching the tops
of the pins. It seems all signals are getting through. I will check 16
w.r.t. the ROM CS as well happened to find my old 'DIP clip' the other day.
I think there is enough room to get it clipped on M2. That SIP resistor is
pretty close though.

 

 

>>It should be possible to get this down to a single failed IC or track
without pulling chips :-D

 

That is my goal! It is fun to learn a bit about the architecture while
troubleshooting. Thanks again for your help.

Re: [M100] SPAM-LOW: Re: New member - question on 'half' alive Model 100

[Fugu ME100]

Are the RD*, WR* and IO/M* signals OK?  They go through a buffer M20 before 
being used.  The ROM CS- only relies on A15, STROM- & IO/M-, if IO/M- is stuck 
at 0, then CS would work, but the I/O ports would not be accessed.  Holding the 
80C85 is reset should allow the outputs of M20 to go high, the inputs have 
pull-ups.

If the ‘245 M2 data bus buffer direction is not changed by RD* then the 
processor might be reading garbage from the data bus.  All of the Address 
Decoding is done on the upper 8 Address bits so the chip selects do not depend 
on AD0-AD7 buffers.

On boot there is a 10,000 cycle loop (approx 100ms delay) before there is I/O 
activity setting up the 81C55.  This might be the 'The ROM /CS is also toggling 
for a while after reset’ state you are observing, any idea how long the 
activity lasts?  After that the IO/M- line should start to toggle as the 81C55 
is set up and the keyboard read.

The first RAM access occurs after all the I/O is configured and the keyboard 
scanned.  If you see no IO/M* activity after the short delay then the processor 
could be reading invalid data and just not executing any IN/OUT operations.
There could be a few reasons for this:  faulty buffer M20, faulty M2, address 
conflict another CS/CE line could be low at the same time, bad ROM socket or 
failing ROM.  Check that all the CE– lines (M4 only one RAM module present)  
are high and none are low, also check that none of the I/O port enables (M16) 
are low during the ROM CS-.   Might want to make sure these chips also have VDD 
present.

I would read the ROM in situ.  If you can clip onto M2 it should be possible to 
check that the 80C85 is really getting the data from the ROM.

It should be possible to get this down to a single failed IC or track without 
pulling chips :-D

From: M100 
<m100-boun...@lists.bitchin100.com<mailto:m100-boun...@lists.bitchin100.com>> 
on behalf of Jeffrey Birt <bir...@soigeneris.com<mailto:bir...@soigeneris.com>>
Reply-To: <m...@bitchin100.com<mailto:m...@bitchin100.com>>
Date: Friday, May 4, 2018 at 5:21 AM
To: <m...@bitchin100.com<mailto:m...@bitchin100.com>>
Subject: Re: [M100] SPAM-LOW: Re: New member - question on 'half' alive Model 
100

I did find some time last evening to investigate my sick M100 further. All A/D 
signals seem to be propagating through the buffers/latches properly and make 
their way to they ROM. The ROM /CS is also toggling for a while after reset is 
pressed so it does seem it is being accessed. It just occurred to me though 
that I failed to check the various RAM /CExx bank select signals.

I guess after checking out the RAM /CExx signals I could get out my little 
logic analyzer and monitor the data buss after a reset and see if the ROM seems 
to be returning the correct data, or I’ll just build an adapter, so I can read 
it in. I also just recalled that my little eprom programmer can test many 74xx 
style logic chips so if I run completely out of ideas I can do a semi-shot gun 
approach and pull the glue logic chips and test them.

Jeff

Re: [M100] SPAM-LOW: Re: New member - question on 'half' alive Model 100

[Jeffrey Birt]

I did find some time last evening to investigate my sick M100 further. All A/D 
signals seem to be propagating through the buffers/latches properly and make 
their way to they ROM. The ROM /CS is also toggling for a while after reset is 
pressed so it does seem it is being accessed. It just occurred to me though 
that I failed to check the various RAM /CExx bank select signals. 

 

I guess after checking out the RAM /CExx signals I could get out my little 
logic analyzer and monitor the data buss after a reset and see if the ROM seems 
to be returning the correct data, or I’ll just build an adapter, so I can read 
it in. I also just recalled that my little eprom programmer can test many 74xx 
style logic chips so if I run completely out of ideas I can do a semi-shot gun 
approach and pull the glue logic chips and test them.

 

Jeff

 

From: M100 <m100-boun...@lists.bitchin100.com> On Behalf Of Fugu ME100
Sent: Thursday, May 3, 2018 10:29 AM
To: m...@bitchin100.com
Subject: Re: [M100] SPAM-LOW: Re: New member - question on 'half' alive Model 
100

 

Have you been able to replace the NiCd?  

 

Another thought would be to check the ROM socket is really making contact with 
the ROM.  Over the years the spring contacts might not be so good.  You could 
try plugging the ROM into a turned pin socket and then into the sock just to 
make sure there is a good contact.   

 

Re: [M100] SPAM-LOW: Re: New member - question on 'half' alive Model 100

[Josh Malone]

I'd say totally on-topic, but probably worthy of a fresh thread :)

I'm all for test harnesses. If I can help with dev/test/etc lemme know!

-Josh

On Thu, May 3, 2018 at 11:54 AM, Fugu ME100  wrote:

> A little bit off topic here…. With quite a few people trying to resurrect
> dead Model T’s I was wondering if this idea:
> http://blog.tynemouthsoftware.co.uk/2016/04/pet-exerciser-
> upcoming-project-preview.html
>
> might be of interest to other Model T owners?
>
> Of course it would have to be developed for the 80C85 which is not
> socketed on the Model T, but the HOLD pin is available as are 40pin test
> clips.  It could run diagnostics for a voltage check, Keyboard, LCD, RAM
> and ROM to check everything is working and potentially isolate the problem.
>   If it was based on the Arduino UNO platform (perhaps an 80C85 Shield?)
> then it should be quite simple to put together the hardware and software
> development would be well supported for those that wanted to tinker with
> the diagnostics.
>
> I have a T102 that so far is resisting being debugged, I suspect it is a
> cracked track (or two) so I have some interest :)
>
> Apologies if this is not an appropriate discussion topic for the list.
>

Re: [M100] SPAM-LOW: Re: New member - question on 'half' alive Model 100

[Fugu ME100]

A little bit off topic here…. With quite a few people trying to resurrect dead 
Model T’s I was wondering if this idea:
http://blog.tynemouthsoftware.co.uk/2016/04/pet-exerciser-upcoming-project-preview.html

might be of interest to other Model T owners?

Of course it would have to be developed for the 80C85 which is not socketed on 
the Model T, but the HOLD pin is available as are 40pin test clips.  It could 
run diagnostics for a voltage check, Keyboard, LCD, RAM and ROM to check 
everything is working and potentially isolate the problem.   If it was based on 
the Arduino UNO platform (perhaps an 80C85 Shield?) then it should be quite 
simple to put together the hardware and software development would be well 
supported for those that wanted to tinker with the diagnostics.

I have a T102 that so far is resisting being debugged, I suspect it is a 
cracked track (or two) so I have some interest :)

Apologies if this is not an appropriate discussion topic for the list.

From: M100 
<m100-boun...@lists.bitchin100.com<mailto:m100-boun...@lists.bitchin100.com>> 
on behalf of Jeffrey Birt <bir...@soigeneris.com<mailto:bir...@soigeneris.com>>
Reply-To: <m...@bitchin100.com<mailto:m...@bitchin100.com>>
Date: Thursday, May 3, 2018 at 7:17 AM
To: <m...@bitchin100.com<mailto:m...@bitchin100.com>>
Subject: Re: [M100] SPAM-LOW: Re: New member - question on 'half' alive Model 
100

Thanks for the info about the ‘oddness’ to both you and another poster I now 
have some more insight into what I am looking at and for. I probably won’t have 
a chance to work on it again until tomorrow evening.

I did find a ROM disassembly on Kevin Petit’s folks at the club100 website. 
Looking at it now whilst minding a little CNC mill making a calibration fixture 
for a microwave sensor (very slow and boring but it has to be done  )

I’ll do some more investigation and probably be back with more questions.

Thanks again everyone!
Jeff

Re: [M100] SPAM-LOW: Re: New member - question on 'half' alive Model 100

[Fugu ME100]

Have you been able to replace the NiCd?

Another thought would be to check the ROM socket is really making contact with 
the ROM.  Over the years the spring contacts might not be so good.  You could 
try plugging the ROM into a turned pin socket and then into the sock just to 
make sure there is a good contact.

From: M100 
<m100-boun...@lists.bitchin100.com<mailto:m100-boun...@lists.bitchin100.com>> 
on behalf of Jeffrey Birt <bir...@soigeneris.com<mailto:bir...@soigeneris.com>>
Reply-To: <m...@bitchin100.com<mailto:m...@bitchin100.com>>
Date: Thursday, May 3, 2018 at 7:17 AM
To: <m...@bitchin100.com<mailto:m...@bitchin100.com>>
Subject: Re: [M100] SPAM-LOW: Re: New member - question on 'half' alive Model 
100

Thanks for the info about the ‘oddness’ to both you and another poster I now 
have some more insight into what I am looking at and for. I probably won’t have 
a chance to work on it again until tomorrow evening.

I did find a ROM disassembly on Kevin Petit’s folks at the club100 website. 
Looking at it now whilst minding a little CNC mill making a calibration fixture 
for a microwave sensor (very slow and boring but it has to be done  )

I’ll do some more investigation and probably be back with more questions.

Thanks again everyone!
Jeff

Re: [M100] SPAM-LOW: Re: New member - question on 'half' alive Model 100

[Fugu ME100]

The ‘oddness’ is due to the buffers tri-stating or entering a high-impedance 
state,  as the data-sheet calls it, when ALE goes high.  If you put up both the 
address and ALE trace they should match.  If the inputs and outputs of the 
buffers look good then the next step would to check the address decoders to 
make sure the ROM, SRAM and IO ports are being selected.  The ROM CS should go 
low immediately after the reset goes high to fetch the 1st instruction from 
H.  For the M100 the first instruction is a JMP 7D33H - the boot routines.

There is an M100 ROM disassembly somewhere but I cannot find the link to it at 
the moment.  That I think would help a lot with the debug process.

Not sure what type of rosin they used for the soldering process but I have 
being using 90% CVS isopropyl alcohol to remove it without much problem.

From: M100 
<m100-boun...@lists.bitchin100.com<mailto:m100-boun...@lists.bitchin100.com>> 
on behalf of Jeffrey Birt <bir...@soigeneris.com<mailto:bir...@soigeneris.com>>
Reply-To: <m...@bitchin100.com<mailto:m...@bitchin100.com>>
Date: Wednesday, May 2, 2018 at 3:25 AM
To: <m...@bitchin100.com<mailto:m...@bitchin100.com>>
Subject: Re: [M100] SPAM-LOW: Re: New member - question on 'half' alive Model 
100

Thanks for the response concerning the 40H parts.

I took some time this evening to very carefully look at all the signals on the 
80C55. I thought I saw some odd waveforms and after setting the scope to single 
shot mode I did indeed see some oddness on AD0 through AD7.

Take a look: 
https://1drv.ms/u/s!AtH4vpaZnzX7j8A29GFkjLbQlWpLUA<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2F1drv.ms%2Fu%2Fs!AtH4vpaZnzX7j8A29GFkjLbQlWpLUA=02%7C01%7C%7Cc9a81e6722d9409f239208d5afd40610%7C84df9e7fe9f640afb435%7C1%7C0%7C636608247519969338=79DwUiP8IQhmbwYzZCf0tIcl6bSU0GRMz381YCR72MQ%3D=0>

I checked that it is the same at the 80C55 side of M1 and M2 while the ‘other’ 
side of M1 and M2 has nice square waves. I then checked that the control 
signals ALE and /RD appear to be correct and they do. This leads me to believe 
that one or both of M1/M2 are defective. I believe I have a 74HC version of 
these on hand.

I very much appreciate being steered in the right direction 

On an unrelated note: what kind of evil flux did they use on these boards. I 
tried to clean the flux off of my capacitor installation and wound up taking 
30+ minutes to flush the back side of the PCB with alcohol several times to get 
the yellow tinged flux off. It wanted to form a nasty white chalk type coating.

Thank again,
Jeff

Re: [M100] SPAM-LOW: Re: New member - question on 'half' alive Model 100

[Francesco Messineo]

On Wed, May 2, 2018 at 4:25 AM, Jeffrey Birt  wrote:
>
> Thanks for the response concerning the 40H parts.
>
>
>
> I took some time this evening to very carefully look at all the signals on 
> the 80C55. I thought I saw some odd waveforms and after setting the scope to 
> single shot mode I did indeed see some oddness on AD0 through AD7.
>
>
>
> Take a look: https://1drv.ms/u/s!AtH4vpaZnzX7j8A29GFkjLbQlWpLUA


those aren't necessarily bad signals if they happen for example when a
bus transceiver is disabled and the signals start to float to a
mid-voltage value. Also you see some spikes on trasceivers signals
when they switch direction.


Frank

Re: [M100] SPAM-LOW: Re: New member - question on 'half' alive Model 100

[Brian White]

It's not clear from that page but the AD0-AD15 pics are from the 80C55
itself, and the logic analyser shots are from the ribbon cable to the lcd.
I have one m100 that doesn't run that I was poking at several weeks ago. It
seems to be in the lcd board. IE, the lcd board atually prevents the rest
of the machine from running, not merely that it fails to work as a display.
If I connect a good lcd board to the motherboard, it runs. If I connect a
good motherboard to the bad lcd, I don't get a beep from blindly entering
basic and typing a beep command.

I guess the ramps I'm seeing are smaller, so that's a difference.

-- 
bkw


On Tue, May 1, 2018 at 10:50 PM, Brian White  wrote:

> I see those same funny ramps and someone here said it was normal. I see
> them on both working and non-working M100's
> https://photos.app.goo.gl/vcTg4yUhvjXKBxeh1
>
>


-- 
bkw

Re: [M100] SPAM-LOW: Re: New member - question on 'half' alive Model 100

[Brian White]

I see those same funny ramps and someone here said it was normal. I see
them on both working and non-working M100's
https://photos.app.goo.gl/vcTg4yUhvjXKBxeh1

Re: [M100] SPAM-LOW: Re: New member - question on 'half' alive Model 100

[Jeffrey Birt]

Thanks for the response concerning the 40H parts.

 

I took some time this evening to very carefully look at all the signals on the 
80C55. I thought I saw some odd waveforms and after setting the scope to single 
shot mode I did indeed see some oddness on AD0 through AD7. 

 

Take a look: https://1drv.ms/u/s!AtH4vpaZnzX7j8A29GFkjLbQlWpLUA

 

I checked that it is the same at the 80C55 side of M1 and M2 while the ‘other’ 
side of M1 and M2 has nice square waves. I then checked that the control 
signals ALE and /RD appear to be correct and they do. This leads me to believe 
that one or both of M1/M2 are defective. I believe I have a 74HC version of 
these on hand.

 

I very much appreciate being steered in the right direction 

 

On an unrelated note: what kind of evil flux did they use on these boards. I 
tried to clean the flux off of my capacitor installation and wound up taking 
30+ minutes to flush the back side of the PCB with alcohol several times to get 
the yellow tinged flux off. It wanted to form a nasty white chalk type coating. 

 

Thank again,

Jeff

 

From: M100 <m100-boun...@lists.bitchin100.com> On Behalf Of Josh Malone
Sent: Tuesday, May 1, 2018 5:46 PM
To: m...@bitchin100.com
Subject: Re: [M100] SPAM-LOW: Re: New member - question on 'half' alive Model 
100

 

I replaced my 40H decoder with a 7x part and have had no issues. The address 
decoder circuit failed in my 102 and it turned out to be the demultiplexer / 
decoder.

 

On Tue, May 1, 2018, 4:57 PM Jeffrey Birt <bir...@soigeneris.com 
<mailto:bir...@soigeneris.com> > wrote:

Possible silly question…I have been able to find no data on the 40H244, 40H245, 
40H373 part numbers. Given their function and pinout I’m guessing that a 74HC 
part would be an acceptable substitute?

 

Thanks again,

Jeff

 

From: M100 <m100-boun...@lists.bitchin100.com 
<mailto:m100-boun...@lists.bitchin100.com> > On Behalf Of Fugu ME100
Sent: Tuesday, May 1, 2018 9:26 AM
To: m...@bitchin100.com <mailto:m...@bitchin100.com> 
Subject: Re: [M100] SPAM-LOW: Re: New member - question on 'half' alive Model 
100

 

If checking the buffers etc you should see the I0/M line toggle quite quickly 
after power on and of course the ALE line.  If it does not then it is not even 
starting a proper boot, I feel your processor is OK they are quite robust and 
well protected by all the buffers.  

 

I think you mentioned a click on power-on this could be the remote relay 
clicking on, it is controlled by M14, this too is a symptom of an improper boot 
sequence.  This part also controls access to the ROM, if it does not initialize 
correctly the ROM might never be accessed properly.

 

The chip ids look good to start.   You may also want to check continuity to the 
ROM and RAM chips just to make sure there are no cracks in the Address and Data 
PCB tracks.  The quality of the M100 boards is quite low.  

Re: [M100] SPAM-LOW: Re: New member - question on 'half' alive Model 100

[Josh Malone]

I replaced my 40H decoder with a 7x part and have had no issues. The
address decoder circuit failed in my 102 and it turned out to be the
demultiplexer / decoder.

On Tue, May 1, 2018, 4:57 PM Jeffrey Birt <bir...@soigeneris.com> wrote:

> Possible silly question…I have been able to find no data on the 40H244,
> 40H245, 40H373 part numbers. Given their function and pinout I’m guessing
> that a 74HC part would be an acceptable substitute?
>
>
>
> Thanks again,
>
> Jeff
>
>
>
> *From:* M100 <m100-boun...@lists.bitchin100.com> *On Behalf Of *Fugu ME100
> *Sent:* Tuesday, May 1, 2018 9:26 AM
> *To:* m...@bitchin100.com
> *Subject:* Re: [M100] SPAM-LOW: Re: New member - question on 'half' alive
> Model 100
>
>
>
> If checking the buffers etc you should see the I0/M line toggle quite
> quickly after power on and of course the ALE line.  If it does not then it
> is not even starting a proper boot, I feel your processor is OK they are
> quite robust and well protected by all the buffers.
>
>
>
> I think you mentioned a click on power-on this could be the remote relay
> clicking on, it is controlled by M14, this too is a symptom of an improper
> boot sequence.  This part also controls access to the ROM, if it does not
> initialize correctly the ROM might never be accessed properly.
>
>
>
> The chip ids look good to start.   You may also want to check continuity
> to the ROM and RAM chips just to make sure there are no cracks in the
> Address and Data PCB tracks.  The quality of the M100 boards is quite low.
>

Re: [M100] SPAM-LOW: Re: New member - question on 'half' alive Model 100

[Jeffrey Birt]

Possible silly question.I have been able to find no data on the 40H244,
40H245, 40H373 part numbers. Given their function and pinout I'm guessing
that a 74HC part would be an acceptable substitute?

 

Thanks again,

Jeff

 

From: M100 <m100-boun...@lists.bitchin100.com> On Behalf Of Fugu ME100
Sent: Tuesday, May 1, 2018 9:26 AM
To: m...@bitchin100.com
Subject: Re: [M100] SPAM-LOW: Re: New member - question on 'half' alive
Model 100

 

If checking the buffers etc you should see the I0/M line toggle quite
quickly after power on and of course the ALE line.  If it does not then it
is not even starting a proper boot, I feel your processor is OK they are
quite robust and well protected by all the buffers.  

 

I think you mentioned a click on power-on this could be the remote relay
clicking on, it is controlled by M14, this too is a symptom of an improper
boot sequence.  This part also controls access to the ROM, if it does not
initialize correctly the ROM might never be accessed properly.

 

The chip ids look good to start.   You may also want to check continuity to
the ROM and RAM chips just to make sure there are no cracks in the Address
and Data PCB tracks.  The quality of the M100 boards is quite low.  

Re: [M100] SPAM-LOW: Re: New member - question on 'half' alive Model 100

[Fugu ME100]

If checking the buffers etc you should see the I0/M line toggle quite quickly 
after power on and of course the ALE line.  If it does not then it is not even 
starting a proper boot, I feel your processor is OK they are quite robust and 
well protected by all the buffers.

I think you mentioned a click on power-on this could be the remote relay 
clicking on, it is controlled by M14, this too is a symptom of an improper boot 
sequence.  This part also controls access to the ROM, if it does not initialize 
correctly the ROM might never be accessed properly.

The chip ids look good to start.   You may also want to check continuity to the 
ROM and RAM chips just to make sure there are no cracks in the Address and Data 
PCB tracks.  The quality of the M100 boards is quite low.

From: M100 
<m100-boun...@lists.bitchin100.com<mailto:m100-boun...@lists.bitchin100.com>> 
on behalf of Jeffrey Birt <bir...@soigeneris.com<mailto:bir...@soigeneris.com>>
Reply-To: <m...@bitchin100.com<mailto:m...@bitchin100.com>>
Date: Tuesday, May 1, 2018 at 2:57 PM
To: <m...@bitchin100.com<mailto:m...@bitchin100.com>>
Subject: Re: [M100] SPAM-LOW: Re: New member - question on 'half' alive Model 
100

Thanks that was very helpful. I’ll double check the A/D lines and all other 
pins on the 80C85 but as I recall they were all toggling nicely in the 0-5V 
range. I’m having to relearn how 8080’ish systems work. It is one of the first 
processors I learned on (well Z80 on a TS 1000) and then I got into the 6502 
and really went to town.

I’ll also try to determine if the AD buffers / mux are functioning properly. 
Unless I misread the schematic M1, M2 and M21 are the primary culprits. I also 
just noticed that the AL/E line runs though a buffer so I need to check that 
signal on both sides of the buffer as well.

Thanks again,
Jeff

Re: [M100] SPAM-LOW: Re: New member - question on 'half' alive Model 100

[Jeffrey Birt]

Thanks that was very helpful. I'll double check the A/D lines and all other
pins on the 80C85 but as I recall they were all toggling nicely in the 0-5V
range. I'm having to relearn how 8080'ish systems work. It is one of the
first processors I learned on (well Z80 on a TS 1000) and then I got into
the 6502 and really went to town.

 

I'll also try to determine if the AD buffers / mux are functioning properly.
Unless I misread the schematic M1, M2 and M21 are the primary culprits. I
also just noticed that the AL/E line runs though a buffer so I need to check
that signal on both sides of the buffer as well.

 

Thanks again,

Jeff

 

From: M100 <m100-boun...@lists.bitchin100.com> On Behalf Of Fugu ME100
Sent: Tuesday, May 1, 2018 5:16 AM
To: m...@bitchin100.com
Subject: Re: [M100] SPAM-LOW: Re: New member - question on 'half' alive
Model 100

 

On boot up one of the first things the M100 does is to configure the PIO
(81C55) in order to scan the keyboard for the ctrl-break.The PIO and LCD
all use port addresses, there should be a lot of activity on the IO/M pin on
a normal boot!  Indeed within about 10 instructions, for a normal boot, the
IO/M pin should be toggling quite a lot :) 

 

However if the address or data lines are failing then it might just execute
code that does not include any IO/M based operations.   For example, if the
mux is broken then the reset vector might never be loaded so it could just
execute random code.  I tend to feel the 80C85 is probably OK (the fact the
IO/M line toggles on reset is a good sign),  as is the ROM.  Most likely
there is a buffer issue either a failed line,  very weak drive or even a
simple dry joint.  The parts are quite old and some might just fail due to
age.  If you can I would check the address and data lines are all being
driven with full voltage swings and none are stuck or just hovering around.
This is kind of hard to do easily but might save you the headache of
replacing a 40pin CPU package.  

 

You might want to check the +5V is OK on all the chips just in case the
leaking caps did etch through a power copper trace.  

 

Re: [M100] SPAM-LOW: Re: New member - question on 'half' alive Model 100

[Fugu ME100]

On boot up one of the first things the M100 does is to configure the PIO 
(81C55) in order to scan the keyboard for the ctrl-break.The PIO and LCD 
all use port addresses, there should be a lot of activity on the IO/M pin on a 
normal boot!  Indeed within about 10 instructions, for a normal boot, the IO/M 
pin should be toggling quite a lot :)

However if the address or data lines are failing then it might just execute 
code that does not include any IO/M based operations.   For example, if the mux 
is broken then the reset vector might never be loaded so it could just execute 
random code.  I tend to feel the 80C85 is probably OK (the fact the IO/M line 
toggles on reset is a good sign),  as is the ROM.  Most likely there is a 
buffer issue either a failed line,  very weak drive or even a simple dry joint. 
 The parts are quite old and some might just fail due to age.  If you can I 
would check the address and data lines are all being driven with full voltage 
swings and none are stuck or just hovering around.This is kind of hard to 
do easily but might save you the headache of replacing a 40pin CPU package.

You might want to check the +5V is OK on all the chips just in case the leaking 
caps did etch through a power copper trace.

From: M100 
<m100-boun...@lists.bitchin100.com<mailto:m100-boun...@lists.bitchin100.com>> 
on behalf of Jeffrey Birt <bir...@soigeneris.com<mailto:bir...@soigeneris.com>>
Reply-To: <m...@bitchin100.com<mailto:m...@bitchin100.com>>
Date: Tuesday, May 1, 2018 at 1:10 AM
To: <m...@bitchin100.com<mailto:m...@bitchin100.com>>
Subject: Re: [M100] SPAM-LOW: Re: New member - question on 'half' alive Model 
100

While I agree the ROM is not a usual failure point they can fail. I may just go 
ahead and order an 80C85 but I hate to throw parts at it. The fact that the 
IO/M does not change states when it is ‘running’ (it does change states on 
reset) bothers me. Even if it were running garbage code due to an address/data 
latch issue what are the odds that it would never try to address the IO address 
space?

Thanks,
Jeff
--

Re: [M100] SPAM-LOW: Re: New member - question on 'half' alive Model 100

[Jeffrey Birt]

It would be nice to have an unmolested ROM dump for comparison sake. 

Jeff

-Original Message-
From: M100 <m100-boun...@lists.bitchin100.com> On Behalf Of Mike Stein
Sent: Monday, April 30, 2018 3:22 PM
To: m...@bitchin100.com
Subject: Re: [M100] SPAM-LOW: Re: New member - question on 'half' alive Model 
100

There will be minor differences, e.g. Y2K, the copyright message etc.

m

- Original Message - 
From: "Jeffrey Birt" <bir...@soigeneris.com>
To: <m...@bitchin100.com>
Sent: Monday, April 30, 2018 3:57 PM
Subject: Re: [M100] SPAM-LOW: Re: New member - question on 'half' alive Model 
100


Thanks, I was able to download the emulator and locate the ROM bin files. I'll 
read in my ROM this evening and see how they compare.

Thanks,
Jeff

-Original Message-
From: M100 <m100-boun...@lists.bitchin100.com> On Behalf Of Daryl Tester
Sent: Sunday, April 29, 2018 6:35 PM
To: m100@lists.bitchin100.com
Subject: Re: [M100] SPAM-LOW: Re: New member - question on 'half' alive Model 
100

 Hi Jeff.

 On Sun, 29 Apr 2018 16:11:08 -0500, Jeffrey Birt wrote:

> I replaced C90 and have the same symptoms. I'll now dig out my eprom 
> programmer and read in the main ROM. I still need a known good rom 
> dump to compare to. Anyone have one of those?

 I thought the Bitchin' Wiki or the Club web-site would have had dumps,  but  a 
quick look (admittedly *very* quick) didn't find anything.  However,  I 
remember that the Model 100/102/200 emulator "Virtual T" has the ROMs  as 
separate files, so you could download a copy and use those -

 https://sourceforge.net/projects/virtualt/

 And a thought on your diagnosing (again, only quickly caught up with  emails  
and definitely pre-coffee), but before you replace the CPU you may want  to 
check that the address latching is working correctly, given if the  
multiplexing screws up that's going to cause all sorts of weird  behaviours.

 Best of luck!

 Cheers.

--
 Regards,
   Daryl Tester
   Handcrafted Computers Pty. Ltd.

Re: [M100] SPAM-LOW: Re: New member - question on 'half' alive Model 100

[Jeffrey Birt]

Thanks for that tip! My cheap little TL866CS of course does not support the 
Sharp LH535618 so I’ll need to make an adapter.

 

While I agree the ROM is not a usual failure point they can fail. I may just go 
ahead and order an 80C85 but I hate to throw parts at it. The fact that the 
IO/M does not change states when it is ‘running’ (it does change states on 
reset) bothers me. Even if it were running garbage code due to an address/data 
latch issue what are the odds that it would never try to address the IO address 
space?

 

Thanks,

Jeff

 

From: M100 <m100-boun...@lists.bitchin100.com> On Behalf Of Brian White
Sent: Monday, April 30, 2018 5:49 PM
To: m...@bitchin100.com
Subject: Re: [M100] SPAM-LOW: Re: New member - question on 'half' alive Model 
100

 

Also remember, the pinout is not 27C256. So you'll need to use two dip28 
sockets (or at least one) and 28 wires to relocate some of the pins to read the 
rom in a reader.
http://bitchin100.com/wiki/index.php?title=Model_100_ROM

 

On Mon, Apr 30, 2018 at 6:06 PM, John R. Hogerhuis <jho...@pobox.com 
<mailto:jho...@pobox.com> > wrote:

Seems like the mask rom would be the least likely thing to fail, but I suppose 
it's possible. Keep in mind it's not an EEPROM that can get erased though.

 

-- John.




-- 

bkw

Re: [M100] SPAM-LOW: Re: New member - question on 'half' alive Model 100

[Brian White]

Also remember, the pinout is not 27C256. So you'll need to use two dip28
sockets (or at least one) and 28 wires to relocate some of the pins to read
the rom in a reader.
http://bitchin100.com/wiki/index.php?title=Model_100_ROM

On Mon, Apr 30, 2018 at 6:06 PM, John R. Hogerhuis  wrote:

> Seems like the mask rom would be the least likely thing to fail, but I
> suppose it's possible. Keep in mind it's not an EEPROM that can get erased
> though.
>
> -- John.
>



-- 
bkw

Re: [M100] SPAM-LOW: Re: New member - question on 'half' alive Model 100

[John R. Hogerhuis]

Seems like the mask rom would be the least likely thing to fail, but I
suppose it's possible. Keep in mind it's not an EEPROM that can get erased
though.

-- John.

Re: [M100] SPAM-LOW: Re: New member - question on 'half' alive Model 100

[Mike Stein]

There will be minor differences, e.g. Y2K, the copyright message etc.

m

- Original Message - 
From: "Jeffrey Birt" <bir...@soigeneris.com>
To: <m...@bitchin100.com>
Sent: Monday, April 30, 2018 3:57 PM
Subject: Re: [M100] SPAM-LOW: Re: New member - question on 'half' alive Model 
100


Thanks, I was able to download the emulator and locate the ROM bin files. I'll 
read in my ROM this evening and see how they compare.

Thanks,
Jeff

-Original Message-
From: M100 <m100-boun...@lists.bitchin100.com> On Behalf Of Daryl Tester
Sent: Sunday, April 29, 2018 6:35 PM
To: m100@lists.bitchin100.com
Subject: Re: [M100] SPAM-LOW: Re: New member - question on 'half' alive Model 
100

 Hi Jeff.

 On Sun, 29 Apr 2018 16:11:08 -0500, Jeffrey Birt wrote:

> I replaced C90 and have the same symptoms. I'll now dig out my eprom 
> programmer and read in the main ROM. I still need a known good rom 
> dump to compare to. Anyone have one of those?

 I thought the Bitchin' Wiki or the Club web-site would have had dumps,  but  a 
quick look (admittedly *very* quick) didn't find anything.  However,  I 
remember that the Model 100/102/200 emulator "Virtual T" has the ROMs  as 
separate files, so you could download a copy and use those -

 https://sourceforge.net/projects/virtualt/

 And a thought on your diagnosing (again, only quickly caught up with  emails  
and definitely pre-coffee), but before you replace the CPU you may want  to 
check that the address latching is working correctly, given if the  
multiplexing screws up that's going to cause all sorts of weird  behaviours.

 Best of luck!

 Cheers.

--
 Regards,
   Daryl Tester
   Handcrafted Computers Pty. Ltd.

Re: [M100] SPAM-LOW: Re: New member - question on 'half' alive Model 100

[Jeffrey Birt]

Thanks, I did pull and reseat the ROM to no avail I'm going to read it in
via my eprom burner this evening and verify it is OK.

 

Jeff

 

From: M100 <m100-boun...@lists.bitchin100.com> On Behalf Of Fugu ME100
Sent: Monday, April 30, 2018 4:18 AM
To: m...@bitchin100.com
Subject: Re: [M100] SPAM-LOW: Re: New member - question on 'half' alive
Model 100

 

You could also try contact cleaner on the ROM socket,  it could of oxidized
over the years.  

 

Re: [M100] SPAM-LOW: Re: New member - question on 'half' alive Model 100

[Jeffrey Birt]

Thanks, I was able to download the emulator and locate the ROM bin files. I'll 
read in my ROM this evening and see how they compare.

Thanks,
Jeff

-Original Message-
From: M100 <m100-boun...@lists.bitchin100.com> On Behalf Of Daryl Tester
Sent: Sunday, April 29, 2018 6:35 PM
To: m100@lists.bitchin100.com
Subject: Re: [M100] SPAM-LOW: Re: New member - question on 'half' alive Model 
100

 Hi Jeff.

 On Sun, 29 Apr 2018 16:11:08 -0500, Jeffrey Birt wrote:

> I replaced C90 and have the same symptoms. I'll now dig out my eprom 
> programmer and read in the main ROM. I still need a known good rom 
> dump to compare to. Anyone have one of those?

 I thought the Bitchin' Wiki or the Club web-site would have had dumps,  but  a 
quick look (admittedly *very* quick) didn't find anything.  However,  I 
remember that the Model 100/102/200 emulator "Virtual T" has the ROMs  as 
separate files, so you could download a copy and use those -

 https://sourceforge.net/projects/virtualt/

 And a thought on your diagnosing (again, only quickly caught up with  emails  
and definitely pre-coffee), but before you replace the CPU you may want  to 
check that the address latching is working correctly, given if the  
multiplexing screws up that's going to cause all sorts of weird  behaviours.

 Best of luck!

 Cheers.

--
 Regards,
   Daryl Tester
   Handcrafted Computers Pty. Ltd.

Re: [M100] SPAM-LOW: Re: New member - question on 'half' alive Model 100

[Fugu ME100]

You could also try contact cleaner on the ROM socket,  it could of oxidized 
over the years.

From: M100 
<m100-boun...@lists.bitchin100.com<mailto:m100-boun...@lists.bitchin100.com>> 
on behalf of Jeffrey Birt <bir...@soigeneris.com<mailto:bir...@soigeneris.com>>
Reply-To: <m...@bitchin100.com<mailto:m...@bitchin100.com>>
Date: Sunday, April 29, 2018 at 10:11 PM
To: <m...@bitchin100.com<mailto:m...@bitchin100.com>>
Subject: Re: [M100] SPAM-LOW: Re: New member - question on 'half' alive Model 
100

I replaced C90 and have the same symptoms. I’ll now dig out my eprom programmer 
and read in the main ROM. I still need a known good rom dump to compare to. 
Anyone have one of those?

Thanks,
Jeff

Re: [M100] SPAM-LOW: Re: New member - question on 'half' alive Model 100

[Daryl Tester]

On Mon, 30 Apr 2018 09:05:18 +0930, Daryl Tester wrote:

Oh, it's April 30th.  I made myself sad.  :-(

A moment to reflect that Rick is still missed ...

--
Regards,
  Daryl Tester
  Handcrafted Computers Pty. Ltd.

Re: [M100] SPAM-LOW: Re: New member - question on 'half' alive Model 100

[Fugu ME100]

4.  You could also check the Electrolytic Cap on the reset line it may of 
leaked too which could impact the reset timing.
C90 is the only electrolytic that seems to be part of the reset 
circuitry. I have not changed it and it is of the same manufacture as the other 
ones that did leak. Interesting how it is all caps of that one brand/series 
that leak.

I never noticed the brand on the ones I replaced they all seemed to be bad :)  
I have had the reset cap fail which caused some weird behavior.  Although 
pressing reset after power on usually works.

5.  The new NiCd might need some more time to charge up.
The NiCad is removed which I think should be OK as I should 
still get VS?

Not sure about this it should work,  the NiCd only backs up the RAM. It could 
mean the RAM starts up with garbage every time you power on.  Could try a power 
on then perform a clean boot by using the reset button rather than power on 
sequence to clear out the RAM.

One other thing to check is the soldering in the area of the clock chip.  I 
have two M100s that had bad soldering in that area, just a matter of retouching 
joints that look bad.  It was so bad there were bubble holes in the solder.
The build quality on the M100 is quite atrocious.

Re: [M100] SPAM-LOW: Re: New member - question on 'half' alive Model 100

[Jeffrey Birt]

 

Answered in line below, thanks for your replay. - Jeff

 

Ju>>st a couple of quick things:

 

1.  Have you tried a cold boot to clear out any bad data in the memory?  

Just tried, not change.

 

2.  Is the LCD contrast adjustment working?  

Yes

 

3.  If the LCD is going dark it usually means the processor has reset it, if
it did not there would be garbage bits on the LCD,  and the beep is a normal
part of the boot.Once it is powered on hit return this should enter
BASIC, then type beep and enter.  The unit should beep.  This would indicate
the unit is booting but the there might be a problem with the LCD.

The reset line seems to be working. The LCD is in the reset
but not initialized state which is all black.

 

4.  You could also check the Electrolytic Cap on the reset line it may of
leaked too which could impact the reset timing.  

C90 is the only electrolytic that seems to be part of the
reset circuitry. I have not changed it and it is of the same manufacture as
the other ones that did leak. Interesting how it is all caps of that one
brand/series that leak.

 

5.  The new NiCd might need some more time to charge up.

The NiCad is removed which I think should be OK as I should
still get VS?