MagiC/MagiCMacX source updated

[ThorstenOtto]

Hi,

i've done some work recently to simplify building the MagicMacX sources as published by Andreas Kromke, including needed changes to actually create a working kernel both for MagicMacX.OS (the one that is used by AtariX) and a "normal" Atari ST version (magic.ram). Major changes include:

• Restructuring of most directories, to keep pathnames short
  (Pure-C does not like too long pathnames very much)
• Converting source files to CR/LF line endings, where that was not already
  the case (again, mainly for Pure-C)
• Converting UTF-8 input to ASCII. German umlauts in comments
  are converted to ae, ue etc, while characters in messages were
  converted to their hexadecimal equivalents. This was needed to be
  able to compile the sources just after checking out, without having
  to convert them every time.
• Disassembling of mxvdiknl.o into source file. In the meantime, the
  original source was uploaded to the upstream archive, but the version
  there is slightly different than the object, and does not work with the
  VDI drivers.
• Sources for some CPX control modules were added
• Some constants were moved to separate files, and included where needed.
  This was mainly done because some EQUs that were exported could not be
  linked to elsewhere.
• Sources for PDLG.SLB were added.
• Sources to build WDIALOG.PRG were added.
• Sources for CHGRES.PRG were added.
• Sources for the CD filesystem library were added, so spinmagc.xfs can now be completely build.
• binary files that can be rebuild were removed.
• Some bug fixes. Notably a few fixes to the FAT32 code, which caused problems when the same image was also used by MiNT. Take a look at the commit history.
• Automated builds are now generated using travis, and deployed to https://bintray.com/th-otto/magicmac-fi ... sion#files

The sources are available at https://github.com/th-otto/MagicMac.

Have fun!

[itaboy]

Thank you! I'll check the lot

[mikro]

Wow, great job!

Btw this:

Converting UTF-8 input to ASCII. German umlauts in comments
are converted to ae, ue etc, while characters in messages were
converted to their hexadecimal equivalents. This was needed to be
able to compile the sources just after checking out, without having
to convert them every time.

is perhaps not what Andreas would have wanted, he'd spent some time on the exactly opposite, converting umlauts to UTF-8 so anyone can read it on present PCs.

[ThorstenOtto]

is perhaps not what Andreas would have wanted, he'd spent some time on the exactly opposite, converting umlauts to UTF-8 so anyone can read it on present PCs.

Yes, i know. But there were several problems with this:

• it was not done for all sources, so some are still in Atari encoding.
• you aren't able to compile the source after checking out. You first have to convert them. And if you are working on it, you have to convert them back before checking in. This process was even more complicated by the fact that the tool creates long filenames that can't be used with Pure-C (appending ".ataritext" to the name)
• As mentioned above, (most of) the sources should be now plain ASCII, so you can read it anywhere, whether working on Atari or PC. Of course the comments are still german
• The sources on gitlab are not compilable anyway (mentioned above already, i had several problems linking the original versions). And even if you manage to compile them, they are inconistent (eg. the recently added mxvdiknl.s apparently uses a different API for the drivers, which make them crash).

So basically, i think he just uploaded everything he had left on his HD. Of course we are very thankful for this, but it didn't work out-of-the-box.

[joska]

Amazing job

[TheNameOfTheGame]

Awesome work to get the sources to compile! I think the next year will be bring some good things for MagiC!

Hopefully it can be made to compile to different languages eventually. And where we can compile our own from Github.

[joska]

I'll have to take a closer look at this when I get some spare time. I wonder if it would be possible (with a reasonable amount of work) to add ROM-targets too? Would be usable with emulators, MiST/MiSTer and real hardware with flash-TOS.

[ThorstenOtto]

Hopefully it can be made to compile to different languages eventually.

For most applications, that's just a matter of adding a new resource file. There are a few places where strings are compiled into the executables though, where possible this should also be moved to the resource files (just grep for COUNTRY). Keyboard tables for most languages should already be there. Only problem: the emulator will not be aware of this, so has to be changed, too.

[ThorstenOtto]

I wonder if it would be possible (with a reasonable amount of work) to add ROM-targets too?

If you look closer, you will find already rom_de.prj etc. in the kernel build directory. Compiling a rom version is just a matter of setting the Text segment to the correct address (will only work at 0xe00000, since it does not fit in 192k ROMs). What's missing though is memory initialization & detection. Shouldn't be too hard. A user from the german forum has already tried it (with a hacked version where i had set some fixed values), and it basically worked. Only problem was that his drive sometimes was not ready after a coldboot, and he had to reset in order to boot.

[joska]

If you look closer, you will find already rom_de.prj etc. in the kernel build directory.

I didn't download anything (yet) but only read your BUILDING.md. Good to hear that a ROM-version has already been taken care of

What's missing though is memory initialization & detection. Shouldn't be too hard.

I guess this could be lifted from EmuTOS? Also, there is a mag2rom-tool which I guess adds this functionality. I could not find any references to this tool in the MagiC sources, maybe it's a third party tool.

