Cartridge port IDE IF design finished (project CATA)

[paulwratt]

having a read-only set of IDE devices on the cartridge port would still be useful. Especially if you have a lot of large data, or even a BBS (file server)

anyway, someone will eventually figure out a "trick" for the Falcon, even if that means it would only write at "standard" STE speeds..

Anyway keep us posted about how things are going..

Paul

[Petari]

I don't think that it will write well on Falcon and TT ever without some additional components. And I don't think that there will be much interest by those users. Concept is based partially on fact that 68000 CPU has very accurate instruction ececution timing, and it is constant all time.
68030 is different story. No wonder that we don't see any fancy demos with some special, irregular video on Falcon, TT - because they are usually based on exact CPU timing.
I focus on STE - mostly because better features and is more stable than ST (faster signals on cart port for instance), and overall, buying today some ST, because 'it is most compatible with games' is dummy - STE is very-very compatible. I can make every game to work on STE, quickly.

I just needed to update GAL logic of CATA, so it can playback AV at 320x200, 4096 colors, 25fps - something most not really expected to see on STE ever, including myself

[paulwratt]

I don't think that it will write well on Falcon and TT ever without some additional components. And I don't think that there will be much interest by those users.

CD/DVD or CF or massive IDE-HD - as long as it can read, some poeple will be interested for Falcon & TT030

The HD I lost at christmas was 350Gb of Atari stuff on 2TB drive, of which <1% was demo/scene/ym stuff. If it had been hooked up on CATA to Falcon/TT030 I might still have it (cos write protected)

BTW how does inacurate 030 timing cope with internal IDE (Falcon) and internal SCSI (TT) - (maybe not worth discussing atm)

Anyway, I think should not worry about Falcon/TT write until you get more than a couple of people asking "why cant it write", but just make sure it can still read. Later more people will realize the benefits of an external IDE interface on cartridge (ie no need to open machine up to change media/drives)

Yes I prefer STE too. Just need more bigger memory addons (incl FastRAM) (and PCI adapter for my 2x Silent HD5450 : )

Paul

[kovacm]

super cool project!!

how do you achieve so high speeds? is ROM port directly connected to MC68000 so transfer speed depends only on MC ability to read/write from register to ROM port address? NetUSBEE LAN cart for ROM port can achieve ~150KB/s on plain ST at best! how did you get 10x performance?


and since I have NetUSBEE for LAN, is it possible for use both card (NetUSBEE and CATA) at same time on ROM port?


EDIT: to replay to myself I just read thread http://forum.8bitchip.info/hardware-16/about-interfaceadapteradd-on-design-concepts-for-atari-st/

Cartridge port is special case - in fact, by ST it is used mostly for diagnostic purposes (service cartridge) and diverse add-ons, which were mostly something other than ROM expansions. The reason is clear: it is connected directly to CPU data bus, so allows fast transfer to ST RAM.

but than again - why NetUSBEE is so slow? What kind of data Realtek chip provide to ROM Port? and is it possible to connect more devices on ROM port at once?

[Petari]

...
The HD I lost at christmas was 350Gb of Atari stuff on 2TB drive, of which <1% was demo/scene/ym stuff. If it had been hooked up on CATA to Falcon/TT030 I might still have it (cos write protected)

BTW how does inacurate 030 timing cope with internal IDE (Falcon) and internal SCSI (TT) - (maybe not worth discussing atm)

Anyway, I think should not worry about Falcon/TT write until you get more than a couple of people asking "why cant it write", but just make sure it can still read. Later more people will realize the benefits of an external IDE interface on cartridge (ie no need to open machine up to change media/drives)

Yes I prefer STE too. Just need more bigger memory addons (incl FastRAM) (and PCI adapter for my 2x Silent HD5450 : )

You lost data on that drive, or drive broke ?

SCSI has nothing with CPU timing - it uses DMA. And problems with CATA are because it is not intended for write at all - I use dirty tricks for it and speed.

[Petari]

