Jump to content
IGNORED

ACSI-to-USB alternative to an Ultrasatan?


Recommended Posts

Just wondering out loud...

 

Is there an alternative to Ultrasatan similar to RespeQt for the 8-bit machines that can run over ACSI as a USB HDD emulator?

 

Nothing against Ultrasatan, but I've just had three pieces of hardware free themselves up that would be ideal candidates for this.

 

(Yep, I'm aware of Netusbee, but would like to also know of alternatives to that if possible.)

 

 

Edited by x=usr(1536)
Link to comment
Share on other sites

Gigafile is not USB, it works with SD cards too.

 

I don't think that USB on Atari is really good for mass storage. NetUsBee is very slow in that. What speed is OK for 8-bit machines is slow for ST.

And prices of SD cards are low now, so I really don't see the point to insist on USB-Pen drive way.

I'm not saying that making fast ACSI-USB adapter is not possible. First condition is fast USB chip, what can convert storage transfers to something what can be converted to ACSI (SCSI in fact). Surely someone need to develop that second part. And that will be pretty hard and time consuming.

Don't see that will happen soon. And if, price will be likely pretty high, especially at start.

 

 

Link to comment
Share on other sites

Sorry - I should have been a bit clearer as to what it is I'm looking to accomplish.

 

Ideally, I'd like to be able to connect the ST to another machine via USB, have that machine see the USB device as mass storage and create a mountpoint for it.  On the ST side, something similar would happen, and be presented as drives C through P.

 

Changes made under the mountpoint on the remote machine would reflect on the ST and vice-versa.

 

As for attached mass storage, I'm agnostic when it comes to USB or SD cards.  Either one is fine by me.

Link to comment
Share on other sites

5 hours ago, x=usr(1536) said:

Sorry - I should have been a bit clearer as to what it is I'm looking to accomplish.

 

Ideally, I'd like to be able to connect the ST to another machine via USB, have that machine see the USB device as mass storage and create a mountpoint for it.  On the ST side, something similar would happen, and be presented as drives C through P.

 

Changes made under the mountpoint on the remote machine would reflect on the ST and vice-versa.

 

 

So something like GhostLink but over USB instead of serial ports?

Link to comment
Share on other sites

8 hours ago, Cyprian_K said:

ACSI to USB: http://www.atari-forum.com/viewtopic.php?t=25276 I'm not sure whether ST can boot from that USB

Other option is CosmosEx - it allows you to boot ST from shared folder from e.g. Windows

 

Yep, and CosmosEx looks about right for what I'm trying to accomplish.  However:

 

7 hours ago, myriadcs said:

CosmosEx is great but unfortunately hard to buy

 

Which is the downside to the CosmosEx.

 

4 hours ago, MrMaddog said:

 

So something like GhostLink but over USB instead of serial ports?

 

Essentially, yes.  My idea was to implement this on a Raspi Zero W for maximum physical portability - it would be dead easy to move it between multiple machines.  It'd also be cheap enough that putting one together for each machine (including the 8-bits) wouldn't be a huge deal, and I could keep software centralised on the existing fileserver which would be far preferable to trying to manage it on individual machines.

Link to comment
Share on other sites

I forgot about Unicorn. And really don't know much about it. But it seems that it is not good for what OP wants - other computer as storage, and connection via USB.

 

Well, I think that best, and not expensive solution is PARCP . It goes on parallel port of ST. And uses USB now, as no parallel ports on newer computers. There are threads around about it.

Speed will be not so great, but that's what is available. Certainly faster than serial port solutions.

 

  • Like 1
Link to comment
Share on other sites

7 hours ago, ParanoidLittleMan said:

I forgot about Unicorn. And really don't know much about it. But it seems that it is not good for what OP wants - other computer as storage, and connection via USB.

 

Yep, it's not quite what I'm looking for.  It does provide the basic ACSI-to-USB interface that I want, but not the ability to be seen as a mass storage device.

 

Quote

Well, I think that best, and not expensive solution is PARCP . It goes on parallel port of ST. And uses USB now, as no parallel ports on newer computers. There are threads around about it.

Speed will be not so great, but that's what is available. Certainly faster than serial port solutions.

 

PARCP would be fine, except that the software isn't cross-platform - and I don't have a Windows box that can be dedicated to running it.  It would be possible to run it on the ESXi server, but then I'd have to drag the Atari hardware over to that box whenever changes were being made, which would be a real pain after doing that the first time ;)

 

FWIW, the reason why I'm fixating on the ACSI-to-USB idea is that, in theory, going this route should allow any ST or TT machine to see the device as an HDD provided that it presents itself to TOS correctly; it would also allow for it to be bootable if desired.  Additionally, ACSI has the highest usable transfer rate (1.25MB/sec) of any of the ST's ports, so would theoretically give the best performance on storage operations, though I accept that that data rate isn't likely to be reached in real-world scenarios.

 

 

Edited by x=usr(1536)
Link to comment
Share on other sites

OK, I have picture about what you want. And that is possible. But I don't think that is made, especially not that it can boot from external storage.

CosmosEx has SD card mode - what is same as UltraSatan, with 1 SD card only. And shared mode - when some folder on PC appears as Atari logical drive. That's most similar to so called GEMDOS emulation in emulators like Steem and Hatari. But is different from real hard disk a la Atari way of work. And not so compatible with SW.

Atari TOS can handle only FAT16 partition format, with limited capacity, and it is not compatible with usual DOS FAT16 (the reason why we need TOS/DOS compatible partitions and driver SW for them).  What CosmosEx does is some kind of translation to concrete file access functions in TOS - via trap #1 disk functions like  file open, file read, file write ... 

 

You want that it presents to TOS correctly. Well, that's possible only with images of whole drive, or at least partitions. For autoboot must have whole disk (Flash card) image with MBR -  on host.  That's not problem - 14x512 MB will take only 7 GB - TOS can max 14 partitions C-P, and max size is 512 MB (TOS 1.00-2.02 256 MB) . 

 

Now, I really can not see why using some other computer for storing it is better than Flash card adapter (like UltraSatan) ?

When you can easily attach SD or CF card to modern computer and do file transfers - modern OS-es support FAT16 partitions.

 

And I need to correct some claims: ACSI max rate is 2 MB/sec - but it's not your fault. Atari DOCs are wrong.

IDE port can more (than false claim) - 1.6 MB/sec - OK, ST, STE have no IDE port, but still, that's cheapest storage adapter, especially if you can DIY. I made mine in 1992.

And even faster: http://atari.8bitchip.info/astams.php

  http://atari.8bitchip.info/astide.php

 

And more about autoboot: ST, STE have only regular ACSI autoboot (code in TOS is needed for). That means that only if adapter supports regular ACSI commands it will autoboot. And that's extra work for designer. Some ACSI-USB link should access image files on host via ACSI commands, better said via ICD extended ACSI commands, because basic ACSI can max 1 GB . Need to translate ACSI/SCSI to USB, writing special driver SW for Atari and for host computer - pretty much to do. With ACSI-SD card adapters it is easier, because SD cards have protocol very similar to SCSI.

 

Link to comment
Share on other sites

42 minutes ago, ParanoidLittleMan said:

OK, I have picture about what you want. And that is possible. But I don't think that is made, especially not that it can boot from external storage.

 

Agreed - the more I look into it, the less it appears as though it's something that's currently available.

 

42 minutes ago, ParanoidLittleMan said:

CosmosEx has SD card mode - what is same as UltraSatan, with 1 SD card only. And shared mode - when some folder on PC appears as Atari logical drive. That's most similar to so called GEMDOS emulation in emulators like Steem and Hatari. But is different from real hard disk a la Atari way of work. And not so compatible with SW.

 

Yep.  This is why, as much as I like the CosmosEx, the compatibility issues you mention are a reason why I'm not (immediately) going for one.  It has probably 95% of what I want, though.

 

42 minutes ago, ParanoidLittleMan said:

Atari TOS can handle only FAT16 partition format, with limited capacity, and it is not compatible with usual DOS FAT16 (the reason why we need TOS/DOS compatible partitions and driver SW for them).  What CosmosEx does is some kind of translation to concrete file access functions in TOS - via trap #1 disk functions like  file open, file read, file write ... 

 

Understood.  More:

 

42 minutes ago, ParanoidLittleMan said:

You want that it presents to TOS correctly. Well, that's possible only with images of whole drive, or at least partitions. For autoboot must have whole disk (Flash card) image with MBR -  on host.  That's not problem - 14x512 MB will take only 7 GB - TOS can max 14 partitions C-P, and max size is 512 MB (TOS 1.00-2.02 256 MB) . 

 

My thinking is that loopback filesystems on the USB-attached storage could get around this problem to some extent.  Create a 512MB loopback on the RasPi; partition, format, and mount it as TOS (which, IIRC, the Linux kernel supports); present that loopback to the ST over USB; repeat for drives D through P ;)

 

