Falcon: yes or no?

[calimero]

26 minutes ago, ParanoidLittleMan said:

If IDE has max transfer rate of 3 MB/sec and SCSI 1.8 MB/sec then audio hard disk recording speed is lower than 1.8 MB/sec for sure - in case of Falcon.  Let's say it is 1.5 MB/sec - then CPU load will be 50% with IDE, so no, CPU is not occupied totally, and SW can work with lower speed (what happens with DMA too, as said CPU must wait when DMA accessing RAM - that's less than 50% normally, but with higher transfer speeds is more. My disk speed test program shows CPU slowdown in DMA mode, for instance - and I don't know any other knowing that).

There should be some slowdowns since there are no separate (exclusive) data paths on motherboard for SCSI to RAM data transfer, right?

 

btw one audio track is 98KB/s (at 49KHz). Cubase Audio could use 16 tracks IIRC. So there will be around 1.5MB/s of data...

 

22 hours ago, ParanoidLittleMan said:

Most of disk access happens via TOS calls, actually in case of hard disk it is only via it (except some very rare cases, like music playback during games ? ), so all other activity is stopped.

I do believe that Cubase does not use TOS for disk acces. Steinberg did make MROS for ST long time ago so they probably do not stall CPU. 

Cubase Audio can perform realtime effect on sound using D2D. I do believe that it will be no possible with IDE. I wonder if there is any multitrack D2D audio software for Falcon that can be compared with Cubase Audio in terms of effects and to use IDE?

My point is that SCSI is in a Falcon with good reason. 

 

Sidenote: MagiC also has an option for Background DMA access. When it is turned on, even floppy operation works in background. 

Edited July 30, 2021 by calimero

[calimero]

41 minutes ago, ParanoidLittleMan said:

"I also saw, back in 90s, that people used same SCSI hard drive connected to Atari and PC and used it to transfer files!"

Why exclamation mark for something completely normal and simple ?

Because I lime exclamation marks. I have collection of them: ! !! ! !!! !!!!

 

Not really

But I do forgot to mention: in same time. SCSI harddrive was connected to Falcon and PC in same time and both computers could access it. 

Edited July 30, 2021 by calimero

[ParanoidLittleMan]

Well, if Cubase has special SCSI code for Falcon (and it is not same as SCSI for TT) then yes, it needs SCSI disk. But as said, disks were much slower in that time, so IDE could work with modern storage.

 

Magic is multitasking, so disk access via OS must be background, to not stop other running PRGs. That's not hard to solve, btw.

[ParanoidLittleMan]

8 hours ago, calimero said:

Because I lime exclamation marks. I have collection of them: ! !! ! !!! !!!!

 

Not really

But do I forgot to mention: in same time. SCSI harddrive was connected to Falcon and PC in same time and both computers could access it. 

I must admit - SCSI won this time - IDE can not work with 2 computers attached (well not without some special separating chips) .

In any case, I would not recommend to do it now, with old and valuable Falcon.

[calimero]

32 minutes ago, ParanoidLittleMan said:

I'm not sure about that Cubase will not work with some Falcon and CF card.

D2D will not work for sure. 
 

There is a bunch of threads on this topic, like this one: https://www.atari-forum.com/viewtopic.php?t=38884

 

Btw

I am not sure why you mention MegaST and Cubase at all...? 

[calimero]

15 minutes ago, ParanoidLittleMan said:

Well, if Cubase has special SCSI code for Falcon (and it is not same as SCSI for TT) then yes, it needs SCSI disk. But as said, disks were much slower in that time, so IDE could work with modern storage.

probably not if 1.5MB/s spent 50% of CPU time. 

Quote

 

Magic is multitasking, so disk access via OS must be background, to not stop other running PRGs. That's not hard to solve, btw.

So in this case SCSI also have advatnage over IDE. (We can argue that on Atari you do not move tons of MB per second so difference for user experience would be minimal but... SCSI had advantage that is exploited with MagiC)

Edited July 30, 2021 by calimero

[TGB1718]

2 hours ago, ParanoidLittleMan said:

OK. And what was price of it ?

Unfortunately I have no idea, I've had it since about 1989 and can't even remember where I got it,

but it still works and the Syquest, but having issues with the Syquest due to it's age

[ParanoidLittleMan]

You don't listen - I wrote here multiple times that disk access via TOS stops execution of everything except interrupts. And it stays for DMA disk access too (floppy, ACSI, SCSI) . In other words not relevant is it DMA or CPU driven disk access when usual Trap #1 disk access is used. It will wait until file access is completed. In case of DMA it means that CPU will spend it executing wait code most time (wait that DMA finishes). 

And it is just not good for multitasking OS. So, there disk access is practically one separated process too. What does not stop other processes to run (in their shared time segment). But there is flag that disk access is on, so other tasks need to wait with their disk access that other process disk access is finished.  Ergo, in unlucky case other tasks may need wait for disk access, and that has nothing with is it DMA or IDE.

 

"I am not sure why you mention MegaST and Cubase at all...?   As I know Cubase works on ST machines too - probably not same build as for Falcon.  It is called personal experience, and that some musician had IDE disk in his Atari, despite it is so horrible thing.

 

[calimero]

2 hours ago, ParanoidLittleMan said:

"I am not sure why you mention MegaST and Cubase at all...?   As I know Cubase works on ST machines too - probably not same build as for Falcon.  It is called personal experience, and that some musician had IDE disk in his Atari, despite it is so horrible thing.

I san say excatly same thing for you:

 

“You don't listen - I wrote here multiple times”... that Cubase Audio (“Audio” is special version of Cubase for Falcon that can perform direct to disk (D2D) audio recording (only on SCSI disk) while can also perform realtime effects on audio that is playing (it can record and playback at same time up to 16 channel IIRCC). (Sidenote: PC could not perform same thing well until Pentium class processors. Many musician, my friends, was satisfied only with Pentium II class CPU and Cubase...)

 

So, do we understand each other?

 

ST Cubase and IDE have nothing with topic on SCSI, Falcon and Cubase Audio. 
 

—-

 

Next topic:

 

2 hours ago, ParanoidLittleMan said:

not relevant is it DMA or CPU driven disk access when usual Trap #1 disk access is used...

do you know what is MROS?

 

(I must ask like this to be sure that you understand me)

2 hours ago, ParanoidLittleMan said:

So, there disk access is practically one separated process too. What does not stop other processes to run (in their shared time segment).

But in multitasking system IDE will spent CPU cycles on transfer and in case of SCSI CPU will be free to do other stuff (it will not need to insert Waits like in TOS). 

[ParanoidLittleMan]

OK, this is completely pointless.

MROS is Midi related. And here is talk about realtime recording of music data on hard disk.