how do you achieve so high speeds? is ROM port directly connected to MC68000 so transfer speed depends only on MC ability to read/write from register to ROM port address? NetUSBEE LAN cart for ROM port can achieve ~150KB/s on plain ST at best! how did you get 10x performance?
and since I have NetUSBEE for LAN, is it possible for use both card (NetUSBEE and CATA) at same time on ROM port?
EDIT: to replay to myself I just read thread http://forum.8bitchip.info/hardware-16/about-interfaceadapteradd-on-design-concepts-for-atari-st/

Cartridge port is special case - in fact, by ST it is used mostly for diagnostic purposes (service cartridge) and diverse add-ons, which were mostly something other than ROM expansions. The reason is clear: it is connected directly to CPU data bus, so allows fast transfer to ST RAM.

but than again - why NetUSBEE is so slow? What kind of data Realtek chip provide to ROM Port? and is it possible to connect more devices on ROM port at once?

Cartridge port is in fact pretty simple - it is intended to attach max 128KB ROM at certain memory area ($FA0000-$FBFFFF) to machine. There are all necessary signals, adresses decoded, so you need only board and 4 32KB EPROMs. And designers forgot write support from some reason.
It is connected to CPU data and address bus directly - and reading speed is same as reading RAM.
But write is another story. To achieve it, usual trick is to use address lines as data instead addressing - and it makes first limit then - part of cartridge area is not for ROM, but for such writing. For instance only first half is used for ROM (64KB), and another for writing via addresses - adapter logic will know according to addresses area is it regular read, or write via trick.  And this method means much slower writing than reading, because code can not be so straight as by normal writing. About 200-250KB/sec max is possible, if I remember correct.
Now, why NETUSBEE is only 150KB/sec (even by read ?) I really don't know. Reading could be up to some 1300KB/sec.  Most likely some other things cause it.

When I started to think about cart port, I wanted faster write. The whole concept is based on how data transfers work:
CPU reads data from selected port or memory address into internal registers, then writes to destination. Only case where it is different is DMA transfer, where DMA chip writes directly into RAM.  But we can use DMA only with floppy and ACSI port.
So, back to by CPU done transfers:  there is no separated port access by 68000 (like by Intel CPUs or Z80) - all is mapped into RAM address space. So, cart port too.
Typical code for transfer is:  move.l  (a0)+,(a1)+  ... repeat it as many data must be transferred.
For those not knowing asm:  move means copy in fact, l is long, so 4 bytes. (a0)+ means that source is at address equ content of register a0 (32bit one). After reading it autoincrements by operation size, so 4 bytes, and will be ready for next transfer. a1 is dest, other same.  This way allows max 1600KB/sec - because max bus speed in ST(E) is 4MB/sec, but half is used for read and half for write. Additional 25% is wasted on instruction opcode reading - every time again, even if it is same.
With movem we can get more, about 1900KB/sec, but it is more complicated for usage, and not suitable for IDE because bug.
Blitter:  it works on same bus, so same speed limitations - but because no need to reread opcode every time, it can almost 2MB/sec in HOG mode. At price of stopping CPU while doing it. 

So, how then I achieved over 2MBsec ?
First thing is:  IDE port is alway on same address, and IDE self autoincrements data pointer, internally. So, we don't need to care about source address. Second came with need for fast write:
if we ensure that nothing will interfer with our code (interrupts disabled etc) we can open IDE port at every RAM access and write what is on data bus in that moment. Then simple:
move.l  (a1),d0  will do the job, faster than way above - because no reading into CPU first.
Above code reads data at a1 into CPU register d0, what is not where we really want it - point is that in that moment data appears on data bus, and will be written on hard disk, which will autoincrement and may write to next loc by next same instruction.  This allows over 2200KB/sec write speed.  Logic of adapter ensures that IDE write activates only when RAM is addresses, and not when cartridge port code. And yes, it means that above works only from ROM of cartridge self.

