Posts by Jens

Quote from temisu

1. You said you are going to charge 50€ less since not all features are ready. Are these features available for free later to early adopters or are they paid feature when they come available?

Yes, these features are free for all customers. Updates will be software/flash only, nothing hardware-related.

Quote from temisu

2. I can see the card pricing on the shop but what is the upgrade pricing? Especially if coming from the lowest tier to the highest tier?

I already mentioned that this will be added to the shop soon, but with 21 possible different update steps, there's 21 chances that the shop system totally breaks down if I make these changes in the data base. I'm carefully doing that on a test system, though. Max price from 25MHz to open-end is 150,- EUR plus VAT where applicable.

Quote from temisu

3. Are all cards fully capable of all speeds i.e. there is no other difference but the cpu installed?

Yes, all cards are fully capable of running 133MHz. Note that we have only achieved this speed for memory yet. Top speed for the CPU is 100MHz - anything higher we've tried resulted in crashes after seconds only.

Quote from temisu

Its been a while but as I recall the license was not that expensive (5k/year, although not justifiable if implemented only in a single small scale product) and the terms were not that onerous (mandatory self-testing and some IP-entaglements). After that you could official call it SD-support...

Yeah, that's not possible to finance on a project this small. We're pretty far already, and I'm confident that we'll have our own IP, without entanglements. Who knows where we can use that in the future

Jens

72-pin SIMMs aren't vendor-specific - at least they shouldn't be. It's a Jedec standard if I remember right. Only the organization of address muxing is different on larger modules (>32MByte), but that shouldn't be a concern here. So if you have an old PC lying around that uses 72-pin SIMMs, you should be able to harvest them and use on the A4000D.

Jens

Quote from utri007

All Gloom versions does crash if runned RTG screen with Indivision.

Please contact the Gloom authoprs and point them to the latest developer archive. As noted years ago, some things have changed.

Will take a look at the other games when we're testing the Blitter implementation. Keep bug reports coming!

Jens

Do those problematic games even support RTG screens?

Jens

I'm prioritising current orders, but have been sending out the updates to customers "backwards" until late october as of now. If you want your update sooner, send me an eMail, don't forget to include the last paid order ID.

Jens

The 4MB version is substantially different from the 2MB version - in fact it's plain vron to speak about "versions", as these cards are fundamentally different: While the "normal" Cirrus 5434-based cards use the chip in ISA mode (where it is limited to handling 2MByte), the GBA version either uses Vesa local or PCI mode of the chip, which allows adressing more memory.

We don't have such a card, so supporting it won't be possible.

Jens

Setting TOD clock to AUTO will use 60Hz on NTSC and 50Hz on PAL. If your time is off and you know that the BBS software is actually using the TOD function of the CIA chips (do you actually know that for sure?), then we need to know what VIC chip you have isntalled_ PAL or NTSC?

Another important info missing is: Is the clock running too fast or too slow? How many minutes/hours per day?

Jens

To my knowledge, all you're looking for is single-sided SIMMs.

Can't take any pics, as my A4000 uses 4x4MB SIMMs.

Jens

Quote from Phil

We are almost at the end of the year, is there already a timeslot for the repair of the CA-PSU or do you have more news about how far you are with the repair?

This year the holidays were extremely employee-friendly - we mainly spent the available time on shipping orders. However, I'm confident that it's going to be more relaxed in January, so yes, returns will be handled soon.

Quote from Phil

Will the warranty be extended by the time the device was with you and I could not use it because of that?

Yes.

Jens

You obviously installed the latest core; Does the config tool show "unsaved" settings when you start it? If it does, please do save all settings.

Quote from rolle

Running IndivisionECSv4 Tool switch the indi to NTSC preset shows a black screen.

The Indivision ECS tool will not switch WB to NTSC- Only the Prefs tool "Screenmode" can do that.

If I'm understanding this wrong, feel free to open a thread in the German part of the forum - I know you're native German.

Jens

This seems to be a problem restoring the saved configuration. I'm pretty sure that this was discussed during development, and I have considered it a solved problem. Will get back to you when I find a solution (or at least I can reproduce it here).

On another note, Doom is surprisingly fast on your setup!

Jens

Please start the config tool and check if Graffiti emulation is switched on - the demo might activate the Genlock Audio bit, but activates Graffiti translation.

Further, you can enable debug output in the advanced options. This will show the number of lines that's found. It may be that the demo is using a non-standard number of lines.

Jens

...as mentioned in the product description, yes. Unfortunately, I now have trouble with my eMail server as well. I already contacted my admin.

Jens

Quote from shan2752

Do you estimate there being a shortage for 040 chips for the ACA1240? I really would like to see the SD card implemented before I give up on my ACA1234 given the ease of access to the card.

I can't say how many I'll sell, but I do see that even the price of of the lowest-cost version is so high that it's nothing that will fly off the shelves.

Quote from shan2752

Do you have a rough estimate as to when the SD card support will be implemented?

