My summer project: A colour Stacy

[agranlund]

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".

Last I checked you get a nice speed boost if you build it with -DSTATIC_ALT_RAM_ADDRESS=0x01000000
Most of EmuTOS's internal variables will end up in that region instead of slow st-ram - this means it won't run at all if you don't have alt-ram at that address though, which may be of importance in your 68030/68000 switchable setup :)

I'm following your project with great interest as I'd love something similar in my machine eventually.
Are you planning on muxing the IDE interface as well to get both modes working from the same card?

[derkom]

Last I checked you get a nice speed boost if you build it with -DSTATIC_ALT_RAM_ADDRESS=0x01000000
Most of EmuTOS's internal variables will end up in that region instead of slow st-ram - this means it won't run at all if you don't have alt-ram at that address though, which may be of importance in your 68030/68000 switchable setup :)

Ah, good tip, thanks. If I'm booting EmuTOS using a PRG instead of a ROM, it should be quite simple to use XBoot to swap in whichever binary works for the configuration I'm trying to boot, so extreme customisation is definitely doable.

Are you planning on muxing the IDE interface as well to get both modes working from the same card?

Can you explain what you mean here? The IDE interface on the TF card will only work in 68030 mode, so I was expecting to end up using only the IDE interface on the Lightning ST, which will work in both 68030 and 68000 modes. Obviously that does come at the cost of some performance when in 68030 mode, but it's the simple way to make everything work.

I did ponder whether I could build some additional multiplexing setup, such that the TF IDE interface was active in 68030 mode and the Lightning ST IDE interface in 68000 mode, with both connected to the same storage hardware, and maybe this is what you were referring to. But this idea seemed like it would add significant complication, and may not actually be reliable.

[agranlund]

I did ponder whether I could build some additional multiplexing setup, such that the TF IDE interface was active in 68030 mode and the Lightning ST IDE interface in 68000 mode, with both connected to the same storage hardware, and maybe this is what you were referring to. But this idea seemed like it would add significant complication, and may not actually be reliable.

Yep, that setup was pretty much exactly what I was referring to :)
But it does sound a great deal easier with a TF536 firmware which has the IDE interface disabled though, at the expense of performance in 68030 mode though.

[agranlund]

@derkom

You could give the latest version of maprom a try and see if it helps:
https://github.com/agranlund/tftools

If that fails it would be interesting to hear if either of the two test versions in this archive works:
http://www.happydaze.se/wp-content/uplo ... omtest.zip

[derkom]

You could give the latest version of maprom a try and see if it helps:

If that fails it would be interesting to hear if either of the two test versions in this archive works:

Thanks. I'll let you know as soon as I have the system bootable again. Right now I'm about half way through building the final relocator/switcher board, so I can't test. I'll probably get it finished tomorrow.

[derkom]

Some slow progress on my final switcher build today...

IMG_20200913_183843.jpg

IMG_20200913_183916.jpg

That is why you put that hole there, right @czietz? :lol:

I've only got the 68000 side built so far. Since soldering in the TF536 will make me lose access to the mux connections for the switched signals to the 68000, I want to be sure the 68000 side is solid before I move on. Sorry, @agranlund, I won't get to test maprom just yet. :D

[derkom]

Not running quite stable yet. It had run through a bunch of GEMBench loops before I went to bed, but crashed before the morning, and then would not boot again. Sticking a 68HC000 directly into the motherboard socket worked fine. I did not find any shorts or opens on the bus connections on my switcher board, but then by the time I removed the tower from the (soldered in) Lightning ST, I had a short between D1 and D2.

This is quite curious, because I found the exact same short yesterday, and thought it had been resolved by cleaning off a bit of mess from the Lightning. Not seeing any further mess, I cleaned up the Lightning with IPA again anyway, and the short disappeared again. What's really strange here, besides the same short showing up twice, is that I really don't think it was there before I removed the tower. But maybe I just missed it.

Since these passthrough pins have gotten a lot more in/out cycles than I wanted, I very gently bent out the pins on the Cloudy and Storm and reassembled, crossing my fingers it's the last time. As this is supposed to be a pretty permanent setup, inside a computer that isn't easy to open, I'm not opposed to flowing a little bit of solder from the side onto all of these pins, but since that significantly reduces my troubleshooting options, I don't want to do that unless I know it'll fix things up once and for all, which I can't know without doing it. Bit a chicken and egg problem there.

It's back to running GEMBench now, and I need to be doing actual work today, so it will have some alone time now, to either keep working or not. :ball:

[derkom]

After 24 hours of successful GEMBench on the 68000, I finished up the board today...

IMG_20200915_120327.jpg

IMG_20200915_120405.jpg

The orange and yellow wire is the 68030/68000 switch cable and the multicoloured cable is JTAG for the TF536. When I eventually close this thing back up, I'll stick the other end of that somewhere reachable.

Onward to installation...

IMG_20200915_120819.jpg

IMG_20200915_135224.jpg

They keyboard fits! And the Stacy boots successfully in both 68000 and 68030 configuration. I will now run a bunch of GEMBench cycles in 68030 mode to verify stability there.

[derkom]

@agranlund, now that I've got the 68030 back in, I have run a few tests with the various maproms. Results as follows:

maprom.prg (v1.6): I get a fast ROM, but no device icons. When I "Install Devices", I get three icons (A, B, c), all named "DEVICE", and the directories read, but executables are not recognised as executable.

mrtest01.prg: I get a fast ROM, and correct reading of disk directories, but read errors when I try to run GEMBench off floppy (this is a known good floppy, since I'm using it to run GEMBench without maprom with no problems). GEMBench runs successfully (from ST-RAM) off cartridge and shows 384% ROM speed.

mrtest02.prg: Everything works normally, but slow ROM. It's as if there is no maprom at all.

[agranlund]

@agranlund, now that I've got the 68030 back in, I have run a few tests with the various maproms. Results as follows:

maprom.prg (v1.6): I get a fast ROM, but no device icons. When I "Install Devices", I get three icons (A, B, c), all named "DEVICE", and the directories read, but executables are not recognised as executable.

mrtest01.prg: I get a fast ROM, and correct reading of disk directories, but read errors when I try to run GEMBench off floppy (this is a known good floppy, since I'm using it to run GEMBench without maprom with no problems). GEMBench runs successfully (from ST-RAM) off cartridge and shows 384% ROM speed.

mrtest02.prg: Everything works normally, but slow ROM. It's as if there is no maprom at all.

Good that it doesn't hang like the old version did, it was the memory detect past 64MB that made it hang then.
You can toss the mrtestxx programs, they have various amount of stuff disabled to help pinpoint what was causing the hang on your machine if it hadn't been the mem detect stuff.

I had issues with the floppy as well but I can't really tell exactly what the issues were since I stopped having the floppy drive connected a long time ago. TOS2.06 can actually boot without a floppy drive attached if it's able to boot off the IDE instead.

Try disabling cache in the TOS options and see if this solves the issue.
I remember something about TOS < 3.xx not flushing the cache after DMA operations, but I could be wrong..
I'm still running TOS2.06 with cache disabled.. not sure if that is at all necessary without the floppy though (but my Ultrasatan works great, maybe it would stop working correctly if I enable cache :lol:)

When I get a chance I'll plug that Gotek back in and see what works and what doesn't on my machine, can't promise when though :)