What V4SA is for and not

[OL]

Hello

Let me put some known information about V4SA with Emutos running on it, to clarify what it is able to do and what it is not fro the moment. I can't speak for future.

What it is able to do

- start with Emutos for V4SA (base on Emutos 1.0 modify for this) that able fix all resolution of V4SA throw vsetscreen(), it not want to said Emutos is able draw in such resolution, it is only able to do it for ST screen format only. VDI Open worstation can be open throw v_opnwk as under TOS 4, Emutos has too support of xbios sound, it is far not perfect, some feature not work at all but we are able to play music with mxplay and aniplayer, notice mplayer directly manage sound with SAGA and not use Xbios. There is no NVRAM but a fake one in Emutos limit is you can't choose disk boot
- ST screen format are supported but need to be fixed it is flickering but hope now it will be fixed soon. Falcon 8 plane not work, but 8 bit chuncky work and palette change is ok if done throw xbios
- Boot can be done from SD card or CF card or on IDE disk (not tested don't know which type of disk can be plug )
- Mint 1.19 is stable rock, work really nice without known issue
- We have been able run Mint 1.12, 1.15.12, 1.16, AES 4.1 was able run under Mint 1.15.12
- AES running can be NAES, XaAES and MyAES
- Internet work throw ethernet port RJ45 with Mint 1.19
- There is an FPU and CPU run at 93Mhz (could be more soon) and it is faster than CT60 100Mhz, my point of performance is quiet homogenous and for firebee user all said it look faster, I have never seen firebee so can't compare Kronos bench are not fully in agreement for pure calculation compare with native coldfire binary but code was generated by gcc 4 for this test long time ago and we know it not very efficient.
- Copy bloc on STRam is around 300Mb/sec and TTRam 350Mbs/sec that is huge.
-NVDI with Shoggoth driver work well and give acces to most SAGA mode from 1 bit to 32.
- Most GEM program work nicely there is some with issue see above.
- Some game can work but not that much, but more can be used throw Castaway done and optimized by Anders
- Shoggoth YM emulation was working but stop work after Emutos change but hope be back soon, to have the horrible key beep! Castaway need it to play sound.
- A patched version of PureDebugguer can run under Emutos, the patch is link to FPU registers.
- An usb port is used for keyboard, one for mouse and another for Joypad (don't know if something can work with), so USB for the moment can't be se for something else, not all keyboard and mouse work on it there is list for working material.
- 2 serial port
-1 hdmi video output, resolution from 320x200 to 1920x1080, but in the case of this last resolution all monitor could not support it, there is some monitor not working at all too I think but all I have test was able display default resolution, sound is emit throw hdmi too, no jack output.
- PC Keyboard I think is well support, help and undo are map on F11, F12, at my known only printscreen and page up page down are not yet map.

What it is not able to do

- This is not hardware compatible so if software bang hardware register not work, there is some discussion to have better support
- So most game and demo not work natively
- Some GEM programs look have issue with FPU like Kadinsky or some module of smurf.
- xbios sound is not perfect some lack such pointer sound position not give useful information
- no DSP support
- no analogical sound input output (perhaps with extension board like MIDI port), notice my monitor has output sound
- Some program not recognize sound capacity link to cookie (like Daroo gem demo if cookie set as expect sound start but it start on first sound buffer for ever, I suppose something link to xbios sound or some hardware expect but software work except for sound)
- Notice we put video cookie as Falcon one because a lot of software expect that information to run such NAES but work fine just with this cookie.
- There is no MMU we can access for the moment, it not want to said 68080 has no MMU but can't be used for our need

So not perfect, it is a clone and should be consider like this. It could change in future but we can't be sure only of current state we are not a lot to work on.

At the end

All that have been done at free time, this is perhaps not enough and not linear progress, but there is a lot of improvement this last years, from us but a lot on hardware side. It have been possible without huge work on Emutos and more in particular the Amiga version else we never start this, I think to Vincent and Otto and perhaps people I forgot, it was crazy to see Emutos run first time on this computer even it was on poor OCS resolution 320x120 B&W!
We don't know what will be done in the future, we have no link with Apollo team, just good relation to try progress. This is not a computer for all, we not try to do thinking this computer is able to do that it is not, we think it is funny machine, some prefer emulator, some prefer acceleration card, some prefer FPGA hardware compatible, this is a choice and a budget too! When I see beepi configuration this is very nice, I like it too, really depend what we expect.
I hope continue work on V4SA and one day use some specific hardware capacity of this computer but before it was more important to have stable working system we can work with and I think this is the case now.

Olivier

[joska]

- There is no MMU we can access for the moment, it not want to said 68080 has no MMU but can't be used for our need

I'm a bit confused about this one. You (and others) say it can't be used for our needs, then I hear others saying that it can, it's just not 030/040/060 compatible.

[OL]

- There is no MMU we can access for the moment, it not want to said 68080 has no MMU but can't be used for our need

I'm a bit confused about this one. You (and others) say it can't be used for our needs, then I hear others saying that it can, it's just not 030/040/060 compatible.

There is MMU internally but as I understand it is used internally to be able the card work, it is here for memory protection and suppose create exception. Gunnar said it add protection read, write and exec area, and there is no translation. Perhaps I'm wrong. No documentation for this and nothing done to be able use even partially or there is something not explain, but it is too much tricky for me. So we have to consider there is none because in fact it is like this, I should simply said no MMU to not confuse anyone.

Olivier

[Cyprian]

I think that 1st of April isn't good for a such announcements
Anyway the hardware is real and the Atari OS for it is also real.

Many thanks Atari V4SA Team for your great work. Also thanks BigGun and the Team for a great 68080 and the rest of hw.

[TheNameOfTheGame]

Thank you @OL for the write-up. That makes it very clear what the hardware does and does not offer at this point in time.

[maxtosfire]

Dear Olivier,

Thank you very much for your outstanding work on V4SA - for me it works great as a high-performance Atari TOS compatible platform.

Your work and the work of the V4SA team is greatly appreciated!

Best
Markus

[Gunnar68080]

- There is no MMU we can access for the moment, it not want to said 68080 has no MMU but can't be used for our need

I'm a bit confused about this one. You (and others) say it can't be used for our needs, then I hear others saying that it can, it's just not 030/040/060 compatible.

Maybe I can answer this.

As everyone know the MMU of the old 68K was often changed in behavior.
This makes sense ... as the MMU was adapted to the Memory changes and needs of this time..
At the time of the first MMU - a complete OS did fit on a 700 KB floppy disk and the computer had little memory...
The amount of memory that system use increased and increased and today the Apollo System come with 512 MB memory minimum.

The 040 MMU and 060 MMU design in our opinion have some weak spots.
You can trigger situations where the CPU runs out of MMU registers and looses a lot performance because of this.

A simple example for this is are games like DOOM or Heretic
DOOM renders walls not in rows .. but in colums. This means every next pixel that it paints will be in another screen row.
If you do such a game on a MMU tiled memory mapped area, and you set a screen mode - what people like today like 800x600 or 1024 or so.
Then you can easily create a situation where the MMU table lookups dominate the system performance.

Our MMU design tries to handle this better.
The MMU is split in to units a MPU and MTU
Protection and translations tables are seperated.
This is a big advantage for system not using translations but only protection bits.
As the protection information needs less bits and can be cached very efficiently.

As you might know the AMIGA OS does not use MMU.
MMU on Amiga is if used at all then only for debugging to report programs doing memory violations.
The split MPU / MTU design works very efficiently in this scenario.
For Amiga there are tools like "APOLLO-SHIELD" which allow activate the APOLLO 68080 MMU to find memory access failures.

I hope you find this information useful.

[OL]

- There is no MMU we can access for the moment, it not want to said 68080 has no MMU but can't be used for our need

I'm a bit confused about this one. You (and others) say it can't be used for our needs, then I hear others saying that it can, it's just not 030/040/060 compatible.

Maybe I can answer this.

As everyone know the MMU of the old 68K was often changed in behavior.
This makes sense ... as the MMU was adapted to the Memory changes and needs of this time..
At the time of the first MMU - a complete OS did fit on a 700 KB floppy disk and the computer had little memory...
The amount of memory that system use increased and increased and today the Apollo System come with 512 MB memory minimum.

The 040 MMU and 060 MMU design in our opinion have some weak spots.
You can trigger situations where the CPU runs out of MMU registers and looses a lot performance because of this.

A simple example for this is are games like DOOM or Heretic
DOOM renders walls not in rows .. but in colums. This means every next pixel that it paints will be in another screen row.
If you do such a game on a MMU tiled memory mapped area, and you set a screen mode - what people like today like 800x600 or 1024 or so.
Then you can easily create a situation where the MMU table lookups dominate the system performance.

Our MMU design tries to handle this better.
The MMU is split in to units a MPU and MTU
Protection and translations tables are seperated.
This is a big advantage for system not using translations but only protection bits.
As the protection information needs less bits and can be cached very efficiently.

As you might know the AMIGA OS does not use MMU.
MMU on Amiga is if used at all then only for debugging to report programs doing memory violations.
The split MPU / MTU design works very efficiently in this scenario.
For Amiga there are tools like "APOLLO-SHIELD" which allow activate the APOLLO 68080 MMU to find memory access failures.

I hope you find this information useful.

It is always better to speak to god than his angels as we said in French.

My point of view most people are more interest by memory protection rather translation except very unix fan and for some ports but there is something I not understand very well, if you can validate memory protection so it want to said in apolloos you manage memory table for the MMU so we should be able do the same in Mint, is there any documentation for that? As I think have understand apollo-shield was just activate processor in protection mode but the processor has no know of area that should be protected and how.

Olivier

[Gunnar68080]

My point of view most people are more interest by memory protection rather translation except very unix fan and for some ports but there is something I not understand very well, if you can validate memory protection so it want to said in apolloos you manage memory table for the MMU so we should be able do the same in Mint, is there any documentation for that? As I think have understand apollo-shield was just activate processor in protection mode but the processor has no know of area that should be protected and how.

Olivier

You can do both if you want.
You can do address translations and you can do memory protection.
Memory protections allows protection from read, from write and from execution (to prevent stack code insert attacks)
The Apollo MMU is also DMA aware.
The Super-AGA DMA system and the Apollo CPU are coherent.
This means the CPU "sees" DMA updates to memory and its caches are kept automatically coherent and in sync.

In my opinion this is a great improvement over previous 68K system.
On Amiga often you used DMA - e.g. SCSI controller - a big problem on Amiga was that the CPU was not aware of the DMA transfers.
So while using DMA to load some blocks form hard drive is great, the Amiga OS did not to invalidate the CPU cache after DMA access.
This was of course very bad for total system performance.
Apollo 68080 does solve this perfectly. The CPU is fully aware of DMA from drives or from DMA from network chips
and the Data and Instruction caches are automatically kept coherent. There is not need to "drop" the caches which would ruin system performance.

DMA channels going through Super-AGA system are also aware of the MMU of the 68080 System.
This means the 68080 MMU can also protect memory areas from being overwritten by DMA!

That said, the MMU is on Amiga normally not used.
The reason is simple. Amiga OS is designed in such a way that each program is allowed to give other programs pointers to send him message.
This means programs are by design allowed to write into memory parts of other programs.
This is design foundation of the Amiga OS and makes message passing very swift.
But at the same time it completely nullifies any idea of memory protection.
So MMUs are by design basically useless on Amiga.

Maybe on Atari this is different?

In my opinion the Apollo design with automatically coherency is much cleaner and smarter compared to old 68K Amiga designs.

[Eero Tamminen]

On Amiga often you used DMA - e.g. SCSI controller - a big problem on Amiga was that the CPU was not aware of the DMA transfers.
So while using DMA to load some blocks form hard drive is great, the Amiga OS did not to invalidate the CPU cache after DMA access.
This was of course very bad for total system performance.
Apollo 68080 does solve this perfectly. The CPU is fully aware of DMA from drives or from DMA from network chips
and the Data and Instruction caches are automatically kept coherent. There is not need to "drop" the caches which would ruin system performance.

Can this behavior be disabled? Apollo could be nice target for developing & debugging things, before testing them on (slower) original HW, but that would require enough compatibility (in addition to MMU protection) that it would catch programming errors that are fatal on target HW.

That said, the MMU is on Amiga normally not used.
The reason is simple. Amiga OS is designed in such a way that each program is allowed to give other programs pointers to send him message.
This means programs are by design allowed to write into memory parts of other programs.
This is design foundation of the Amiga OS and makes message passing very swift.
But at the same time it completely nullifies any idea of memory protection.
So MMUs are by design basically useless on Amiga.

Maybe on Atari this is different?

While there are some protocols where writes are done to other programs memory, it's not all-to-all, so you just set a bit in the program header telling that given program memory can be written by other programs, and everything else is still protected, i.e. memory protection is still very much useful.

With Amiga on V4, couldn't the messages go through buffers owned by some third ("server") process?

[Gunnar68080]

On Amiga often you used DMA - e.g. SCSI controller - a big problem on Amiga was that the CPU was not aware of the DMA transfers.
So while using DMA to load some blocks form hard drive is great, the Amiga OS did not to invalidate the CPU cache after DMA access.
This was of course very bad for total system performance.
Apollo 68080 does solve this perfectly. The CPU is fully aware of DMA from drives or from DMA from network chips
and the Data and Instruction caches are automatically kept coherent. There is not need to "drop" the caches which would ruin system performance.

Can this behavior be disabled? Apollo could be nice target for developing & debugging things, before testing them on (slower) original HW, but that would require enough compatibility (in addition to MMU protection) that it would catch programming errors that are fatal on target HW.

Can you explain me what you want to disable?

That said, the MMU is on Amiga normally not used.
The reason is simple. Amiga OS is designed in such a way that each program is allowed to give other programs pointers to send him message.
This means programs are by design allowed to write into memory parts of other programs.
This is design foundation of the Amiga OS and makes message passing very swift.
But at the same time it completely nullifies any idea of memory protection.
So MMUs are by design basically useless on Amiga.

Maybe on Atari this is different?

While there are some protocols where writes are done to other programs memory, it's not all-to-all, so you just set a bit in the program header telling that given program memory can be written by other programs, and everything else is still protected, i.e. memory protection is still very much useful.

With Amiga on V4, couldn't the messages go through buffers owned by some third ("server") process?

Not with Amiga OS.
Amiga OS is designed very open minded like woodstock Hippis culture.
Where everybody is allowed to have sex with everyone and everybody experiments with new drugs.

Every program on Amiga OS is allowed to write in other programs memory and every program is allowed to Peek and Poke as much as they like also in OS structures or in Chipset registers.

Its a very free minded system.
That works very good if you have good behaving programs.

[Gunnar68080]

Regarding DMA and CPUs.

The idea to offload the CPU with DMA is in theory very good.
Why should the CPU copy a disk block from hard drive of 512 byte , if the DMA could do this for free?

So far so good. And if you have an 68000 then DMA is always a nice bonus.

With better CPUs like the 68020 you have 256 byte Cache
This cache helps to run faster, but it will not see the DMA changes.
This means the OS needs to "drop" the cache.
As there is a small chance of serious problems.
In many cases not dropping the cache will work but this is unpredictable.
If you not drop the cache there could be random errors, data loss, filesystem corruption, even crashes
All totally unpredictable - Therefore the save options is dropping it.

The 68030 has 2x256 byte cache ... you also want to drop them.

Now the 68040 CPU has even 2 x 4096 Byte cache
To benefit from the "free" DMA copy of a disk block of 512 Byte - the 68040 will need to drop its 8 KB cache!!
Is this still a good deal? Obviously not.

But to be save and to avoid unpredictable problems its the only option.

The 68060 has 2x 8KB cache ..
Using DMA becomes even more costly for it.

The Apollo 68080 has even bigger caches …
Dropping them would cost you a lot. But DMA is still a great system ... if you find a solution to not need to drop the caches!
What can you do to benefit from DMA?
The Apollo 68080 solves this very elegantly you not need to drop them .. as the DMA system of Super-AGA is visible to the 68080 CPU.
No need to drop the caches greatly improves System performance..

Does disable this feature bring an avantage for debugging?
I dont think so.
The problem is if you forget to drop the cache - you can get rare and random errors
That can crash your OS, destroy your filesytems on disk... these are very unpredictable errors.
I think such error nobody wants.

[joska]

You can do both if you want.
You can do address translations and you can do memory protection.
Memory protections allows protection from read, from write and from execution (to prevent stack code insert attacks)

Where can I find more information/technical details about the 68080 MMU?

[mikro]

The Apollo 68080 has even bigger caches …
Dropping them would cost you a lot. But DMA is still a great system ... if you find a solution to not need to drop the caches!

Just curious, how is this problem solved on modern PC architectures?

Oh and btw, you don't need to flush instruction cache on every dma access. That's the same problem as self modifying code, the programmer has to take care of it by himself in case he would want to stream code from disk directly to memory and execute it.

[tofro]

Modern PC architectures and operating systems typically handle this with an MMU: Code and data segments are typically marked as such and, once initially loaded, memory that's marked as code is read-only. So that problem doesn't even occur in the first place for the program cache.

Data caches can be handled by an MMU-aware DMA (or DMA-aware MMU ) that can trigger the cache reload only selectively when Cache contents and DMA-target are overlapping.

[MasterOfGizmo]

Now the 68040 CPU has even 2 x 4096 Byte cache
To benefit from the "free" DMA copy of a disk block of 512 Byte - the 68040 will need to drop its 8 KB cache!!
Is this still a good deal? Obviously not.

The 68040 supports bus snooping for exactly that reason, and so the cache is not "dropped" or invalidated. Unless your DMA bypasses the CPU bus it will update or invalidate the affected parts of the caches accordingly.

See section 7.9 in https://www.nxp.com/docs/en/reference-m ... 8040UM.pdf

[MasterOfGizmo]

Just curious, how is this problem solved on modern PC architectures?

There are many solutions for this. One is bus-snooping which e.g. the 68040 does. In this case, the CPU switches all control signals to inputs and just listens to what another bus master (DMA controller) does. That way, the CPU and its caches see what changes to memory contents the DMA does and can update or invalidate the affected cache areas only.

Another very common solution is that the CPU has some control over its caches. So if it triggers a DMA transfer it can explicitly invalidate the affected cache areas only, leaving the unaffected ones intact.

A third approach is to use special non-cacheable memory areas for DMA only (somewhat like the Atari TT where the DMA can only use ST RAM). The downside is that this memory is rather slow, and you'd usually copy the data from that no-cache buffer into regular ram. This may seem stupid as you need another slow memory transfer, but e.g. TOS uses a special buffer (pointed by _dskbufp) for floppy and HDD IO. If all software used that, it could be marked non-cacheable.

[mrbombermillzy]

While we are on the subject of caches...

I had a project a few years back on the TT which, whilst not requiring cycle exact timing, did require a relatively tight leash on the 030 CPU timing.

Unfortunately, if (as the case was) the 030 needs to R/W arbitrary data/locations, then this basically destroys any benefit of the data (if not instruction) cache.

If the D/I can be managed to fit in tight little 256 byte sections (a bit less actually IIRC), then all is well, otherwise, it may even be a better option - like implied in some of the above posts, but for different reasons - to disable the caches completely, otherwise timing is too erratic. This is what I had to do in the later builds.

As a last ditch effort to counter the effect of disabling the caches, I even attempted to disable the MMU address translations. By my calculations, there was ~5% speed boost...far from enough to bother with hardwiring all the program addresses/labels/org manually, at least.

Anyway, back to caches/DMA issues; Im sure I read a document by Dave Haynie about how he worked around the DMA/cache issues, possibly on the Amiga 3000-4000 era machines. I will try to find the file, but it may have suggested non cacheable memory 'zones' like mentioned in the above post.

[mikro]

far from enough to bother with hardwiring all the program addresses/labels/org manually, at least.

You might have misunderstood what address translation really is. It has nothing to do with generating absolute/relative code, on Atari (or better said: in TOS) the translation is basically unused (with the exception of the two translation registers which map stuff like 0xFFFFxxxx -> 0x00FFxxxx).

[mrbombermillzy]

You might have misunderstood what address translation really is.

Not as far as Im aware.

I was relocating code to TT RAM and definitely circumventing TOS.

The only part of ST RAM used was pinging data to the Shifter palette/screen RAM.

I can probably dig up the code to describe in detail what I did, but thats the general gist of it and it seemed to work as expected.

[mrbombermillzy]

double post

[shoggoth]

Well you can use the MMU for that of course, but that's not how it works on our platform. We've got flat memory and relocation.

[mikro]

Yeah, you can write your own relocator, reconfigure MMU and whatnot or ... you can just set one bit in the program flags. ;)

So I'd encourage you to get back to your experiments, 5% speed boost is pretty interesting, especially if you get it for free.

[shoggoth]

Right, does this mean we've always had 1:1 address translation enabled for no good reason?

[mikro]

I think the ATC cache helps here. IIRC only the top level table is defined (with entries "don't translate") but I may be wrong. @ThorstenOtto perhaps remembers better as he has rewritten 030 MMU code in FreeMiNT.

But I also remember doing a similar experiment on Falcon when I disabled the MMU entirely, all interrupts off and used only 0x00FFxxxx addresses and could spot a speed boost as well, so who knows, maybe it really has some performance gain.