4MB Upgrade & 16MHz Booster progress

[DarkLord]

The Mega is a 8MHZ machine without cache.

Does your Mega not have the blitter chip in it?

[qq1975b]

Yes, but it is possible to disable it on dektop menu like on STe. Besides, I have another Mega 2 upgraded to 4 MB with TOS 2.06 and no blitter in it (is not compatible with the 1.44MB installed mod but I don't know why yet). So, I can test both to see if the results are the same +another Mega 4 with 1.04TOS. I will post everything here and someone can tell if it is ok for test purposes or not. If I can help at least in this...

It would be great if the 16MHZ board can be attached to a Mega with blitter.

[AtariZoll]

Mega STE at 8 MHz is practically same as STE, considering CPU is same as ST(FM) . Blitter can switch off. And it is normal that tests will give little lower results with TOS 2.06 - because it performs more things in regular interrupts.

qq1975b: you may run QINDEX22.PRG (DL link in this thread) to confirm said.

[exxos]

The forum hasn't been loading for me past couple of days, but here is GB4.

GBNCH403.zip

GadgetUK got his STFM with blitter working. So assume it will work on other machines. Though I think he had to connect the blitter clock to the CPU clock, so needs some track cutting. Though if I remember right, speeding up the blitter had no effect on speed either. Again, I think its a similar problem with the ROM.

After seeing the speed boost with 32bit alt-ram at 16mhz I think this is the only next step. Rodolphe and I have been talking about this the past few days and we are going to start a new 020 based card. This should basically rival the figures on the veloce.

I have been trying for hours to speed up the CPU clock beyond 16mhz. Though I hit the same problems as before. for example, the CPU can operate at 10mhz and 12mhz, but the ST will not boot. It seems to be a huge problem to sync odd multiples of clock speeds. 24mhz is the next step, but the 16mhz CPU will not run at this speed. Most of the 020 CPUs are 25mhz, so 24mhz is a easy work for it. There are 33mhz ones (be it stupid money), so possible this might work at 32mhz also.

32bit access will double the speed of alt-ram and ROM, so we can rival the 400% speeds on the veloce that way at 16mhz. If things go well, then we can try 24mhz speeds so the speeds would be 600%. Even 16mhz is still amazingly fast on the veloce anyway. Looking way down the line, I think a hard drive, probably IDE based to link straight onto the CPU bus will allow much faster hard drive access. The DMA is already maxed out so it becomes the next huge bottleneck.

Rodolphe also mentioned that the 020 has larger address space, so 4GB ram is possible. I doubt that will be fitted, but it depends on price of SRAM. It would be a huge boost in RAM in any case. Rodolphe is working on the 020 design currently, I don't know how long it will take, probably some months as much testing and coding needs to be done.

Meanwhile, I will try and start on the smaller basic 16mhz booster and the ST RAM upgrades.

[qq1975b]

Here there are the results:

Mega 4 TOS1.4 with blitter enabled:

Blitter 1.4.JPG

Mega 4 TOS 1.4 Blitter disabled:

No Blitter 1.4.JPG

Another Mega 4 TOS 1.4 Blitter disabled:

Another No blitter 1.4 (2).JPG

Mega 4 TOS2.06 without Blitter (no blitter chip on the motherboard):

No blitter 2.06.JPG

I have tested another TOS 2.06 Mega 4 with the Blitter disabled and showed the same results as the last one.

[exxos]

Seems in that case both TOS speeds are the same according to that then.

Still makes not sense though, as some speeds in my other post shows TOS206 faster, others slower results. I would try GB4 as that shows more tests. Then try TOS104 vs 206 and see what the differences are, then they can be deducted from my 16mhz TOS and we can see what the final differences are then. Tests done without blitter.

I will do a re-test with GB4 as it seems I was mixing GM3 before, just to make sure. Then once errors in TOS speeds can be omitted, then we can see what the final 16mhz ROM boost scores are. Its possible there is a 1-5% boost but I put that down to differences in TOS speed (104 vs 206).

[exxos]

I went back to basics tonight to try 8mhz mode, but the speeds work out slower than 100%. I did manage to fix this, but ultimately it broke 16mhz speeds

But as 8mhz speed is around 80%, then 16mhz will be 20% slower than it should. Ironically, I think the GAL logic is slowing down the access time by 20%, which means 16mhz would have to be 20% faster in order to break even with 100% scores... if that makes sense..

st1.jpg

Which if I deduct the error amount the actual speed differences are as follows..

err.jpg

Overall, ROM has to be running around 15% faster...

[exxos]

Well I am very pleased to say after about 50 emails to Rodolphe and some highly mathematical guess work on my part, I got this thing working

Here are the results just in!

16mhzROM.jpg

First row is 16mhz CPU 8mhz TOS
Second row is 16mhz CPU & 16mhz TOS
3rd row is the speed boost of 16mhz TOS.

[rpineau]

Brilliant !
I'm glad we got that one sorted out.
Rodolphe

[exxos]

Brilliant !
I'm glad we got that one sorted out.
Rodolphe

Indeed! I am glad I looked back into the 8mhz testing and un-forgot 8mhz was down in speed. Now if only I could get 20mhz working

[AtariZoll]

Well I am very pleased to say after about 50 emails to Rodolphe and some highly mathematical guess work on my part, I got this thing working
Here are the results just in!

16mhzROM.jpg

First row is 16mhz CPU 8mhz TOS
Second row is 16mhz CPU & 16mhz TOS
3rd row is the speed boost of 16mhz TOS.

But ROM access gain is only 18% . What is similar to test result with my proggy. It should be much more , at least 60% .
This is why I suggested to look timings with analyzer. I can supply test with permanent duration, if it helps . There will be only 2 CPU instructions involved - movem and dbra . So, will be not hard to see exactly where it works not as fast as it should.

[exxos]

The ROM access speed (in GB4) is not related to actual ROM speed ( possible bug in program) , it goes to 18% when CPU is boosted to 16mhz, not ROM itself. The speed boost is good around 30% and 41% for blitting speed, and it shows during testing there is a speed boost.

ROMSPT shows 119 (was 183 before) so 64% according to your program

[AtariZoll]

The ROM access speed (in GB4) is not related to actual ROM speed ( possible bug in program) , it goes to 18% when CPU is boosted to 16mhz, not ROM itself. The speed boost is good around 30% and 41% for blitting speed, and it shows during testing there is a speed boost.

ROMSPT shows 119 (was 183 before) so 64% according to your program

Yes, but that program tests only 52 bytes of ROM , again and again for 65536 times . Second test program tests on 192 KB ROM area, what is certainly better. With it gain is much lower - while code is same in fact, except 1 + sign , but execution time of loop core is same. And I supplied special version which tests 4 sections of TOS 2.06 separately, to see is access to all sections same.
Note that diverse graphic tests like VDI scroll, Dialogs depend more from RAM access speed than ROM access speed , even if code is in ROM.

[exxos]

The other program gives

138 ROM & 236 RAM. 16mhz CPU&ROM
244 ROM & 245 RAM. 8mhz CPU &ROM

Not much difference showing there at all. Probably speed gain comes into play when running actual routines, a small boost in speed even 1% on each instruction adds up over a lot of code.

[GadgetUK164]

Wow, awesome news!!! What was wrong then? Really curious to understand how TOS access at 16Mhz behaved as if it was running at 8Mhz?

[GadgetUK164]

Brilliant !
I'm glad we got that one sorted out.
Rodolphe

Indeed! I am glad I looked back into the 8mhz testing and un-forgot 8mhz was down in speed. Now if only I could get 20mhz working

Well done both of you =D

[exxos]

Wow, awesome news!!! What was wrong then? Really curious to understand how TOS access at 16Mhz behaved as if it was running at 8Mhz?

The problem being from what I understand, is that while the GAL code was correct in generating DTACK, we didn't factor in the GAL delays itself. Overall data should have been latched on cycle 4, but because of delays, it was cycle 5. This resulted in 8mhz operation being over 20% slower as the CPU was simply waiting for DTACK to be issued. So when we operated at 16mhz, it was like pure coincidence that the speeds ended up at 100%. Its why I thought there wasn't any speed boost.

Second problem was I couldn't get the speed boost to work at 16mhz after the mod. I think at 16mhz even 45ns ROM wasn't fast enough, so DTACK was being issued at the same time as the ROM was selected, so there was a 45ns delay. Basically resulted in random data on the bus when DTACK was issued.

So what I did was based on a idea Rodolphe had some time ago, in not syncing to /AS for address decoding. So ROM is actually always operating and decoding the address bus. This means the ROMs have something like 60ns head start. Now ROM is always decoding the bus, but ROM CS is not allowed until CPU issue /AS. Before decoding was only done when CPU issue /AS so that plus GAL delays and ROM delays, just added up to to much ns delay.

In anycase, we can now see a clear speed boost up around 20- 40%

[AtariZoll]

The other program gives

138 ROM & 236 RAM. 16mhz CPU&ROM
244 ROM & 245 RAM. 8mhz CPU &ROM

Not much difference showing there at all. Probably speed gain comes into play when running actual routines, a small boost in speed even 1% on each instruction adds up over a lot of code.

That is OK, and realistic result. Then: nice work
You wrote right after I posted second test proggy : RAM 236, ROM 183 - that was what worried me.

[troed]

Thanks for an interesting thread. Loved reading how you hunted this down.

[exxos]

Glad this thread is of interest. I am learning a lot about the 68000 and how things work myself. Rodolphe is way ahead of me in that respect though together we are starting to make some real progress now

[rpineau]

We learn one big thing .. there is a big difference between the theory and reality. When you write GAL code and simulate it (I use Cups in a Windows VM as there is nothing on OS X for that), you see the "perfect" timing of the signals. These simulations do not account for the GAL speed or anything so the simulation looks all fine.. and then you try it on the real hardware and nothing works !!.
So now that we got it right we can move forward with other idea we have.

Rodolphe

[GadgetUK164]

The other program gives

138 ROM & 236 RAM. 16mhz CPU&ROM
244 ROM & 245 RAM. 8mhz CPU &ROM

Not much difference showing there at all. Probably speed gain comes into play when running actual routines, a small boost in speed even 1% on each instruction adds up over a lot of code.

That is OK, and realistic result. Then: nice work
You wrote right after I posted second test proggy : RAM 236, ROM 183 - that was what worried me.

Thanks for writing that code at such short notice btw! Much appreciated, it has helped =)

[GadgetUK164]

Out of interest, could you do a test in Gem Bench? Just curious to see the overall effect when testing using that!

[exxos]

http://atari-forum.com/viewtopic.php?f= ... 95#p261347

That GB4 figures, just you can save the info to a txt file rather than keep taking screenshots

[qq1975b]

If you need to test anything else, just let me know.

It seems it will be compatible with blitter, right? Will the blitter work faster too? The Blitter in a MGSTE works at 8mhz, isn't it? I mean when you're running the mgste in 16mhz the blitter is not speeded up. Only Falcon has a 16 Mhz blitter?