MagiC/MagiCMacX source updated

[ThorstenOtto]

Maybe the reason is just this

Edit: should be fixed in MagiC6

[ThorstenOtto]

If I ever get this board together I can try it out.

Bump Did you miss the links above?

[TheNameOfTheGame]

Ooops, yes, I missed it. Thanks for bump. That's good to know.

[ThorstenOtto]

So it looks it wasn't really a bug, just not obvious where that 64k did go. The only question remains if, whether it is really neccessarry to install a FRB for Magnum ST.

[TheNameOfTheGame]

Yes, well I don't know of any Magnum boards at the moment to test this with. The ones I have are DIP. I've asked Uwe Schneider if he could provide some build files for the PLCC version. There is no ALT-RAM options for STE at this time that I'm aware of. I would like to get a small batch of bare boards made for STE if Uwe is ok with it and still has the files that is.

[ThorstenOtto]

There is no ALT-RAM options for STE at this time that I'm aware of

It's also a matter of the of the TOS version used, and the harddisk driver. I'm not sure about TOS 1.62, but TOS 2.06 has Maddalt() at least. Magic6 uses the FRB for everything that is above _phystop (ie not in ST-RAM). But the harddisk driver may behave differently.

[iggydrougge]

I suppose building MagiCMac and AtariX in the same process requires additional tool chains?

[ThorstenOtto]

MagicMac requires some atari or emulator, and Pure-C (you can also build the normal magic.ram with this environment). AtariX can be build on macOS only. Once you got AtariX running, you can use that emulator to build a new kernel for it

In my environment, i run Virtualbox on linux, using an image of macOS Sierra to build AtariX, then run it and build the magic kernels inside that emulator. The latter can also be done automatically (i use travis CI in my magicmac fork, which downloads aranym and a harddisk image with Pure-C and a few other tools preinstalled).

But they are different source repositories, so creating for example an installer can currently not be done in one step.

[Gaiyan]

Here is a ROM-version of the latest build from Thorsten. It is mostly translated, using some of Atarizoll's and some of mine. It is built from the MAGIC.RAM using r2 p12 a0. I like to see the versions and text on the boot screen, that's why 12 seconds. It's skippable anyway.

It's running as-is on my MonSTer STacy from IDE. None of that offscreen driver BS. I'm booting from the ROM and I have verified it to save 237KB of RAM.

NOTE: The rest of Thorsten current snapshot is unuseable. Runs out of memory. Haven't figured which part is causing. So I'm using the rest of Atarizoll's package.

Why did I do this? Atarizoll's IMG, while boots fine, has somehow corrupted the date function. It's permanently set to 12:35 15/08/72. Every program or ACC or utility that tries to set the date causes a hard crash. It might be for my specific STacy + MonSTer setup. Nevertheless, it was unusable and after a lot of troubleshooting I came up with this fix.

Hope this works for the rest of you. So far so good for me.

Thanks to Thorsten for the good work!

[ThorstenOtto]

What tool did you use to create the ROM image? IIRC, the MAGIC.RAM is missing some code in the early boot phase to initialize some hardware. I already thought about adding such functionality, but never got to it, and it would require quite some testing. But as a first step, if a commandline tool is available, they could be automatically created during the build process.

What do you mean with "the rest of the current snapshot", applications like magxdesk etc? I just wonder, because i'm using them myself, and would certainly have recognized if such problems exist.

[Gaiyan]

What tool did you use to create the ROM image? IIRC, the MAGIC.RAM is missing some code in the early boot phase to initialize some hardware. I already thought about adding such functionality, but never got to it, and it would require quite some testing. But as a first step, if a commandline tool is available, they could be automatically created during the build process.

I used this one:

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.

What do you mean with "the rest of the current snapshot", applications like magxdesk etc? I just wonder, because i'm using them myself, and would certainly have recognized if such problems exist.

So I was able to replicate the problem on Steem where the screenshots are from. But, turns out the problem was the MAGIC.INF file which is attached. That works with Atarizoll's version. As soon as I removed it problem was gone.

[ThorstenOtto]

The 2nd screenshot is imho an error message from NVDI. Can be turned off by deactivating "Compatibility" option in the NVDICONF.CPX (but might as well be that this message is just the result from some previous error)

The magx.inf looks rather normal. Only thing that could make problems are the *.img files; maybe they are corrupt, or something is wrong with the routine that loads them. But the ones from magx.inf are only used during booting, if you use jinnee that will display a different pattern later, so imho that feature isn't really very useful.

However that seems to be default settings (i have that lines there, too). So only possibility would be to compare the old and new magx.inf, and activate different features one after the other to find out what causes problems, but that is of course time consuming.

[Gaiyan]

The 2nd screenshot is imho an error message from NVDI. Can be turned off by deactivating "Compatibility" option in the NVDICONF.CPX (but might as well be that this message is just the result from some previous error)

The magx.inf looks rather normal. Only thing that could make problems are the *.img files; maybe they are corrupt, or something is wrong with the routine that loads them. But the ones from magx.inf are only used during booting, if you use jinnee that will display a different pattern later, so imho that feature isn't really very useful.

However that seems to be default settings (i have that lines there, too). So only possibility would be to compare the old and new magx.inf, and activate different features one after the other to find out what causes problems, but that is of course time consuming.

