My summer project: A colour Stacy

[czietz]

Storm ST memory needs to be accessible by the 68000; hence it's below 16 MB, starting at 0x00400000.

[derkom]

Storm ST memory needs to be accessible by the 68000; hence it's below 16 MB, starting at 0x00400000.

Aha. Hrm. Then I need to go back and look at things again. I may have lost track at some point of what I was doing myself, because if @agranlund's fastram.prg isn't looking for anything below 0x01000000, then it would seem like he should be right that TOS 2.06 wouldn't have this problem, as long as I don't run the Storm's own altram driver program.

If that's correct, and I can easily make non-EmuTOS ignore the Storm, then I think I would be happy with keeping both expansions in the system, because at that point, yes, I need to modify EmuTOS if I want it to ignore the Storm, but that's relatively simple to do (I presume the simplest approach would be to adjust where it begins its own altram scan), and if I can control whether or not TOS 2.06 sees the Storm based solely on what AUTO prg I run, then I think I'm golden.

Edit: Er, yeah, of course the Storm is going to be below 16 MB. I was completely ignoring the address space limit of the 68000. :mrgreen:

[derkom]

Durr, okay, I obviously got myself a bit turned around earlier today and simply never noticed that actually things work fine in TOS 2.06 with fastram.prg. Indeed I do get the fast altram, and the Storm is effectively non-present.

Still don't know why maprom.prg is just hanging. I'm having that problem with or without the Storm, and with TOS 2.06 coming from either the Cloudy or the exxos IDE board. I didn't get around to sticking the TF back into the H4, where I know it worked before. I also haven't been keeping up carefully with the TF firmware thread, so I may not be on the best TF build, although I would expect that as long as the RAM passes YAARTTT (and it does), then there shouldn't be anything there that would be upsetting maprom.

I'll poke around at this stuff some more tomorrow.

[PhilC]

@derkom might be worth trying a different firmware on the TF536 if its still using the same as Ivsent it with, check the TF536 on Atari thread.

[derkom]

@derkom might be worth trying a different firmware on the TF536 if its still using the same as Ivsent it with, check the TF536 on Atari thread.

It's probably not the same version, but it's also not particularly new. Recall that I toasted the CPLD on this one and soldered on a new one. I flashed whichever was the newest "stable" version in the thread at that time, but it's been a while, so it's probably worth a refresh.

[PhilC]

@derkom oh yes, I forgot you are a fully paid up member of the break it clan :lol:

[agranlund]

Still don't know why maprom.prg is just hanging. I'm having that problem with or without the Storm, and with TOS 2.06 coming from either the Cloudy or the exxos IDE board. I didn't get around to sticking the TF back into the H4, where I know it worked before.

I’ll make you a couple of different test version of maprom to see if it’s possible to narrow down what’s going on. Possibly this evening or tomorrow.

[czietz]

yes, I need to modify EmuTOS if I want it to ignore the Storm, but that's relatively simple to do (I presume the simplest approach would be to adjust where it begins its own altram scan),

Actually, EmuTOS has its own code to add Alt-RAM for MonSTer and for Storm ST: https://github.com/emutos/emutos/blob/d ... ry2.c#L138
(The same code is used for both expansions.)

Imho, the simplest "hack" for your situation would be to run this only if a 68000 CPU has been detected.

[derkom]

Actually, EmuTOS has its own code to add Alt-RAM for MonSTer and for Storm ST: https://github.com/emutos/emutos/blob/d ... ry2.c#L138
(The same code is used for both expansions.)

Yeah, I saw that while poking through the code last night. Also saw that one can define alt-ram statically if one desires, so that's also an option. But it looks like the simplest approach is just to "#undef CONF_WITH_MONSTER".

Given that the ultimate desire is to be running TOS out of RAM anyway, I'll probably look into just building my own PRG versions of EmuTOS, with the RAM detect twiddled, and then use XBoot to stick the executable in the AUTO folder for my 68030 boot configuration. Then I can keep regular TOS 2.06 in the Cloudy, and boot either that or a different EmuTOS binary for 68000 mode, and of course with 2.06, I'd run the altramon.prg to bring up the Storm.

It also may be possible to use the same EmuTOS binary for both modes, and simply run altramon.prg if booting the 68000 configuration. I haven't tested if this actually works with EmuTOS, since I don't have an EmuTOS that doesn't do the detection already on its own.

I verified last night that 68000 mode still works fine, and that altramon.prg finds the Storm memory just fine, so I do get the desired 8 MB altram in TOS 2.06 in 68000 mode. Seems like this will all work out just fine.

Today I'm working on building up the final switcher board. I'm taking this build nice and slowly and checking everything I can, each step of the way, because in this build, the Lightning ST and TF536 will be soldered directly to the board (vertical space limitations), so with 64 pins each, it's a bit a one-shot deal. :geek:

[derkom]

I’ll make you a couple of different test version of maprom to see if it’s possible to narrow down what’s going on. Possibly this evening or tomorrow.

Okay, glad to test it out. FYI, what I'm seeing is the fastram active text, followed by maprom active text (nothing else in AUTO), and then when the system tries to start the desktop, I get a white screen with a frozen bee in the middle. This is all running from floppy, since that's currently the only storage connected to the Stacy. Oh, and it's stock TOS 2.06 in the Cloudy.

Certainly no hurry. I may not even have the system bootable again today, and of course there are other solutions that work even if maprom isn't.