RapidRoad USB starts shipping oct-20-2014

[dirkies]

since this happens on an A3640 card only, you may aswell check for memory/register differences kickstart wise between an accelerator and standard A3640, even without rapidroad present. Could well be a library that is not loaded when no A3640 is present (?)

[demolition]

I think I have the same issue with my A600 as well (ACA620+Indivision+RR w. USB Ethernet adapter). Poseidon crashes when I use the USB Ethernet adapter and I see nak timeouts. I did try using a fresh WB3.1 with just the required stuff installed (Poseidon+Trident+MUI+AmiTCP/Miami) but the issue remained so if third party software causes this, the list of suspects is limited.

[dirkies]

this part of the Deneb USB FAQ is interesting, worth a try with those having an A3640 and RR NAK issues (disabling CPU cache):

DENEB works only without CPU caches
Some rare hardware configurations show a mixture of problems while operating DENEB: Poseidon can't start the card driver, USB devices are not recognized (or only after restarting Poseidon in Trident), USB operation is unstable.
Most configurations with these problems have a Cyberstorm Mk1 or Mk2 involved, sometimes also A3640 are affected. Problems change or vanish after resorting Zorro cards in the Zorro backplane or by adding/removing the CPU card SCSI module.
Root of this problem is that the CPU cache is activated too early by some card ROM, in most cases CPU ROM. This can trigger a bug in the expansion.library. You can workaroung this problem by activating the "nocache" module inside the DENEB FlashROM. More information on this module can be found inside the Poseidon and Luciferin guides.

[roomeo]

Originally Posted by dirkies

since this happens on an A3640 card only, you may aswell check for memory/register differences kickstart wise between an accelerator and standard A3640, even without rapidroad present. Could well be a library that is not loaded when no A3640 is present (?)

I think the machine Jens uses to reproduce the problem uses a cyberstorm.

[dirkies]

interesting! Has the mainboard revision any influence? or does it happen on various mobo revisions?
Maybe it should be attempted to repro on an A4000 which has the issue, then swap out ONLY the CPU card (eg with a different brand but same CPU or simply different CPU) and check again.

[roomeo]

Originally Posted by dirkies

interesting! Has the mainboard revision any influence? or does it happen on various mobo revisions?
Maybe it should be attempted to repro on an A4000 which has the issue, then swap out ONLY the CPU card (eg with a different brand but same CPU or simply different CPU) and check again.

Nothing of the information that is out points to a specific mb rev. Don't quote me on that.

If I only had another accelerator. I have played with the idea to get hold of a a3630 just to test.

[roomeo]

btw.. nobody should get their hopes up that i will come up with anything quick..
this is way over my head, but im looking at it for fun.. life and web development comes first...

[dirkies]

On the other hand ì surprised that debugging on the Amiga seems so limited. I have seen kernel developers debugging on windows which was really impressive how much you could control and modify live. Protected memory/mmu etc is missed dearly

[demolition]

Just tried it out in the 600 with a Vampire 2 board and still getting nak timeouts with Ethernet, just in case the CPU type would have an impact.

[Don_Adan]

Resourced device in the Zone.

[Schoenfeld]

Originally Posted by demolition

Just tried it out in the 600 with a Vampire 2 board and still getting nak timeouts with Ethernet, just in case the CPU type would have an impact.

Vampire is not a real 68k CPU, and the hobbyist-way that the "team" approaches this task does not indicate that it will ever come close to a real 68k CPU. As much as I'd hope that FPGAs will some day be able to replace the ever-shrinking supply of 68k CPUs, Vampire takes the wrong approach (try&error simply doesn't work on this kind of task).

Ethernet on USB: Make sure it's an ASIX chip in your Ethernet adapter.

Jens

[demolition]

Originally Posted by Schoenfeld

Vampire is not a real 68k CPU

It also doesn't work on the ACA620, so I don't see any reason to put blame on the Apollo core. The background for my thought was that the Apollo core should be safe in regards to self-modifying code written for 68000 while a genuine 020 is not, if this was why there could be an issue. Although system-friendly code should not use those tricks, you sometimes get surprised what people have done, particularly in remains of old legacy code.

And yes, my USB Ethernet adapter comprises an ASIX chip, or at least it identifies as such as I haven't opened it to check.

Am using a 3c589 PCMCIA card atm, and it runs stable so far, so it is a workable solution since I can then use a USB card reader with RR instead of through the PCMCIA. I have not had issues with other USB devices besides the Ethernet adapter.

