TT SCSI performance

[Guest]

but fast ide is handy
what sort of transfer speeds do you get???

2,4MB/sec
Settings:
- 32MB NIKON CompactFlash card (more than 10 years old)
- Hardware byte swap
- IDE interface cycle time set to 250ns (PIO Mode 2 timing)

its funny because using a ide adapter from scsi i get about the same
while i see most users of scsi get around 1.4.1-8 MB

very interesting and i wonder why???
i have a revj modded pcb {wires soldered on factory mods}
ive also changed the dma controller it had as it was faulty and also the scsi section has had work {i have 6 of these ics if anyone needs one}
to add active termination supply and a buffer i also modded the clock to add a better drive to the mpu and removed the resistor
i use a dds unit to get the clock now... has a dramatic effect on the video
i used an ACARD adapter and flashed it with the older x86 firmware so pio mode worked correctly i sold it to a german user
i wish i had kept it i use an 18GB scsi3 drive now with a couple of adapters buts its noisey
i want a ssd for it i think.. i bought the board as dead and fixed it so its a test bed for the magnums only


so what about it blend both magnum code and better ram with ide...??
i dont mind doing the pcb work and schematics,,, would take a few hours in proteus. to draw it up
i have 100 plugs for the ttram socket i have 50 magnum pcb being made...
costs about 100 euros for 2 protoboards 4 layers... or 6 as needed.. perhaps
im not sure what too do??

[pakman]

All the disk drivers I know of (except HDDriver which can do background DMA but only uses it with Magic, at least to my knowledge) use CPU busy waiting for DMA transfers to finish. I suppose waiting for a DMA register to change by frequently reading it with the CPU isn't much more efficient than doing the same with an IDE register?

That's true!
During DMA the CPU ist totally cut off the bus, no chance for the CPU to do anything else.
DMA or CPU transfers don't make a big difference. It is all about the bus bandwith.

Some calculations for TT IDE with CPU transfers:
Transfer speed measured: 2400 kByte/sec (XFERRATE.TTP)

No. of 16 bit reads from the IDE port: 1228800 per sec.
IDE port access cycle time (1WS): 250 ns (assuming IORDY always true = best case)
Total time allocated for reading the IDE port: 307,2 msec

No. of 32 bit writes to TTRAM: 614400 per sec.
TTRAM access cycle time (1WS): 250 ns (assuming longword write, address long aligned = best case)
Total time allocated for writing to TTRAM: 153,6 msec

Both together is already almost 50% of the TT 16MHz bus bandwith

What is happening in the remaining 539,2 msec (1sec - 307msec - 154msec)?
- Above calculations were based on best case scenarios, reality is always worse
- Transfer setup overhead
- Read loop control
- Not to forget: Interrupts!

So don't expect to see 5MByte/sec on the TT..

[pakman]

so what about it blend both magnum code and better ram with ide...??

Possible. My IDE interface is using so far:
- 1x GAL 20V8 (24pin DIL)
- 1x M4A5 64/32 (44pin PLCC)
- 2x 74HCT245 (20pin DIL)
- TT connector (96pin)
- IDE connector (40pin)
- JTAG connector (8pin)
- approx. 45 resistors
- 5 ceramic capacitors
- Jumper, LED, etc
Do you have in mind to use one bigger CPLD (84pin for instance) for everything?

But: There are some drawbacks, as project are getting bigger:
- Cost increasing
- Number of potentially interested people decreasing
- Last, not least: Probability of finishing the project drastically decreasing!

[AtariZoll]

...
Some calculations for TT IDE with CPU transfers:
Transfer speed measured: 2400 kByte/sec (XFERRATE.TTP)
No. of 16 bit reads from the IDE port: 1228800 per sec.
IDE port access cycle time (1WS): 250 ns (assuming IORDY always true = best case)
Total time allocated for reading the IDE port: 307,2 msec
No. of 32 bit writes to TTRAM: 614400 per sec.
TTRAM access cycle time (1WS): 250 ns (assuming longword write, address long aligned = best case)
Total time allocated for writing to TTRAM: 153,6 msec
Both together is already almost 50% of the TT 16MHz bus bandwith

What is happening in the remaining 539,2 msec (1sec - 307msec - 154msec)?
- Above calculations were based on best case scenarios, reality is always worse
- Transfer setup overhead
- Read loop control
- Not to forget: Interrupts!
So don't expect to see 5MByte/sec on the TT..

