Terrible Fire Accelerators - Page 100

28 September 2017, 21:58

Quote:

Originally Posted by plasmab

I may be able to get it to work at 4Mb with a firmware update. there is a bug in the firmware which allocates the RAM to the wrong location because it allocates 2 zorro devices at the same time.

What kind of information can I get to you in order to help you with this effort?

Also dumb question... is there a way to change the ID of the "SCSI" controller so that there is a chance that another SCSI controller could function? I only ask as my A2091 is much faster than the built in IDE controller using a CF card.

plasmab · 28 September 2017, 23:30

Quote:

Originally Posted by Vecanis

What kind of information can I get to you in order to help you with this effort?

Also dumb question... is there a way to change the ID of the "SCSI" controller so that there is a chance that another SCSI controller could function? I only ask as my A2091 is much faster than the built in IDE controller using a CF card.

I pretty much know how to do this but I havent got time at the moment. My wife is away travelling and I have children to look after and a business to run. Also there has been a big push on the TF328 front.

There isn't an "ID" for the IDE interface. At least not at the hardware level. That's all software controlled. Maybe someone else can help there? All my board does is emulate Gayle (but a little faster).

However I get 3.5Mbyte/sec from the TF530 IDE interface if the scsi.device is running in my fast ram. Is your scsi device faster than that?

29 September 2017, 04:27

Quote:

Originally Posted by plasmab

I pretty much know how to do this but I havent got time at the moment. My wife is away travelling and I have children to look after and a business to run. Also there has been a big push on the TF328 front.

There isn't an "ID" for the IDE interface. At least not at the hardware level. That's all software controlled. Maybe someone else can help there? All my board does is emulate Gayle (but a little faster).

However I get 3.5Mbyte/sec from the TF530 IDE interface if the scsi.device is running in my fast ram. Is your scsi device faster than that?

Totally understand life coming first.

