New products for C64 and Amiga from Individual Computers

[Schoenfeld]

You're assuming that memory speed is a bottleneck. It isn't. The 68020 will run 0-waitstate with 1/2 or 1/3 divider. Even at 66MHz mem and 33MHz CPU clock. Who said a 68020 can't be fun :-)?

For the 68030, triple mem speed compared to CPU clock doesn't help, as it only gains half a clock cycle. In order to gain speed at all, you need to gain a full cycle in order to shave off a waitstate. You might think that this may work for a divider of 4 and 100MHz memory speed, but it's not that easy either, because if you go higher with memory speed, you must insert NOP cycles in order to meet memory timing requirements.

The one thing I always wanted to try is to disable 68030 caches completely and start cycles early with the ECS signal (external cycle strobe). I might prepare the mass-production boards for that - maybe I'll have time for that someday :-)

Jens

[TotO]

Hehe. OK, great.

The 68030 is finally just a 68020 improvement, "fixing" some things and adding cache.
So, sure, if today a 68020 can run at 33MHz if may be faster than a 68030 using your architecture.

But, if the 68030 cache should be fully disabled you may seriously increase performance by reaching highest frequency ? (the embedded memory cache may goes defective but the CPU running well w/o)

[Schoenfeld]

Originally Posted by TotO

Hehe. OK, great.

The 68030 is finally just a 68020 improvement, "fixing" some things and adding cache.
So, sure, if today a the 68020 can run at 33MHz if may be faster than a 68030 using your architecture.

Well, the 68030 is more than that, especially with it's faster bus interface.

Originally Posted by TotO

But, if the 68030 cache should be fully disabled you may seriously increase performance by reaching highest frequency ? (the embedded memory cache may goes defective but the CPU running well w/o)

Disabling the cache would be well within specifications. There is a pin on the CPU that is dedicated to doing just that. It has nothing to do with "defective". Motorola has prepared the 68030 bus interface for an external cache controller, and if I can make a memory controller that is as fast as a cache-hit, you don't require the on-chip caches any more. It would be like 128MByte first-level-cache (well, if it works the way I'm thinking).

Jens

[TotO]

Originally Posted by Schoenfeld

Well, the 68030 is more than that, especially with it's faster bus interface.

Disabling the cache would be well within specifications. There is a pin on the CPU that is dedicated to doing just that. It has nothing to do with "defective". Motorola has prepared the 68030 bus interface for an external cache controller, and if I can make a memory controller that is as fast as a cache-hit, you don't require the on-chip caches any more. It would be like 128MByte first-level-cache (well, if it works the way I'm thinking).

Great!
Sure, "defective" is not the good word. I would like to said that using an external cache you may clock the 68030 faster, if the internal cache was a limitation to increase the speed.

[Lord Aga]

Originally Posted by Schoenfeld

Motorola has prepared the 68030 bus interface for an external cache controller, and if I can make a memory controller that is as fast as a cache-hit, you don't require the on-chip caches any more. It would be like 128MByte first-level-cache (well, if it works the way I'm thinking).

Jens

In the spirit of true Amiga ingenuity

[SpeedGeek]

Originally Posted by Schoenfeld

Well, the 68030 is more than that, especially with it's faster bus interface.

Disabling the cache would be well within specifications. There is a pin on the CPU that is dedicated to doing just that. It has nothing to do with "defective". Motorola has prepared the 68030 bus interface for an external cache controller, and if I can make a memory controller that is as fast as a cache-hit, you don't require the on-chip caches any more. It would be like 128MByte first-level-cache (well, if it works the way I'm thinking).

Jens

The 68030 can run a 2 clock synchronous (external) cycle. However, the internal cache can be accessed in one clock. So an external cache will never be as fast as internal but you can get pretty close with a 2+1+1+1 burst cycle on reads. If can you can make a memory controller which can do that for fast memory than the external cache would be obsolete.

[Schoenfeld]

Originally Posted by SpeedGeek

The 68030 can run a 2 clock synchronous (external) cycle.

Really? The way I'm reading the datasheet is that STERM is sampled on the next half-clock after AS, and the cycle can be completed on the half-cycle after that, so the total time after AS would be a single cycle.

If you count from ECS, this would be 1.5 cycles. Either way, it's a full cycle less than the fastest access that I have done before. ACA1231 beats the crap out of the B1230-IV, despite almost 20% lower clock rate. So much for "on-chip cache hit rate of the 68030".

Jens

[SpeedGeek]

Originally Posted by Schoenfeld