Well, there is way to improve above speeds. If you use 32-bit IDE adapter for 32-bit data bus TT. That requires some extra logic and latches + clocks for. In case of reading from disk, it needs to read 1 word from disk and store in 16 bit latch, then reading next word from disk - when it arrives you read in one step 16 bits from latch and 16 bits from IDE, so 32-bit transfer. With this IDE read takes same time as writing to TT RAM.
Something like I designed 22 years ago: http://zx48.8bitchip.info/idehard.htm
That's of course opposite in some way - 16 bit IDE to 8 bit micro. But principle is same practically. It was must, because usual IDE disks can not work in 8 bit mode.
And I think if Falcon can 3.2 MB/sec with it's 16-bit data bus and 16 MHz CPU, that TT should 2x, so 6.4 MB/sec with IDE. But I don't know it's exact bus timings. And of course, speed will go down if some higher graphic mode is active.
DMA transfers depend much from used DMA chip - for instance ACSI on TT is not faster than on some ST - because same DMA chip is used. SCSI DMA chip is faster, but still much less than TT bus bandwith . Don't forget that DMA transfers load data bus 2x less than PIO mode IDE - where you need 2 steps for 1 transfer - reading from IDE port, then writing to RAM .

[Cyprian]

No. of 32 bit writes to TTRAM: 614400 per sec.

According to Nembench figures from there, TTRAM can write at least 3 000 000 32bit words per second.

Code: Select all

Linear 32bit write (FastRAM) -> 12.615 MByte/sec (~195%)

No. of 16 bit reads from the IDE port: 1228800 per sec.
IDE port access cycle time (1WS): 250 ns (assuming IORDY always true = best case)

With 250ns access time a disk driver should be able to read 4 000 000 16bit words per second.

Therefore, theoretically when a disk driver spends a half of a time for reading and the other half a time for writing, it should reach value 2 000 000 16bit words per second - 4MB/s

[Guest]

so what about it blend both magnum code and better ram with ide...??

Possible. My IDE interface is using so far:
- 1x GAL 20V8 (24pin DIL)
- 1x M4A5 64/32 (44pin PLCC)
- 2x 74HCT245 (20pin DIL)
- TT connector (96pin)
- IDE connector (40pin)
- JTAG connector (8pin)
- approx. 45 resistors
- 5 ceramic capacitors
- Jumper, LED, etc
Do you have in mind to use one bigger CPLD (84pin for instance) for everything?

But: There are some drawbacks, as project are getting bigger:
- Cost increasing
- Number of potentially interested people decreasing
- Last, not least: Probability of finishing the project drastically decreasing!

im gona chrun out 25 magnums anyway as you say most users wont need ide ill have 25 boards spare
just now i have over 10 members already payed a small fee and i need to satify this order...
and jookies ssd looks the bis.. for me anyway,,,

i think i have 100 connectors and so far 75 free perhaps make another 25 from the pcbs ill have spare
it would be nice to make a duel board remove the simms to perfect ram no looking etc

even just doing this is worth it and i dont think many members would mind paying a 10er more etc
for nice all in one ram.. no need to search ps2 simms etc..

i dont want to make a pig in a poke for people ...
so ill make 25 magnums from the pcb batch

[calimero]

again offtopic:

I just used Windows PC with AMD 2GHz CPU but with harddisc in PIO mode!!

Computer is utterly unusable! What ever you touch in windows, CPU will go to 100% and even mouse will stop to respond!

[Guest]

sounds like your scsi card has no stable drivers use dos only for atari stuff ..... learn the stucture and help fuctions
if you used ide and like windows vista or xp or win7 8 8.1 windows will capture the drive and take it prisoner....
scsi drives it depends on what o/s you use use a win 98 iso2 boot disk iso on cd... adaptect card etc... acard did one...
you need to add the drivers to the initial boot up for scsi cards its easy you just download the boot tools
cost is $7 peboot...
i use a win98 osr2 boot iso with tools and 32 bit drive access... dos is handy if you type help /? then you get a list of commands
if you then type help /command ? then you get details on the command if you type help? then you get help on help...
learn dos...

[AtariZoll]

again offtopic:
I just used Windows PC with AMD 2GHz CPU but with harddisc in PIO mode!!
Computer is utterly unusable! What ever you touch in windows, CPU will go to 100% and even mouse will stop to respond!

First big ROFL for Simbo's reply - he don't know what type of disc PIO means.
That's well known thing. PIO mode is obsolete disk access type, where GHz CPU needs to work with timings from 20 years ago - when CPUs were much slower. It means practically that it needs to wait most time - therefore is big slowdown. But in case of IDE disks it's easy to turn on UDMA mode. Similar slowdown happened when printing with parallel port - what works practically in PIO mode too. No wonder that parallel port is missing on new motherboards.