42 minutes ago, ParanoidLittleMan said:

 

Now, I really can not see why using some other computer for storing it is better than Flash card adapter (like UltraSatan) ?

When you can easily attach SD or CF card to modern computer and do file transfers - modern OS-es support FAT16 partitions.

 

Absolutely.  However, I'd like a solution that can be managed remotely and that doesn't require physical intervention to change software on the target host.  It also opens up the possibility of a single RasPi handling storage for multiple STs, which would help with consolidating the physical location of my Atari hardware.  And, finally, it would allow for keeping the environment that I create on the fileserver rather than scattered onto several SD cards, which would help with backups and tracking changes on a per-machine basis.

 

Having said all of that, I do not disagree with the idea of SD, CF, or other card-based media as a possible solution - and that may be the route I end up taking.  But if there's an alternative ;)

 

42 minutes ago, ParanoidLittleMan said:

And I need to correct some claims: ACSI max rate is 2 MB/sec - but it's not your fault. Atari DOCs are wrong.

IDE port can more (than false claim) - 1.6 MB/sec - OK, ST, STE have no IDE port, but still, that's cheapest storage adapter, especially if you can DIY. I made mine in 1992.

And even faster: http://atari.8bitchip.info/astams.php

  http://atari.8bitchip.info/astide.php

 