Falcon recording on SCSI - basically same as ST recording on ACSI (what is just early SCSI, and even performance is approx. same, with proper adapter (and ICD pro adapters could 1.6 MB/sec).

Falcon has DSP, and that's why was ahead in some things. I'm sure that some later 486 was overall much more powerful, if could not do some things what Falcon could, it was because SW.  And I know the answer - PC is crap Win is crap, etc. From someone who even can not write ACSI properly (over and over again). Much worse is  complete lack of logic.

For the end something what people who wrote hard disk driver SW,  TOS improvements: while IDE does transfers with CPU code, it is usually faster than ACSI on ST(E), or SCSI on Falcon.  During SCSI disc access CPU is not free for other stuff - it just waits for transfer ended  signal.

Only way to override it is own, direct SCSI access code - is there something like it in Cubase ?

Or special interrupts, which will perform some timing sensitive tasks during disk access. And they will make SCSI/DMA transfers slower too, because will delay part of DMA code what sets and starts transfers.  In case of IDE it will slowdown transfers, but as it is about 80% faster than SCSI on Falcon, will be still not slower - of course if disk is fast enough. 

Lot of it said 25-28 years ago stays not anymore. And I saw lot of it on Atari sites. I'm who measured exact max Atari ST DMA transfer rate.

With all possible DMA chips. What writes in diverse Atari DOCs is wrong. And smartheads just copied it. That's not knowledge. That's how sheep act.

I made something even more 'CPU hogging' than IDE transfer - with CATA adapter - where complete bus is hogged - because that's only way to do it fast on read only cartridge port. And it is so fast that even in single sector mode can over 3 MB/sec on ST(E). 1 sector transfer time is so low that can have very frequent interrupts after each sector transfer - and then it is nothing worse than SCSI considering available CPU time for other things than disk transfers. My only dilemma with it was about it - how diverse interrupts will work ? And they worked well with all SW I tested.

For the end: music playback during games (like Xenon2, Cannon Fodder) - there is low level IDE and ACSI code in those game versions. And it works very well with IDE. Couple people complained about choppy  sound - and they all have some ACSI adapter, where usual transfer rates are lower than with IDE and newer disks, CF cards.  In other words - transfer rate is what matters more than CPU load.

 

[Mr SQL]

7 hours ago, ParanoidLittleMan said:

Considering claims about Win95 - "just on top of DOS" - that simply contradicts with all what was written about it in diverse magazines what I read in those years when it was actual. Contradicts with my own experience too. 

Win 95 is made as GUI OS, and it starts in graphic mode, has some minimal requirements considering graphic capabilities - and it is not textual mode, as is with DOS.  There were many new solutions implemented (for instance LFN), and it worked with min 2 MB RAM, if I remember correct (or was it 4 ?) - that sounds as very little now, and actually was modest in 1995 too.

Forums are place where people should write own experiences in first place. Copying from diverse sources (and some do it without mentioning it) is not really useful. And errors are present everywhere. Sometimes it is only because bad formulation, shallowness, not going enough in details. Yes, people tends to like short and simple explanations, but that is often not enough to understand whole thing. And can be interpreted pretty much wrong, especially as basic knowledge in area is missing.  And yes, I dare to say that most of people at computer forums is missing some really elementary knowledge about hmmm... how computers work (what actually did not change much since 1980).

Then, I don't go in threads, discussions if I don't know that area, not sure in things.

It is really pathetic to bash Windows here, just to show self as some bigger Atari fan. The fact is that it won OS war decades ago. I liked more IBM OS/2. But somehow it went not popular. I don't think that reason was it's quality. Most likely marketing was not good, development not enough fast.

 

"The iPhone and Android OS are built on top of DOS too (Unix variants) we generally need a powerful DOS Shell behind a GUI. "

This is just completely wrong formulation. Of course that any modern OS has Disk component (or better said filesystem component). On top ?

There is no top and bottom. Disk part and GUI part work parallel. It is same in TOS too.

 

Good point Win95 could run with 4 MB. It needed 16 MB to avoid heavy use of swapping out memory to disk, now we need 16 GB and 10x more Mhz with Windows 10 to run many of the same programs with comparative performance.

 

I see your perspective that the GUI parts work in parallel with the Unix operating system and both together comprise the Android GUI OS or iPhone GUI OS. 

 

I think Win95 gets bashed a lot because it had no bash shell equivalent for many functions and was comparatively sparse for working in tandem with a GUI.

 

Fun Trivia: Microsoft initially had a "Windows" development tool Visual BASIC for DOS for creating "windows" based applications using just the DOS text screen to draw overlapping windows with ASCII art using the character set built into ROM.  That tool could have been ported to the Falcon or the 800 even using Disk BASIC.

 

[TGB1718]

23 minutes ago, Mr SQL said:

Fun Trivia: Microsoft initially had a "Windows" development tool Visual BASIC for DOS for creating "windows" based applications using just the DOS text screen to draw overlapping windows with ASCII art using the character set built into ROM.  That tool could have been ported to the Falcon or the 800 even using Disk BASIC.

I used to write programs using something similar, it was call The C Windows Toolkit and allowed you to write

"windowed" application running under DOS, usually with a Btrieve Database for the data.

C Windows Toolkit.zip

[Mr SQL]

2 minutes ago, TGB1718 said:

I used to write programs using something similar, it was call The C Windows Toolkit and allowed you to write

"windowed" application running under DOS, usually with a Btrieve Database for the data.

C Windows Toolkit.zip 137.19 kB · 1 download

Very cool lightweight development tool! Those were fun times...

There are many offices still using programs in production written with tools like this. Sometimes see them getting "screen scraped" for integration with modern kit.

 

[zzip]

7 hours ago, ParanoidLittleMan said:

Win 95 is made as GUI OS, and it starts in graphic mode,

But change one flag in Win95 and it will start in DOS mode.  

Also for Windows 3.1 you could add "win" to autoexec.bat and your computer starts in GUI mode.   So this doesn't mean anything.

 

Yes Microsoft made significant effort to hide MSDOS from the users in Windows 95,  but it is still there underneath.

[calimero]

4 hours ago, ParanoidLittleMan said:

OK, this is completely pointless.

MROS is Midi related. And here is talk about realtime recording of music data on hard disk.

Yes, MROS is MIDI related and is Steinberg OS and Cubase (among other software) use it. 

What I believe is that Cubase Audio (software that have D2D audio recording and runs only on Falcon) exploit DMA SCSI ability by skipping TOS for disk access and thus skipping problem that you mentioned: that CPU wait while DMA transfer is over (in TOS) - which basically defeat the purpose of DMA (if CPU is stalled while DMA is not finished)!

Quote

Falcon recording on SCSI - basically same as ST recording on ACSI (what is just early SCSI, and even performance is approx. same, with proper adapter (and ICD pro adapters could 1.6 MB/sec).

Right now I can not access Falcon manual, but I do know that there is explanation how sound matrix is connected (and it is not the same "as ST recording", it is Falcon audio recording on SCSI/DMA). There can be found exactly how data is transfered (I read it few years ago, now I am on vacation so my internet access is limited, and time ).

Quote

Falcon has DSP, and that's why was ahead in some things.

Please note that audio recording on Falcon does not have anything with DSP. DSP can be involved in audio by adding realtime effect but is not mandatory for audio hard disk recording (D2D).

 

Quote

I'm sure that some later 486 was overall much more powerful, if could not do some things what Falcon could, it was because SW. 

Because of operating system. Steinberg did make ASIO drivers to skip/patch/avoid (I do not know technical details how they did it) whole Windows mess.

Beside whole PC hardware was/is bunch of lowest common denominator:

e.g. put IDE in PC and than wait for X years to gain everything that SCSI had years before.

Same goes for any other technology used in PC (BIOS, CPU/AltiVec, card slots, ports and finally Microsoft OS).

Today problem is that Wintel destroy any alternative company so you can not even compare PC to anything else (so you can not tell how crap PC is! Fortunately Apple is the only company that survive Microsoft "Embrace, extend, and extinguish" strategy and they present last year alternative to Wintel in form of M1 chip (chip that expose how crap is Wintel universe)). 

Back in days it was much more obvious when you could see Falcon doing stuff that only Pentium grade PC could match.

 

Quote

During SCSI disc access CPU is not free for other stuff - it just waits for transfer ended  signal.

On MagiC this is not the case.

Quote

Only way to override it is own, direct SCSI access code - is there something like it in Cubase ?

Probably. Finally you understand what I was talking about in posts days ago... bravo. (sarcasm)

 

Did not occur to you or you just did what OldSchoolRetroGamer suggest in post #92?

- Continue to talk for few more posts how TOS stall CPU on DMA transfer. Which is good. But why I need to wait for dozen post for you to come to this simple conclusion: "Only way to override it is own, direct SCSI access code - is there something like it in Cubase ?"

 

Thank you.

 

Quote

Or special interrupts, which will perform some timing sensitive tasks during disk access. And they will make SCSI/DMA transfers slower too, because will delay part of DMA code what sets and starts transfers.  In case of IDE it will slowdown transfers, but as it is about 80% faster than SCSI on Falcon, will be still not slower - of course if disk is fast enough. 

You still can not grasp that there is no need for more than 1.5MB/s for 16 audio tracks and, more important, that Cubase probably need every CPU cycle for other task while recording/playing audio tracks. In Cubase Audio you can mix MIDI tracks with Audio, you have update of screen in realtime... so loss of CPU cycles in case of potential IDE transfer would probably harm whole program.

Quote

Lot of it said 25-28 years ago stays not anymore. And I saw lot of it on Atari sites. I'm who measured exact max Atari ST DMA transfer rate.

With all possible DMA chips. What writes in diverse Atari DOCs is wrong. And smartheads just copied it. That's not knowledge. That's how sheep act.

I made something even more 'CPU hogging' than IDE transfer - with CATA adapter - where complete bus is hogged - because that's only way to do it fast on read only cartridge port. And it is so fast that even in single sector mode can over 3 MB/sec on ST(E). 1 sector transfer time is so low that can have very frequent interrupts after each sector transfer - and then it is nothing worse than SCSI considering available CPU time for other things than disk transfers. My only dilemma with it was about it - how diverse interrupts will work ? And they worked well with all SW I tested.

For the end: music playback during games (like Xenon2, Cannon Fodder) - there is low level IDE and ACSI code in those game versions. And it works very well with IDE. Couple people complained about choppy  sound - and they all have some ACSI adapter, where usual transfer rates are lower than with IDE and newer disks, CF cards.  In other words - transfer rate is what matters more than CPU load.

 

...but reading what you wrote, I do believe that you could write Cubase Audio that would work like Steinberg program but with IDE audio direct to disk recording...  (I am serious about this statement!)

 

Like Douglas Little showed that Falcon can run Doom like game and Quake like engine (without Pentium grade CPU)  it is pure software goodness!   so I do believe that you could do same for writing audio tracks to IDE on Falcon...

Edited July 30, 2021 by calimero

[Cyprian]

11 hours ago, ParanoidLittleMan said:

If IDE has max transfer rate of 3 MB/sec and SCSI 1.8 MB/sec then audio hard disk recording speed is lower than 1.8 MB/sec for sure - in case of Falcon.  Let's say it is 1.5 MB/sec - then CPU load will be 50% with IDE, so no, CPU is not occupied totally, and SW can work with lower speed (what happens with DMA too, as said CPU must wait when DMA accessing RAM - that's less than 50% normally, but with higher transfer speeds is more. My disk speed test program shows CPU slowdown in DMA mode, for instance - and I don't know any other knowing that).

It might be that IDE drives were simply too slow in Cubase early years, and they were - like max speed under 1 MB/sec .

That ~3 MB/s was my result on a boosted Falcon (phantom like booster). On a stock machine it was much less. There I see https://www.atari-forum.com/viewtopic.php?p=84075#p84075 an IDE figure: 2670 Kb/s

For 8 tracks 16bit 44,1Khz we need 705 600 bytes per second, in case of that IDE figure about 26% (705 600/2 670 000)of the CPU taken only for data transfer. In case of SCSI it is 4% (705 600/8 000 000 ) of the Bus usage.

I was using D2D with SCSI (Cubase) and also with IDE (I don't remember the App name now) and that 26% vs 4% sounds very realistic. GEM GUI was less responsible in case of IDE than with SCSI.

 

I wonder how Cubase managed that SCSI disk access.

Edited July 30, 2021 by Cyprian

[OldSchoolRetroGamer]

[Chri O.]

Quote

I wonder how Cubase managed that SCSI disk access.

Falcon 030 - SDMA IC.

 

[Cyprian]

On 7/30/2021 at 8:36 PM, Cyprian said:

 In case of SCSI it is 4% (705 600/8 000 000 ) of the Bus usage.

should be (705 600 / 2) /8 000 000 = 4%  

we need count of audio data words (16bit): 705 600 bytes / 2, and we divide them by 8 000 000 - data bus slots available per second

 

 

 

On 7/30/2021 at 8:36 PM, Cyprian said:

I wonder how Cubase managed that SCSI disk access.

@Chri O. I mean how they get data from HDD, via TOS calls or by direct access to the SCSI device

[Chri O.]

On 7/31/2021 at 4:02 PM, Cyprian said:

I mean how they get data from HDD, via TOS calls or by direct access to the SCSI device

What Does Direct Memory Access (DMA) Mean?
Direct memory access (DMA) is a method that allows an input/output (I/O) device to send or receive data directly to or from the main memory, bypassing the CPU to speed up memory operations.

The process is managed by a chip known as a DMA controller (DMAC).

[calimero]

On 7/30/2021 at 3:13 PM, ParanoidLittleMan said:

Falcon has DSP, and that's why was ahead in some things. I'm sure that some later 486 was overall much more powerful, if could not do some things what Falcon could, it was because SW.

I just stumble on http://longview.be where you can find a lot of old Mac stuff...

Among many articles I found interesting card for audio recording: "DigiDesign Pro Tools Audio Card" - it was released in 1990 as "first tapeless studio". It has two DSP MC56001 on-board and it could play/record 4 tracks for cost of 6000$.

 

Later, in 1994., Digidesign (author of ProTools) release ProTools II TDM software that could do 16 track by linking FOUR cards (so 4 x 6000$ ?!) and with Digidesign designed SCSI card! 

[calimero]

On 8/4/2021 at 5:23 AM, Chri O. said:

What Does Direct Memory Access (DMA) Mean?
Direct memory access (DMA) is a method that allows an input/output (I/O) device to send or receive data directly to or from the main memory, bypassing the CPU to speed up memory operations.

but as Petari noted: problem is that TOS will wait until DMA transfer is finished (so defeating the purpose of DMA).

Steinberg overcome this problem probably (almost certainly) by skipping TOS while working with SCSI.

And multitasking OS also "hide" this TOS problem with "waiting to be finished" DMA transfers...

 

On 8/4/2021 at 5:23 AM, Chri O. said:

The process is managed by a chip known as a DMA controller (DMAC).

SDMA chip in Atari Falcon.

[Chri O.]

10 hours ago, calimero said:

problem is that TOS will wait until DMA transfer is finished

Apparently not in Falcon TOS at least for SDMA and SCSI controller.

LINK:  Atari Falcon030 Service Guide October 1, 1992.

 

The dma controller is set up to select the source and the number of 512 byte block to transfer, and then the FDC or external peripheral (SCSI) is given the command to send or receive data. The entire block of data is then transferred to or from memory without intervention by the CPU (PAGE 20).

 

[Sporny Kun]

1 hour ago, Chri O. said:

Apparently not in Falcon TOS at least for SDMA and SCSI controller.

LINK:  Atari Falcon030 Service Guide October 1, 1992.

 

The dma controller is set up to select the source and the number of 512 byte block to transfer, and then the FDC or external peripheral (SCSI) is given the command to send or receive data. The entire block of data is then transferred to or from memory without intervention by the CPU (PAGE 20).

 

 

I believe that what @calimero wanted to say is that should the CPU requires memory access, it MUST wait for the DMA chip to finish the transfer. Meaning that if the CPU does not need to write to RAM and that there is no miss in its cache, the CPU may happily continue working for a while.

Edited August 5, 2021 by Sporny Kun
fix typos

[calimero]

16 hours ago, Sporny Kun said:

I believe that what @calimero wanted to say is that should the CPU requires memory access, it MUST wait for the DMA chip to finish the transfer. Meaning that if the CPU does not need to write to RAM and that there is no miss in its cache, the CPU may happily continue working for a while.

Well no  

 

I repeat what Petari told: problem is not on hardware level (both, Sporny K. and Chri O., you are right from purely hardware point of view).

But Petari said that problem is in TOS: TOS will wait for DMA transfer (more precisely: wait for file access) to be finished before it continue to execute code!

So IDE and SCSI data transfer, from user point of view, will be the same: TOS will wait for transfer to be finished before it continue (TOS does not utilize SCSI DMA ability, TOS will block execution of code).

 

My argument was, like you both pointed, that from hardware side, there is no reason for CPU to be blocked in case of DMA transfer and that Cubase probably skip TOS when accessing to hard disc (doing D2D recording).

Edited August 6, 2021 by calimero