[calimero]

again offtopic:
I just used Windows PC with AMD 2GHz CPU but with harddisc in PIO mode!!
Computer is utterly unusable! What ever you touch in windows, CPU will go to 100% and even mouse will stop to respond!

First big ROFL for Simbo's reply - he don't know what type of disc PIO means.

yes, sometimes conversations looks like Turing tests

That's well known thing. PIO mode is obsolete disk access type, where GHz CPU needs to work with timings from 20 years ago.

that make sense.
So CPU MUST wait until it get response from predefined timings from harddisc and in meantime it can not do anything?
but it is sad that today OS and applications assume that they can read and write megabytes and megabytes of data per second and end result is not much more spectacular than on ST.

[AtariZoll]

Modern computers are equipped with complex IDE interface - nobody calls it port anymore, with reason. And IDE normally works in DMA mode, so all what CPU does is giving commands for disk access, other is on IDE-DMA logic. Here I must brag again: my ACSI-CF adapter works like that - CF in DMA IDE mode on Atari DMA port. Only bottleneck there is 8-bit wide ACSI port.
Back to PCs : in era of windows 95-98 it was common error that disk driver switched back to PIO mode, what was immediately noticeable because of slowdown. The reason was usually that driver noticed some glitch and assumed HW error, so for safety it turned off DMA mode. That was easy to switch back to DMA in Device manager. With XP I never experienced switching back to PIO . And I guess that something like that happens not with SATA disks

[AtariZoll]

No. of 32 bit writes to TTRAM: 614400 per sec.

According to Nembench figures from there, TTRAM can write at least 3 000 000 32bit words per second.

Code: Select all

Linear 32bit write (FastRAM) -> 12.615 MByte/sec (~195%)

No. of 16 bit reads from the IDE port: 1228800 per sec.
IDE port access cycle time (1WS): 250 ns (assuming IORDY always true = best case)

With 250ns access time a disk driver should be able to read 4 000 000 16bit words per second.
Therefore, theoretically when a disk driver spends a half of a time for reading and the other half a time for writing, it should reach value 2 000 000 16bit words per second - 4MB/s

If we calculate with 250nS RAM cycle time, then writing to RAM self: 4 Mega x 32 bits = 16 MB/sec . But reading from IDE port is 16-bit wise. Plus we need to add opcode fetch time . So, timing would be roughly, for fastest opcode move.l (a0),(a1)+ where a0 is IDE port addr. and a1 is RAM addr. :
opcode fetch 250nS, or less from cache, reading 2x16 bits 512nS, writing 32 bits in one step 250 nS, so total 1mS for 4 bytes > 4MB/sec .
However, as fetch may take less time, and we can at cost of extra circuit to decrease IDE read time to 250 nS it may be that time for reading 4 bytes is about some 700nS - what would give about 6MB/sec .
Not possible that disk driver spends half time for read, and half time for write - only with blitter. But no such in TT . You need to read opcode over and over again. Then, there is question about TT slow (video) RAM - is it slowdowns CPU at some ST res. ? Or just in higher video modes ?

[Guest]

this is what ive found ide is more than 2X faster that scsi even when i convert scsi to ide even via DMA
its twice as fast very nippy .... i used a fujitsu 8GB drive... split to 16 drives... of 511MB using hdriver v9
i get like 1.4Mb from scsi but from even scsi to ide ive tried i get like 2.4Mb....
i used pperas tools to test transfer speeds and to check i used icd utils
not sure why
its a worthwhile upgrade

so perhaps blended ide with TTRam {without simms} is the way

for the TT rev d-k i use 90ns eproms
makes a big differance to boot time...
less chipset glitch..... i have a rev j at the moment...
just going to use this board for the magnum TT run and if it survives ill do some mods...
perhaps its a driver issue... or something missing... from the driver translations

ttram ide is defo worth adding as the mmu inside the 68030 is sole used for control of the ttram port
but i think you need to load everything on boot too ttram and disown stram {too slow}
and some sort of TTRAM virtual drive is needed

[Cyprian]

Not possible that disk driver spends half time for read, and half time for write - only with blitter. But no such in TT . You need to read opcode over and over again.

In TT, thanks to 030 instruction cache, opcode fetch time can be omitted.

So, timing would be roughly, for fastest opcode move.l (a0),(a1)+ where a0 is IDE port addr. and a1 is RAM addr. :

Due to 16bit IDE access we rather should use move.w (A0),(A1)+

If we calculate with 250nS RAM cycle time, then writing to RAM self: 4 Mega x 32 bits = 16 MB/sec .