Ah, thanks for that - I've been under the 1.25MB/sec impression for decades.

 

42 minutes ago, ParanoidLittleMan said:

And more about autoboot: ST, STE have only regular ACSI autoboot (code in TOS is needed for). That means that only if adapter supports regular ACSI commands it will autoboot. And that's extra work for designer. Some ACSI-USB link should access image files on host via ACSI commands, better said via ICD extended ACSI commands, because basic ACSI can max 1 GB . Need to translate ACSI/SCSI to USB, writing special driver SW for Atari and for host computer - pretty much to do. With ACSI-SD card adapters it is easier, because SD cards have protocol very similar to SCSI.

 

True...  But USB-to-SCSI is already implemented in the Linux USB subsystem (reference), which means that all that likely needs to be handled is the ability to translate between ACSI and SCSI (and vice-versa).  Granted, that's not the only hurdle to overcome, but it seems like a lot of the basic building blocks are already there.

Link to comment
Share on other sites

OK, so idea is to use (small) Raspberry as some kind of network server. This reminds me on how it was solved in 1992, when I went on some DOS SW curse - only server was with hard drive, PCs by us, students were only with floppies. And we had partitions via network . What was quite fast enough for DOS and those times.

Idea is good, but there are things to solve: as said, TOS FAT16 is not same as DOS FAT16, and of course later is used by Linux. It was, and maybe is still possible to compile in Kernel TOS FAT16 support. But I'm not sure that is possible to create such partitions. Then, there is LFN problem - TOS don't like Windows long file names, and if they are present on disk, partition, it may cause serious errors. Filtering is necessary.

 

Let's say that above problems are solved - maybe just to using on Atari created TOS/DOS compatible partitions,    comes main thing:

communication. If Raspberry can have SCSI adapter somehow then it could be used ... Hmmm... but there is problem that it needs to be not host, but target. Since Atari ACSI is host only. Proposed connecting multiple Ataris to Raspberry as server needs that Ataris be targets. And I don't think that DMA chip in Atari is ready for that way.

Parallel port is much more flexible, and even cartridge port. Then, SCSI is not good for longer distances. USB not too, but should be OK up to 1 meter or little more. 

All in all, it will need lot of work on SW, and HW too, but later depends a lot of available USB chips - what they can, how fast.

 

Maybe should think another way:  Ataris with own storage. Or just one UltraSatan (or something else) for all them, of course not at once. I don't think that really want all time to use all them at once ?  And PARCP for transferring files between Rasp and Atari/SD card.

Link to comment
Share on other sites

21 hours ago, ParanoidLittleMan said:

OK, so idea is to use (small) Raspberry as some kind of network server.

 

Pretty much.  Network connectivity (e.g., to the fileserver) would only take place between the Raspi and fileserver.  Between the Raspi and ST, the ST would appear as USB-attached mass storage to the Raspi, and the Raspi would appear as ACSI-attached hard disks to the ST.

 