Only problem was that his drive sometimes was not ready after a coldboot, and he had to reset in order to boot.

This also happens occasionally with the ROM-ified original MagiC 6.2, which I use with my MonSTEr'ed STE.

[ThorstenOtto]

I guess this could be lifted from EmuTOS?

Maybe partly, but the current implementation there uses a mixture of C/asm, and also a different order (ALT-Ram is checked there much later for example).

Also, there is a mag2rom-tool which I guess adds this functionality.

I've found a tool magixrom.ttp done by Wilfried Mintrop, from 1994. But it does not work with MagiC 6.2. If you have something different/newer, or a working ROM image, pls let me know

[joska]

I've found a tool magixrom.ttp done by Wilfried Mintrop, from 1994. But it does not work with MagiC 6.2. If you have something different/newer, or a working ROM image, pls let me know

See this post: http://atari-forum.com/viewtopic.php?f= ... om#p269681

This is an updated version of the program you found.

[ThorstenOtto]

Thanks, i'll have a look at it. Just one sentence in the README that's a bit strange:

Code: Select all

Leider nicht für TT oder Falcon, eventuell Problem mit STe.

, or in english

Code: Select all

Unfortunately not for TT or Falcon, possibly problems with STe.

I don't understand why this should not work with TT, if the original magic.ram works.

[joska]

I have only tested this with MagiC 6.2 on STM and STE, so I really can't say. Maybe the author just did not have any way to actually test it on TT and Falcon? And MAGIC.RAM is designed to run from RAM after TOS has initialised the hardware, maybe there's more than memory to initialise on these machines?

[ThorstenOtto]

Beside the memory, everything seems to be already initialized, there was only one problem which i already fixed, when MagiC waited for an VBL during video initialization when the exception vectors still pointed to the previous ROM version.

That tool seems to work, now i have to find a way to test it. Neither Hatari nor Aranym can directly boot a magic.rom currently

BTW: further search seem to indicate, that there should be a release 6 of this tool, but i cannot find it, only the version you posted in the other thread. Should be named magrom6.lzh.

[TheNameOfTheGame]

Beside the memory, everything seems to be already initialized, there was only one problem which i already fixed, when MagiC waited for an VBL during video initialization when the exception vectors still pointed to the previous ROM version.

That tool seems to work, now i have to find a way to test it. Neither Hatari nor Aranym can directly boot a magic.rom currently

BTW: further search seem to indicate, that there should be a release 6 of this tool, but i cannot find it, only the version you posted in the other thread. Should be named magrom6.lzh.

Steem as of 3.8.0 can boot the MagiC rom as I use it that way.

[TheNameOfTheGame]

Also magrom6.lzh can be found here http://atariftp.czietz.de/pub/atari/Uti ... agrom6.lzh. That is the mirror of the old ftp.cs.tu-berlin.de/pub/atari/ site.

[ThorstenOtto]

Ah, nice, thanks!

[ThorstenOtto]

Just added to the repo: (reconstructed) the missing sources for CHGRES.PRG.

[TheNameOfTheGame]

One long-standing issue with MagiC that may be fixed now is file-locking or rather MagiC's lack thereof. See this page: https://web.archive.org/web/20040212050 ... crash.html

[ThorstenOtto]

The error that is described there has nothing to do with file locking. Being able to delete a directory that is in use, or a file that is open, should be normal behaviour of a filesystem. Beside that, filelocking is supported (at least when i look at the source, currently don't have any programs to try it).

[TheNameOfTheGame]

Oh, I didn't know the details. I kept that webpage in case the source ever got released because deleting a file that is open shouldn't trash a partition even if it doesn't involve file-locking. Never tried to reproduce the behavior myself though so can't vouch for the veracity of it.

[alienkidmj12]

this is awesome news, i really like magic

[ThorstenOtto]

See this page: https://web.archive.org/web/20040212050 ... crash.html

Just tried to reproduce the error using the ramdisk mentioned in the other thread. Nothing bad happens. mc_coy seems to keep the hiscore file open which apparently is the reason for the report. But when i try to delete its folder while the program is running, the program file itself is deleted, and then i get a "access denied" when trying to delete the file, and also for the folder itself.

Unfortunately that page does not mention which exact version of Magic was used, maybe that bug is already fixed?

[susher]

The error that is described there has nothing to do with file locking. Being able to delete a directory that is in use, or a file that is open, should be normal behaviour of a filesystem.

Incorrect. It's the normal behaviour for a fully POSIX compliant filesystem but that's about it. (This is able to be done as the primary file/directory reference is not its name but another reference number, unlike FAT/NTFS. The OS can clean up after all file access has completed.)

NTFS filesystem, for example, doesn't allow renaming, deletion or modification of a file or directory which is open. I believe that the FAT filesystem under MSDOS (Win9x) also has this restriction, as does CP/M and mini-computer OSs such as VMS.