Requesting support for other M68K computing devices about serena HOT 18 OPEN

Hi,

I'm in principle open and interested in ports to other 68k systems. To you have a specific one in mind?

from serena.

What about the 080 ? I would LOVE native support for the 080 instructions. The OS will work anyway, but with 080 spesific stuff, it would be much much faster than lets say the 060.

The Vampire V4 Standalone is a fantastic platform.

from serena.

I looked up information about the 68080 and the Vampire V4 and it does look very interesting and I would in principle be interested in adding support for this CPU and platform in the future. However, I do not have plans for any concrete work on that front at this time.

In any case, a first step would be to find out which C compiler and assembler is able to generate machine code for the 68080. It also looks like that there's some documentation publicly available, although it's not clear how complete and accurate it is.

So if someone is interested in looking into this then this would be helpful and the result of those investigations could then serve as a starting point for further discussions on this topic.

from serena.

from serena.

Thinking a place to start could be Sun3 as that is emulatable easily via SIMH if you ever wanted to tinker around that path? Then from there there are a bunch of hobby boards. Old macs would be cool, but then you have to deal with ROM workarounds to boot (which Debian and NetBSD have fairly well documented)

from serena.

Ok so from some digging around today here is a draft of my initial thoughts about the 68080:

1. Toolchain: The m68k-amigaos-gcc toolchain (https://github.com/bebbo/amiga-gcc) seems like a good starting point. It supports the 68080 and includes GCC, binutils, and other essential tools.

2. Apollo 68080 specifics:

   • 4-stage dual-issue CPU (roughly Pentium 2 equivalent)
   • AMMX (Advanced Multimedia Extensions) for SIMD-like operations
   • Current FPGA implementations clock around 80MHz, but ASIC potential is much higher

3. Assembler: VASM now supports 68080 and AMMX... Which could be MASSIVE for low-level optimizations.

4. SMP?

   • AROS has experimental SMP support - could be worth a look

5. Challenges:

   • Adapting Serena's virtual processor concept and dispatch queues to the 68080
   • Leveraging AMMX for performance gains
   • Dealing with current FPGA speed limitations

NetBSD and Linux both seem to run on everything but I'm finding nothing about 68080-specifics. I'll shoot the M68K and NetBSD/M68K mailing lists a message unless someone else wishes to do so?? Any 68080 kernel-specifics could help with Serena, I think, if they are out there?

Overall, the Apollo team seems to be the best source for detailed 68080 docs... I couldn't find public low-level tech/engineering specs so I'll shoot them an email also.

Please help guide me on where to go from here as my ADHD unfortunately sometimes gets in the way of a specific direction and I branch everywhich way...

from serena.

5. Challenges - Dealing with current FPGA speed limitions.

Care to explain what you mean ? If the OS was meant for 68020-68060, then the 080 runs circles around theese. That beeing said, im not that TECHY. Try to explain :-)

from serena.

from serena.

Its not capped. It all depends on the core. I have used cores from 80 - 110 mhz.
And the plan is to go ASIC in 2 years time. Exciting times.

from serena.

from serena.

Still device without ASIC is still MUCH MUCH faster than any previous Amiga. But i guess you are talking about compiling o the device itself ? am i correct? if not, my bad.

If you guys were to prioritize the Vampire V4 Standalone, i am willing to support you with 1 x V4SA. And i would also like to test stuff for you guys on this device.

from serena.

Please help guide me on where to go from here as my ADHD unfortunately sometimes gets in the way of a specific direction and I branch everywhich way...

Regarding:

1. Toolchain: ideally we would be able to continue to use vbcc and vasm. It sounds like that vasm has gained support for the 080 which makes me wonder whether a newer version of vbcc might actually take advantage of the 080 specific instructions? And whether it can support 64bit mode? These are things that should be clarified next. Switching to gcc is in principle possible but would be more work since it would be necessary to first ensure that that gcc version supports standalone mode and it would then be necessary to adopt the existing makefiles so that it's possible to build with vbcc and gcc.
2. AMMX/vector instructions: I'd love to support stuff like this.
3. SMP: same thing. The Serena Kernel has been written with potential future support for SMP in mind. Well, in the sense that I've generically avoided doing things that would get in the way of supporting SMP in the future.
4. 64bit: same thing. I'd love to support 64bit mode. The Serena Kernel and user space is designed to support 32bit and 64bit environments. In fact we already compile the filesystem portion of the kernel for 64bit Windows when we build the diskimage tool on Windows. The bit width is controlled by the __ILP32__ and __LP64__ compile time switches which control the definitions in the libsystem/abi header files.

I think that the next steps should be:

1. Verify how complete the vasm support for 080 specific feature is, which version of vasm this is and for which platforms it is available.
2. Same for vbcc. Do newer versions generate 080 specific instructions? Is there support for 64bit mode?
3. Find out what the overall hardware differences are between the Vampire and the original Amiga hardware. Serena supports the original Amiga hardware at this time. Is the Vampire hardware backward compatible in the sense that the hardware looks and behaves like a original Amiga system at power-up/reset time?
4. If the Vampire is not compatible to the original Amiga hardware, how does it differ? What are the required minimum set of changes that are necessary to get the kernel to boot on that hardware?
5. Clarify whether the 68080 presents itself as a 68030/40/60 at power-up/reset time or whether it comes up in a mode that is incompatible to the original 68k chips.
6. Clarify whether there's emulator support for Windows/Linux/macOS. Doing kernel-level development with an emulator is way simpler compared to having to run on the actual hardware.
7. If there's no emulator support and the only way to run the kernel is to run it on the Vampire hardware, then we need to know how booting works there. Does it implement the original Amiga boot-from-floppy mechanism? If so then it would be necessary to add support for this to Serena. Right now we build Serena into a ROM image because it allows for a much faster development turnaround time compared to doing things with floppy images.

I think that the overall strategy should be to try to initially get away with as little changes as possible to the existing code base to get the system up and running. If for example it is the case that the 080 looks and behaves like a 68030/40/60 at power-up time then this would make things much simpler since then it wouldn't be necessary to change anything in the VP scheduler. You wouldn't be able to take advantage of the 080 specific features and you would "only" get the better speed as an improvement, but you would be able to make things work much faster.
Then in a second step it would make sense to look into adding support for 080 specific features like the extended register file, 64bit mode and vector instructions.

from serena.

vasm
Currently the following CPUs are officially supported by vasm (loosely ordered by maturity):
M680x0 family (including M6888x, M68851, CPU32 and Apollo 68080)

crossdev
https://github.com/WDrijver/ApolloCrossDev

ammx ^ instructions
http://www.apollo-core.com/instructions.html
http://www.apollo-core.com/index.htm?page=coding&tl=1

I will have someone come here and fill in the blanks..

from serena.

What about Atari support? You already stole our executable file format ;)
You might use Hatari emulator for that https://hatari.tuxfamily.org/

from serena.

Hatari emulates Falcon and TT quite well (CPU emulation core comes from WinUAE).
Atari with transputer (ATW800) was a combination of Atari Mega ST and transputer cards from Inmos. There were wery rare and are even rarer now. There is no emulator (that I know of) for ATW800.

There is also Aranym https://aranym.github.io/, which does not emulate 'real' Atari machine - it is described as virtual Atari clone. You might also try that, as it emulates way 'faster' CPU (Hatari is limited to 32MHz 680x0). It has been used by m68k Linux people for development.

from serena.

68020 support would be useful - specifically so this will run on MiSTer (Minimig core). AFAIK there's not much difference between the 68020 and the 68030 so it shouldn't be difficult to support this? The rest of the Minimig hardware should already work.

from serena.

I'm definitely interested in adding support for Atari machines in the future. I've never owned one but the Atari Falcon and the TT look very interesting.

The STF/E line also have TF (terriblefire) accelerator cards with 68030's on them available, so they should be able to run this OS as well.

from serena.

Atari with transputer (ATW800) was a combination of Atari Mega ST and transputer cards from Inmos. There were wery rare and are even rarer now. There is no emulator (that I know of) for ATW800.

I wish there would be an emulator somewhere. It's such an unusual machine which makes it very interesting from a technical viewpoint.

There is also Aranym https://aranym.github.io/, which does not emulate 'real' Atari machine - it is described as virtual Atari clone. You might also try that, as it emulates way 'faster' CPU (Hatari is limited to 32MHz 680x0). It has been used by m68k Linux people for development.

This looks interesting. I'll check it out more thoroughly.

68020 support would be useful - specifically so this will run on MiSTer (Minimig core). AFAIK there's not much difference between the 68020 and the 68030 so it shouldn't be difficult to support this?

68020 isn't completely out of the question, although not really a priority for me. A big reason why I went with the 68030 as the baseline is that this was the first member of the 68k family that has a paged MMU built-in. The 68020 doesn't. There was an external MMU available but it was very rare for systems to have it installed and this MMU has a machine model that is quite a bit more complex compared to the streamlined 68030+ PMMU.

That said, if someone wants to look into this and work on an MR then I would consider picking it up. But a requirement would be that supporting the 68020 wouldn't get in the way of adding virtual memory support later on and that it wouldn't make it significantly more complex to do so.

There are really only three areas to look into if you want to add 68020 support:

• Compiler configuration, which is currently set to 68030 min CPU level
• The assembler files in kernel/krt which define the basic C runtime functions. I think at least the 64bit bit shift functions use 68030 specific instructions
• The _Reset entry point in kernel/hal/cpu_vectors_asm which checks that the boot CPU is at least a 68030

Everything else should work fine on a 68020 as is.

The STF/E line also have TF (terriblefire) accelerator cards with 68030's on them available, so they should be able to run this OS as well.

Sounds interesting. I'll take a look at this too. I think that adding support for the ST/STE (with a 68030 accelerator card) would in principle make sense.

Thank you all for your pointers and information. Just to be clear: I'm interested and open towards porting Serena to other 68k systems like the Atari machines. However at this time it's not a priority for me to personally sit down and start writing code to reach that goal. If someone is interested in looking into this then feel free to start a concrete porting discussion and I'll help to make this possible.

My primary goals for now are bug fixes, and improving the architecture of the kernel. Things like designing a real HAL, filesystem & disk management, more complete user space APIs, kernel introspection functionality like devfs and procfs, etc. Also building out the shell and the shell line editor more.

from serena.