Overview Features Instructions Performance Forum Downloads Products OrderV4 Reseller Contact

Welcome to the Apollo Forum

This forum is for people interested in the APOLLO CPU.
Please read the forum usage manual.
VISIT APOLLO IRC CHANNEL



All TopicsNewsPerformanceGamesDemosApolloVampireAROSWorkbenchATARIReleases
The team will post updates and news here

WANTED : Developers for AMIGA OS Or Drivers

Gunnar von Boehn
(Apollo Team Member)
Posts 4452
14 Jun 2017 17:54


AMIGA OS is nice.
 
it could be even nicer for all of us with
 
a) an SDCard driver for Vampire able to boot from
 
b) IDE/SCSI device using DMA for best performance
 
c) a filesystem cache included in the OS
 
 
 
  it would be great if any developer would like to help on any of these tasks
 
 
 


Roman S.

Posts 149
14 Jun 2017 22:12


Gunnar von Boehn wrote:

c) a filesystem cache included in the OS

This is probably the least concern.

1. Use PFS3 filesystem (AFAIK the buffers cache only file system metadata, not the data itself - but I can be wrong):

EXTERNAL LINK  EXTERNAL LINK  EXTERNAL LINK 
2. Use SFS filesystem:

EXTERNAL LINK  EXTERNAL LINK 
3. There are some general disk cache utils on Aminet:

EXTERNAL LINK


Matthew Langtry

Posts 165
14 Jun 2017 22:29


Are we setting bounties for certain drivers / coding priorities?


Gunnar von Boehn
(Apollo Team Member)
Posts 4452
15 Jun 2017 06:38


Roman S. wrote:

 
Gunnar von Boehn wrote:

  c) a filesystem cache included in the OS
 

 
  This is probably the least concern.
  3. There are some general disk cache utils on Aminet:
 

 
  Nice.
  Which of them would you recommend?
 
  Apollo 68080 is fast enough to allow us to run several games - which were originally designed for the PC. Some of those games use a huge number of datafiles / and or reread Sprites/audio/background game files constantly during play. Those work very well on the PC as there is a good filecache existing and its always ON. Now running those games on AMIGA OS without filesystem cache will be not ideal - therefore ideally AMIGA OS should also install with one enabled per default.
 
 
 
 
 
 
 


Thierry Atheist

Posts 618
15 Jun 2017 10:49


Games that can be started from the CLI/SHELL often work pretty darn good with the, C:ADDBUFFERS command.

Haven't played games on AOS for a while, but I think some games won't even use the floppy or hard drive after all segments of a game have already been run.

edit- Hmmm. I think I remember playing some games where the whole game was in the ADDBUFFER!!!

edit2- Hmmmmm. I think some games had parts of them coded such that, they were "forced" to read directly from the drive, ignoring the ADDBUFFERs that were available. And, I'm not talking about games that were copy-protected. They were just hard coded to do so.


Roman S.

Posts 149
15 Jun 2017 11:15


Gunnar von Boehn wrote:
Which of them would you recommend?

 
I would start with fcache11.lha (http://aminet.net/package/disk/cache/fcache11). It's from 1997 (so rather new), and it is free. I don't have much time for Amiga nowadays, but testing it on A1200 is on my TODO list :)
 
Another potnetially interesting one is fda.lha (http://aminet.net/package/disk/cache/fda), which seems to be tested even with UAE JIT. Problem: it is commercial and it seems you can't purchase the full version anymore :(

BTW. Running such games on Amiga will never be ideal - these are only ports, often limited, usually very outdated and not well tested.


Gunnar von Boehn
(Apollo Team Member)
Posts 4452
15 Jun 2017 11:52


Roman S. wrote:

  BTW. Running such games on Amiga will never be ideal - these are only ports, often limited, usually very outdated and not well tested.
 

 
 
There is a number of games which were were designed for 100-200 MHz PC and were done very professionally.
 
These games could run very good on Apollo 68080
But you need mandatory a disk cache for them.
 
some Examples:

 
 
 
 
 
 
 


Simo Koivukoski
(Apollo Team Member)
Posts 521
15 Jun 2017 12:13


Smart Filesystem has read-ahead cache. This is not the same as the buffers you can add using the AddBuffers command. With SetCache tool you can set read-ahead buffers.
 
From SFS manual:
"The read-ahead cache is used to prefetch information which
may be needed later on.  Because most harddisks don't suffer
a speed penalty when reading a bit more data this can
increase performance drastically."


Wawa T

Posts 690
15 Jun 2017 13:27


i wouldnt use sfs.


Simo Koivukoski
(Apollo Team Member)
Posts 521
15 Jun 2017 13:34


wawa t wrote:

i wouldnt use sfs.
 

Yes, personally I prefer the PFS3 AIO. Toni has made a nice work with it. I just raised this SFS feature, that if someone like to research how it does affect to the previously discussed issue.


Wawa T

Posts 690
15 Jun 2017 13:56


exactly. im using pfs3 for ages now testing aros68k on defferent amigas and it works as flawlessly that i have really forgotten what file system im using. this of course involves ocassional crash and constant rewriting huge amounts of data on drive. my experience with sfs was long term fs dagrade leading to corruption and data loss.


Matthew Langtry

Posts 165
15 Jun 2017 20:50


wawa t wrote:

  exactly. im using pfs3 for ages now testing aros68k on defferent amigas and it works as flawlessly that i have really forgotten what file system im using. this of course involves ocassional crash and constant rewriting huge amounts of data on drive. my experience with sfs was long term fs dagrade leading to corruption and data loss.
 

 
 
  I found same plus with smart file system need 020 min with pfs aio if cpu card fails can still get to data with even 68000, just all your eye candy may not show up lol


Kalamatee (AROS)

Posts 15
16 Jun 2017 12:09


Gunnar von Boehn wrote:

AMIGA OS is nice.
 
  it could be even nicer for all of us with
 
  a) an SDCard driver for Vampire able to boot from

AROS has an SDCard driver that I wrote for the raspi port, however it is a little hard coded for its controller in some places (easy enough fixed), and the overall code should be modular enough to be adaptable to support Vampire.


  b) IDE/SCSI device using DMA for best performance