Really? The way I'm reading the datasheet is that STERM is sampled on the next half-clock after AS, and the cycle can be completed on the half-cycle after that, so the total time after AS would be a single cycle.

If you count from ECS, this would be 1.5 cycles. Either way, it's a full cycle less than the fastest access that I have done before. ACA1231 beats the crap out of the B1230-IV, despite almost 20% lower clock rate. So much for "on-chip cache hit rate of the 68030".

Jens

Yes, but AS is asserted 1/2 clock after the cycle begins unless a cache hit causes the 68030 to abort the external cycle! So it's 1.5 clocks from AS or 2 clocks from ECS. With your 2x clocked SDRAM I would be surprised if you didn't beat the crap out of any older DRAM based design operating at similar (68030) clock speeds.

[Schoenfeld]

Originally Posted by SpeedGeek

Yes, but AS is asserted 1/2 clock after the cycle begins unless a cache hit causes the 68030 to abort the external cycle! So it's 1.5 clocks from AS or 2 clocks from ECS.

Here's a quick hack: Disabled one of the two 64M banks and added a simple equation that pulls STERM as soon as AS becomes valid on the area. CPU is a 68030RP25C, clocked at 25MHz. This looks like a single cycle to me:

However, you also see a problem with ECS and cache active: If the CPU hits a valid cache entry, the time until the next ECS is very short. Now if you open a row "just in case", you must go through the whole cycle of precharge and Precharge-to-row-open time before you can open the next row. Trouble is that the CPU may start the next access no more than two cycles after that, and you must be ready, otherwise you don't win but even lose time.

Disabling the cache makes sure that there's always an access after ECS:


At true 0-waitstate, I wanted to know the difference between "cache and no cache", so I tried bustest. First with all caches disabled:

...and then with all caches on (which also turns caches&burst on for the Bustest inner loop):

...and this looks like a measurement error to me, 'cause the read values are too close together. Write value is even more of an indication of a measurement error, because Cache is not updated on writes. Only the fastmem, which gains a lot from bursts, is a tiny bit faster.

Originally Posted by SpeedGeek

With your 2x clocked SDRAM I would be surprised if you didn't beat the crap out of any older DRAM based design operating at similar (68030) clock speeds.

I may be a memory cycle short to complete the time after precharge, but this quick measurement hack shows me that my idea of "external cache equals internal cache performance" is close to being correct. You must be right in terms of "burst helps", because fastmem with cache+burst is faster than the 0-waitstate area.

I'll need triple memory speed vs. CPU speed to really become fast enough to "play cache". Is it worth it? Not sure. I have to sacrifice at least one pin on the logic chip, and pins is what I'm always short of. I'd have to work on the memory controller in terms of "close the row ASAP if no access" in order to work with cache, and I need more state-bits for the memory controller because I need to stretch burst accesses. Need to draw some state diagrams...

Jens

[SpeedGeek]

Originally Posted by Schoenfeld

Here's a quick hack: Disabled one of the two 64M banks and added a simple equation that pulls STERM as soon as AS becomes valid on the area. CPU is a 68030RP25C, clocked at 25MHz. This looks like a single cycle to me:

However, you also see a problem with ECS and cache active: If the CPU hits a valid cache entry, the time until the next ECS is very short. Now if you open a row "just in case", you must go through the whole cycle of precharge and Precharge-to-row-open time before you can open the next row. Trouble is that the CPU may start the next access no more than two cycles after that, and you must be ready, otherwise you don't win but even lose time.

Disabling the cache makes sure that there's always an access after ECS:

At true 0-waitstate, I wanted to know the difference between "cache and no cache", so I tried bustest. First with all caches disabled:

...and then with all caches on (which also turns caches&burst on for the Bustest inner loop):

...and this looks like a measurement error to me, 'cause the read values are too close together. Write value is even more of an indication of a measurement error, because Cache is not updated on writes. Only the fastmem, which gains a lot from bursts, is a tiny bit faster.

I may be a memory cycle short to complete the time after precharge, but this quick measurement hack shows me that my idea of "external cache equals internal cache performance" is close to being correct. You must be right in terms of "burst helps", because fastmem with cache+burst is faster than the 0-waitstate area.

I'll need triple memory speed vs. CPU speed to really become fast enough to "play cache". Is it worth it? Not sure. I have to sacrifice at least one pin on the logic chip, and pins is what I'm always short of. I'd have to work on the memory controller in terms of "close the row ASAP if no access" in order to work with cache, and I need more state-bits for the memory controller because I need to stretch burst accesses. Need to draw some state diagrams...