Sorry, no real estimate here. We do know that the hardware can do it (as we've done hardware-test routines that read and write blocks of an SD-card in 4-bit mode), but this hasn't been transferred into an Amiga-device driver yet. It may be a quick thing to do, or we may stumble across more difficulties talking to SD-cards in 4-bit mode. Note that this is not publicly documented and we have to work with documentation from unofficial sources.

Jens

Quote from nightfox

Can it damage it if the manual says positive polarity but I might have been using negative?

This monitor appears modern enough to not be affected by any signalling error. That said, positive/negative syncs are usually not a problem, as the polarity has been used for screenmode recognition like "forever". Worst case is that the picture is slightly offset. Sync signals are normally edge-triggered, not level-triggered.

Since you've bought it used from a dealer, you should be covered by EU customer protection, which clearly says that a one-year warranty must be given, also on used items. It's unlawful to exclude such a warranty. And it's a possible explanation for the high price - note that I'm assuming you're in the EU, and I may be wrong...

Jens

Quote from NicoPPC

Does it means we could enjoy faster 320x256 8 bit fast (without c2p) for games like Doom? Will it have bitter/faster operation later ?

Please read this thread for answers about that.

Quote from NicoPPC

Could t also be done on the Indivision AGA mk3?

No, the memory of that product is wired in a way that it doesn't allow random access. Although Indivisino ECS V4 looks very similar to the predecessors, the wiring between memory and FPGA is quite different.

Jens

The new version V3.5.0 contains updates for the Trio64 (Cybervision), IMSG300 (Visiona) and ET4000 (Merlin/oMNiBus) drivers, and it adds new drivers for Vooodoo Banshee, the Voodoo 3 and Voodoo 4/5 class of graphics chips. This requires a PCI bridge board that is supported by the OpenPCI.library, which is not part of the package, but can be freely downloaded.

V3.5.0 also contains an early alpha version of the framebuffer driver for Indivision ECS V4. This driver needs a processor with MMU and an installed MMU library to work. Note that you may have to update the FPGA core of your Indivision ECS V4 card with the latest one from the Wiki. Supported colour modes are 8-bit (256 colours) and 15/16 bit (65k colours), dual screens with screen dragging and panning for oversized screens. Note that Indivisino ECS V4 does not yet have a blitter, so don't expect high speed!

All changes are summarized in the Wiki article of P96.

Unfortunately, this current shop system is still giving us a hard time, with lots of problems during the order process, and even more problems when we attempt to update the downloadable files, so we don't even try for this new version. We'll send the new version via eMail upon request, but will also pro-actively send out eMails over the course of the next few working days.

We with everyone happy holidays!

Quote from nightfox

Is there something the Indivision is doing in the VGA signal that is able to damage a monitor?

You need to read the technical data of the monitor and compare to the screenmode you're running: If you operate a CRT outside of it's recommended frequencies, this can indeed damage the monitor, especially older "multisync" ones that don't have an OSD (newer monitors see the out-of-spec frequency and don't allow the monitor to display at that frequency).

This is clearly mentioned in the config tool documentation. It's your own responsibility to make sure that you don't send too-high frequencies to a monitor. So the question isn't if "Indivision" has killed your monitors, but if your careless connection of the two without reading any of the documentation that comes with the two products, has been the cause.

Further, since electronics ages even when it's not used, it's very likely that a leaking/ageing capacitor in the sync circuit(s) is the cause. After all, CRTs aren't produced any more since.. 20 years? You're running ancient equipment there, which needs some extra care.

Let me know what type of monitors they are, take pictures of the place you've set it up for the Amiga, then we can *maybe* find out where to look for the fault and what to tell a service guy.

Jens

Quote from sailor

So if I understand correctly, ( some ) 68040 CPUs can do 50 MHz and the memory is 133 MHz and thus fast enough.

So the problem is the matching of CPU and memory clock multiples?

No.

The special thing about the ACA1240/1260 is that memory and CPU run in lock step. Memory clock is always a whole-number multiple of CPU clock. The highest memory frequency of 132MHz is only used for the 66MHz CPU cores. For 40MHz CPU, we can use 80 or 120MHz memory clock - both are equally fast. For 50MHz CPU, we use 100MHz memory clock, which provides read data after 5 memory cycles or 3 CPU cycles. That's really fast and likely the cause of the 040 CPU failing at 50MHz, because it just can't pick up data that soon.

Quote from sailor

And 040 / 40 MHz has 0.6 x 25 / 40 = 0.96, so one clock is enough?

On SD-Ram, almost nothing is happening in one clock cycle. You always have multiple cycles of:

- open-row

- possibly wait for a minimum latency

- open column for read or write

- wait for CAS latency (2 or 3 cycles)

- pick up data

- possibly run more column cycles for burst-read/burst-copyback access

- decide if you're closing the row, or keep it open for later, faster access

The last step is a gamble: You don't know if the next piece of data is in the same row or not. If it is, you save several clock cycles on the next access. Since the ACA1240/1260 has so much memory, we can keep a lot of rows open to increase our odds. This is another specialty of the ACA1240/1260, as the strategy of keeping rows open is actually faster than keeping a lot of 2nd level cache memory.

There may be a possibility to insert NOP cycles into the memory controller and then provide data later to the CPU in order to stabilize it at 50MHz. Our memory controller does have the possibility to run slower and insert wait states, but we figured it's not worth it, because you want to gain speed, not step on the brakes. We may give this another shot at some point, but right now, I don't see any more sales resulting from such a core - even if it's a tiny fraction faster than 40MHz.

Jens

Quote from Reloaded

What about the access to chip memory? For demoscene we need 7 Mb/s at any CPU clock speed.

Same message for you: Please read the product description, or at least read the full specifications that this thread has started with. The 0-wait chip ram interface ensures that on a chip.ram write, the CPU getts an immediate ACK and can continue to run in it's local memory, while the interface takes the wait states until the main board is ready to accept written data. This ensures exactly what you want: 7M/s write performance at any CPU speed (that's of course a bit less than half that if operated on ACA500plus).

Jens