exxos's Atari, Amiga & retro forum

dml wrote: 16 Nov 2022 23:04 Did you try the mandelbox raytracer yet? It should be a decent burn-in :twisted:

Not heard of that one :) if it will fit on the floppy then I can try..

exxos wrote: 16 Nov 2022 23:06 Not heard of that one :) if it will fit on the floppy then I can try..

I posted it in here a few days ago, although I probably can't find it among the traffic. I'll relink it tomorrow morning. Time to collapse now :p

dml wrote: 16 Nov 2022 23:08 I posted it in here a few days ago, although I probably can't find it among the traffic. I'll relink it tomorrow morning. Time to collapse now :p

Oh I see it.. viewtopic.php?f=112&t=5934&p=93487&hili ... box#p93487

The night is still young ;)

EDIT:

Thats gonna take forever :lol:

EDIT2:

Oh it died :lol: :roll:

exxos wrote: 16 Nov 2022 22:44

Badwolf wrote: 16 Nov 2022 22:33 I can abandon this direct DSACK-DSACK firmware until next board spin, then, I take it?

I would say so yes. I will do some loading testing on the oscillator which I will look into more tomorrow. I would put some series resistance in the DSACK lines from the FPU to PLD though. Assume 68R be about right. May need some experimentation..

I think @12-MHz got good results putting inline termination resistors between AS and DS between the two processors. Perhaps on the next board spin I'll put in a single 4-way resistor network and route AS,DS,DSACK0 and DSACK1 directly between the processors via that. Extra part, though... Might be better to do four separate footprints and use the same value resistor as I use for the clock inline termination resistors. Perhaps settle for 47R or something.

I would probably adopt that direct connection and drop the routeing via the CPLD, though as I have now proved it works at least.

I would definitely address all the capacitors issues we talked about earlier in the new spin.

My only worry about adding another four caps is it's starting to get hard for the hobbiest. If we're making a small run with the parts pre-assembled, it's fine. I reckon two more -- one for each pair of VCC pins -- might have to do. I could mask off VCC around the pins so that the power has to pass via the cap connection, though.

I would probably suggest just going with a separate oscillator for the FPU. As we cannot really assume what speeds the CPU or FPU can run at currently.

The only issue I had with that is I knew people would just fit a 40MHz part and wonder why their 40MHz chip failed. At least by driving it we can divide it down. The firmware updates I'm working on at the moment default to driving he FPU at motherboard frequency and you can then select OSC/2 or full OSC in software.

Perhaps I've made the switch from internal to external oscillator too complex (removing an SMD component), though. Perhaps I'll put another jumper on. Bah, but then that needs soldering and a jumper. Dunno.

Incidentally it still does not run at 50MHz, it crashes on the first test :lol: :roll: But I need to put maybe a 33R in series with it yet, its hardwired to the OSC currently. But I think this particular FPU is just simply a 40MHz part.

I think some FPUs will do some instructions at 50MHz, but I bet they all fail on the trig tests.

BW

exxos wrote: 16 Nov 2022 23:09

dml wrote: 16 Nov 2022 23:08 I posted it in here a few days ago, although I probably can't find it among the traffic. I'll relink it tomorrow morning. Time to collapse now :p

Oh it died :lol: :roll:

I'm six lines in at 50/25... :lol:

BW

Badwolf wrote: 16 Nov 2022 23:15 My only worry about adding another four caps is it's starting to get hard for the hobbiest. If we're making a small run with the parts pre-assembled, it's fine. I reckon two more -- one for each pair of VCC pins -- might have to do. I could mask off VCC around the pins so that the power has to pass via the cap connection, though.

ahh "exxos edition branch" ;)

Badwolf wrote: 16 Nov 2022 23:15 The only issue I had with that is I knew people would just fit a 40MHz part and wonder why their 40MHz chip failed. At least by driving it we can divide it down. The firmware updates I'm working on at the moment default to driving he FPU at motherboard frequency and you can then select OSC/2 or full OSC in software.

Maybe... see very bottom line on this page... https://exxosforum.co.uk/atari/last/FPU/index.htm They very easy to kill.

I think some FPUs will do some instructions at 50MHz, but I bet they all fail on the trig tests.

I saw that before.. but since the clock fix, it fails on the first test now. :shrug:

Badwolf wrote: 16 Nov 2022 23:25 I'm six lines in at 50/25... :lol:

My screen went blank after it did like a inch.. now crashes after 3 lines.. Well I say crash.. the screen goes blank.. so no idea what it's doing.

exxos wrote: 16 Nov 2022 23:38

Badwolf wrote: 16 Nov 2022 23:25 I'm six lines in at 50/25... :lol:

My screen went blank after it did like a inch.. now crashes after 3 lines.. Well I say crash.. the screen goes blank.. so no idea what it's doing.

You need a software control firmware to select the OSC/2 option ;-)

I'm running that firmware ATM, but I don't have the software to control anything yet! :lol:

I've decided I'm adopting the 0x00F1DFBx range for my registers. F1DFB0 will tell you the board version (0x01 in this case). F1DFB2 is the primary configuration register. Single byte, upper of a word read.

Bitwise: xxFFOxfE.

xx = unused ATM.
FF = FPU speed select; 11 FPUOSC (in next board revision); 10 Motherboard clock; 01 OSC/2; 00 OSC.
O = OPTION2
x = unused
f = FLASH enable
E = master enable

E, f, O default to their jumper settings on power on, but can be overridden on the fly. Some changes take effect on reset only, others are immediate.

Can only be set at the moment by poking that variable, but it seems to work.

Calling it a night now, this is how far I've got. Not sure what I'm looking at!!

BW

Sounds like a plan :)

Mines done about 20% more than your image . Never thought to check if it's running from TTram or not :lol:

EDIT

It finished :)

exxos wrote: 17 Nov 2022 00:04 Mines done about 20% more than your image . Never thought to check if it's running from TTram or not :lol:

It should run from STRam or TTRam. If it crashes it is likely a FPU exception (I did say it would be a burn-in :-p)

It looks like nonsense but it's actually a close up of this fractal, at some random orientation:


Each time it redraws (slowly) it has rotated some amount. That's all really. FPU should be toasty after a while!