A direct connection between the Raspi and fileserver wouldn't be mandatory: the Raspi could conceivably host the filesystem(s) that the ST mounts on itself.  But in the ideal case for my situation, it would work as described above.

 

21 hours ago, ParanoidLittleMan said:

This reminds me on how it was solved in 1992, when I went on some DOS SW curse - only server was with hard drive, PCs by us, students were only with floppies. And we had partitions via network . What was quite fast enough for DOS and those times.

 

Yep, we had something similar as well.

 

21 hours ago, ParanoidLittleMan said:

Idea is good, but there are things to solve: as said, TOS FAT16 is not same as DOS FAT16, and of course later is used by Linux. It was, and maybe is still possible to compile in Kernel TOS FAT16 support. But I'm not sure that is possible to create such partitions. Then, there is LFN problem - TOS don't like Windows long file names, and if they are present on disk, partition, it may cause serious errors. Filtering is necessary.

 

Agreed on all points.  When I have some more time after Christmas / the New Year, I'll look into what TOS filesystem support is like in a modern kernel.  If that's not there (and usable; there's no telling what state it's in at present, assuming it exists), that makes this a much more realistic approach to consider moving forward with.  If it's not usable, it's pretty much dead in the water for me as I am not anywhere near qualified to write filesystem LKMs or similar ?

 

21 hours ago, ParanoidLittleMan said:

Let's say that above problems are solved - maybe just to using on Atari created TOS/DOS compatible partitions,    comes main thing:

communication. If Raspberry can have SCSI adapter somehow then it could be used ... Hmmm... but there is problem that it needs to be not host, but target. Since Atari ACSI is host only. Proposed connecting multiple Ataris to Raspberry as server needs that Ataris be targets. And I don't think that DMA chip in Atari is ready for that way.

 

Points taken.  However, I *think* (and that is a big 'maybe') that the SCSI issue may not be that difficult to work around. But you're right about the DMA controller in the Atari: that could be a showstopper.

 

21 hours ago, ParanoidLittleMan said:

Parallel port is much more flexible, and even cartridge port. Then, SCSI is not good for longer distances. USB not too, but should be OK up to 1 meter or little more.

 

Valid points, but distance isn't really a concern in this situation - Raspis are small enough that they can easily be located within the limits of the cabling's reach.

 

21 hours ago, ParanoidLittleMan said:

All in all, it will need lot of work on SW, and HW too, but later depends a lot of available USB chips - what they can, how fast.

 

True.  I'm also going to ask (after the first of the year) friends of mine who actually work with hardware at this level about the feasibility of implementing it.  Looking at a Unicorn might also be useful, since it seems to have done a fair amount of the interfacing groundwork.

 

21 hours ago, ParanoidLittleMan said:

Maybe should think another way:  Ataris with own storage. Or just one UltraSatan (or something else) for all them, of course not at once. I don't think that really want all time to use all them at once ?  And PARCP for transferring files between Rasp and Atari/SD card.

 

Oh, I agree ?  And this may end up being the way(s) that I go.  But I'm wondering about the practicality of having a direct ACSI-to-USB interface as described previously, and want to do some poking around.  If it goes nowhere, not a big deal - we're really lucky in that we're spoiled for choice these days in terms of ST peripherals, so at least there are plenty of working alternatives to choose from.

Link to comment
Share on other sites

After spending a couple of days reading up on how ACSI functions, I think this is possibly doable with some caveats:

  • There will need to be a microcontroller (PIC?  Arduino/custom?) or similar between the ACSI and USB busses, but that's not a surprise.
  • The ST's DMA chip should be a non-issue provided that the microcontroller understands the need for flushing it at the end of data transfers.
  • Keeping the ACSI and USB busses in sync may be... Interesting.

Not sure if I can invest a whole lot of time into trying to figure this out, but will look back into it after the New Year.

Link to comment
Share on other sites

After some consideration, I've come to the conclusion that an ACSI-to-USB solution may not be the best way to approach the underlying issues it seeks to solve.  The idea has merit, but it also has limitations that can probably be solved more flexibly (and elegantly) via network-attached filesystems.

 

With that in mind, I'd invite anyone interested to take a look at the #FujiNet Project.  Yes, it's being implemented on 8-bit machines at this time.  However, from discussion with one of the main developers, it should be possible to implement the underlying TNFS protocol on any machine that wants to connect to FujiNet or private fileshares.

 

