Vampire 600 more cores..

[Turran]

So I finally got my USB-Blaster today. Since I had core 0.1 loaded, it only has 5 MB of fast ram. Wanted to try core 1.0 which has 64MB.

Loaded it up fine, but its very unstable, as its described so no news there.

What I was wondering is; is there anyone else making cores for this baby? I'd like the stability of 0.1 but with at least 8 MB memory.

[lukassid]

Majsta switched his interests to bitcoin instead of charging 50 euros more for each Vampire and enjoy bank account filled with cash. I would rather pay 140 euros for nice accelerator than 90 for half working crap. Idea was right but nobody will develop fast accurate core for nothing. Sorry but I don't understand working long time on the product that people want and willing to pay for it, than selling the product with minimal or no profit just to drop everything coz I need money. I wish Majsta all the best, he was always honest and kind.

[voyager]

It's really sad, think a lot a people would pay extra for there vampires so he could make a nice profit.

[Turran]

Yeah, I was wondering about his bitcoins venture. Sounded like a very bad idea =(

[NovaCoder]

There are actually a few people left in the Classic scene that have the skills to finish this, in fact I was actually talking to one of them at the local Amiga meeting the other day.

I don't know all the details but apparently there are various 68k cores in different states of development that could be used. I guess the currently problems are something to do with the bus/timing logic and not the core itself?

It's a real shame to leave the thing so close to finished. If this A600 board was fully developed (eg fast/compatible and stable) then an A1200 board wouldn't be far behind.

[chaos]

You know, some people said making Amiga FPGA accelerators was a bad idea Just let the man do his thing, the least he'll gain is knowledge.

[Brannigan]

Originally Posted by NovaCoder

local Amiga meeting

What is this local Amiga meeting? Please tell me more

[alexh]

Originally Posted by Turran

Yeah, I was wondering about his bitcoins venture. Sounded like a very bad idea =(

I did try to tell him that he missed the boat by 5 years.

[pandy71]

He prove something and AFAIR He open source thus i see no issues to fix/improve core - as i don't have A600 i was not interested in Vampire personally (as Majsta stuck on reimplementing HDD functionality from Gayle for A500 version).
Thing can be for sure improved: less cycles per instruction, deeper pipeline, cache, new instructions, higher clocks etc only FPGA resources are limitation.
Perhaps some startup on Kickstarter for this?

[Lord Aga]

Don't worry, Majsta did not give up
Amiga development is only on hold until he sorts out the mining rigs. It's not like he has to participate in mining actively
He'll be back at his Workbench soon enough

[Promilus]

Actually it's GPL so anyone with mild skill in VHDL can modify sources. For your information the file you should check is Vampire_600.vhd; there you can make it work with more RAM (so use 32bit zorro space for autoconfig) but it won't get any faster through that. Only that "unstable" core is made for speed. It's kinda sad - majsta gained quite large pre-paid beta testers to catch and resolve all bugs in softcore yet just released sources and went bitcoin mining :/

[robinsonb5]

Originally Posted by Promilus

Actually it's GPL so anyone with mild skill in VHDL can modify sources. For your information the file you should check is Vampire_600.vhd;

Yes, indeed - this stuff isn't rocket science - it's just rather time-consuming.

there you can make it work with more RAM (so use 32bit zorro space for autoconfig) but it won't get any faster through that.

The speed difference between the two cores comes from the slow one using a simplified SDRAM controller that doesn't do any caching, and the unstable one using the two-way cache from my TG68MiniSOC project (which is also in the Chameleon64's Minimig core).

[T_hairy_bootson]

Originally Posted by Brannigan

What is this local Amiga meeting? Please tell me more

Linky

[tnt23]

Originally Posted by robinsonb5

The speed difference between the two cores comes from the slow one using a simplified SDRAM controller that doesn't do any caching, and the unstable one using the two-way cache from my TG68MiniSOC project (which is also in the Chameleon64's Minimig core).

