DENEB various small issues

[mboehmer_e3b]

1) Thumbdrive must be in port 0 (internal port) in order to boot. If any other mass storage device is plugged in ahead of it it will not boot.

Not true. Tested on all ports, on ports of attached hubs, and various combinations of bootable (FFS) and non-bootable USB mass storage devices.
Booting is handled only by RDB entries, which are not present on FAT formatted sticks.

The port number just influences the sequence in which attached mass storage devices are recognized by the stack, not the boot order.

4) USB audio eats full 500ma of power. Locks up system even when plugged into a powered hub. A hub that Trident says it likes.

Blame the Taiwanese chip manufacturer who made the USB audio dongle. We have two USB audio sticks here which heated up during operation until the case of the stick got soft and melted. That's what I call inefficient power handling (both were 4USD parts from ebay, btw).

Recommandation: spend more than 5EUR on a quality stick, not the Taiwan junk from ebay.

Regarding hubs: not true - or better: if you draw more than 500mA as allowed by the specification, strange things will occur. If a device increases the load over the 500mA limit, the voltage will drop (to protect your Amiga), and with the dropped voltage the device seems to become unreliable.

The behaviour depends on the way the hub implements overcurrent situations, and almost no hubs uses a dedicated circuit to handle this.

5) PsdStackLoader never copies to envarc: during the install. This is a definite bug. I keep psdstackloader on floppy because of this.

Will look into this issue tomorrow.

   a) Installing Deneb software requires setting the rescue jumper so that the deneb 'hardrive' will appear on the desktop. Unfortunately this disables all usb devices and there is no thumbdrive to install to. Interesting dilemma , right? Perhaps an install CD with every card purchased?

Not true. "Dilemma" here is that you didn't read the manual (page 8, jumper description: "USB is only available as Zorro II in rescue mode. More information can be found in appendix A.").
Setting the "RESCUE" jumper automagically downgrades the USB host controller into Zorro II mode. You have full access to all USB functions (only limited by Zorro II transfer rates) in rescue mode.
We made this on purpose to have easy access to installation media (like USB sticks) even on systems with broken disk drives, missing CDROMs or no network card attached.
We really did try to get a solution where you just fit the DENEB into any Amiga system, and are able to install the whole Poseidon software without relying on the old and in many system inreliable mass storage devices like floppy disk or CDROM.
(apart from that: many old CDROM drives have problems with CD-Rs, so in case we had supplied CD-Rs as installation media, you would have complained here that we didn't provide really mastered CD-ROMs, I guess...)

   b) Upgrading Poseidon to a newer version causes usb stack to halt and thumbdrive you were installing to disappears and the usb cdrom you were installing from goes bye bye too! Ouch!

Not reproducable here, sorry. We installed several rescue systems on CF cards, and upgrading the Poseidon stack on the CF card attached by an USB reader did work.

In case you fail, there's still the option of manually copying the new files to the USB mass storage without restarting the Poseidon stack inbetween.

You just have to make sure that USB operation is not interrupted during the upgrade, as this will lock up everything (as you stated correctly).

   c) Neither Installer 43.3 nor MUI 3.8 which are required to install the Deneb software are included with the software on flashrom. Makes installing to an os 3.1 formatted drive (non-usb) a little difficult.

Not true. You can operate the whole USB stack from shell without MUI or installer (well, look into the Poseidon guide). Size of the installation FlashROM is limited, and neither MUI nor the new installer could be included, also regarding copyright issues.
It is clearly stated that MUI V3.8 is required for operation, so in case you don't have it on your system yet - don't blame us, as your system does not fulfill the requirements, simply said.

More later. Share your issues too.

/bin/done

Michael

[mboehmer_e3b]

So, I found some time to verify your issues. Let's start:

1) Thumbdrive must be in port 0 (internal port) in order to boot. If any other mass storage device is plugged in ahead of it it will not boot.

Just tried again: port 0 connects to a 128MB fat formatted USB stick, port 1 to a 256MB CF card (fat) reader and port 2 to a 128MB CF (FFS) card reader with integrated USB2.0 hub. The port 2 media is bootable, and boots right into the install WB3.1 - without any need for intervention by user, or any changes in the boot menu.

Tested with Poseidon V4.1, A4000D, DMA driver.

Michael  

[mboehmer_e3b]

...devieces but the difference is the drives are not visible under media toolbox either. must be some installation detail i have overseen. or the way os4 handles things differently than 3.9. (newbie)

Some versions of the HDToolBos do not like USB drives, after my experiences. Try the OS3.1 HDToolBox, as well as the versions of 3.5 and 3.9.

Michael

[mboehmer_e3b]

LOL. None of us like to RTFM and I'm guilty of that more than anyone.

And believe me, almost 90% of all customer support requests are caused by not reading the manual (which did take us also some time to create).

This creates a big and completely unnecessary overhead in support, which keeps us away from our normal business.

Maybe you can imagine that this makes us angry, sometimes - as time is a resource which cannot be replaced by money, or anything else in the world.

Michael

[mboehmer_e3b]

Do you get your head bitten off on a regular basis by a nagging wife?

Please don't try to put up my private life here for discussion, that's none of your business - you don't know anything about me, so stop making assumptions.

Regarding the other stuff - take a few minutes and read the last mails from you sent to us, and ask yourself who started "boxing" in this issue.

You did put up some "observations" in your list of small issues which are either not true, or simply show that you didn't read the manual.