Very fast reading:  opposite CPU operation would allow fast readings too, so writing to RAM what is on data bus. But no CPU instruction what performs it, naturally. You can only write to RAM what CPU puts on data bus.  Here comes even more nasty trick:  if we invert CPU signal R/W before MMU chip, will have memory writing instead read.  So, move.l  (a1),d0 will write to loc at a1, but of course not content of register d0, because CPU will still perform reading. but what is on data bus - and there will be data from IDE disk - adapter logic will put it in reading mode when RAM write happens.  Price is need for small modification in ST(E) -  need to cut R/W line from CPU to MMU and lead 2 wires at that cut to CATA adapter. When it is not attached, you must shortcut it.
Even faster read:  I avoided movem because mentioned bug. But because need for more than 2.3MB/sec for movie playback, I found the way to use it - see more in another thread: 
http://forum.8bitchip.info/software-17/high-color-video-playback-on-ste/

More devices to ROM port at once ?  That is very unlikely - conflict is almost certain. With CATA for sure nothing else - it uses all signals and addresses for self. Not to mention possible signal degradation because more bus load.

[paulwratt]

Nice explanation Petari, thanks

More devices to ROM port at once ?  That is very unlikely - conflict is almost certain. With CATA for sure nothing else - it uses all signals and addresses for self. Not to mention possible signal degradation because more bus load.

can you come up with a design (like an adapter manager) that would allow multiple CATA-style cartridges to be used. Just on paper ATM.

I mean similar to MSX cartridge extenders, 1 allows 4 (or 2) to be plugged in.

The design I mean: specifically this "extender" manages the write (and read?) according to your "tricks" for CATA

What I think is simplest (according to your last post) is 2x seperate CATA-style cartridge each with 32k EPROM. "Extender/Manager" allows 64k write. #1 is an IDE. #2 (network card) or (2nd IDE) or (custom grafix) etc..

Again I say "on paper", based on what your CATA development is doing.

I personally would love to see a 2 or 4 port adapter that can provide high speed write access to the cartridge port. That would greatly extend the life of ST & STE hardware into the 2020's



for the switch to replace the cut read/write line: Is it possible to use a "soft switch" so that the CATA IDE driver (or above extender driver) can set "we have write on cartridge port"

So the "real switch" would be:
OFF (READ ONLY)
PROGRAMABLE (selectable - READ ONLY/READ WRITE)

At power on PROGRAMABLE value is "READ ONLY" by default

(IDE) driver can auto-set "READ/WRITE" at startup. And that way you could also allow the driver to set "READ ONLY" via software (selected by the user) too.


Paul

[Petari]

In principle, it would be possible to have attached multiple devices on cartridge port - if solve somehow by SW controlleable complete deactivating of device not used at moment. But then, we need new design of all such adapters + SW what can controll all that mess.  Sounds not realistic.
Additional problem, as already said is increased bus load - cart. port is connected directly to CPU. If we connect multiple devices, it may overload lines, causing less reliable work or even damage. And even deactivating devices not in use at moment will not decrease bus load.
All in all, it would be fine, but even if I would made new, more complicated design it is not enough.
And because CATA is made for speed, it is very sensitive on any additional bus load.

Conflicts between multiple devices on cart port will happen even if they work only in read mode. And in fact, there is never pure read mode with storage or NET adapters - you need to give commands to device what to read for instance - and it is write, of course. Reading data from hard disk is not like reading ROM - instead giving address, you write commands and parameters to IDE port. Similar is for sure with NET adapters too.

As only reasonable way to use old, very old Atari machines I see avoiding any overload. I even don't like to attach multiple devices on ACSI port. And why should I do it ?  On PC can copy data much faster.

If you need hard disk and NET at once, better go on 1 attached to ACSI, another to cart. port.

I don't get what exactly you mean about replacing cut read/write line. That cut is necessary only for readings - better said if want very fast readings, over 2MB/sec. For write it is not needed.
In driver is autodetection about it. What is visible in video at YT.

Read only is interesting only on TT, Falcon - and it is already in driver too.

[kovacm]

^ multi-ROM-port devices SOLVER:





btw it is fine to have one device. don't bother with this!