exxos's Atari, Amiga & retro forum

Posted: **10 May 2025 14:42**

@agranlund yes you are right, there is an issue with long word addressing

Screenshot 2025-05-10 at 14.40.58.png

Will this be the two 254 chips do you think?

Posted: **10 May 2025 22:17**

That's a possibility, especially since they are quite hard to solder but there's a few too many bits different for it to feel like a sure thing. The effected word would pass through U103

Another possibility is if it's related to when the 68150 splits a large access into multiple small ones, such as the cpu 1xLong into 2xWord for the isa card.

I would try to determine if it's on read, write or both. Might not be super useful and it's probably both but one cannot have too little information.

I'm going to assume all byte access are working since the test image is showing correctly.
Thus, let's check if long reads work.

Code: Select all

pb $820a4ec0 $12
pb $820a4ec1 $34
pb $820a4ec2 $56
pb $820a4ec3 $78
pl $820a4ec0

Then check long write, verifying by reading back byte by byte.

Code: Select all

vga test
pl $820a4ec0 $12345678
pb $820a4ec0
pb $820a4ec1
pb $820a4ec2
pb $820a4ec3

Then it could be interesting to know what happens when doing a single word access to where we got garbage on the long access. In case it's somehow A1 related perhaps.

Code: Select all

vga test
pw $820a4ec2 $ab75
pw $820a4ec2

Similarly, a long access that is offset 2 bytes from what we did last time.
Would be interesting to see if this gives back $1234xxxx or $xxxx5678 where x is some garbage.

Code: Select all

vga test
pl $820a4ec2 $12345678
pl $820a4ec2

And finally, let's try forcing it to split that long access into 4xByte instead of 2xWord when talking to the isa card.
(write 4xByte, read 4xByte, read 2xWord)

Code: Select all

vga test
pl $800a4ec0 $12345678
pl $800a4ec0
pl $820a4ec0

(write 2xWord, read 4xByte, read 2xWord)

Code: Select all

vga test
pl $8200a4ec0 $12345678
pl $800a4ec0
pl $820a4ec0

Oh, and while we're there may as well check bus-sizing a word access to 2xByte too.
And try reading it back as 2xByte as well as 1xWord.

Code: Select all

vga test
pw $800a4ec0 $ab75
pw $800a4ec0
pw $820a4ec0

Then the word after because why not

Code: Select all

pw $800a4ec2 $ab75
pw $800a4ec2
pw $820a4ec2

Sorry for the wall of text.
Due to the turnaround time it feels more efficient to overtest rather than one thing at a time :)
What clock speed are you running at by the way?

Posted: **10 May 2025 22:29**

@agranlund ok,might take me a bit longer to work out this time :lol:

I'll post the results in the morning.

Btw, you can never have too much information.

Posted: **11 May 2025 16:38**

Hi @agranlund I've put my answers for each code snippet in bold after the code associated with it :)

agranlund wrote: 10 May 2025 22:17
I'm going to assume all byte access are working since the test image is showing correctly.
Thus, let's check if long reads work.
Code: Select all
pb $820a4ec0 $12
pb $820a4ec1 $34
pb $820a4ec2 $56
pb $820a4ec3 $78
pl $820a4ec0
Okay, the first test gives $12345678 as expected

Then check long write, verifying by reading back byte by byte.
Code: Select all
vga test
pl $820a4ec0 $12345678
pb $820a4ec0
pb $820a4ec1
pb $820a4ec2
pb $820a4ec3
This gives back the answer 12,34,FF,FF

Then it could be interesting to know what happens when doing a single word access to where we got garbage on the long access. In case it's somehow A1 related perhaps.
Code: Select all
vga test
pw $820a4ec2 $ab75
pw $820a4ec2
I get back $ab75

Similarly, a long access that is offset 2 bytes from what we did last time.
Would be interesting to see if this gives back $1234xxxx or $xxxx5678 where x is some garbage.
Code: Select all
vga test
pl $820a4ec2 $12345678
pl $820a4ec2
I get back $12345678

And finally, let's try forcing it to split that long access into 4xByte instead of 2xWord when talking to the isa card.
(write 4xByte, read 4xByte, read 2xWord)
Code: Select all
vga test
pl $800a4ec0 $12345678
pl $800a4ec0
pl $820a4ec0
This time its $12ffffff followed by $12ffffff

(write 2xWord, read 4xByte, read 2xWord)
Code: Select all
vga test
pl $8200a4ec0 $12345678
pl $800a4ec0
pl $820a4ec0
$12ffffff twice this time.

