MagiC/MagiCMacX source updated

[ThorstenOtto]

Okay, going a bit offtopic, but: NTFS does allow to delete an open file. Its the Windows layer that forbids this. They are not identical, eg. Windows allows only 260 char long pathnames, while NTFS can handle up to ~64K. Without this, POSIX layers like MS own subsystem or cygwin would not work.
And the Windows layer does those checks only, because they decided to make it compatible to MSDOS/CPM, where the GEMDOS also derives from.

[dhedberg]

Yes. NTFS is not a bad fs but the Windows layer cripples it in many ways. Not making any distinction between lower- and upper-case letters is another one. It's kind of amusing to see how confused Windows gets in this case.

[ThorstenOtto]

There had been some notable updates recently, including automated builds (see link in the first post). Stay tuned!

[mpattonm]

Wonderful! Pretty please, keep it up!
BTW The commits list is impressive. I see lot of effort towards CT60, does it mean we can expect CT60 test builds soon?

[ThorstenOtto]

According to a user of the german forum, they should work already. He used magic_p.tos to patch the resulting magic.ram (source included, but not currently build; has to be verified if that still is needed) and a slightly modified version of the ct60 specific boot program (also not currently build, but that will change soon), the ct60new.s in the kernel/bios/atari/boot folder. With those, he successfully booted MagiC.

[Cyprian]

Hey Otto,
What does this message means?

Steem__00002.png

It is from Steem. I prepared an empty hard disk partition,and I copied then content of "EN" folder from "magicmac-20190112-090039-bin.zip":
https://bintray.com/th-otto/magicmac-fi ... /snapshots

[Ektus]

According to a user of the german forum, they should work already. He used magic_p.tos to patch the resulting magic.ram (source included, but not currently build; has to be verified if that still is needed) and a slightly modified version of the ct60 specific boot program (also not currently build, but that will change soon), the ct60new.s in the kernel/bios/atari/boot folder. With those, he successfully booted MagiC.

That would be me. Haven't done any more testing yet, but the machine is up and running, CTPCI and all. That's with the build from post https://forum.atari-home.de/index.php/t ... #msg235546


Regards
Ektus.

[ThorstenOtto]

Hey Otto,
What does this message means?

It means that

• there are still some messages that need to be translated
• The *.OSD driver was not found when initializing the VDI. I have this error occasionally when running an emulator on a harddisk image that is also mounted in linux. Make sure that is not the case. Otherwise: how was STeem configured (which machine type, resolution etc?)

[ThorstenOtto]

There were some minor mistakes in the layout (themes & pat folder ended up in the wrong location), these are now fixed. But that should not prevent the system to work.

I have uploaded now also a ~16MB sample Harddisk image populated with the english version, that works in Hatari & Aranym. Maybe that should give you also a start for SteeM.

[ThorstenOtto]

oops, duplicate post deleted.

[Cyprian]

Thanks for preparing harddisk image.
I've checked with Hatari 2.1.0 and Steem 3.9.4 (both with EmuTOS 0.9.10) and both of them shows me:

floppy_00001.png

ant then:

floppy_00002.png

[ThorstenOtto]

I don't use Steem, so i can't tell how to set up a harddisk image there. For Hatari it should work however, at least with recent versions on linux. Same for Aranym (where the last official release is quite old). In both cases i'm using current (snapshot) versions.

Maybe for Steem you could try attaching it as a 2nd Harddisk first, and boot from some already working one, to check whether it is recognized at all. It's just a normal partition table with only a single partition in it.

[TheNameOfTheGame]

In Steem, I have to use an ASCI drive image for MagiC, could't work with GEMDOS (host system) drive. I believe when the ASCI drive is enabled, GEMDOS drives have to be disable for MagiC to work. Just trying to remember off the top of my head.

[Cyprian]

I don't use Steem, so i can't tell how to set up a harddisk image there. For Hatari it should work however, at least with recent versions on linux. Same for Aranym (where the last official release is quite old). In both cases i'm using current (snapshot) versions.

