Sorry for the thread bump, but I wanted to add this:
Cyprian wrote:Jookie, would be possible to use that device as an graphics card?
It could be done, but it would lower your hard disk transfer speed and it probably wouldn't work well with existing games and demos (if it would be done through ACSI port), but if you are asking only about supporting new stuff, then you could get interesting things out of it (although there would be lack of ST software for that).
I'd be very, very, very, very interested in such an extension! I pondered the possibility in this thread:http://atari-forum.com/viewtopic.php?f= ... 72#p339572
The way I imagined it would be to tap into the VDI calls, and send the drawing instructions (not bitmap data) over the ACSI bus to the Raspberry Pi. The Pi could then use a simple off-the-shelf graphics library to actually draw those primitives to the full-HD screen using its extremely fast GPU. While you wouldn't be able to bit-bang the frame buffer from the ST side, I don't think that matters since software running on a graphics card doesn't bit-bang the frame buffer either (it has to go through VDI - since it knows nothing about how the frame buffer is organised, some cards are chunky - nibble and byte - and some are planar).
Not only would it easily add full HD support to an ST without any internal soldering, it would be absolutely blazingly fast! Since the Pi can draw so quickly, I reckon a simple 1040 would feel about as fast as a TT. A much better solution than adding ET4000 graphics cards - and a lot of people do that so there's definitely demand. Fitting an ET4000 to a 1040 is an enormous pain, so it would be the perfect solution for those who don't own MegaSTEs or TTs.
Obviously it wouldn't work with games and demos. But lots of people use their STs for productivity (especially music), and I think any music software that supports a graphics card would also work with such a system.
I'm not sure I can help much with implementing this. I'm reasonably fluent with 68000 assembly and C, and my main area is hardware. I might be able to do the drawing software on the Raspberry Pi side - I don't know much about Linux internals, but I've used a few graphics libraries before. My sticking point is figuring out how to tap into VDI - I know very little about how it works. I suppose you could just install a new handler for that particular trap but I'd need to do quite a lot of research and I'd need the assistance of someone deeply familiar with VDI.
I don't think it would necessarily cause a major problem for hard disk speed. When there's lots of activity on the screen (especially blitting bitmap data from ST RAM to the frame buffer) the bus will be busy. But most programs do very little screen updating when loading/saving. Cubase Audio might be slightly more difficult because it needs to update the screen and read/write the disk when recording and playing. But even then, Cubase is mostly just doing simple line drawing and rectangle fill operations - the commands to initiate those drawing operations are tiny and would use hardly any bandwidth.
I have another completely unrelated suggestion too. Seeing as it allows connection via SCSI, does that mean you can use it as a USB mass storage device for other SCSI hosts? I'm thinking particularly of musical instruments like samplers. If so, it potentially opens up another much bigger market! There do exist micro SD card to SCSI adapters, but they're still relatively expensive and don't accept USB. Dealing with micro SD cards is just an enormous pain. Of course, it would be even better if you could tell Linux to mount a network share and mount a hard disk image on an external server. Samplers use non-standard file systems so I don't expect to have file-level access, but it would still be great to network it to another computer which hosts the hard disk image.
One feature which would be really handy for sampler support would be the ability to emulate a CD-ROM drive using an ISO image. You often need to load sample CDs into a sampler - one of the existing SD to SCSI converters allows this by formatting the SD card in a special way. But it would be so much more convenient to bung an ISO file on a USB stick and have the Raspberry Pi detect it and mount it. I think CD-ROM emulation is very similar to emulating a hard disk, just with a different sector size. Again, samplers use non-standard file systems so it would need to just make the ISO available to the host on a sector-by-sector basis - not try to interpret the file system.