What sort of price are we looking at?

ta-da!

DENEB is available for a recommended end user price of 139.95EUR (incl. VAT) directly at E3B (http://www.e3b.de/usb/) as well as at selected Amiga dealers.

Last edited by Stephen_Robinson on 07-May-2008 at 05:54 PM.

_________________
Rage quited 29th May 2011

Amiga Kit lists it as £112.99 This looks like a brilliant little card but sadly for me, I can't afford it at that price

Order placed

I really hope the OS4 dma issue can be resolved some how.

_________________
4000T/BFG9060
CD32/Elsat ProModule, TF360
CD32/ Edu's CD32 <> A1200 Adapter, Vampire V2
CD32/ FMV Module

Thank you- much appreciated!

_________________
Amiga Kit Amiga Store
Links: www.amigakit.com | New Products | A600GS

@mboehmer_e3b

Quote:

Neither Prometheus nor Mediator nor G-Rex use DMA on Zorro III. They all use fake DMA only on PCI side between one PCI card and the PCI gfx card. Data between PCI and Amiga Classic is transfered by PIO.

I understood that you were planning to "fix" the DMA issues on the Prometheus - is this still on the cards?

Will the DMA knowledge you have gained in the Deneb development be helpful in this?

If you do begin work on this, would your aim be to enable Z3 Buster-controlled DMA for the prometheus? If so, would this affect its operation in conjunction with Deneb?

Thanks for all your hard work, I have a Deneb on order with Amigakit.

Best Regards



Rich

_________________
Troll - n., A disenfranchised former potential customer who remains interested enough to stay informed and express critical opinions.
opp., the vast majority who voted silently with their feet.

Quote:

I understood that you were planning to "fix" the DMA issues on the Prometheus - is this still on the cards?

Yes, if time permits. Some important personal issues are now on highest priority.

Quote:

If you do begin work on this, would your aim be to enable Z3 Buster-controlled DMA for the prometheus? If so, would this affect its operation in conjunction with Deneb?

I do not begin with this, it is finished. Only some software issues to be finished, like creating archives and installers. Z3 Buster DMA for Prometheus is out of question due to limitations in the CPLD architecture used there. Despite the Prometheus offers more logic resources than comparable Mediator boards, the resources are too small.
Real Zorro III DMA needs some workarounds to work properly, and without FPGA this is a pain. Last part of question therefore is no.

With a FPGA like the DENEB ones it would be possible to think about direct DMA conversion from PCI to Zorro III, but even this is a tricky business, as you need to bridge from a fast synchronous burst-orientated bus to a relatively slow asynchronous one with single shot operation.

Quote:

Will the DMA knowledge you have gained in the Deneb development be helpful in this?

No. This knowledge may be helpful for other issues, but not the Prometheus business (which was finished before DENEB project).

E3B will (after the private issues ) now focus on possible bug fixes for the DENEB FPGA firmware, if necessary, and maybe adding some improvements or additional features, if needed and / or possible (hard to get better after three year development

Michael

ok..great product now if only I could use it in my 1200

Last edited by xyphoid on 08-May-2008 at 03:56 AM.

@mboehmer_E3B
Excellent, thanks for the update!

Regards



Rich

EDIT: added the name of the person to whom I was speaking.
EDIT: Re-worded sentence previously ended with a preposition.

Last edited by Boot_WB on 18-Oct-2009 at 03:47 PM.
Last edited by Boot_WB on 14-Jun-2008 at 07:15 PM.

_________________
Troll - n., A disenfranchised former potential customer who remains interested enough to stay informed and express critical opinions.
opp., the vast majority who voted silently with their feet.

Great piece of work, with a bit of prodding will also be able to get it to fit onto A500s.

But.. just one worry.

Placing Deneb on an A500, is similar to placing it on an A500 clone, such as a MiniMig.

MiniMig has FPGA, USB port, and the whole OCS chipset, and a 68k CPU, and is the Same price as the Deneb?

Is the price listed primarily due to limitations of restriction in supply and demand, and amount of work required?

If so, would it be better to make basic addons for the classics, such as Parralel or IDE to USB using simplified systems, as anything more complex, might as well be created as a Full system replacement, such as MiniMig, AGA, etc?

RodTerl

Cant even afford a 2nd hand DS classic, never mind a MiniMig 8(

_________________
The older and more respected a scientist is, the longer it takes to prove him wrong.

Ooohh... Why can't we ever get USB 2.0 for AmigaOne OS4??

_________________
- Don't get fooled by my avatar, I'm not like that (anymore, mostly... maybe only sometimes)
> Amiga Classic and OS4 developer for OnyxSoft.

Quote:

MiniMig has FPGA, USB port, and the whole OCS chipset, and a 68k CPU, and is the Same price as the Deneb?

Thanks for your comment, as you do not just start bashing but asking first.

First of all, DENEB is targetting big box Amigas and CPUs including 030 and above. The A500 is not our main target for this product.

I will try to explain now where the differences in both products are, and why comparing them is not a fair issue. Don't take it as offense for Minimig, which I consider a very nice piece of hardware demonstrating what's possible with nowadays technology.

Using Minimig as comparison is not a perfect deal. Minimig was developped by a single person on a private base. It wasn't aimed at marketing. Minimig comes without Kickstart, without Workbench, without software, just as a bare PCB.

The development of DENEB included two persons, one for hardware, one for software. DENEB includes a licensed OEM version of Poseidon as well as a set of software utilities. Both cost time and money.

Let's take a look on the hardware: the Minimig is a double sided PCB, has only standard components and no visible specialities. DENEB uses a four layer with edge connector, 100pins hard gold plated. Gold is expensive, especially as hard plated connector version.

Next thing to think about : development. In Minimig case, development, PCB layout and FPGA design was done by Dennis, which may see some part of the money or not (don't know how the deal is). Minimig is stand alone, has not to take care about software or hardware compatibility issues to existing systems.
DENEB was developped from scratch, had four different PCB steps in between, and both FPGA design work and PCB layout are to be taken into account. And DENEB has to take care about compatibility issues, as well as providing bug fixes and work arounds for broken hardware it will have to work with (CS MK2, Kickstart, Buster, bus boards).

Documentation: both products have one, so no differences.

RoHS / EAR: Minimig is not registered at EAR as product, and I can't say anything about RoHS compliance. We as producer have to take care about these issues ourselves, and provide an EAR registration which is definitely not for free. We have to take care about recycling of our product, which is an issue not foreseen in Minimig cases, as I learned at a user meeting in Nuernberg recently.

So, let's resume: you have a product Minimig manufactured by a company at almost no development but only material and production cost. The other product DENEB has to take full development costs into account, as well as a complex set of software stuff and cope with existing (partially buggy) hardware. Minimig is priced at 159EUR, DENEB at 139EUR (both prices in Germany, same dealer Vesalia).

Do you see the differences now, and get an impression which product ist the "more expensive" one?

Michael

Quote:

Non-linear memory on standard AllocMem(), which is used in many programs. Amiga Classic delivers linear memory, while OS4 gives a sum of little pages, which are not ordered.

AllocMem never gave any guarantees about pages and how they are ordered. A lot of broken software assumes so, but that is not a problem of the OS 4 memory system.

Quote:

In OS3.x this works fine, in OS4.x it fails, as the AllocMem() functionality has been made incompatible with OS3.x.

No, they haven't. Point me to the place in the Autodoc where it says that pages are continous. The presence of CachePreDMA/CachePostDMA already implies that this need not be the case in OS 3.x. It was the case under 3.x, but that is another matter.

Quote:

Behaviour did get better, but is still unstable.

That might be, but that is a bug in a function, not a "broken memory system". Instead of claiming that OS 4 has a broken memory system, you might have written a mail and I could have looked into the issue.

Quote:

I know that such memory models may have advantages for programmers, but for DMA hardware it makes life unnecessarily complicated

It has advantages for everyone. The fact for example that there is virtually no memory fragmentation on OS 4 is a good argument. All modern DMA controllers support scatter/gather operation anyway. This isn't any different on other OSes either.

If you really need continuous memory, that can also be arranged (there is a tagged AllocVec function), but it is not accessible from the 68k side.

Quote:

in my opinion this change in memory model was not a wise decision for existing hardware

IIRC the cybppc.device uses DMA as well. The change was necessary, and no PCI hardware I know of has any issues with it.

Quote:

Elaborate enough?

Not really. You are basically looking for an excuse not to implement DMA by claiming wrongfully that OS 4 has a broken memory system, The only issue in OS 4 is the problem with the CachePreDMA/CachePostDMA function, which could have been resolved if we had a test case. Other than that, your drivers are making false assumptions about the behavior of system functions, working on implementation-specific details that were never part of the specification and in fact are clearly pointed out as invalid by the mere presence of CachePreDMA functions.

_________________
Seriously, if you want to contact me do not bother sending me a PM here. Write me a mail

Quote:

Elaborate enough?

However elaborate it was, it would have been much easier to actually contact me (it's not as if you don't have my email address or are in constant contact with Timothy), and elaborate THERE instead of in different fora that I'm not reading on a regular basis anymore.

But sure, it's much easier to whine in a public forum, blaming others instead of contacting the people that could actually help directly. But it seems to be the normal behavior in Amiga companies to think that all communications should be on message boards instead of email or phone.

_________________
Thomas, the kernel guy

"I don't have a frigging clue. I'm norwegian" -- Ole-Egil

All opinions expressed are my own and do not necessarily represent those of Hyperion Entertainment

Quote:

There already was a Thread from mboehmer on amiga-news.de about the 'broken' OS4 DMA in january.

I do not read amiga-news.de, nor do I regularly read other forums. However, my E-Mail address isn't exactly a secret, so if there was any *real* wish to resolve the issue (and from what I read, there isn't), I could be contacted.

_________________
Seriously, if you want to contact me do not bother sending me a PM here. Write me a mail

Quote:

Nevertheless, PIO works just fine, so this DMA bug in OS4 was not urgent.

No whining is much more urgent, true

_________________
Thomas, the kernel guy

"I don't have a frigging clue. I'm norwegian" -- Ole-Egil

All opinions expressed are my own and do not necessarily represent those of Hyperion Entertainment

Quote:

All modern DMA controllers support scatter/gather operation anyway. This isn't any different on other OSes either.

And again, I'm talking about OS4 Classic, and there are no modern DMA controllers with scatter / gather option, at least to my knowledge. Correct me if I'm wrong, but DMA on Zorro III is limited to A4091, Fastlane Z3 and DENEB. First two fails as no PIO mode is possible, latter one works in PIO (which is a viable workaround for users, anyhow).

Quote:

IIRC the cybppc.device uses DMA as well. The change was necessary, and no PCI hardware I know of has any issues with it.

AFAIK the SCSI controller behind that device does support some kind of scatter / gather, but it's hard to tell as no data sheets are available any more.

PCI hardware: again, we're talking about OS4 Classic. There is no DMA on PCI solutions there which is hindered by the memory issue. And PCI DMA controllers usually have already scatter / gather functionality, or at least the PCI bridge between CPU and PCI has it.

We're talking about Zorro III cards and the A4000T internal SCSI controller.
Do you expect any updates for that cards from the manufacturers?

Quote:

You are basically looking for an excuse not to implement DMA by claiming wrongfully that OS 4 has a broken memory system.

Don't take me wrong, but we *have* implemented a working DMA system under OS3.x with correct CachePreDMA() and CachePostDMA() handling. I need no excuses. We have also implemented correct treatment for the memory chunks, and with the February update it still doesn't work.
So if I have working DMA under OS3.x and failures under OS4.0 on the same machine what conclusion would you draw?

Changing the system behaviour of a system in a way that old software "making false assumptions" is bound to fail makes a system for me broken.

Quote:

The only issue in OS 4 is the problem with the CachePreDMA/CachePostDMA function, which could have been resolved if we had a test case.

As I said before: we take the results of CachePreDMA() and CachePostDMA() into account, and still fail on DMA under OS 4.x Classic.

Quote:

Other than that, your drivers are making false assumptions about the behavior of system functions, ...

Still, I haven't seen any explanation why backward compatibility to the existing hardware has been given up for not obvious reasons. You know that quite some software out there (almost all for M68k based classics) makes these "false assumptions", and that no way of correcting this is available, as most programs are not actively developped anymore?

Michael

Quote:

As I said before: we take the results of CachePreDMA() and CachePostDMA() into account, and still fail on DMA under OS 4.x Classic.

Then why did you moan about OS4 being broken on public forums instead of taking your concerns to the OS4 development team and trying to fix the problem?

Don't get me wrong, I respect that you are an intelligent person and you do make excellent products (I used to have an Algor and it was great), but really, this is not such a professional way to behave.

_________________
Playstation Network ID: xeron6

@

Does it really matter what is to blame here?
There are obviously 3 very bright people here that acknowlege a lack of function for a certain opperation. Perhaps the three of you can work together to come up with a solution for the DMA issue? It souds to me as though the OS4 team are willing and it will benifit all involved. You for your product and them for an improved product. Sounds win win to me :)

_________________
It's not the question that's the problem, it's the problem that's the question.

Hi guys,

I just contacted one of our discussion members here per PM and asked for proposals on how to debug this issue.

A simple and maybe very easy solution would be to patch the JIT in a way to provide always physically linear memory for M68k code. This way DMA should work as expected, and if it doesn't we know that there are other problems (timings, interrupts) to blame for.

This "patch" would also allow to use other DMA cards like the A4091 and FastlaneZ3 to check this behaviour, so we would have more than one test case.
I guess some OS4 developper have these cards laying around, and tests could be made very easily without providing every tester with a DENEB.

Sorry to all for any inconvenience caused by me. Let's solve this issue.

BTW, any volunteer for a FlashROM loader for OS4.x, like we have one for MOS (ups, both words in one line, please put aside the stones )

Michael

@mboehmer:

Very good solution and I wish all of you success with it!

Can´t wait to see your astonishing product running at full speed in my (lended out) A4000 with OS4. Maybe in short it´s time to retire the good ol´ (but nonetheless perfectly working!) Highway

Btw., would this solution for the DMA issue imply that some elder Zorro2 controller/RAM combo devices can be brought back to service with OS4? It´s a GVP Impact Series II SCSI/RAM combo, which is in question here. It´s no tragedy if this patch wouldn´t be a solution for this. Just curious

Regards