oops, removed.

Regards,
--
St?phane

@Hans

Hi,

I am not actively working on AmiVNC4 ; Daniel Westerberg made some changes in 2006, as shows the readme on os4depot.

AmiVNC4 is a pretty complex piece of software, which took me a lot of time to handcraft, because of the many different gfx modes to support (planar, chunky, all sorts of resolution / pixel depth / endianness, gfx api's) combined with the relatively slow cpu power.

I consider it to "basically work ok", it is missing some zlib compression to speed transfers over dialup lines or slow DSL, but I don't have that need.

The code is open source, and anyone can contribute (many claimed they would, or would do a better VNC server, which did not occur apart from DW's contributions).

Regards,
--
St?phane

@Hans

I'm actually glad to hear that :)

Regards,
--
St?phane

@Renoir

Hi,

Here are my suggestions:

1- set the speed to 9,600 baud on both sides as a start

2- set the terminal program's preferences to 8 data bit, 1 stop bit, no parity

3- set the terminal program's preferences to no handshaking (not hardware nor software)

4- in terms of cable, a 3 wires one should be enough in that configuration:
GND -> GND
TX -> RX
RX -> TX

5- make sure you connect to the DB9 port which is the closest to the keyboard plug

That should work.

Regards,
--
St?phane

@Renoir

Please attach a serial cable to your a1's port 1, and grab the output during bootlog (make sure to check the serial speed setting in uboot).

Show me that output, we'll fix it.

Regards,
--
St?phane

@agafaster

Ok, i've indeed had some sleep.

Sorry if I misinterpreded your words. English not being my native language, I thought you were saying "your support sucks".

Regards,
--
St?phane

@agafaster

It seems you have a hard time reading and understanding me.

Anyway, down to facts:

- your adaptec will never be supported by uboot. Thus you will never be able to boot your system entirely from an SCSI drive that is hooked to it. I chose to support lsi just because it is the *only* scsi chip supported in uboot.

- the reason why there exists an OS4 scsi driver is that I was gently asked and convinced by some os4 betatesters, to write one to help the community transferring hardware and data from older systems to os4 machines. I *made the effort*, to *please them*, on my *spare time*, at *night*, to try & fill that need. All that *without any compensation of any form*, *just to be helpful*.

- now you don't seem to like that you have bought an os4-unsupported hardware, and that eventually you realize that it is os4-unsupported. Given the tone of your wording, I don't share the disease.

- finally, yes, I indeed suggest that you (or anyone else wanting an adaptec driver), download the SDK, a driver template, the adaptec chip docs, the linux or netbsd code for inspiration, and *make the effort* to code a new driver (which I made myself earlier).

Aloha.

@agafaster

Hi,

fxcan works here too with my GT7000 (even tho I have to click GR to "continue" once or twice because it seems to have some null pointer access bugs).

As for adaptec support, as I've aldeady stated more than once, there wont be any other scsi driver for OS4... from me.

The lsi driver was a quick shot, made just to fill the bridge from older scsi-stuffed classics to newer os4 machines. It has performance limitations, but it is good for what it is : you can attach your old scsi stuff and use it. The reason why I chose lsi is that this chip is also supported in UBoot, permitting an lsi scsi-only configuration to be fully os4-bootable.

That said, making a driver is really not that difficult, both in terms of amigaos integration (there are sources and documentations on how an amigaos driver should look like) and target chip (linux or netbsd etc. have open source drivers for tons of chips, to get inspiration from).

Regards,
--
St?phane

@R-TEAM

My scsi driver has never been intended for anything else than allowing copying old stuff to ATA/SATA drives, and maybe using old scanners etc.

Now, there may be other drivers from other people in the future... Maybe an evolution of igniatios's cybppc.device ?

Regards,
--
St?phane

@srupprecht

memf_public is not the way.

He has to wait for a new sdk with allocvectags.

Plus he does not need getphysicaladdress, the prd's returned by getdmalist are all he needs to set his dma hardware. If his hardware does not support scatter/gather then he has to allocate his buffer using the contiguous tag of allocvectags.

If he wants to cache flush the buffer, he needs a 32 byte aligned buffer at both ends to avoid side effects of ppc cache flushes.


Regards,
--
St?phane

@R-TEAM

Hi,

before you heat up too much, please note that the scsi driver was made only to "fill the gap" for people with an a1 and old scsi stuff. As such, it implements only 8 bit asynchronous transfers, and in a very trivial way, which means it tops at 5 MB/s.

It will stay like that, it will not evolve towards a high performance solution, because it was never the point.

Thus, don't spend any money on high end scsi stuff, in the purpose of using it with this driver.

Regards,
--
St?phane

@ssolie

indeed, we have abandoned memf_public as a safe way to allocate contiguous / physical=virtual buffers, in favor of a more flexible api but this obviously requires the new sdk...

Regards,
--
St?phane

@Spirantho

Well, I don't know, as I'm not using the SDK (but rather, compiling directly within the OS cvs).

But if you don't have access to that function (or if its not documented in exec.doc) then indeed I'm afraid you'll have to wait for a new SDK.

BTW you did not tell me the return of allocvec.

Regards,
--
St?phane

@Spirantho

Did you check the return of allocvec ?

By the way there's no reason why you'd need memf_public, you should rather use the new allocvectags, and ask for contiguous memory, with proper alignment.

Also, while it may sound wise to lockmem, its not necessary until the pager is running.

Finally, you don't have to get the physical address of your buffer, startdma takes a virtual address, and getdmalist will return the physical mappings of your buffer.

Note, given that allocvec can return scattered pages, if your DMA hardware does not support scatter/gather, then you HAVE to use allocvectags and explicitly ask for a contiguous buffer.

Regards,
--
St?phane

@Spirantho

I'd like you to paste (or send me) the complete code.

I also have access to the kernel cvs so i can investigate in the kernel source if necessary.

Regards,
--
St?phane

@Spirantho

I'd be glad to help ; I'd have thought that the exec autodocs for startdma/getdmalist/enddma are rather well written (no, i did not write them :)

Can you please paste here your code :

- which allocates the dma buffer

- which is between startdma and enddma

Regards,
--
St?phane

@haslenuts

Hi,

From your captures, the device is loaded (found in residents) but not running (no device task).

This can only mean that it found nothing during the SCSI scan.

Please paste here the bootlog, capturing it the way joerg suggests.

Regards,
--
St?phane

@haslenuts

Can you please take the list of running tasks (using top or scout or anything alike) and paste it here ?

Also, please tell me your board's PCI vendor and product IDs.

Regards,
--
St?phane

I have added TD64 support in the drivers, and am now waiting for a betatester to confirm you can now directly use those filesystems.

Regards,
--
St?phane

Well, I have added TD64 to experimental versions of my drivers, for who'd like to test those filesystems without the patch.

It would probably require a pretty uptodate system though (like the current betatester's installation).

Regards,
--
St?phane