4MB Upgrade & 16MHz Booster progress

[Ragstaff]

We are very lucky to have someone like yourself, exxos, still making things like this. Very cool.

Not to derail your thread, but it may be vaguely related - could/would it be possible and worthwhile to put a DSP on an ST accelerator card, mapped to the same addresses as the 56001 on the Falcon? I remember some years ago seeing that they were extremely cheap. Like, $5.50 each when bought in quantities of 1000 from Freescale... I forget the exact chip except that it was a later, faster model than the 56001, but supposedly fully compatible. This may have even been for the 96002. The only catch was that it came in BGA packaging, the PGA version was much more expensive.

What would the use be for this? Obviously there isn't going to be a whole new load of ST software written to take advantage of a DSP! But I thought it might increase compatibility with the Falcon, maybe some Falcon software that runs with ST video modes might run on an ST if it has a DSP. If the hardware was cheap it might be interesting to have it there on a booster board like this, however I appreciate the effort to put it on and get it working might not be "cheap". Any thoughts on this?

[exxos]

We are very lucky to have someone like yourself, exxos, still making things like this. Very cool.

[smilie=greencolorz4_pdt_01.gif] There is of course Rodolphe who is heavily involved with all the boosters of late also

Not to derail your thread, but it may be vaguely related - could/would it be possible and worthwhile to put a DSP on an ST accelerator card, mapped to the same addresses as the 56001 on the Falcon? I remember some years ago seeing that they were extremely cheap. Like, $5.50 each when bought in quantities of 1000 from Freescale... I forget the exact chip except that it was a later, faster model than the 56001, but supposedly fully compatible. This may have even been for the 96002. The only catch was that it came in BGA packaging, the PGA version was much more expensive.

What would the use be for this? Obviously there isn't going to be a whole new load of ST software written to take advantage of a DSP! But I thought it might increase compatibility with the Falcon, maybe some Falcon software that runs with ST video modes might run on an ST if it has a DSP. If the hardware was cheap it might be interesting to have it there on a booster board like this, however I appreciate the effort to put it on and get it working might not be "cheap". Any thoughts on this?

It kinda reminds me of the "FPU" type discussions a while back. While the FPU is fantastic at math stuff, there is almost nothing which uses it. Similar with the DSP, it could may well be possible to add it. Though if the DSP is used for audio stuff, then it needs access to a DAC, so probably better suited on the STE maybe.

One good thing about the upcomming V3 series, is the addon port, so if anyone wants to develop a DSP addon or any other addon, then they are free to do a card for it and simply plug it into the V3 expansion port.

[DarkLord]

Okay, got some sleep, attended my daughters "Young Authors - Christmas through the eyes of a
child" awards ceremony (she was a school winner), grabbed a quick nap, back up, Atari stuff!

Downloaded Gembench 5, read through your notes, looks good. Seems to run fine on my Pak 68/3
equipped STacy. Results seem...really good compared to GB3 and 4. Here is a pictures (sorry for
the low quality - cellphone):

Gembench 5 results.jpg

Also, I shot a really low quality video of Gembench 5 running:

STacy-GB5.flv.zip