There's one point to be checked left - the installation issue on USB mass storage based systems, which seems to be an issue (I tried the installation with the beta versions of V4.1 which behaved differently, the V4.1 user archive seems to do a "AddUSBHardware REMOVE ALL" after installation of the necessary files, so you get a lockup, but have all new files installed correctly.
This issue relates to creating a new PsdStackloader file with the new file versions of the updated version.

Michael

[mboehmer_e3b]

I ordered a Deneb from AmigaKit yesterday, so I now feel entitled to my two cents worth of commentary. ;-)

Nice to hear, despite the fact that there's a bad guy at E3B doing the support :-)

Germany's current export laws. (Has any incarnation of Amiga ever revoked that license?) Apart from storage limitations

Wuha... ever ordered something in US? Never?
I ordered some schottky diodes there, and was asked by a phone call half an hour later if I planned to bring down the US government using these diodes... (for god's sake, I didn't tell them that I studied nuclear physics, who knows what would have happened then...).
So, if you feel like moaning about German laws, then start with the Stiftung EAR or the GEZ issue, that's really unique in the world :-/

I once commented on the total cost of ownership of an Amiga system, including registration charges for the most commonly used system and user applications. It's a bit ludicrous. ;-)

Hope the full OEM license of Poseion helps your balance here a little bit.

Michael

[mboehmer_e3b]

I'll probably keep it around for testing clockport software, but if anyone needs or wants a Kickflash, I might be interested in a trade (no cash) of some sort.

Well, for testing hardware it seems reasonable - please PM me on mboehmere3bde and tell me what expect for it.

Michael

[mboehmer_e3b]

With so many variations of hardware and software on the Amiga combining to produce some unwanted side effects then asking questions in a thread like this can be far less painful than wading through a text file for one sentence amongst a thousand.

I fully agree, as you give the best example (CV643D) here.

For example, I was unaware of the conflict between the Deneb and the Cybervision 64/3D which had me banging my head agaist a wall for several hours.  Is it mentioned in the manual?  I've no idea, but I never noticed it.  I found out because I happened to catch Chris H posting some advice on the Deneb and I asked him.

Well, I didn't know about this issue myself unless it was reported by several people, and we needed some time to get this issue down to the CV64/3D interface. We have many test cards here, but no CV64/3D, so we had to borrow one from our customers, and after having it in the test lab connected to the logic analyzer it was a matter of one hour to trigger the problem, analyse it and fix it in the firmware of DENEB.

To give you some insight on this issue: Zorro III multiplexes address and data lines (24bit multiplexed, 8bit data direct, 6 bit address direct). During a Zorro III access, the bus master puts up the address on the bus, waits a short period in time, and turns the /FCS strobe signal from high to low; this falling edge validates the addresses, the addressed Zorro III card activates /SLAVE, and shortly after the falling edge of /FCS the multiplexed address lines turn to data lines.
The CV64/3D, unfortunately, does not support the maximum allowed timing at this point as defined by the spec; it seems the hardware designer kept to "observed behaviour".
Simply said, the CV64/3D is too slow at this point of the access - while the DENEB uses the defined timings ("slow" Zorro III accesses from CPU card via Buster).

By this, the CV64/3D misinterprets the data on DMA cycles done by the DENEB as address information, and depending on the data direction of the transfer data is scrambled or simply turned to 0xffffffff - which leads to serious troubles with USB operation, of course.

So we stumbled across some old bug in the CV64/3D which only occurs during certain data transfers, and only in certain situations.

Luckily I decided early in the development phase to switch from a CPLD to a much more versatile FPGA device, which easily supports upgrading the firmware by simply reflashing some FlashROM - by this decision we are flexible enough to provide hotfixes in such cases without sending in the cards, changing CPLD chips or other cost and time intensive actions.

installed the v9 firmware and posted a thread for others to read letting them know that it works perefectly.

That's what it's intended to do :-)

I know one thing though, I wouldn't give up my Deneb card for the world!   :-)

Nice to hear :-)

Michael

[mboehmer_e3b]

Personally speaking, that was the #1 selling point of the Deneb over the previous USB solutions for me.  It's a win-win situation as far as you and the consumer goes, the software is included in the hardware and goes with the hardware when it's sold so no mucking around with online registration, keyfiles or worrying whether you can get a second hand device working, plus you don't need to worry about piracy.

Hm, having a second hand Mediator from the SUBWAY test phase I  have learned about the joy of being a "second hand" customer, so this was not an option for DENEB.

The auto update feature rocks too (now that my A4000 is online) and the idea of setting the jumpers so that a "drive" containing the software appears is just bliss.

Well, blame Chis for that. The FPGA firmware images are quite small, and the firmware FlashROM is quite big, so it was kind of natural way to implement this feature.
Even with four different firmware images stored in FlashROM there is plenty of space...
If I had killed the watchdog in the FPGA many people would have had an easier start, but with the CS MKii and the kickstart bug in expansion.library it seemed as a good idea to have some last resort (by having the FPGA deactivating the FlashROM).
Looking back, it was not a good decision, but this has been changed in firmware V8 and V9 (user can deactivate FlashROM by reset length).

Michael

[mboehmer_e3b]

I'm really glad you fixed that bug so quickly.  I had actually resigned myself to just using AGA as I had decided that USB was more useful than RTG.  It would also have been easy to say, "Well, it's the CV64/3D that's at fault" and just ignored it so I think you deserve a gold star for service and support for addressing the bug and fixing it.

If I just could trigger the Buster 11 bug (lockup with several busmasters on Zorro III) in a reliable way, and maybe add some bugfix into the DENEB FPGA also... but this is a long term project, if spare time allows... :-(

Michael