Oh, and while we're there may as well check bus-sizing a word access to 2xByte too.
And try reading it back as 2xByte as well as 1xWord.
Code: Select all
vga test
pw $800a4ec0 $ab75
pw $800a4ec0
pw $820a4ec0
$ab00 twice this time

Then the word after because why not
Code: Select all
pw $800a4ec2 $ab75
pw $800a4ec2
pw $820a4ec2
abff twice this time.

Sorry for the wall of text.
Due to the turnaround time it feels more efficient to overtest rather than one thing at a time :)
What clock speed are you running at by the way?

Posted: **12 May 2025 15:33**

Gone over all the sad chips once more with the microscope set at a high magnification and cleaned a few more bits up, mainly stuff like flux between the pins but its gone or as gone as can be without putting the whole thing in a large sonic cleaner

Annoyingly I tried the mouse and keyboard and neither work at the moment.

Posted: **12 May 2025 18:50**

PhilC wrote: 12 May 2025 15:33 Gone over all the sad chips

No love for the happy chips? :lol:

Posted: **12 May 2025 18:55**

PhilC wrote: 11 May 2025 16:38 I've put my answers for each code snippet in bold after the code associated with it

This is interesting results.

So it looks like in all the cases where you have multiple 68150 writes from a single cpu write, only the first becomes correct.
Interestingly, multi read cycles appear fine. And single byte/word access appears to work both in read and write.

I can't immediately think of what could be shorted to cause this kind of behavior.
I'm thinking U103 and U106 are probably fine since we've seen good data flowing in both directions through both.

U501 (ATF22V10) helps with ISA related logic so that could be one to check, as well as U108 (ATF1508) and U104 of course (the 68150).
Timing issue? What are the speed grades of these and what mhz is your main oscillator running at?

Let's investigate if this problem is exclusive to ISA by trying to do something similar to the YM2149.
But first, for the purpose of eliminating whatever we can, let's make the machine boot to the monitor without starting emutos.

Code: Select all

cfg boot_enable 0
reset

Now let's poke at the YM2149 with long write and verifying the result.

Code: Select all

pl $ff8800 $0b00aa00
pl $ff8800 $0c005500
pb $ff8800 $0b
pb $ff8800
pb $ff8800 $0c
pb $ff8800

We're expecting it to return $aa and then $55.

If it doesn't I'd expect this to return $55 doing byte writes:

Code: Select all

pb $ff8800 $0b
pb $ff8802 $55
pb $ff8800

We could also run the selftest program. It's quite minimal so I'm not expecting it to give us much. Would be nice to improve it at some point but you know, it's boring :)

1. Send the file "raven/roms/srec/selftest.s19" using your terminal program.
When uploaded, it should say "S-record upload complete at address 0x00600000".
(And possibly something about invalid rom image which you can ignore because that message is a bug)

2. Now run the uploaded program

Code: Select all

run $600000

Let's check if you can talk to the RTC too because why not (it's connected to one of the MFP's so it's on the same side of the 68150 as YM and ISA etc)

Code: Select all

rtc

(and then change back boot_enable to 1 if you want to enable booting TOS again)

Posted: **13 May 2025 11:21**

Ok, hold that thought for a minute @agranlund

You mentioning frequency made me wonder if the 32mhz was just too slow for all the programmed timings,so I've fitted a 40mhz oscillator. I then set the cpu speed to x2 on J104 & J102 and I now have a proper desktop, although its a bit intermittent, I think the CPU or 68150 are probably crashing but I'll work from here and see if I can work out what's going wrong.

I'll post an update later on.

Thanks for your help so far Anders.

Posted: **13 May 2025 11:36**

Okay I now have a consistent boot to Desktop but now have to get the Eiffel working. I'm not getting a ps/2 clock and am wondering if it's the way I've programmed it.

I've used a TL866 to program the PIC and left the fuses as per the hex file. Is this the correct way to program it?

Btw, pic of desktop soon to be followed by a working Raven I hope :lol:

PXL_20250513_103228964.MP~2.jpg

Edit: The Mach32 now also works which I'm very happy about obviously :lol:

Posted: **13 May 2025 14:08**

And thanks to a dodgy ps/2 socket, my keyboard and mouse are now working. I'll have to order a new one but at least I can now get everything like VGA drivers etc all working.

exxos's Atari, Amiga & retro forum

Phil C's Raven build

Re: Phil C's Raven build

Re: Phil C's Raven build

Re: Phil C's Raven build

Re: Phil C's Raven build

Re: Phil C's Raven build

Re: Phil C's Raven build

Re: Phil C's Raven build

Re: Phil C's Raven build

Re: Phil C's Raven build

Re: Phil C's Raven build