(forum won't let me upload video directly like Atari Age does)

Interesting results. Whatcha think?

EDIT: Forgot to mention, have to double-check but I believe I had NVDI running.

[wongck]

Wow ... great stuff.... is that 18 times faster ????
Worth every penny

[exxos]

Okay, got some sleep, attended my daughters "Young Authors - Christmas through the eyes of a
child" awards ceremony (she was a school winner), grabbed a quick nap, back up, Atari stuff!

Downloaded Gembench 5, read through your notes, looks good. Seems to run fine on my Pak 68/3
equipped STacy. Results seem...really good compared to GB3 and 4. Here is a pictures (sorry for
the low quality - cellphone):
Interesting results. Whatcha think?

EDIT: Forgot to mention, have to double-check but I believe I had NVDI running.

Thanks for the results Probably not so fair if NVDI is running, I've not tested my boosters with that yet Maybe you can disable it ? Also if you have a way to disable the cache memory on the 030 then it would give a "raw" benchmark of what the CPU is capable of

If I get chance later, I will setup NVDI on my 32mhz machine and see what the results are.

[DarkLord]

Can do - taking Alexia to school this morning, I'll try both (disabling NVDI is easy)
and repost the results, as soon as I get back.

[DarkLord]

Ah, just did a fast check, was afraid of this. The cache on the Pak 68/3 is controlled by a jumper
on board, not software. So I'd have to take my STacy apart to disable the cache, as far as I know.

STacy's are not fun to take apart.

If in the near future I take that sucker apart again (for example, to replace the current Ultrasatan
with the CosmosEX I bought), then I'll run GB5 on it again with the cache disabled.

Here is a picture of what's jumper controlled on the Pak 68/3:

PAK Jumpers.jpeg

[exxos]

Ah, just did a fast check, was afraid of this. The cache on the Pak 68/3 is controlled by a jumper
on board, not software. So I'd have to take my STacy apart to disable the cache, as far as I know.

STacy's are not fun to take apart.

If in the near future I take that sucker apart again (for example, to replace the current Ultrasatan
with the CosmosEX I bought), then I'll run GB5 on it again with the cache disabled.

It's not that critical, just out of interest really to what the 030 can do as a "raw cpu". Not worth taking your machine to bits just for that

I would assume the 020 would be comparable speed wise to the 020 without the cache, though I'm only running 32mhz currently. Though I will try and test with NVDI as should be interesting at 32mhz

[DarkLord]

Okay, ran Gembench 5 with NDVI disabled. Pretty big differences in all the areas
you would expect. Here are 2 pictures, one with the results and one with the
info screen when you go to save your results as a *.TST file. Oh, it was NVDI
v5.03 that I was running before, in case that makes a difference.

Gembench 5 results02.jpg

Gembench 5 results03.jpg

Hope this helps with your work. Anything I can do just let me know. Can't wait
to see all your work completed. Good STuff.

[exxos]

Here is side by side results. Though its a little unfair as the pak30 will have caches enabled. So that will be the reason integer division etc show such high results.

Overall 410% on display vs 401% on mine. So I suspect without the cache, the pak30 would most likely be a lot slower. Mine beats the pak30 on some tests like the VDI stuff, and I don't have a cache even

Myself and rodolphe are working on higher than 32mhz speeds, though we pretty much maxed out ROM access and most likely SRAM at 32mhz. So the CPU may take 50mhz+ so results will be a lot faster, in particular integer division. Most likely 50mhz will match the pak30 speeds and thrash it in other stuff. We shall see

pak030v2v3.jpg

[rpineau]

You can disable both cache on the 68030 with:
moveq #0,d0
movec d0,CACR

I can probably write a quick asm prog to do this.

[exxos]

You can disable both cache on the 68030 with:
moveq #0,d0
movec d0,CACR

I can probably write a quick asm prog to do this.

I did wonder about that CPX you sent me ages ago to disable the 020 instruction cache, I don't know if that works with 030 or can turn off the data cache aswell..

[rpineau]

it probably does.

[exxos]

Here is 32mhz with and without NVDI 5.03

ndvi23mhz.jpg

I also found that in gembench "resource file not found" actually means "out of memory"

[rpineau]

Try this, it should disable both caches.

CACHEOFF.zip

[DarkLord]

Okay, downloaded both those - give me a bit and I'll report back what happens.

@ Chris - If I were you I'd be pretty pleased with your boards results vs my Pak
, considering no cache and mine is clocked faster.

[exxos]

Okay, downloaded both those - give me a bit and I'll report back what happens.

@ Chris - If I were you I'd be pretty pleased with your boards results vs my Pak
, considering no cache and mine is clocked faster.

Glad someone notice that Theres 3 of us working on breaking the 32mhz barrier now

Reminds me, do you have a machine with a T25 in still ? I wanted to benchmark mine in GB5, but it isn't working, and it was last time I used it

[DarkLord]

The more the merrier.

Ah, sorry not now. I was using it in my STacy first when I was playing around with
the Pak board, not knowing whether or not I was going to be able to get it to work
(I received it from the seller in very poor shape). So with the STacy closed up, I
don't have a "test" machine ready. Let me poke around in my closet and see if I can
come up with something later.

Now...I'm a bit confused (normal state for me!). The SI.CPX is what NVDI uses to
control its fonts and caches, right? With NVDI disabled in the first place, isn't that
kind of useless? If I'm being dense just point it out to me.

About the CACHEOFF.PRG - I ran it after a clean boot. It runs, no messages that I
could see, exits. Strangely enough, after running it, GB5 wants to report slightly
faster results?

I've only been running GB5 with a single pass - should I be using the 10 pass option?

Thanks.

[exxos]

I only know SI.CPX as Rodolphe suggested it to disable the 020 instruction cache, other than that no idea about anything else with it. The only options I had in it was to disable the blitter I think.

GB5 just needs 1 test to be done, doing more will just loop all tests, its more just for testing stability than anything

[DarkLord]

Okay, well then, maybe my machine is not so stable.

I've been sitting here running GB5 on the STacy over
and over. Not going to post xxx pics so the long and
short of it is, with NVDI disabled and running the
CACHEOFF.PRG, I'm getting an "average" of 1200 to
1400 percent. It is holding steady in that range but
it does vary each time, back and forth, in that same
range.

Do you think that means there is a problem somewhere?

Thanks.

[rpineau]

Weird indeed.
CACHEOFF.PRG does display something but as it's really fast you don't see it.
I would expect the CPU to always return the same results.

[exxos]

Okay, well then, maybe my machine is not so stable.

I've been sitting here running GB5 on the STacy over
and over. Not going to post xxx pics so the long and
short of it is, with NVDI disabled and running the
CACHEOFF.PRG, I'm getting an "average" of 1200 to
1400 percent. It is holding steady in that range but
it does vary each time, back and forth, in that same
range.

Do you think that means there is a problem somewhere?

Thanks.

STacy stikes again

Only thing it could be is the cache is "hitting and missing" as its doing the tests for whatever reason. Raw MHz wise it should be stable and same results each time. So I can only assume its a cache problem. Though its not really a problem, its just how the cache works. Only way to know 100% is to disable the cache and try again.

[DarkLord]

Does CACHEOFF.PRG affect the secondary cache? IIRC, the Pak board has a
couple of levels...

EDIT: There is a CPU cache and a SLC - secondary level cache.

[DarkLord]

Okay, just some more results, running the CPU test only, with the CACHEOFF.PRG
both running and not...then I think I'll quit for the night - head hurts.

Running the CPU portion of GB5, averaging 20 tests, I'm getting 3915%, most of
the time, like 17 out of 20 tries. The other results I'm going to regard as "fliers"
although I don't know what's causing the difference. The other 3 were slower,
like 2406%.

Now, doing the exact same thing with CACHEOFF.PRG running changed the results
almost not at all.

Don't know what's going on with that. I did catch the message when I ran it this
time. Something like "CPU cache turned off"?

I'll let you experts ponder what all this means (if anything?), possibly changes from
the chips as they heat up during use? I've had my STacy on for about 3-4 hours straight
now, running these tests. Nary a crash or lockup. if that counts.

[rpineau]

Weird. I'm fairly sure my code does disable both internal cache on the 68030 (I just checked the 68030 UM again and setting all the bit to 0 disable the caches and flush them). If the PAK as an external cache it is not affected by my prg.