With the previously-suggested ACSI-to-USB interface, the ST has to do its file accesses via a USB-attached host.  Under the FujiNet model, everything happens without the need for hardware other than the FujiNet WiFi interface. Also, FujiNet doesn't rule out the option of local network-attached storage; if your storage host can run TNFS, then you're as good as if you were USB-connected to it.

 

I don't believe that the ACSI-to-USB idea is without merit, and it really does warrant further exploration.  However, given what can be accomplished with TNFS, the flexibility it offers appears to be a better approach.

Link to comment
Share on other sites

Yeah, I wanted to add here something before couple days, but was little away.

Connecting multiple computers together via ACSI and/or USB is not good idea because powering of them with transformers on electric grid. That may cause some voltage between GNDs of them. Only avoidable really with common PSU and strong GND lines.

That's why network goes galvanicaly separated via opto copplers . But to serve multiple Ataris that way, and with NetUsBees need to have multiple network adapters/connectors in PC or Raspberry.

WiFi seems as very good idea in this case. Speed is more than good for Ataris. I guess that main question is how much will cost WiFi interface for Atari.

Link to comment
Share on other sites

9 hours ago, ParanoidLittleMan said:

Yeah, I wanted to add here something before couple days, but was little away.

Connecting multiple computers together via ACSI and/or USB is not good idea because powering of them with transformers on electric grid. That may cause some voltage between GNDs of them. Only avoidable really with common PSU and strong GND lines.

 

True.  All of our equipment is connected to UPSes, but that's only good for cleaning the grid side.  The output side can generate its own problems which have the potential to be shared between machines.

 

9 hours ago, ParanoidLittleMan said:

That's why network goes galvanicaly separated via opto copplers . But to serve multiple Ataris that way, and with NetUsBees need to have multiple network adapters/connectors in PC or Raspberry.

 

Multiple interfaces on the host acting as fileserver wouldn't be necessary - just place a switch between the Ataris and the PC / Raspi / Whatever.

 

9 hours ago, ParanoidLittleMan said:

WiFi seems as very good idea in this case. Speed is more than good for Ataris. I guess that main question is how much will cost WiFi interface for Atari.

 

Agreed.  I'm waiting to see what the final hardware design looks like; TNFS is already fairly mature, so from the software side it's really just a question of implementing it on the ST.  Assuming that the FujiNet hardware can be easily adapted to the ST, it should be possible to come up with a working prototype relatively quickly.

Link to comment
Share on other sites

  • 1 month later...

One of the reasons why SIO2USB works so nice is that there is only one I/O connector. But on ST/Falcon you have at least two: floppy and ACSI and/or SCSI and/or IDE. So in that sense CosmosEx is really the closest because it handles both in one device. It's quite easy to actually make a RPi application similar to RespeQt running on CE itself or even to make a RespeQt-like application for PC which communicates with the CE and selects floppy images.

 

If you were after standalone project, I guess you could go after pure USB -> floppy transfer, reuse HxC's firmware (on the fly conversion to streaming-friendly HFE format) and just output the data similarly as Gotek or HxC do.

 

EDIT: Oh I see you have specifically asked about ACSI. In that case it should be still possible with USB 2.0+ but you have to ask yourself what would you expect from such software? Hard drive images? Emulated hard disk on given folder? In that way CosmosEx is really the closest. :) If I were to do it, I wouldn't bother with HD emulation (like CE or Hatari does) but created a hd image in memory and streamed that directly to USB -> ACSI.

Edited by mikro
Link to comment
Share on other sites

  • 4 weeks later...
On 12/22/2019 at 6:26 PM, x=usr(1536) said:

 

True.  All of our equipment is connected to UPSes, but that's only good for cleaning the grid side.  The output side can generate its own problems which have the potential to be shared between machines.

 

 

Multiple interfaces on the host acting as fileserver wouldn't be necessary - just place a switch between the Ataris and the PC / Raspi / Whatever.

 

 

Agreed.  I'm waiting to see what the final hardware design looks like; TNFS is already fairly mature, so from the software side it's really just a question of implementing it on the ST.  Assuming that the FujiNet hardware can be easily adapted to the ST, it should be possible to come up with a working prototype relatively quickly.

As both an 8bit and 16bit owner, I was wondering if anybody has started with adopting TNFS for the Atari ST or the FujiNet hardware for the Atari ST ?

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...