[roomeo]

Originally Posted by Schoenfeld

Vampire is not a real 68k CPU, and the hobbyist-way that the "team" approaches this task does not indicate that it will ever come close to a real 68k CPU. As much as I'd hope that FPGAs will some day be able to replace the ever-shrinking supply of 68k CPUs, Vampire takes the wrong approach (try&error simply doesn't work on this kind of task).

Ok. its not a REAL 68k, but thats just semantics. If it walks like a duck...
I dont see whats wrong with their "hobbyist-way" to do things. They sure deliver dont they? They also have a rapid release cycle fixing bugs and improvements.

I understand why you would take that approach to the vampire. Easy to say its not a real cpu so i dont support or care about it. In the end it sure is real amiga hardware regardless of how you look at it..

[kwaku85]

Originally Posted by Schoenfeld

Vampire is not a real 68k CPU, and the hobbyist-way that the "team" approaches this task does not indicate that it will ever come close to a real 68k CPU. As much as I'd hope that FPGAs will some day be able to replace the ever-shrinking supply of 68k CPUs, Vampire takes the wrong approach (try&error simply doesn't work on this kind of task).

Ethernet on USB: Make sure it's an ASIX chip in your Ethernet adapter.

Jens

It's real, but just much better on every fields. You mean it's not from Motorola/Freescale- You're right. But who cares?

[FREEMILK]

This is total BS

FPGA is real CPU, how about we look at intel who uses FPGA in their XEON cpus.

Vampire is the fastest and best thing that has happened to the AMIGA since 1992

Get over it JENS, the APOLLO and Vampire are changing the AMIGA for the better.

Keep selling your 20 year old remakes ....

competition is good, hoe about showing support for the AMIGA and not yourself.

[Daedalus]

Give it a rest guys, this isn't the place for 68k bashing, Jens bashing or Vampire worship, nor Vampire bashing or 68k worship.

Excited and all as I am for the Vampire, it's getting tiring reading crap like this polluting otherwise interesting threads. Yes, it's a "real" CPU, but that doesn't mean it behaves identically to any 68k CPU. It has to be programmed to behave as a 68k CPU, so it's hardware emulation. There's no escaping that fact, and it doesn't make it inferior to a 68k, just different. Many of the differences between it and a real 68k CPU can rightly be considered improvements, but this makes it *different*, in much the same way as a 68060 is different from a 68000. And these improvements/differences will cause different behaviour in certain circumstances, again like the difference between a 68060 and a 68000. This adds extra variables to the type of troubleshooting that's going on, so it only makes sense to discount it from testing for now.

What do you hope to achieve by derailing a thread like that? Let the Vampire speak for itself, which shouldn't be a problem if it lives up to the hype.

[flype]

Originally Posted by Schoenfeld

Vampire is not a real 68k CPU, and the hobbyist-way that the "team" approaches this task does not indicate that it will ever come close to a real 68k CPU [...]

Jens

Ahah, Vampire is much more usable and useful than your accelerators and Apollo-Team knows much more about how an Amiga works than yourself. So, please, avoid such free attacks.

[demolition]

Originally Posted by Daedalus

It has to be programmed to behave as a 68k CPU, so it's hardware emulation. There's no escaping that fact, and it doesn't make it inferior to a 68k, just different.

It is not emulation in any way. It is a real CPU - the only difference between an ASIC (like genuine 680x0 CPUs) and an FPGA is that the latter can be reconfigured while an ASIC has its internal connections fixed and thus cannot be reconfigured. Emulation would imply some kind of underlying CPU running an emulation and this is not the case. This is a quite important difference.

[Daedalus]

I'm very aware of how it works, thanks. It's why I specified "hardware emulation". It doesn't natively run 68k code and hasn't been designed specifically to run any particular instruction set, but has to be configured that way. I was also very clear in pointing out that this isn't a bad thing, just different. It depends entirely on whoever tells it *how* to run 68k code. If I programmed one to run 68k code and you programmed one to run 68k code I guarantee that there are cases where both would behave differently. This is the important point here.

[demolition]

Yes, a blank FPGA does not run 68k code but once programmed, it does run 68k code natively. That's the whole point. Of course, it is not an identical copy of the original 68000 masks, but neither is an 020. I would also consider an 68020 to natively run 68000 code, but that doesn't mean that it is 100% compatible.