Re: what can run on a plain 48k Apple2 europlus

["Bryan Parkoff" <nospam@nospam.com>]

"Knut Roll-Lund" <kr-lund@nogarbage.online.no> wrote in message 
k_-dnUiz8JdmlfLbRVnzvAA@telenor.com">news:k_-dnUiz8JdmlfLbRVnzvAA@telenor.com...
> Knut Roll-Lund wrote:
>
>> Knut wrote:
>>
>>> "Michael J. Mahon" wrote:
>>>
>>>> Linards Ticmanis wrote:
>>>>
>>>>> Knut Roll-Lund wrote:
>>>>>
>>>>>
>>>>>
>>>>>> Grasping at straws: What if there is an adressing problem that data 
>>>>>> is
>>>>>> overwritten because of an adress line failure. Would APTEST see that? 
>>>>>> Is
>>>>>> there a RAM test that would test the address lines?
>>>>>
>>>>>
>>>>>
>>>>> I don't think APTEST would see this at all. The RAM test in APTEST is
>>>>> extremely simple minded: fill all of RAM with Value X, then test if 
>>>>> it's
>>>>> still there. Repeat for next X. This obviously won't find broken or
>>>>> flaky address lines.
>>>>>
>>>>> You could try something simple like this (with no DOS loaded):
>>>>>
>>>>> 10 FOR I = 2500 TO 49000 STEP 2
>>>>> 20 PRINT I;
>>>>> 30 POKE I, 85:POKE I+1, 170
>>>>> 40 NEXT I
>>>>> 50 FOR I = 2500 to 49000 STEP 2
>>>>> 60 PRINT I;
>>>>> 70 POKE I, 170:POKE I+1, 85
>>>>> 80 NEXT I
>>>>>
>>>>> Then see if and at what value of I you get screen corruption.
>>>>
>>>>
>>>> Or you could take two passes, and store the high/low byte of
>>>> the address at each address, then read back and verify.
>>>>
>>>> If any address line is open, stuck, or shorted to another, the
>>>> values read back will not match.
>>>
>>>
>>>
>>> Hi, thanks for the answers.
>>>
>>> I have designed simple RAM tests through my work (embedded stuff). I 
>>> would typically test address lines by using powers of two for each RAM 
>>> area (in assembly using registers so the RAM is free) writing and 
>>> reading back to see if they would affect each other.
>>>
>>> I'm still learning about the Apple2 and especially I don't yet know 
>>> where it is allowed to POKE. I could probably interpolate on your 
>>> program and use the area 2500 to 49000 to test all the address lines, 
>>> test separately within each bank of RAM.
>>>
>>> BTW I did have a flaky RAM, at first, but identified it and fortunately 
>>> I have some compatible spares. It sometimes got through the APTEST and 
>>> sometimes not. I have been moving the RAM chips around so I'm pretty 
>>> sure they work now (tested them all in the first bank). The faulty RAM 
>>> was originally in the middle bank so DOS3.3 would boot fine even with it 
>>> failing.
>>>
>>> After changing that RAM the fault that is left is there all the time. 
>>> Beautiful boot has never worked nor Wizardry or any other big games I 
>>> have tried. Some smaller games work. There was something strange with 
>>> the graphics on one lunar lander I tried but the game seemed to work 
>>> (the hillsides were corrupted) I have no joystick or paddles for II+ yet 
>>> so I couldn't test more there.
>>>
>>> I have tried beautiful boot in several emulators in II+ mode but this is 
>>> not a good test as emulators tend to have lots of extra "hardware". 
>>> Should beautiful boot work on my plain II+ 48k machine with only a 
>>> DiskII card? Beautiful boot is very typical on floppy images I find on 
>>> the net and it seems to use HGR.
>>>
>>> I'll try some basic when I get home from work.
>>>
>> ok this one revealed how worthless a test APTEST's ramtest is. I did the 
>> test in 3 batches one for each bank of ram. This is for the second one 
>> and I didn't bother with powers of two.
>>
>> 10 POKE 16384,0
>> 20 FOR I=16385 TO 32767
>> 30 POKE I,255
>> 40 IF PEEK(16384) <> 0 THEN PRINT "FAIL", I;:INPUT A$:POKE 16384,0
>> 50 NEXT I
>>
>> This one failed immediately with 16385 but closer inspection by peeking 
>> and poking from the command line revealed that none of the addresses in 
>> the middle bank holds any value. That is addresses from 16384 to 32767 
>> won't hold a value. I have checked all the signals and they seems ok, I 
>> do get both RAS and CAS (CAS when I PEEK or POKE). I really wonder how it 
>> is. The RAM seems ok. Can something be clobbering the bus when I access 
>> the D bank of RAM. The data latches are the same as the other banks so it 
>> can't be those...
>>
>> I think this is the fastest way basic can do POKE and PEEK and C is never 
>> 0 (32786 or 16383 works fine even with me typing the POKE and PEEK 
>> separately on the command line). Poking 255 also fails.
>> 10 A=32767:B=0:POKE A,B:C=PEEK(A):PRINT C
>>
>> APTEST still reports all ok
>>
>> I probably have to break out the logic analyzer, and follow the data from 
>> the RAM to the CPU during POKE and PEEK.
>>
>
> It was the "gatekeeper" LS20 at D2 that controls the LS257's that let the 
> RAM output from the latches back on the databus. Didn't react on one 
> input. And I didn't break out the logic analyzer, I found that it was a 
> suspect and tried a replacement.
>
> Now Beautiful Boot works and even Wizardry-I works.
>
> Why the APTEST 48K RAM test failed is probably that the bus was high-z 
> when reading the D bank of RAM and the databus that was not driven would 
> still have the correct value. The test has a major flaw. If it had done 
> any kind of address type test it would have found the fault.
>
> Now I think it is fully restored. Yippee

    I would be surprised to write simpler routine using Applesoft BASIC or 
6502 assembly to dagnose each byte while isolating address bus to determine 
why data bus does not get complete 8-bit data correctly.  It could be the 
timing to fail activating one or more chips to respond like you stated 
earlier.
    What if code routine starts at $2000 and data starts at $3000 through 
$BFFF?  Code routine at $2000 scan $3000 through $BFFF by modifying $00 to 
$FF and $FF to $00 and do comparison to identify failure.  If data is on 
$2000 through $BFFF while code routine is on $2000, I suppose that data is 
modifying each code's byte in the code routine at $2000 for comparison 
before code's byte must be written back to the original value in the code 
routine otherwise, it attempts to execute wrong 6502 instruction in modified 
code's byte in the code routine before it crashes.  It is bad practice to 
modify code routine at $2000 while it is running and scanning starting at 
$2000.

Bryan Parkoff