EmuTOS 0.9.8

Latest news in the Atari world

Moderators: Mug UK, Silver Surfer, Moderator Team

BlankVector
Captain Atari
Captain Atari
Posts: 389
Joined: Wed Oct 24, 2007 7:52 pm
Location: Paris, France
Contact:

Re: EmuTOS 0.9.8

Postby BlankVector » Sat Apr 29, 2017 1:30 pm

Eero Tamminen wrote:I wonder whether EmuTOS will eventually cover a larger number of the m68k machines simulated by MiST (MachinTos, Sinclair QL)? :-)

Sure, it COULD! As it worked fine on Amiga and ColdFire Evaluation Boards.

But the case of Amiga was lucky: it was possible to display something because the Amiga hardware is able to create a video mode compatible with ST-High (even if it is uglyly interlaced). Resolution is not a problem, but pixel format (1 bit for each pixel, from high-bit to low-bit) is required for current EmuTOS VDI.

If the video is not compatible, then you will have to live with a simple serial port to run text-mode TOS programs (like ColdFire EVB). Or write a special fVDI driver for the new video hardware, as I recently did with WinUAE and Vampire/SAGA.

The only requirement to port EmuTOS to something else is to have a 680x0/ColdFire CPU and enough RAM (256 KB is enough). Then you can easily port EmuTOS to new hardware. Then of course, additional drivers for new hardware will have to be written.

wongck wrote:if I am force sensitive and able to do that.... I would mind trick Vincent & Roger to make an ARM Emutos :lol:

Well, I would love to see EmuTOS running natively on ARM / Raspberry Pi :)
As it has already been said, this has already been done for ColdFire. But ColdFire is very similar to 680x0, that's much easier. And despite that, it had been a lot of work to port EmuTOS to ColdFire, mainly to handly written assembler sources, and some CPU-specific code. The result can be seen on the FireBee: a perfectly working EmuTOS, but only able to run programs recompiled for ColdFire.

For ARM or x86, it would be much more complicated. Several EmuTOS parts require a Big Endian CPU. Many parts (if not all) written in C require that the "int" type is 16-bit wide, I'm not sure that GCC can support that on those processors. And of course, all the assembler sources would have either to be converted to C, or to the target assembler.

Conclusion: It is very unlikely that a native EmuTOS for something else than 680x0 / ColdFire appears soon... or even later :wink:

penguin
Atari maniac
Atari maniac
Posts: 83
Joined: Tue Dec 24, 2013 10:43 am

Re: EmuTOS 0.9.8

Postby penguin » Sat Apr 29, 2017 3:01 pm

I did an interview with then-team member Martin Doering back in 2002. The article has some screenshots of EmuTOS 0.5.

http://stcarchiv.de/stc2002/11/emutos-interview
AtariUpToDate - Atari ST/TT/Falcon software database and version tracker: http://www.atariuptodate.de
st-computer magazine - http://st-computer.atariuptodate.de/

BlankVector
Captain Atari
Captain Atari
Posts: 389
Joined: Wed Oct 24, 2007 7:52 pm
Location: Paris, France
Contact:

Re: EmuTOS 0.9.8

Postby BlankVector » Sat Apr 29, 2017 9:26 pm

penguin wrote:I did an interview with then-team member Martin Doering back in 2002.

Hey, that's a collector article :)
Fortunately, nowadays Google can easily translate it to any language.

User avatar
wongck
Ultimate Atarian
Ultimate Atarian
Posts: 11772
Joined: Sat May 03, 2008 2:09 pm
Location: Far East
Contact:

Re: EmuTOS 0.9.8

Postby wongck » Sat Apr 29, 2017 11:52 pm

BlankVector wrote:Conclusion: It is very unlikely that a native EmuTOS for something else than 680x0 / ColdFire appears soon... or even later :wink:


Thanks for replying. I understand the daunting task.
Thanks for your work on EmuTOS. :megaphone:
My Stuff: FB/Falcon CT63+CTPCI ATI R7500 14+512MB 30GB HDD CF HxC_SD EtherNEC/ TT030 68882 4+32MB 520MB Nova/ 520STFM 4MB Tos206 SCSI
Shared SCSI Bus:ScsiLink ethernet, 9GB HDD,SD-reader @ http://phsw.atari.org
My Atari stuff for sale - click here for list

User avatar
mfro
Atari Super Hero
Atari Super Hero
Posts: 647
Joined: Thu Aug 02, 2012 10:33 am
Location: SW Germany

Re: EmuTOS 0.9.8