I did further testing. I deactivated lines from magx.inf and pretty much had to deactivate everything for Magic to boot to the desktop. This was with no NVDI or accs or other auto programs. I also used a fresh set of files from the latest binary.

So only after essentially removin magx.inf entirely did it boot. It seems that my previous statement about it working was premature. After loading QED to edit the inf file in Magic did I realise something was off. QED loaded fine. Only when trying to load the inf file did I start getting the same memory errors. I looked at the available RAM and it was at 6KB.

It seems that loading some (not all) causes the system to use up all available RAM no matter how much you have. MGNOTICE.APP is one such app.

Tested with MAGIC.RAM and my ROM. Problem is only with the files, not ram/rom.

Hope this helps

[Gaiyan]

I thought I'd illustrate how the issue presents itself. These shots are in order. Point is to show the available RAM after each step.

a.gif

b.gif

c.gif

d.gif

e.gif

[Gaiyan]

I may have found the offenders in this weird case.

C:\GEMSYS\MAGIC\XTENSION

EDITOBJC.SLB was the cause of the memory problem. The system booted fine when replacing it.
PDLG.SLB was the cause of bus errors when trying to copy files.

I am using all other files in the latest snapshot. MAGIC.RAM is translated and turned into a ROM as mentioned earlier.

[ThorstenOtto]

That's weird. PDLG.SLB isn't even loaded until someone calls pdlg_create() to create a printer config dialog. EDITOBJC might be loaded by MGNOTICE if that is running.

The system booted fine when replacing it.

Huks. So the memory problems only occur when using the version compiled from the sources, but not when using an older version?

[Gaiyan]

That's weird. PDLG.SLB isn't even loaded until someone calls pdlg_create() to create a printer config dialog. EDITOBJC might be loaded by MGNOTICE if that is running.

The system booted fine when replacing it.

Huks. So the memory problems only occur when using the version compiled from the sources, but not when using an older version?

Yes. Those two files are replaced with ones from http://atari.8bitchip.info/MAGICE62.ZIP

But again, magic.inf is somehow tied to this as I mentioned earlier that removing it allows it to boot. But still has problems.

[Rustynutt]

Just throwing this out there, experience with the Mighty Sonic w fast ram, NVDI was required. I'd thought it setup a buffer for ram located as with the TT addresses. As significant, it disables the blitter. As for the Magnum, it setups memory at a different address in the range of ST RAM, if not mistaken. Frank Lucas could verify that.
Now I think about it, should be able to see the FRB cookie

[mikro]

What tool did you use to create the ROM image? IIRC, the MAGIC.RAM is missing some code in the early boot phase to initialize some hardware. I already thought about adding such functionality, but never got to it, and it would require quite some testing. But as a first step, if a commandline tool is available, they could be automatically created during the build process.

I used this one:

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.

So what's the current situation with Thorsten's builds and magrom? Is it safe to use his latest MagiC 6.x image and convert it into a ROM one using this tool?

Also, have been the strange *.SLB errors solved in the meantime or should I stick with the original/ppera's one for now?

[TheNameOfTheGame]

My STE still uses the original MagiC 6.20 image so I can't answer on that regard.

[ThorstenOtto]

Its been quite some time since i worked on it, but IIRC magrom should work. I just cannot test it.

What SLB errors do you mean? If it the SLBs showing up in appline: i've posted a patched appline version some time ago that should fix that.

[mikro]

The errors Gaiyan posted here: viewtopic.php?p=397926#p397926 and here: viewtopic.php?p=399076#p399076

[ThorstenOtto]

But those were already solved when using the new versions?

[Rustynutt]

Sharing in general, will confirm NVDI printer cpx crashes, or causes issues with fast ram and caches on the 040 using any (zcontrol, xcontrol, cops) control panel acc program.

Not experienced NVDI error notice with compatibility set.

Under TOS (not CT TOS), just thought it may be relevant here.
Food for thought or discard.

The problem manifest as an error message "unable to allocate AES blit memory" (attempting resolution change) or somehow memory allocation becoming corrupt with desk info showing some miniscule amount of ram available.

Another thing noticed, again related only in function, certain speed and alt ram configurations, newdesk.inf will crash a Falcon. Bypassing it at boot is successful.
The file itself is not corrupt (right, certain defaults can cause issue with it).

Probably would have skipped this if not for recent interest building a MagiC ROM for Falcon.

Carry on

[Gaiyan]

What tool did you use to create the ROM image? IIRC, the MAGIC.RAM is missing some code in the early boot phase to initialize some hardware. I already thought about adding such functionality, but never got to it, and it would require quite some testing. But as a first step, if a commandline tool is available, they could be automatically created during the build process.

I used this one:

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.

So what's the current situation with Thorsten's builds and magrom? Is it safe to use his latest MagiC 6.x image and convert it into a ROM one using this tool?

Also, have been the strange *.SLB errors solved in the meantime or should I stick with the original/ppera's one for now?

I'm afraid I have amnesia related to that. I do recall that I had to hack a ROM as the bugs I reported were not resolved but I'm a bit hazy on that. Since I got the TF536 on the STacy I haven't used the ROMs, which are on the MonSTer. All I remember is that the ROMs I had worked fine and I think I did some custom work on them as well.

Josh.