New products for C64 and Amiga from Individual Computers

[duga]

Why would like to use the expansion port? The A500 is already (too) large.

[TotO]

I would like nothing...
You have better to read the topic instead of asking for things already answered.

[Calabazam]

I would prefer "you are on your own" and experiment with A570/A590/GVP and others...
Not to mention the zorro adapter available for the side port.

[ikonsgr]

Originally Posted by TotO

But, in theory it's address compatible...
Just you will have physical problems to add both on your computer.

Hmmm, perhaps then, if you remove the aluminum case, maybe you can fit them both and give it a try,dont you think?
Remove the 68000,then plug kippers2k ram card, and on top of that, plug aca 500! In that case, fast ram will also comunicate directly with the aca 500's cpu at full speed of 14Mhz, isn't that right?
Man, we are talking about serious stuff here... Multi floor amiga 500!

[TotO]

I'm not sure, because it look that the new CMOS CPU, the IDE controller and the embedded RAM may be located on the riser card... (I don't see them on the main board shown on the first page)

Anybody can answer?

[Schoenfeld]

Originally Posted by ikonsgr

I just wondering: From what i unsderstand so far, the on board 2mb ram of aca 500 is not fast ram (it's not reside in the 8mb pooll starting at $200000 right?)

You (and others in this thread) are making a fundamental mistake: You are trying to infer the type of memory by it's address. That's plain wrong. The accelerator is a completely new CPU/memory subsystem, which can control all access speeds and address spaces on it's own. I'm using this to my (and thus the user's) advantage by re-mapping $c0.0000 memory to fastmem and even relocate Kickstart to the accelerator's memory.

Originally Posted by ikonsgr

Remove the 68000,then plug kippers2k ram card, and on top of that, plug aca 500! In that case, fast ram will also comunicate directly with the aca 500's cpu at full speed of 14Mhz, isn't that right?

Nope, the speed on the 68000 socket is 7MHz and can't be changed with a simple plugin-adapter. Trust me, any expansion that already exists doesn't make sense from a performance point of view. You need a faster bus to gain real performance. The ACA500 is not the fastest thing in the world, but adding 7MHz "fastmem" would slow it down to a point where you can't call it "accelerator" any more, because the 68000 does not have caches at all.

Jens

[ikonsgr]

Thanks for clearing this up!
So if i get this right, once installed aca 500 you CANT USE ANYTHING ELSE (add on memory cards like keeper2k's,possibly other cards pluged on 68000 socket, or anything on the 86pin connector) except from trapdoor ram
[YES] [NO] ?

Btw, have you tested whdload with aca 500? Can the 68000/14mhz with 2mb ram, really handle whdload games, without any speed penalty? I'm asking this because if i'm going to buy this card for my Amiga 500, will be EXACTLY for that! Having the ability to enjoy at last, many multi disk games through whdload, without the endless disk loading and swaping!

[TotO]

Originally Posted by Schoenfeld

The accelerator is a completely new CPU/memory subsystem, which can control all access speeds and address spaces on it's own. I'm using this to my (and thus the user's) advantage by re-mapping $c0.0000 memory to fastmem and even relocate Kickstart to the accelerator's memory.

That true.
Toni has explain that in the afternoon. It's not exclusive to Paula. Sorry.

[lurch]

Will be watching this space :-) Zeus68k / ACA500 very exciting times :-)

Hopefully will have enough saved for the release date, don't want to miss out :-/

[Methanoid]

Originally Posted by Schoenfeld

It's not software-selectable, but putting a wire link between two spots. This will change the CPU clock divisor from 3 to 2. The crystal on the board is 50MHz and remains in place. The design is fully async, meaning that the CPU runs async to the A1200 and the memory controller runs async to the CPU.

Could you do the same tests that I have made? I mean bustest and sysinfo. I'd like to know how much faster the Blizzard 1220 is.

Jens

http://ami603.amiga-projects.net/blizz3.jpg

In summary

B1220 default 28mhz = 4851
ACA1220 16.67mhz = 3321
ACA1220 25mhz OC = 4262

For me, I'd be happy with an OC ACA1220 with all that extra Ram!!

Would have been a nice feature if Jens had given us a jumper block rather than needing to solder a wire in place (mk2 maybe???)

[Lord Aga]

A1220 MK2 with 28MHz 020 and a heatsink would be top stuff.

[TotO]

Only 1/2 and 1/3 divider from the 50MHz clock...
What can you do better with 3 more MHz in true???

EDIT:
OK, reading the next post it's no more the case.

[Schoenfeld]

Thanks for those values. I have optimized chipmem access further, and I have found that I'm flushing the caches too often. The mass-produced board has a slightly different wiring for the logic chips, so I can precisely identify if I need to flush caches or not (to experts: Function code lines were pre-decoded in the other CPLD, and are now wired directly to the memory controller). This has already helped performance on the ACA620, and it'll bring the ACA1220 higher as well.

Further, I have decided to not use a canned oscillator, but a PLL to generate the main frequency. The PLL is kind-of programmable with SMD resistors (bridges). This will make overclocking easier, but I won't get tired to emphasize that overclocking is done at your own risk. Memory design is overclocking-friendly, but the CPU is rated 16MHz by Motorola, so that's the highest frequency I will guarantee

Jens

[TotO]

OK, now the clock change not the divider... So, not only the CPU will run faster but the memory too.

[duga]

So it looks like we'll have a ACA1232 card based on the ACA1220 design, that's nice.

[Mr B]

Originally Posted by Methanoid

Would have been a nice feature if Jens had given us a jumper block rather than needing to solder a wire in place (mk2 maybe???)

I'd say it's a good idea to leave it for hardware mods, rather then jumper blocks, as it means the step to voiding your warranty is slightly larger. Also, it's slightly easier to see if someone fiddled with the pads, when your getting a fried accelerator back, and the buyer claims warranty.

[TotO]

Originally Posted by duga

So it looks like we'll have a ACA1232 card based on the ACA1220 design, that's nice.

Sure, you can see that since the first day. The 68030 free space on the top left on the board.

[amigakit.com]

We have added the products to our website:


ACA 1220 128MB Accelerator

ACA 620 Accelerator

[Schoenfeld]

Originally Posted by TotO

OK, now the clock change not the divider... So, not only the CPU will run faster but the memory too.

The divider is a different thing, outside the PLL (different solderpads and cooler required).

Originally Posted by duga

So it looks like we'll have a ACA1232 card based on the ACA1220 design, that's nice.

Even if ACA1220 and ACA1232 are built on the same circuit board, they are substantially different designs. The CPLDs contain completely different code, because the two processors require different timing.

Jens

[TotO]

Originally Posted by Schoenfeld

The divider is a different thing, outside the PLL (different solderpads and cooler required).

I know that. What I said is the frequency table show that the 020 always use a 1/3 divider factor and now increase the speed of the CPU and the RAM by increasing the clock.

Sure, it's always possible to hack the divider to 1/2, but it's not interesting because the available range are close and the user will lose much memory speed and risk to permanently damage the CPU, using a wrong jumper setting.

But for the predicted ACA1232 Board, it may be interesting to switch it to 1/3 if it embed a 25Mhz certified CPU. Allowing to increase the RAM speed from 50MHz up to 80Mhz for a close frequency.

[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.