Postby mfro » Mon May 01, 2017 3:56 pm

Eero Tamminen wrote:I wonder whether EmuTOS will eventually cover a larger number of the m68k machines simulated by MiST (MachinTos, Sinclair QL)? :-)


Your examples are probably of the more difficult species. Mac's have - different models differently - ROM active at lower addresses on startup. With barely documented hardware to bank-switch RAM there. QL's have ROM (not switchable at all) below $10000 and fixed video memory address.

Not the best starting position to implement EmuTOS on both ...

User avatar
Eero Tamminen
Atari God
Atari God
Posts: 1492
Joined: Sun Jul 31, 2011 1:11 pm

Re: EmuTOS 0.9.8

Postby Eero Tamminen » Mon May 01, 2017 8:28 pm

BlankVector wrote:For ARM or x86, it would be much more complicated. Several EmuTOS parts require a Big Endian CPU. Many parts (if not all) written in C require that the "int" type is 16-bit wide, I'm not sure that GCC can support that on those processors. And of course, all the assembler sources would have either to be converted to C, or to the target assembler.


ARM is bi-endian, like some other architectures:
https://en.wikipedia.org/wiki/Endianness#Bi-endianness

There are multiple ways how one can set the ARM processor to big endian (data) mode:
https://community.arm.com/processors/f/ ... -cortex-a9

I don't know whether GCC supports 16-bit ints on ARM. It's quite nasty that EmuTOS sources don't use specific types for 16-bit ints, but in the first phase one could just mass-convert all ints in source code to use 16-bit types instead of ints, and verify with m68k build that resulting binaries are identical.

Having somebody with enough ARM assembly-foo is the by far the largest obstacle.

For the m68k user-space binaries, there would need to be 68k emulation, as lot of the interesting programs are missing sources.

And even for things with sources, somebody would first need to port relevant Atari compilers & their libraries (AHCC, GFA...) to ARM and if the programs themselves have any m68k assembly, that would need alternative ARM assembly code. Or those programs sources would need to be adapted to work with GCC & whatever Atari GCC libaries had been ported to ARM.

IMHO fairly pointless for the amount of programs that the end result is most likely able to be run, but if somebody has a lot of extra time on their hands, it could be an interesting experiment. :-)

User avatar
shoggoth
Nature
Nature
Posts: 827
Joined: Tue Aug 01, 2006 9:21 am
Location: Halmstad, Sweden
Contact:

Re: EmuTOS 0.9.8

Postby shoggoth » Mon May 01, 2017 8:36 pm

#include <stdint.h>
Ain't no space like PeP-space.

User avatar
AdamK
Captain Atari
Captain Atari
Posts: 223
Joined: Wed Aug 21, 2013 8:44 am

Re: EmuTOS 0.9.8

Postby AdamK » Mon May 01, 2017 9:50 pm

Int size with GCC is more problematic in structs. With 32bit GCC, even if struct has short int member, it will use long int there, which screws most of TOS APIs. But there are ways to overcome that, FreeMiNT&MiNTLib do that.
Atari: FireBee, Falcon030 + CT60e + SuperVidel + SvEthlana, TT, 520ST + 4MB ST RAM + 8MB TT RAM + CosmosEx + SC1435, 1040STFM + UltraSatan + SM124, 1040STE 4MB ST RAM + 8MB TT RAM + CosmosEx + NetUSBee + SM144 + SC1224, 65XE + U1MB + VBXE + SIDE2, Jaguar, Lynx II, 2 x Portfolio (HPC-006)

Adam Klobukowski [adamklobukowski@gmail.com]

ThorstenOtto
Atari maniac
Atari maniac
Posts: 92
Joined: Sun Aug 03, 2014 5:54 pm

Re: EmuTOS 0.9.8

Postby ThorstenOtto » Tue May 02, 2017 12:58 am

BlankVector wrote:Several EmuTOS parts require a Big Endian CPU.


I think most of this parts which are not so obvious (ie when accessing the function parameters by the address of the first parameter) have already been fixed. But some others (ie. most FAT related stuff) would have to be addressed.

Many parts (if not all) written in C require that the "int" type is 16-bit wide, I'm not sure that GCC can support that on those processors.


I don't think that this is a requirement for the C-code, only the assembler functions expect it like that, and those would need to be redone anyway. What would make much more problems is when LONG is not the same size as a pointer.

Conclusion: It is very unlikely that a native EmuTOS for something else than 680x0 / ColdFire appears soon... or even later :wink:


The biggest problem is that you won't achieve much with it. Atari users are already rare, some software ported from atari to some even older hardware might not even be noticed, no matter how long it took. But who knows, we are all doing that for the fun of it, maybe someone thinks it would be funny and just does it ;)

User avatar
shoggoth
Nature
Nature
Posts: 827
Joined: Tue Aug 01, 2006 9:21 am
Location: Halmstad, Sweden
Contact:

Re: EmuTOS 0.9.8

Postby shoggoth » Tue May 02, 2017 7:17 am

AdamK wrote:Int size with GCC is more problematic in structs. With 32bit GCC, even if struct has short int member, it will use long int there, which screws most of TOS APIs. But there are ways to overcome that, FreeMiNT&MiNTLib do that.


That's proper C; struct packing isn't defined. You can use pragmas to make it TOS-compatible though.
Ain't no space like PeP-space.

User avatar
wongck
Ultimate Atarian
Ultimate Atarian
Posts: 11772
Joined: Sat May 03, 2008 2:09 pm
Location: Far East
Contact:

Re: EmuTOS 0.9.8

Postby wongck » Tue May 02, 2017 12:21 pm

Because it is both fun and he can.
My Stuff: FB/Falcon CT63+CTPCI ATI R7500 14+512MB 30GB HDD CF HxC_SD EtherNEC/ TT030 68882 4+32MB 520MB Nova/ 520STFM 4MB Tos206 SCSI
Shared SCSI Bus:ScsiLink ethernet, 9GB HDD,SD-reader @ http://phsw.atari.org
My Atari stuff for sale - click here for list

ThorstenOtto
Atari maniac
Atari maniac
Posts: 92
Joined: Sun Aug 03, 2014 5:54 pm

Re: EmuTOS 0.9.8

Postby ThorstenOtto » Tue May 02, 2017 1:51 pm

AdamK wrote:Int size with GCC is more problematic in structs. With 32bit GCC, even if struct has short int member, it will use long int there, which screws most of TOS APIs


That's nonsense. If declared as short, it will be short (16-bit). shorts are only promoted to int (32-bit value) when passed as parameter to a function. And in 68k, there is no requirement to align 32-bit values on 4-byte boundaries, so even if the struct mixes shorts and longs, the layed will be the same. You can't rely on that layout on other architectures, though.

User avatar
AdamK
Captain Atari
Captain Atari
Posts: 223
Joined: Wed Aug 21, 2013 8:44 am

Re: EmuTOS 0.9.8

Postby AdamK » Wed May 03, 2017 8:06 am

ThorstenOtto wrote:
AdamK wrote:Int size with GCC is more problematic in structs. With 32bit GCC, even if struct has short int member, it will use long int there, which screws most of TOS APIs


That's nonsense. If declared as short, it will be short (16-bit). shorts are only promoted to int (32-bit value) when passed as parameter to a function. And in 68k, there is no requirement to align 32-bit values on 4-byte boundaries, so even if the struct mixes shorts and longs, the layed will be the same. You can't rely on that layout on other architectures, though.

That is not nonsense. FreeMiNT/MiNTlib developers struggled with that for long time. GCC, in structs, adds alignment of default int size for all types. For example, if you make have 4 bytes int, and following struct:

Code: Select all