I'm using Windows, maybe there is something different in how Hatari manages disk image between both systems.

I'll let Hatar and Steem SSE team know about my issue.
Is it ACSI or IDE image?

Maybe for Steem you could try attaching it as a 2nd Harddisk first, and boot from some already working one, to check whether it is recognized at all. It's just a normal partition table with only a single partition in it.

Will try

In Steem, I have to use an ASCI drive image for MagiC, could't work with GEMDOS (host system) drive. I believe when the ASCI drive is enabled, GEMDOS drives have to be disable for MagiC to work. Just trying to remember off the top of my head.

I have disabled GemDOS emulation. I can see HD driver message (as posted above) therefore EmuTOS and TOS boots ACSI image.

[TheNameOfTheGame]

ASCI image. I have a blank 1GB hdd image if you need it. Then load HDDriver as a floppy image .ST and partition the drive image and install the driver, then do the same for MagiC, etc. I also used a program- PP's Drive Imager v1.35 to put zip files on the drive so I could install software easier, but had to use a VirtualBox linux install as it only works on linux I think. http://atari.8bitchip.info/drimlus.php

[TheNameOfTheGame]

Btw, I'm using Steem 3.8.0 win32. Not sure if newer versions have changed anything.

[TheNameOfTheGame]

Eh, 3 posts in a row...sorry. Here is the blank drive image I used to install hddriver and magic under steem.

hdd-1gb_blank.zip

[Cyprian]

thanks,
It seems something is wrong with my Hatari setup, due to I'm not able to install the latest HDDriver Demo on your Partition.
I have to check on a clean setup.

[mpattonm]

Apparently, there are no more commits since January, I sincerely hope you have not given up! Please keep on

[Eero Tamminen]

Hey Otto,
What does this message means?

It means that

• there are still some messages that need to be translated
• The *.OSD driver was not found when initializing the VDI. I have this error occasionally when running an emulator on a harddisk image that is also mounted in linux. Make sure that is not the case. Otherwise: how was STeem configured (which machine type, resolution etc?)

The linked image showed similar error for me with Aranym, but worked fine with Hatari.

Then I happened to start sysinfo.app, and changed some NVRAM settings with it. Then I tried looking rest of the info sysinfo provides and magic crashed.

On reboot, I got the same error as on Aranym. Also when restarting Hatari. Removing ~/.config/hatari/hatari.nvram got image working again with Hatari.

(I haven't tried which particular NVRAM option caused the boot failure with Hatari, but I changed following: OS preference, date format, boot delay, keyboard/language.)

Removing Aranym NVRAM file (~/.aranym/nvram) didn't help in getting Otto's Magic image working with the included Aranym config & images, when using distro version of Aranym. But compiling latest Git version of Aranym from Github repo and using that got it working too.

[TheNameOfTheGame]

I was reading the Magnum ST Alt-RAM card readme.txt and it mentions a bug with MagiC >5.04 which caused 64KB of ST-RAM to be lost. Was the bug still carried over as of MagiC 6.20?

Due to a bug in the operating system function Maddalt() in Magic!>5.04 (probably from 5.10 or 5.13) causes the system to loose 64K ST-RAM.
The function of the card and registered memory is not affected by this error.

[ThorstenOtto]

I don't know, i would first have to know how that bug can be reproduced, or what causes it. Do you have any details?

[TheNameOfTheGame]

Unfortunately, I don't know anything other than what it says. I assume Maddalt() was to add in the Alt-RAM from the Magnum card, so probably happens when the auto folder program runs to set up the memory space.

Here is the Magnum package that has the readme.txt file:

mst_117.zip

[ThorstenOtto]

Maybe you can just try and see if that bug still exists? I don't have any hardware which adds memory via Maddalt. If the bug still exists i can try to have a look what the reason might be, but if it doesn't then looking for it would be quite pointless Unfortunately we just got the source "as is", without much history about changes done.

[TheNameOfTheGame]

Ok, that makes sense, but I don't have a populated magnum board, just a pcb. If the issue is untestable atm, that's understandable. If I ever get this board together I can try it out.