exxos's Atari, Amiga & retro forum

exxos wrote: 28 Jul 2021 17:07

Badwolf wrote: 28 Jul 2021 16:40 https://github.com/agranlund/tftools/bl ... C/MAPROM.S

I don't remember exactly, but i think TOS does jumps to specific ROM locations , rather than jumps to labels or whatever. So the patch table has a list of addresses to patch.. Which varies on TOS version, language etc so it pretty much renders maprom useless as it uses the patch tables PP created.

Forgive me if I'm wrong, but I thought the whole point of MapROM's approach was to avoid sticky patches like that.

It uses the MMU to redirect the processor directly to the 'real' address even when the code thinks it's in ROM-space.

So TOS asks for 00E00030 (say). The CPU transparently serves what's at 00010074030 (for example). TOS is none the wiser nor does it need to be.

The crucial thing is that the data at (the real) 00E00030 to the DMA controller is what's at (the virtual) 00E00030 (really 00010073030) to the CPU, else confusion abounds. Because MapROM actually copies from 00E00000 to AltRAM, that shouldn't be a problem, though.

BW

@exxos I think the only OS for the ST/TT/Falcon etc. still being developed is EmuTOS & they seem genuinely interested in supporting other developments too.

Maybe they can offer some advice if not actual changes to help with at least some of these issues?

From their mailing list they do seem to have a range of h/w including 030-based (TTs & Falcons) so getting a build of EmuTOS running in RAM should be possible.

I will have a look to see what build environment I can set up to build their code & see if there's anything suitable as a starting point. Won't be before the weekend though...yet more Flash memory supply issues to overcome first.

:cry: :pullhair: :headbang: :cussing:

JezC wrote: 28 Jul 2021 17:26 From their mailing list they do seem to have a range of h/w including 030-based (TTs & Falcons) so getting a build of EmuTOS running in RAM should be possible.

The PRG version, for example, clearly must reside in RAM.

BW

Yes...and I've been using a pre-v1 build on my H4 with TF536 in the past (with some success), so the potential is definitely there.

I want to make some tweaks to it for my own weird purposes :twisted: so I'm hoping that will get me started in the right direction for checking on future exxos/TF developments for the ST family...

The latest feedback I have is that of floppy issues when running from fastram, which have mostly been cured by using an IMP DMA in the H5. There are still a couple of oddities, I get directory file name corruption using EmuTOS with maprom 1.8e but files are accessed ok but this corruption disappeared when using the same version of msprom and the IMP DMA with tos2.06.

I've not tested it with ultrasatan as yet, which might be a different issue.
Tos2.06 will search for TT ram if booted directly after EmuTOS without a power down and does seem to work very well like that, so maybe a patch to enable TT ram as standard with tos2.06 would be a good idea? (I yjink @Icky may have already done some of this?)

Yep. I have been dabbling with it but again no time and too many projects. I think we got it to boot and TT ram was recognised.

Have I got this right? The issue only occurs when all the below are true?

• H5
• TF536
• TOS/EmuTOS onboard but mapped to fastram at boot
• Undergoing DMA transfers

If so, then the obvious thing would a timing issue in bus arb when the 030 is at 50MHz and it's treading on data bus toes (if the OS in ROM, the 030 would likely be running at 8MHz during handover).

Skipping MAPROM and running the EmuTOS PRG version from fastram should exhibit the same behaviour. If it doesn't it's unlikely to be that theory.

BW

@Badwolf https://www.exxosforum.co.uk/forum/viewt ... 370#p63982

exxos wrote: 28 Jul 2021 19:07 @Badwolf https://www.exxosforum.co.uk/forum/viewt ... 370#p63982

Huu... Cache dependency is odd.

Otherwise I'd be thinking about slightly different (ns-level) chip timings or perhaps enough of a difference between line capacitance on board revisions to have the same effect.

BW

Yeah thing is , the CPU is isolated during DMA access, so the DMA shouldn't affect anything cpu related as GLUE takes care of all that. Even so, I've got fast bus isolators on the rev5 so the DMA cycles are isolated twice. I've tried various delays around DMA access to no avail.

The only thing I've not looked into is the sound decoding. Oddly it seems to work fine, but on my SEC booster I had to decode the sound address as its DTACK control is really bad. But not sure if that would cause the issues with the DMA anyway.