Again that shouldn't be too hard to implement if the DMA engine is documented and detectable - at least for the normal amiga and powerflyer stuff PIO only is used.


  c) a filesystem cache included in the OS

This would help massively - its a big reason why self-hosted builds of AROS are slow on x86 platforms.
 


 
  it would be great if any developer would like to help on any of these tasks
 
 
 




Roman S.

Posts 149
03 Jul 2017 19:28


wrote:
c) a filesystem cache included in the OS

       
  Today I have played a little with fcache ( EXTERNAL LINK ) with its default cache size (only Run >NIL: FastCache.68020 -DEVICE=scsi.device -UNIT=0 in Startup-Sequence) on my A1200 with ACA1233n (68030 @ 40 MHz, 128 MB fast RAM) and SD card attached to the motherboard IDE, I am running OS 3.9 with a lot of patches and addons, PFS3 from here: EXTERNAL LINK . It works - system feels more snappy, I can see the disk LED flashes less - especially while opening drawers with a lot of icons from Workbench.
       
  BTW, the included statistics tool does not work for me, always shows 0's everywhere.
       
  I have also looked at the PFS3 source code - it already has internal cache, but very small and primitive (clearly not geared towards anything as powerful as the Vampire) - 32 entries by (I think) 128 bytes each, only used if one block from the disk is loaded, purely round-robin (if cache is full, it is always the last read entry which gets discarded from memory), cache is organized without any index tree or any other smart data structure - the FS just checks entries one by one whether they match the block needed. This probably could be improved, but - if fcache works properly, it makes no sense.
       
  Gunnar, do you have any particular game (test case) in mind? Could someone test the fcache on the Vampire?


Wawa T

Posts 690
03 Jul 2017 20:10


Roman S. wrote:

  I have also looked at the PFS3 source code
 

 
  please keep in touch with toni, he maintains the pfs3 so far i know. at least it would be good to discuss improvements and avoid forks. btw you can use aros build system to build pfs3, but then it would have to be pushed upwards i guess, and the question is how to build aio best.


Gunnar von Boehn
(Apollo Team Member)
Posts 4452
03 Jul 2017 20:17


Roman S. wrote:

Gunnar, do you have any particular game (test case) in mind? Could someone test the fcache on the Vampire?

Yes "Robin-Hood" for example.
Its re-loading constantly files from disk.
As cache of some MB would help dramatically.


Roman S.

Posts 149
03 Jul 2017 20:57


Few hours later I got a write error on SD card :( I'm not 100% sure if it is the FCache fault, but... it never happened to me before. Damn.

Regarding the PFS3 improvement - we will see, everything depends on the time I have (recently I didn't have much time for Amiga hobby).


Asaf Ayoub

Posts 26
10 Jul 2017 07:59


Has anyone tried a dedicated RAD device ? memory is always faster :)


Vojin Vidanovic

Posts 770
14 Sep 2017 06:43


Kalamatee (AROS) wrote:

   
    AROS has an SDCard driver that I wrote for the raspi port, however it is a little hard coded for its controller in some places (easy enough fixed), and the overall code should be modular enough to be adaptable to support Vampire.
   
    Again that shouldn't be too hard to implement if the DMA engine is documented and detectable - at least for the normal amiga and powerflyer stuff PIO only is used.
 
    This would help massively - its a big reason why self-hosted builds of AROS are slow on x86 platforms. 
   

   
    Seems Kalamitee has answers to 3 remaining weaknessess of AROS 68k for Vamp port. Hope he ll be back and should became AROS Vamp beta tester if fixes any if not all of these + throw in Final Writter :-)
   
 
Asaf Ayoub wrote:

  Has anyone tried a dedicated RAD device ? memory is always faster :)
 

 
  Maybe when we have 1GB or so AROS or OS 3.9/AmiKit could be run from RAD: Always wanted to do that on Amiga and was able to do on A1-x1000 but very few apps I wanted would ran there.

posts 19