struct
{
    char a;
    char b;


it will be 8 bytes big.
Atari: FireBee, Falcon030 + CT60e + SuperVidel + SvEthlana, TT, 520ST + 4MB ST RAM + 8MB TT RAM + CosmosEx + SC1435, 1040STFM + UltraSatan + SM124, 1040STE 4MB ST RAM + 8MB TT RAM + CosmosEx + NetUSBee + SM144 + SC1224, 65XE + U1MB + VBXE + SIDE2, Jaguar, Lynx II, 2 x Portfolio (HPC-006)

Adam Klobukowski [adamklobukowski@gmail.com]

rpineau
Captain Atari
Captain Atari
Posts: 494
Joined: Wed Jun 29, 2011 6:39 am
Location: California / USA
Contact:

Re: EmuTOS 0.9.8

Postby rpineau » Wed May 03, 2017 2:46 pm

On Atari, this :

Code: Select all

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <fcntl.h>
#include <osbind.h>
#include <mint/sysvars.h>


typedef struct
{
    char a;
    char b;
} TEST;

int main(int argc, char* argv[])
{

    printf("size of TEST : %d\n", sizeof(TEST));
    Cconin();
    return 0;
}


will display "size of TEST : 2" .... not 8 (just tested it).
Compile with "m68k-atari-mint-gcc test.c -o test.prg"
Rodolphe
Falcon + AB040 + Eclipse PCI + ATI Rage VGA card + NE2000 Ethernec + HxC Floppy Emulator
MegaSTE 4MB + CosmosEx / 1040 STF for hardware dev
http://www.rti-zone.org/atari.php

User avatar
mfro
Atari Super Hero
Atari Super Hero
Posts: 647
Joined: Thu Aug 02, 2012 10:33 am
Location: SW Germany

Re: EmuTOS 0.9.8

Postby mfro » Wed May 03, 2017 2:56 pm

AdamK wrote:... FreeMiNT/MiNTlib developers struggled with that for long time. GCC, in structs, adds alignment of default int size for all types. For example, if you make have 4 bytes int, and following struct:

Code: Select all

struct
{
    char a;
    char b;


it will be 8 bytes big.


I don't know what compiler you are using (probably an ancient one?), but with mine (m68k-atari-mint-gcc 4.6.4), the size of the struct you showed is just 2 bytes.

You probably mix up this with the behaviour gcc shows when passing short/char arguments to functions. Here it always keeps the stack aligned to 32 bit boundaries (addresses divisible by 4) if you are compiling with 32 bit ints (i.e. without -mshort) which makes it difficult to pass short arguments to some OS (or homegrown assembly) functions (resulting in "empty words" between arguments). In that case, it's indeed gcc's struct alignment that comes to a rescue: if you pack your arguments into a matching struct instead, gcc will align/pack shorts the way you want (i.e. on 16 bit boundaries).
Last edited by mfro on Wed May 03, 2017 3:09 pm, edited 2 times in total.

rpineau
Captain Atari
Captain Atari
Posts: 494
Joined: Wed Jun 29, 2011 6:39 am
Location: California / USA
Contact:

Re: EmuTOS 0.9.8

Postby rpineau » Wed May 03, 2017 3:01 pm

yep. I even tested the above on a 64 bit machine... still says 2
The issue is really with int, long and pointers (and using one for the other).
Falcon + AB040 + Eclipse PCI + ATI Rage VGA card + NE2000 Ethernec + HxC Floppy Emulator
MegaSTE 4MB + CosmosEx / 1040 STF for hardware dev
http://www.rti-zone.org/atari.php

rpineau
Captain Atari
Captain Atari
Posts: 494
Joined: Wed Jun 29, 2011 6:39 am
Location: California / USA
Contact:

Re: EmuTOS 0.9.8

Postby rpineau » Wed May 03, 2017 3:06 pm

One more test to show the issues :
on Atari :
Screen Shot 2017-05-03 at 8.03.45 AM.png


On a 64 bit Intel CPU (OS X) :
size of char : 1
size of short : 2
size of int : 4
size of long : 8
size of pointer : 8

same code on both machines :

Code: Select all

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <fcntl.h>
#ifdef ATARI
#include <osbind.h>
#include <mint/sysvars.h>
#endif

typedef struct
{
    char a;
    char b;
} TEST;

int main(int argc, char* argv[])
{

    printf("size of char : %d\n", sizeof(char));
    printf("size of short : %d\n", sizeof(short));
    printf("size of int : %d\n", sizeof(int));
    printf("size of long : %d\n", sizeof(long));
    printf("size of pointer : %d\n", sizeof(unsigned char *));
#ifdef ATARI
    Cconin();
#endif
    return 0;
}


Rodolphe
You do not have the required permissions to view the files attached to this post.
Falcon + AB040 + Eclipse PCI + ATI Rage VGA card + NE2000 Ethernec + HxC Floppy Emulator
MegaSTE 4MB + CosmosEx / 1040 STF for hardware dev
http://www.rti-zone.org/atari.php

ThorstenOtto
Atari maniac
Atari maniac
Posts: 92
Joined: Sun Aug 03, 2014 5:54 pm

Re: EmuTOS 0.9.8

Postby ThorstenOtto » Wed May 03, 2017 3:33 pm

Maybe i sound like a smartass here, but code like

rpineau wrote:printf("size of int : %d\n", sizeof(int));


is also a common cause for portability problems: the type of sizeof() is size_t, which (on a 64-bit machines) is not the same type as int; using it with %d will fail at least on big-endian machines, and also on little-endian if you had used additional arguments.

rpineau
Captain Atari
Captain Atari
Posts: 494
Joined: Wed Jun 29, 2011 6:39 am
Location: California / USA
Contact:

Re: EmuTOS 0.9.8

Postby rpineau » Wed May 03, 2017 3:37 pm

True, but here we're just displaying the value, this was to demonstrate the size of each type, but if you do indeed need to use sizeof() in an expression (other than printing) you also run into issues (gcc complained about that on OS X when I compiled the above but I didn't care for this case).
Here are the warnings on OS X :

Code: Select all

est.c:19:35: warning: format specifies type 'int' but the argument has type 'unsigned long' [-Wformat]
    printf("size of char : %d\n", sizeof(char));
                           ~~     ^~~~~~~~~~~~
                           %lu
test.c:20:36: warning: format specifies type 'int' but the argument has type 'unsigned long' [-Wformat]
    printf("size of short : %d\n", sizeof(short));
                            ~~     ^~~~~~~~~~~~~
                            %lu
test.c:21:34: warning: format specifies type 'int' but the argument has type 'unsigned long' [-Wformat]
    printf("size of int : %d\n", sizeof(int));
                          ~~     ^~~~~~~~~~~
                          %lu
test.c:22:35: warning: format specifies type 'int' but the argument has type 'unsigned long' [-Wformat]
    printf("size of long : %d\n", sizeof(long));
                           ~~     ^~~~~~~~~~~~
                           %lu
test.c:23:38: warning: format specifies type 'int' but the argument has type 'unsigned long' [-Wformat]
    printf("size of pointer : %d\n", sizeof(unsigned char *));
                              ~~     ^~~~~~~~~~~~~~~~~~~~~~~
                              %lu


So yes sizeof is also a potential issue in porting to other CPU type (aka I agree with you).
Rodolphe
Falcon + AB040 + Eclipse PCI + ATI Rage VGA card + NE2000 Ethernec + HxC Floppy Emulator
MegaSTE 4MB + CosmosEx / 1040 STF for hardware dev
http://www.rti-zone.org/atari.php

BlankVector
Captain Atari
Captain Atari
Posts: 389
Joined: Wed Oct 24, 2007 7:52 pm
Location: Paris, France
Contact:

Re: EmuTOS 0.9.8

Postby BlankVector » Wed May 03, 2017 10:37 pm

rpineau wrote:So yes sizeof is also a potential issue in porting to other CPU type

Solution is easy: just cast the result of sizeof to int.

Code: Select all

printf("size of char : %d\n", (int)sizeof(char));

User avatar
AdamK
Captain Atari
Captain Atari
Posts: 223
Joined: Wed Aug 21, 2013 8:44 am

Re: EmuTOS 0.9.8

Postby AdamK » Thu May 04, 2017 6:42 am

Sorry, for the confusion, you need to do it this way:

Code: Select all

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <fcntl.h>
#ifdef ATARI
#include <osbind.h>
#include <mint/sysvars.h>
#endif

typedef struct
{
    char a;
    int c;
    char b;
} TEST;

int main(int argc, char* argv[])
{
    printf("size of TEST : %d\n", sizeof(TEST));
#ifdef ATARI
    Cconin();
#endif
    return 0;
}

But, yes, I see some improvment with more modern GCC, a lot have changes since 2.95 it seems ;)
Atari: FireBee, Falcon030 + CT60e + SuperVidel + SvEthlana, TT, 520ST + 4MB ST RAM + 8MB TT RAM + CosmosEx + SC1435, 1040STFM + UltraSatan + SM124, 1040STE 4MB ST RAM + 8MB TT RAM + CosmosEx + NetUSBee + SM144 + SC1224, 65XE + U1MB + VBXE + SIDE2, Jaguar, Lynx II, 2 x Portfolio (HPC-006)

Adam Klobukowski [adamklobukowski@gmail.com]

User avatar
mfro
Atari Super Hero
Atari Super Hero
Posts: 647
Joined: Thu Aug 02, 2012 10:33 am
Location: SW Germany

Re: EmuTOS 0.9.8

Postby mfro » Thu May 04, 2017 8:08 am

Exactly as it's supposed to be. gcc uses "natural" alignment, i.e. each struct element gets aligned to its own size. Just as it's recommended practice by Motorola for all m68k.

While the 68000 and 68010 won't need it (since they have a 16 bit data bus only anyway), everything better than that would have performance issues with 32 bit ints _not_ aligned on a 32 bit boundary.

They would need two 16 bit bus cycles on the data bus to access the 32 bit word when they could fetch and store in a single 32 bit bus cycle otherwise. ColdFire would be able to even access a longword on an odd address without complaints (bus error, as on plain m68k), but would need 4 bus cycles instead...


Social Media

     

Return to “News & Announcements”

Who is online

Users browsing this forum: No registered users and 4 guests