Jens

You just confirmed a zero wait state synchronous cycle takes 2 clocks! Remember AS is negated 1/2 clock before the cycle ends. The best way to avoid the row open and pre-charge penalties is to qualify the start of your memory cycle with AS since an external cycle can be aborted after ECS is asserted. ECS is more practical for SRAM based cache (no penalty if cycle aborts) or DRAM refresh arbitration. Another potential problem with ECS is address valid times are not guaranteed with ECS assertion since the address bus often has a greater device or capacitive load and/or address buffers before memory logic (but the on board logic may delay RAS assertion long enough to solve that problem).

I have found Bustest to be most accurate with the instruction cache enabled and data cache disabled. Even so, Bustest results can vary for a number of reasons:

http://www.amibay.com/showthread.php...338#post314338

Also, please remember that Burst is a cache mode so if you disable the cache you also disable Burst!

Kevin

[AmigaDave]

@Schoenfeld.

I haven't visited EAB often enough to keep up with this thread, so forgive me if this question has already been answered.

Are you attending the 2012 AmiWest Show in Oct., and will you be bringing accelerators for the A500, and/or A1200 with you to the show for sale, or just for demonstration purposes?

It is always nice to see you there with new gear for sale, but I understand if the market has changed and if you have changed your selling model to pre-orders only.

Looking forward to AmiWest, maybe I can buy you a beer or two if you are there.

[Schoenfeld]

Dave,

although I love to travel, my recent experience(s) in the US were not exactly nice. Ever since I have decided not to use credit cards any more, I was treated like some alien wherever I went in the US. It appears like the entrance fee to the US (your visitor visa) can only be paid with a CC (or with huge hassle). Hence, I don't really plan to go to Amiwest.

I'm happy to attend a Skype conference or similar.

Jens

[SpeedGeek]

@Jens

If I owned as small company developing new Amiga products I would not waste my time and limited financial resources on AmiWest or any similar event. (and I live in USA!) The Internet offers a vastly more economical means of promoting your products. Most Amiga users just don't understand the practical realities and economics in a market place where failure and bankruptcy are the standard and success is the exception.

Kevin

[Schoenfeld]

Last year and the year before, I have combined the trip with meetings with chipset manufacturers (Broadcom, Nuvoton), so I have paid the trip from the Nequester project pool. The total cost for the "Retro pool" was the sponsoring of the show itself.

If you can organize a meeting with a fibre, cable or xDSL operator who may be interested in a high-quality VoIP 750MBit wireless 11n router, I wouldn't have a money problem.

Amiwest has always been fun, and I always like to meet Amigans. It's not about selling, but about meeting people. You can't really meet people through an online connection only. However, I have to report to an investor who is feeding me risk capital since 2009 for the Nequester project. If I spend that kind of money for a trip, I better have some good story about potential Nequester sales. That would also get me past my own border of trying to pay the visitor visa without a CC.

Jens

[Calabazam]

Just out of curiosity, what is the point of not using a CC?

[Schoenfeld]

(off-topic, but I think everyone should know)

Out of every credit card purchase, a percentage (up to 5%) goes to the credit card company - "the bank". In Europe, most credit cards work like the American "Debit cards" where you spend however much you're allowed to, and it's taken from your account with a monthly bill. However, they're starting to introduce the "American type credit card" in Europe as well, where you can (over)spend amount X, but you're only allowed to pay back a certain share every month. The rest is paid back in the following months and you pay lots of interest for that money (up to 18%).

In essence, you're feeding the banks if you use credit cards. Banks already have too much power. I know I won't make a significant difference by not using credit cards (not even having one any more), but who knows - if you guys all stop using credit cards and don't pay all those (hidden) fees any more, you might have more spare cash to buy Amiga goodies ;-)

Jens

[Phantom]

I never had and I don't plan to have a Credit Card. Cash does the job just fine!

[DDNI]

Cash = No Tax

[wXR]

@Schoenfeld really true.

do you have any familiarity with the cryptocurrency concepts that are coming? bitcoin being i guess the most prominent one, if not the only one that is working (somewhat) already.

[alenppc]

Hmm, well you get the minimum required payment on your credit card, but nothing prevents you from paying the full amount and not paying any fees, just don't overspend what you don't have.

I use almost exclusively my credit card, since I never pay any interest on it (always pay the full bill), there are no yearly fees and I get a 1% cashback on all purchases. I try not to carry cash at all.