In one bus cycle you read 16bit data from IDE and in the next bus cycle you write it to e.g. ST-RAM.
250nS means 4 000 000 memory slots per second. Therefore half of them - 2 000 000 are for reading 16bit data from IDE and other 2 000 000 for writing to the ram. It means 4MB/s.

I'd like to emphasize that those calculations are pure theoretical (but consistent with the TT documentation), therefore in reality figures can be a different.

Then, there is question about TT slow (video) RAM - is it slowdowns CPU at some ST res. ? Or just in higher video modes ?

The same story as in the ST, CPU and TT Shifter interleaves access to memory and Video mode has no impact onto CPU performance. Timing also is the same as in the ST - CPU has access to ST-RAM every 500nS.

[Guest]

the fact remains that ide is twice as fast as scsi with hddriver

perhaps its a driver issue
we should get around the same speed from scsi as ide + any latency added by adapters in the case of scsi to ide...
using ttram the speed should be more like 10Mb as it has direct control
so some optimisation needs done....

i think the scsi drivers in hddriver arent as efficient as they should be
compaired to even translation of scsi to ide

not sure pperas tools for speed are even accurate???

too many questions and no realy answers

[AtariZoll]

In TT, thanks to 030 instruction cache, opcode fetch time can be omitted.

It still takes some time to read it from cache.

Due to 16bit IDE access we rather should use move.w (A0),(A1)+

No. Long is faster - 68030 CPU adjust bus width on fly, according to bus width of accessed port/memory bank. So, it will read/write as described by me.

If we calculate with 250nS RAM cycle time, then writing to RAM self: 4 Mega x 32 bits = 16 MB/sec .

In one bus cycle you read 16bit data from IDE and in the next bus cycle you write it to e.g. ST-RAM.
250nS means 4 000 000 memory slots per second. Therefore half of them - 2 000 000 are for reading 16bit data from IDE and other 2 000 000 for writing to the ram. It means 4MB/s.

That was just example what would be if CPU performed only RAM writes constantly - and that is actual RAM bandwith on CPU bus.

Then, there is question about TT slow (video) RAM - is it slowdowns CPU at some ST res. ? Or just in higher video modes ?

The same story as in the ST, CPU and TT Shifter interleaves access to memory and Video mode has no impact onto CPU performance. Timing also is the same as in the ST - CPU has access to ST-RAM every 500nS.

Above contradicts with 250nS cycle time. If it is true, then max speed is only some 3.2 MB/sec - 2x as in ST, and only because 32 bit data bus.. Talking only about when ST RAM is accessed. Actually not Because it is at much higher clock, so can do IDE read while video accessing ST RAM . It's hard to calculate, and there will be miss and hit cycles - but maybe about 5 MB/sec . And not to forget that there must be some wait states unlike by ST .
I could not find any speed test, membench results after short googling. Someone post here, pls.

[Guest]

tt bus depends what mode its set too

to sum up

[Cyprian]

It still takes some time to read it from cache.

250nS means 4MHz clock, 030 has 32MHz clock, it means that the CPU has 8 cycles between memory access. It is enough to fetch an instruction from i-cache.

No. Long is faster - 68030 CPU adjust bus width on fly, according to bus width of accessed port/memory bank. So, it will read/write as described by me.

you right Long access is faster on the TT, but the IDE offers only 16bit bus. therefore (without any additional electronic mentioned by you) you can fetch data from the IDE in 16bit chunks.

Above contradicts with 250nS cycle time. If it is true, then max speed is only some 3.2 MB/sec - 2x as in ST, and only because 32 bit data bus.. Talking only about when ST RAM is accessed. Actually not Because it is at much higher clock, so can do IDE read while video accessing ST RAM . It's hard to calculate, and there will be miss and hit cycles - but maybe about 5 MB/sec . And not to forget that there must be some wait states unlike by ST .
I could not find any speed test, membench results after short googling. Someone post here, pls.

TT and NemBench: http://www.atari-forum.com/viewtopic.php?f=27&t=17970
Falcon and Nembench: http://www.atari-forum.com/viewtopic.php?f=27&t=23543

[AtariZoll]

Fine - then we need to take ST RAM copy speed as base - what is little less than 4 MB/sec. That's most similar to IDE access.
The question is how smart TT control logic is, and will it allow CPU to access IDE port while video reads ST RAM ? If yes, then IDE speed may reach 5 MB/sec .

[pakman]

so perhaps blended ide with TTRam {without simms} is the way

Which kind of RAM chips do you propose to use?

[Guest]