I've OC'd the A2091 using the 14mhz hack and was regularly seeing 4.7Mbyte/sec (it wasn't consistent.) I'm currently only seeing 1 MB/s now with the TF530.

EzdineG · 29 September 2017, 04:49

Quote:

Originally Posted by Vecanis

Totally understand life coming first.

I've OC'd the A2091 using the 14mhz hack and was regularly seeing 4.7Mbyte/sec (it wasn't consistent.) I'm currently only seeing 1 MB/s now with the TF530.

Do you see better results with CPU FASTROM ?

nogginthenog · 29 September 2017, 18:50

Quote:

Originally Posted by plasmab

However I get 3.5Mbyte/sec from the TF530 IDE interface if the scsi.device is running in my fast ram. Is your scsi device faster than that?

Gayle IDE is quite CPU intensive. Most SCSI cards should support DMA.

plasmab · 29 September 2017, 19:12

Quote:

Originally Posted by nogginthenog

Gayle IDE is quite CPU intensive. Most SCSI cards should support DMA.

DMA isn’t really an advantage. It hogs the bus just like CPU PIO does. Unless you have dual port RAM that is.

EDIT: I suppose i should qualify this a bit. Its an advantage if your CPU speed sucks. If your CPU goes like poop off a stick its not massively advantageous unless its into uncontended memory.

Sent from my iPhone using Tapatalk

patrik · 08 October 2017, 02:06

Dma doesn't really help with transfer rates, unless it is faster at transferring the data than the cpu is copying the data. Which I guess is a possibility for a 68000.

It will however help with the overall system performance for cases where the cpu is busy with other things during the data transfer:
- Like general multitasking performance, when there are more than one process running, so the even if one process is blocking on an I/O request taking place, the cpu is still busy.
- Another example would be if you have a single process doing asynchronous I/O and is working on data, while a request for more data is executing in the background.

Of course this depends on the dma transfer not starving the cpu of memory cycles completely, so bigger cpu caches helps. As long as it starves the cpu less time than time the cpu would have to spend doing the transfer, it is a win. Also another factor to consider is that the dma controller in theory will waste less cycles than the cpu to do a transfer as it just has to read or write the data on the bus, while the cpu has to copy the data, so it has to both read and write.

Do not forget that the dma controllers have to be able to access all of the systems memory to be able to work effectively. For example a Zorro2 dma controller in a system with fastram outside the 24-bit Zorro2-space does not help, it will rather slow things down as it will only be able to dma to/from chipmem and then the cpu has to copy from chipmem to wherever the process requesting the transfer allocated its buffer. Even if the system had placed some memory in the 24-bit Zorro2-space to allow transfers, there is nothing saying that the buffer allocated by a process resides in that memory, so in most cases, the cpu will still end up copying the data.

Examples of usable dma setups would be the classic A2091 + A2630 (all 32-bit mem in 24-bit space), A3000-scsi, Zorro3-Amiga with A4091 or Phase5 Fastlane, all Phase5 accelerators with scsi controller, WarpEngine etc (all system ram accessable by the scsi dma controller).

Black68 · 10 October 2017, 17:56

Quote:

Originally Posted by dalek

@8 Bit Dreams: have you tried adding the pullup resistors to the lower address lines of the Rev 6A board? It solves issues with eproms and kickstart 3.1.

They are:
RP106 and RP107
9 x 4k7 in SIP-10

More details here: http://eab.abime.net/showpost.php?p=...&postcount=322

Adding this resistors fixed the problems I had with the PSU!

I was testing with different 3 supplies: one A600 PSU, one A500 PSU and one ATX PSU. The TF530 on both my rev.6a boards would only boot with the A600 PSU (3.0A).

Now, with RP106 and RP107 in place I can use any of the power supplies without problem!

8 Bit Dreams · 10 October 2017, 19:54

[QUOTE=Black68;1191173]Adding this resistors fixed the problems I had with the PSU!

I was testing with different 3 supplies: one A600 PSU, one A500 PSU and one ATX PSU. The TF530 on both my rev.6a boards would only boot with the A600 PSU (3.0A).

That's good news!

8 Bit Dreams · 10 October 2017, 19:55

[QUOTE=8 Bit Dreams;1191195]

Quote:

Originally Posted by Black68

Adding this resistors fixed the problems I had with the PSU!

I was testing with different 3 supplies: one A600 PSU, one A500 PSU and one ATX PSU. The TF530 on both my rev.6a boards would only boot with the A600 PSU (3.0A).

That's good news!

Black68 · 11 October 2017, 11:32

[QUOTE=8 Bit Dreams;1191196]

Quote:

Originally Posted by 8 Bit Dreams

That's good news!

Are you running your TF530 at 50mhz?

I got mine running at 48mhz very stable but without FPU. The 68882 I have are rated for 40mhz and it makes the system unstable...

plasmab · 11 October 2017, 14:13

I had mine running at 48mhz with FPU nicely

Sent from my iPhone using Tapatalk

Black68 · 11 October 2017, 16:25

Quote:

Originally Posted by plasmab

I had mine running at 48mhz with FPU nicely

I have a couple of MC68882FN40A

What FPUs are you using?

plasmab · 11 October 2017, 19:00

Quote:

Originally Posted by Black68

I have a couple of MC68882FN40A

What FPUs are you using?

I think it was 33s will check the mask

Sent from my iPhone using Tapatalk

8 Bit Dreams · 11 October 2017, 20:22

Quote:

Originally Posted by Black68

Are you running your TF530 at 50mhz?

I got mine running at 48mhz very stable but without FPU. The 68882 I have are rated for 40mhz and it makes the system unstable...

Indeed, all my TF cards running at 50Mhz (with both CPU types, plastic and ceramic) with FPU installed (MC68882FN40A) no crashes, no issues, BUT on beta 50Mhz firmware only, WHDLoad doesn't work on the newest firmware for me. It may be R3 on TF card, that causes error, value on github (BOM) shows 47k on R3, eagle schematics shows 10k, someone told me correct value should be 1k, so i am puzzled a bit, my experience is: if You install so high resistance - You will possibly end up with yellow screen even without FPU installed. have swapped R3 to 1k and now it works.
have asked Steve about correct value, but got no answer on this question..
Your problem can be also CPU itself, that refuses to run at this speed, what kind of CPU do You use?

alenppc · 11 October 2017, 20:33

At 25 MHz it's most stable with R2/R3 at 47k and R1 at 1k. (Both rev 2 and rev 3).

At higher frequencies these values don't work however... I am still trying to figure out which ones to use. The only certainty is R1 always at 1K.

8 Bit Dreams · 11 October 2017, 21:25

Quote:

Originally Posted by alenppc

At 25 MHz it's most stable with R2/R3 at 47k and R1 at 1k. (Both rev 2 and rev 3).

At higher frequencies these values don't work however... I am still trying to figure out which ones to use. The only certainty is R1 always at 1K.

i can speak from my experience:
have bought Xilinx chips from four different sources
One source are 7ns - these cpld's doesen't work correctly
two batches are working with 47K @R3
last batch had a yellow screen with 47K @R3, swapping out to 1K has solved this issue, also floppy drive is working (read & format)

will try to swap R3 to 10K and program newest firmware, maybe it will work then..

Black68 · 12 October 2017, 04:07

Quote:

Originally Posted by 8 Bit Dreams

Your problem can be also CPU itself, that refuses to run at this speed, what kind of CPU do You use?

Im using the latest firmware, TF530 Rev 2 and Amiga Rev 6a boards. I have a few 33mhz plastic cpu and a 50mhz ceramic (the 50 MHz speed is exclusive to the ceramic PGA package, the plastic '030 stopped at 40 MHz).

After adding the pullup resistors to the Amiga main board, the TF530 at 33mhz runs flawless (with FPU).

It refuses to run at 50mhz but it will run perfect at 48mhz (without FPU).

alenppc · 12 October 2017, 13:36

The best I could do was 36 Mhz but I haven't played around with resistors.

patrik · 13 October 2017, 00:55

Sorry for being quite OT, but on the DMA topic I thought I should present an example where DMA makes a difference even on a computer with a rather hefty cpu, instead of just babbling.

A case which would be beneficial for a DMA controller is to do something which causes a high load on the cpu and does disk I/O with at the same time. Cpu time wasted on disk I/O will then be noticed.

I chose to do something quite common which can do that - download a file over the local network to disk. The data transfer through the TCP/IP-stack takes care of causing the high cpu load and for doing the disk I/O at the same time I used aget, which downloads files over http and does asynchronous writes (lets the file system handle writes in the background, while downloading the next batch of data in the foreground).

The idea was to do it on both a PIO controller and a DMA controller and compare the results. I used an A1200 which has both the standard IDE PIO controller and a Blizzard SCSI DMA controller (a working DMA setup where the controller can transfer to/from all the memory of the machine).

To make the IDE and SCSI as even as possible in transfer rate, I used UnitControl to set the SCSI to operate in 2MHz synchronous mode, which resulted in ~2.5MB/sec transfer rate, compared to the IDE transfer rate of ~2.4MB/sec. This does not matter though as the writes are done asynchronously, so even at 10MB/sec transfer rate, the SCSI would not gain anything, but more on that later.

The relevant hardware used is:
A1200
Blizzard 1260@50Mhz
Blizzard SCSI-kit IV
mSATA SSD connected to the internal IDE with mSATA->IDE adapter.
mSATA SSD connected to the SCSI-kit with mSATA->IDE adapter and Acard IDE->SCSI adapter.
Netgear FA411 100Mbit PCMCIA ethernet card

The relevant software used is:
AmigaOS 3.1
BlizKick 1.24 for kickstart in fast and with the usual modules like LocalFast and MoveVBR to improve multitasking performance
1230scsi.device 8.5
UnitControl 2.17
PFS AIO 2.3
Roadshow 1.13 (020 version)
cnet16.device 1.9
aget 0.29

Results:

Code:

9.Ram Disk:> aget 192.168.0.1/test10M.bin RAM:
Buffer size: 128kB
Sent HTTP GET request!
Done parsing HTTP header
Server response: 200 OK
Receiving file: 0% - [oooooooooooooooooooooooooooooooo] - 100% (10MB)
10MB received in 9.43s - 1.06MB/s

9.Ram Disk:> aget 192.168.0.1/test10M.bin IDE-PFS:
Buffer size: 128kB
Sent HTTP GET request!
Done parsing HTTP header
Server response: 200 OK
Receiving file: 0% - [oooooooooooooooooooooooooooooooo] - 100% (10MB)
10MB received in 12.77s - 801.49kB/s

9.Ram Disk:> aget 192.168.0.1/test10M.bin SCSI-PFS:
Buffer size: 128kB
Sent HTTP GET request!
Done parsing HTTP header
Server response: 200 OK
Receiving file: 0% - [oooooooooooooooooooooooooooooooo] - 100% (10MB)
10MB received in 8.65s - 1.16MB/s

Comparing the results for the IDE PIO controller (IDE-PFS: ) to the SCSI DMA controller (SCSI-PFS: ), the DMA controller scored a 48% higher download speed (1.16MB = 1187.84kB).

Also note that it is actually slower downloading to RAM: than to disk using the DMA controller. Thats because when writes are done asyncronously, there is no benefit that the RAM-handler finishes writes much faster than the disk (given the disk is faster than the network), but the fact that the RAM-handler uses quite some cpu time to copy data around steals cpu time - just like a PIO disk controller.

08 October 2017, 02:06	#1987
patrik Registered User Join Date: Jan 2005 Location: Umeå Age: 43 Posts: 935	Dma doesn't really help with transfer rates, unless it is faster at transferring the data than the cpu is copying the data. Which I guess is a possibility for a 68000. It will however help with the overall system performance for cases where the cpu is busy with other things during the data transfer: - Like general multitasking performance, when there are more than one process running, so the even if one process is blocking on an I/O request taking place, the cpu is still busy. - Another example would be if you have a single process doing asynchronous I/O and is working on data, while a request for more data is executing in the background. Of course this depends on the dma transfer not starving the cpu of memory cycles completely, so bigger cpu caches helps. As long as it starves the cpu less time than time the cpu would have to spend doing the transfer, it is a win. Also another factor to consider is that the dma controller in theory will waste less cycles than the cpu to do a transfer as it just has to read or write the data on the bus, while the cpu has to copy the data, so it has to both read and write. Do not forget that the dma controllers have to be able to access all of the systems memory to be able to work effectively. For example a Zorro2 dma controller in a system with fastram outside the 24-bit Zorro2-space does not help, it will rather slow things down as it will only be able to dma to/from chipmem and then the cpu has to copy from chipmem to wherever the process requesting the transfer allocated its buffer. Even if the system had placed some memory in the 24-bit Zorro2-space to allow transfers, there is nothing saying that the buffer allocated by a process resides in that memory, so in most cases, the cpu will still end up copying the data. Examples of usable dma setups would be the classic A2091 + A2630 (all 32-bit mem in 24-bit space), A3000-scsi, Zorro3-Amiga with A4091 or Phase5 Fastlane, all Phase5 accelerators with scsi controller, WarpEngine etc (all system ram accessable by the scsi dma controller). Last edited by patrik; 08 October 2017 at 19:38. Reason: Forgot the cpu has to copy the data

13 October 2017, 00:55	#2000
patrik Registered User Join Date: Jan 2005 Location: Umeå Age: 43 Posts: 935	Sorry for being quite OT, but on the DMA topic I thought I should present an example where DMA makes a difference even on a computer with a rather hefty cpu, instead of just babbling. A case which would be beneficial for a DMA controller is to do something which causes a high load on the cpu and does disk I/O with at the same time. Cpu time wasted on disk I/O will then be noticed. I chose to do something quite common which can do that - download a file over the local network to disk. The data transfer through the TCP/IP-stack takes care of causing the high cpu load and for doing the disk I/O at the same time I used aget, which downloads files over http and does asynchronous writes (lets the file system handle writes in the background, while downloading the next batch of data in the foreground). The idea was to do it on both a PIO controller and a DMA controller and compare the results. I used an A1200 which has both the standard IDE PIO controller and a Blizzard SCSI DMA controller (a working DMA setup where the controller can transfer to/from all the memory of the machine). To make the IDE and SCSI as even as possible in transfer rate, I used UnitControl to set the SCSI to operate in 2MHz synchronous mode, which resulted in ~2.5MB/sec transfer rate, compared to the IDE transfer rate of ~2.4MB/sec. This does not matter though as the writes are done asynchronously, so even at 10MB/sec transfer rate, the SCSI would not gain anything, but more on that later. The relevant hardware used is: A1200 Blizzard 1260@50Mhz Blizzard SCSI-kit IV mSATA SSD connected to the internal IDE with mSATA->IDE adapter. mSATA SSD connected to the SCSI-kit with mSATA->IDE adapter and Acard IDE->SCSI adapter. Netgear FA411 100Mbit PCMCIA ethernet card The relevant software used is: AmigaOS 3.1 BlizKick 1.24 for kickstart in fast and with the usual modules like LocalFast and MoveVBR to improve multitasking performance 1230scsi.device 8.5 UnitControl 2.17 PFS AIO 2.3 Roadshow 1.13 (020 version) cnet16.device 1.9 aget 0.29 Results: Code: 9.Ram Disk:> aget 192.168.0.1/test10M.bin RAM: Buffer size: 128kB Sent HTTP GET request! Done parsing HTTP header Server response: 200 OK Receiving file: 0% - [oooooooooooooooooooooooooooooooo] - 100% (10MB) 10MB received in 9.43s - 1.06MB/s 9.Ram Disk:> aget 192.168.0.1/test10M.bin IDE-PFS: Buffer size: 128kB Sent HTTP GET request! Done parsing HTTP header Server response: 200 OK Receiving file: 0% - [oooooooooooooooooooooooooooooooo] - 100% (10MB) 10MB received in 12.77s - 801.49kB/s 9.Ram Disk:> aget 192.168.0.1/test10M.bin SCSI-PFS: Buffer size: 128kB Sent HTTP GET request! Done parsing HTTP header Server response: 200 OK Receiving file: 0% - [oooooooooooooooooooooooooooooooo] - 100% (10MB) 10MB received in 8.65s - 1.16MB/s Comparing the results for the IDE PIO controller (IDE-PFS: ) to the SCSI DMA controller (SCSI-PFS: ), the DMA controller scored a 48% higher download speed (1.16MB = 1187.84kB). Also note that it is actually slower downloading to RAM: than to disk using the DMA controller. Thats because when writes are done asyncronously, there is no benefit that the RAM-handler finishes writes much faster than the disk (given the disk is faster than the network), but the fact that the RAM-handler uses quite some cpu time to copy data around steals cpu time - just like a PIO disk controller. Last edited by patrik; 13 October 2017 at 00:59. Reason: removed redundant percent after %

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
Listening to Amiga music with too much treble makes it sound terrible!	Foebane	Amiga scene	4	08 October 2016 06:30
Terrible usb drive performance?	lovinggames	support.FS-UAE	5	11 March 2015 09:06
Broken MASPlayer - Terrible hissing.	SS454	support.Hardware	8	17 November 2013 01:41
Accelerators	pmc	MarketPlace	9	04 November 2009 20:23
Problem with a terrible, simply effect!	Camionsauro	Coders. General	13	19 April 2009 08:53

10 October 2017, 19:54	#1989
8 Bit Dreams Retro maniac Join Date: Feb 2017 Location: near Munich / Germany Posts: 486	[QUOTE=Black68;1191173]Adding this resistors fixed the problems I had with the PSU! I was testing with different 3 supplies: one A600 PSU, one A500 PSU and one ATX PSU. The TF530 on both my rev.6a boards would only boot with the A600 PSU (3.0A). That's good news!

11 October 2017, 14:13	#1992
plasmab Banned Join Date: Sep 2016 Location: UK Posts: 2,917	I had mine running at 48mhz with FPU nicely Sent from my iPhone using Tapatalk

11 October 2017, 20:33	#1996
alenppc Registered User Join Date: Apr 2012 Location: Canada Age: 44 Posts: 910	At 25 MHz it's most stable with R2/R3 at 47k and R1 at 1k. (Both rev 2 and rev 3). At higher frequencies these values don't work however... I am still trying to figure out which ones to use. The only certainty is R1 always at 1K.

12 October 2017, 13:36	#1999
alenppc Registered User Join Date: Apr 2012 Location: Canada Age: 44 Posts: 910	The best I could do was 36 Mhz but I haven't played around with resistors.

Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)