DSTB1 - official firmware tests

[exxos]

Yeah using the 192k version, which *shouldn't* need any form of decoding right?

Something has to decode it, GLUE or BOOSTER.

I think EMUTOS 192K might not even support alt-ram ? Can't remember.

But either way I normally wire CE to your 16mhz decoder/booster and it all works fine. Just not on the DST1. I don't know enough about how all this works to draw any conclusions. As mentioned I did try with/without CE connected.

My boosters always decode 104 & 206 space. I think BW did not add 104 decoding as you really need TOS206 for alt-ram usage.

[Steve]

Ah okay so that explains it, it would need to be able to do 104 decoding for my 6chip STm to work. (I don't have knowledge on how to convert it to a 2xTOS machine, but thats besides the point) If it were a trivial thing to add support for 104 decoding I'd appreciate it (and others probably too).

BTW When I said earlier about 'something should decode it' yes I was meaning the Glue. I assumed the Glue would just decode the 6xchip emutos. But I shouldn't assume for things I don't fully know about

[exxos]

I assumed the Glue would just decode the 6xchip emutos. But I shouldn't assume for things I don't fully know about

The GLUE will decode the 192K EMUTOS. But the DSTB1 won't.

GLUE will not decode TOS206 or 256K EMUTOS. But the DSTB1 will.

This is why you need a DUALTOS board so you can hook up the CE line to it.

[Steve]

I fully get all that you've just written. So if the glue should just decode my 6x emutos no issues, why would Emutos crash on boot with the CE line *not connected* to the DST1. Is it because the glue is disabled when the DST1 is plugged in? Or just that the decoding absolutely has to be on the DST1 no matter what.

[exxos]

I fully get all that you've just written. So if the glue should just decode my 6x emutos no issues, why would Emutos crash on boot with the CE line *not connected* to the DST1. Is it because the glue is disabled when the DST1 is plugged in? Or just that the decoding absolutely has to be on the DST1 no matter what.

You kinda lost me.. I'm not really sure where you're connecting CE to on a ST or how you're disabling the GLUE decoding for the CE on the DSTB1 without a dualtos board.

If you forget the TP1 on the DSTB1, EMUTOS 192K should boot with the GLUE doing the decoding just fine. If it's not booting I suggest you take out the booster and put back the 68K as sounds like your ROM is corrupted or has a bad connection. Trying to debug the booster and CE stuff is just complicating things if your machine isn't running as stock 192K ROMs to start with.

EDIT:
Sounds like you are trying to do this on a STM ? That's going to be hard going to use 6 chip TOS with the CE being driven from the booster as there is no simple way to break GLUE driving the 3 ROM select lines. It's easier on a STFM as you have a LS11 in the way normally. Even so, I think it would be easier to plug in a dualtos board and use EMUTOS 256K or TOS206 in ROM. I'm sure BW can add in TOS104 decoding as well, but I don't think TOS104 works with alt-ram very easily anyway (or at all, can't remember) .

[Steve]

Yeah that's fine if he adds T104 decoding, I don't need alt ram in tos104 so it doesn't matter if it doesn't work for 104. Like I say I'm using 6xchip EmuTOS 192k (I'm guessing t104 decoding is required for 6xchip 192k EmuTOS) Yep using short-ST(m) with my own generated CE line via diodes.

[Badwolf]

You'll have to explain a bit more about your memory layout & your hardware, I'm afraid.

If you're using a 192k EmuTOS in 6 chip configuration with the base address of 0xFC0000, then you don't need the OE line.

TP1 doesn't drive open drain -- it expects a dedicated OE/CE line -- so connecting it to an OE line that is also driven by GLUE will be bad mojo and why you get a white screen.

Perhaps that should be driven open drain, but one of the test pads doesn't have a pull-up (and the specified 10k pull-up would likely be inadequate), so that may not be much use anyway.

...and like Exxos says -- 6 chip TOS would need 6 decode lines. Ain't going to happen with only five test points.

Going back to the first error: if EmuTOS is getting to the point it can crash, that means the decoding seems to be working using GLUE alone. The real issue is the crash, then. Does tying the 8MHz select line (TP3) to ground and resetting alieviate any errrors?

NB. I don't think 192k EmuTOS supports AltRAM, although it can be built to (see my STFM dualtos video), if you remove some stuff you don't need.

Cheers,

BW