not sure
something stackable two boards or three or four 64MB per stack unit so something 32MB each side {4X8X32} top bottom 4 layer board
as you plug them if they are ready no jumpers is the way... 50ns edo is prob aok to use.. with a few fixes to the signals
i think a single cpld is plenty perhaps a lattice ic
ill make a few calculations and see the Io count from proteus {easy this way}

the foot print on the main pcb will be the same size so you can buy 1 2 3 or 4 stacker DRAM
making a unit and 64 cards is a better and more standard way...

[pakman]

not sure
something stackable two boards or three or four 64MB per stack unit so something 32MB each side {4X8X32} top bottom 4 layer board

ill make a few calculations and see the Io count from proteus {easy this way}

Any outcome so far?

[pakman]

Fine - then we need to take ST RAM copy speed as base - what is little less than 4 MB/sec. That's most similar to IDE access.
The question is how smart TT control logic is, and will it allow CPU to access IDE port while video reads ST RAM ? If yes, then IDE speed may reach 5 MB/sec .

Indeed..
(8 year old Canon CF card, manufactured by Hitachi)

TT-IDE 093 Canon.jpg

[Guest]

what software on the mach 210 on the magnum are you using ??

I am not using a Mach 210 at all.
I have fitted a Lattice M4A5 64/32 as a replacement for the original Mach device for 2 reasons:
- M4A5 is still available at distributors in germany, whereas Mach 210 is not
- Programming environment available, so I am able to modify the code and program the device

im left with little choice other than too rip up doing the magnum run
people moan too much they cant find the ram type and im at the end
any how ...no matter
got lots of bits... 100 sockets etc

and we have the base design to work from

my idea is too work in the other 2PD detection lines and fix and find all the issues in code
{missing mask?? and not enough power and i/o}
im going to change the design to smd just port and simms as thru hole
we also need to replace the three ttl chips with a better solution
perhaps 1 cpld and no buffers ...
change the cpld out
use the same simm arrangement but it will properly accept all types {EDO BEDO FPM etc..} 72 pin types
other dimms or other is out of range
so we know it does work so we will make it work with more modern FPM types
ive been reading over notes and sites and this is the best way
i will outline a placement that can include a port for expansion
so.. ill draw up a block diagram of units again

would be nice to work on an ide as a dev platform based on the magnum
but as you say more accessible via the same controller this way you can use burst mode with edo ram
and you'll get much faster register shifts with far less negotiation
ill look up details on a better ic {more i/o } perhaps you have a better idea than me
i program mostly in c++ and c microchip and avr atmel stuff..

however this then leaves us with a 3.3v problem .....
perhaps two jumpers and buffer all i/os too the ram as expected
then use smd buffer level converters/shifters small 16 32 pin devices 8 i/os
in design terms its actually a good idea to buffer all the ram i/os to any controller

so what remains is an i/o count

ill work out the i/o count tonight of the magnum
can you do the same for the ide ?? need to work out what sort of either a pair of cpld or one with more i/os

TT <> MAGNUM TT
9 transaction inputs
FC0 >
FC1 >
AS >
RW >
siz0 >
siz1 >
STerm>
POR >
32bit address 32bit data
CPLD AND ROW ADDRESS BUFFERS
32 bit to 12 bit memory address grouped selectors MAD0-11
34 cpld i/os used

one thing i notice is we need 16 bit memory address not 12 and mask as needed at the ram addressing lines

[Guest]

Fine - then we need to take ST RAM copy speed as base - what is little less than 4 MB/sec. That's most similar to IDE access.
The question is how smart TT control logic is, and will it allow CPU to access IDE port while video reads ST RAM ? If yes, then IDE speed may reach 5 MB/sec .

Indeed..
(8 year old Canon CF card, manufactured by Hitachi)

TT-IDE 093 Canon.jpg

there is info about this in the TT chips guide and the tt hardware description docs...
it tells us that one funnel can be used while the other is busy with dma access..
so video is refreshed half cycle 1 wait state

if you fit VME Dram you can cash transfers at -1 wait state access..

gives 1 left for TTRAM as 3 cycles @16mhz... access dram steps
TTram access on the magnum runs at 16 mhz
perhaps reusing the 32mhz clock for the TTRAM control is a far better ide a
can be locked if needed to 16mhz as another signal
perhaps needed for bust mode masked 16/32bit access instead of 12bits {why reuse 12bit access????}

the mmu inside a 68030 is 32bits wide its easily done
then we have access to block mode and dma... Dword 32bit full bus width

with the set up you have there is too much negotiation and unification is the best step too one controller
and adjust the bus width

instead of taking 3 cycles to transfer on the fly by the mpu its taking