Wow, cool. I was thinking about caching within my Zorro SDRAM card, now will check out your TG68MiniSOC project

[NovaCoder]

Originally Posted by Brannigan

What is this local Amiga meeting? Please tell me more

I was talking to the guy who designed this -> Flea FPGA, he's a very clever chap

There are a few people like this still in (or at least near) the Classic scene.

[Brannigan]

Originally Posted by NovaCoder

I was talking to the guy who designed this -> Flea FPGA, he's a very clever chap

There are a few people like this still in (or at least near) the Classic scene.

That's a nice board. I like the size of it and all the peripherals.
I was more wondering about this Amiga meeting you mentioned. Is it some kind of Amiga user group here in Melbourne? And if so, how can I get in touch?

[NovaCoder]

Amiga meeting details are right here

Originally Posted by T_hairy_bootson

Linky

[Promilus]

Originally Posted by robinsonb5

Yes, indeed - this stuff isn't rocket science - it's just rather time-consuming.



The speed difference between the two cores comes from the slow one using a simplified SDRAM controller that doesn't do any caching, and the unstable one using the two-way cache from my TG68MiniSOC project (which is also in the Chameleon64's Minimig core).

Well I thought 0.1 core is 68000 compatible only with 24bit address bus (just as the original) while 1.0 core is almost full 68020 compatibility (most instructions, 32b space, caching). Plus I thought all "instability" comes directly from cache (some apps doesn't like it) so it should be easy to fix without changing core - just as it was quite easy to "fix" while running those apps on 060.

[robinsonb5]

Originally Posted by Promilus

Well I thought 0.1 core is 68000 compatible only with 24bit address bus (just as the original) while 1.0 core is almost full 68020 compatibility (most instructions, 32b space, caching).

That's all true, but unlike a "real" 68000 and 68020, the softcore isn't significantly faster with 68020 instructions enabled - the extra speed comes from the cache.

Plus I thought all "instability" comes directly from cache (some apps doesn't like it) so it should be easy to fix without changing core - just as it was quite easy to "fix" while running those apps on 060.

Yes, I'm sure there are various things that can be done to fix it. I had the Vampire 500 prototype Majsta sent me working pretty well with the '020 core and Fast RAM - but haven't had time to take it further yet. Pinball Fantasies currently doesn't work, and I think that's an address-decoding thing because I've seen that problem on some builds of the Chameleon Miniimg core too. With the Minimig core I've found it's easy to end up with build-to-build stability problems, though - and this seems to get worse as the FPGA fills up. I think there's an element of that problem in the Vampire core, too, which makes debugging much harder than it needs to be.

[matthey]

Originally Posted by robinsonb5

That's all true, but unlike a "real" 68000 and 68020, the softcore isn't significantly faster with 68020 instructions enabled - the extra speed comes from the cache.

The 68020 complexity would probably slow down the CPU clock speed with everything else the same but then more powerful 68020 instructions give a significant speed boost when used. I would expect the same in silicon. It would be easier to make a high clocked 68000 than 68020+. I'd rather have an enhanced 68020 though .

Yes, I'm sure there are various things that can be done to fix it. I had the Vampire 500 prototype Majsta sent me working pretty well with the '020 core and Fast RAM - but haven't had time to take it further yet. Pinball Fantasies currently doesn't work, and I think that's an address-decoding thing because I've seen that problem on some builds of the Chameleon Minimig core too. With the Minimig core I've found it's easy to end up with build-to-build stability problems, though - and this seems to get worse as the FPGA fills up. I think there's an element of that problem in the Vampire core, too, which makes debugging much harder than it needs to be.

Hmm. I wonder if that's part of the problem with getting the fpgaArcade out too? What's the problem as the fpga fills up? Does the timing get worse than simulated?

P.S. I left a message on the Apollo forum about the problems but Majsta seems to be AWOL.