REV 3 - REV 5 - The beginning (ST536)

[agranlund]

@agranlund I was wondering if MAPROM.PRG could check the OS version and use that to autoconfigure how to set the caching. TOS 2.06 would have the brain-dead setting, EmuTOS etc. could have the full-fat caching enabled.

@stephen_usher, it could, maybe it should?
It's already looking at the Tos version to make a less risky decision on what and how much of low ram it should remap to altram so I don't think it would be too much work to do what you suggest.

I like it.
Not 100% sure it how it should actually treat Tos206 though.
If it was a product then I think catering for the lowest common denominator would be the sensible way to go, even if it means crippling the higher ones.

I'm thinking about the cases where you actually can run Tos206 somewhat successfully even with caches enabled?
If it always sets up the MMU to inhibit caching of st-ram on Tos206 then it can't be enabled (easily, by a user anyway)
I always try to make a point of disabling caches for Tos206 - it's the safe thing to do and it reduces the risk of me becoming a tech support.
My own machine is able to run most things in Tos206 with caches enabled because I don't really use DMA devices..

Settings are probably the way to go? But in lieu of that, I'm not sure what's the best:

1) cache inhibit ST-Ram always on Tos206, safest for most, but then no-one can toggle it on.
(the upshot being that since the cache option wouldn't effect st-ram, then tt-ram can be cached)

2) not cache inhibited by maprom, requires users of floppy (maybe other DMA devices) to remember to have cache disabled in Tos206.
(but then they'd disable tt-ram cache too, which might not be strictly necessary)

But then again, maybe it's best if the Github version is by default configured as the safest but slowest option.
I could note in the readme that you can always recompile it with x or y enabled for better performance if you're adventurous :)

[exxos]

There are already 2 versions of maprom, the user has to have one or the other in AUTO anyway. So why just just let the user copy the version they want to use ?

[agranlund]

There are already 2 versions of maprom, the user has to have one or the other in AUTO anyway. So why just just let the user copy the version they want to use ?

Yeah, it's just annoying to rebuild multiple versions :lol:
(and then the same again for fastram.prg which is the same program just with the rom->ram mapping disabled)

But you have me convinced :)
I will upload the 1.9 sources with the st-ram cache inhibit behind a compile time flag.
I'll just rebuild and upload separate binaries for the different option combinations, it's not like it's updated that often anyway.

[stephen_usher]

I’d say that using TOS 2.06 with a 68030 is a broken configuration anyway and just by luck works, so limiting memory caching to TT-RAM is a valid response.

A more intelligent non-cache map, where only RAM which could possibly be used for DMA has cache disabled, would require more work but improve performance. i.e. memory we know is used only by the system, such as system variables. The only other way would be to have a terminate and stay resident program with the translation tables catching access to the DMA-able hardware and dynamically flushing caches and set the target memory to being non-cachable whilst the DMA operation took place and restoring it again later.

But that’s a lot of work just to make TOS 2.06 viable.

[Badwolf]

Exxos has beaten me to it, but if you went down the vasm route rather than devpac a Makefile could spit both out simultaneously.


Original:-

If it was a product then I think catering for the lowest common denominator would be the sensible way to go, even if it means crippling the higher ones.

Are you into the territory of MAPROM.PRG and MAPROM_C.PRG?

An EmuTOS or *cough* TOS4 user would very much like the _C variant throughout whereas a TOS2 user may want it one way one day and the other on another and have both in their AUTO folder/bootmanager.

BW

[exxos]

This is why I mentioned a tos patch for 206 to flush the caches. With maprom 206 works fine. Its only now a problem because of STram cache, So IMO it may be more benifical to spend time on a tos patch than spending time on multiple variations of maprom etc

[agranlund]

Exxos has beaten me to it, but if you went down the vasm route rather than devpac a Makefile could spit both out simultaneously.

I know, right? :lol:

When I got my Atari running, and it's not that long ago, I was all excited to finally be "smart" enough to use Devpac and do the work on the Atari itself. For me, it was much more about that experience than anything else.
I was a young kid last time I had used the machine and Devpac was some kind of black magic to me back then :)
In hindsight, yeah it would for sure be much more sensible to do differently. Like make it in C and cross compile on the Mac.

Are you into the territory of MAPROM.PRG and MAPROM_C.PRG?

An EmuTOS or *cough* TOS4 user would very much like the _C variant throughout whereas a TOS2 user may want it one way one day and the other on another and have both in their AUTO folder/bootmanager.

Yeah something like that. I think it's fine to build a couple of different binaries manually, I don't think those asm maprom sources will be changed very often by me anyway.
The compile time options aren't that many but it'll add up if you start combining.

Theres:
Relocate ROM -> Fastram
Relocate LowRam -> Fastram
Cache-inhibit ST-RAM

You could have them all disabled as well I suppose, and just use it to give Tos206 fastram access (and the FRB buffer).
All this is fine when it was my own little "do everything program" but starts to fall apart as a proper program meant for many :lol:
A remake should probably have runtime options instead.

[Badwolf]

This is why I mentioned a tos patch for 206 to flush the caches. With maprom 206 works fine. Its only now a problem because of STram cache, So IMO it may be more benifical to spend time on a tos patch than spending time on multiple variations of maprom etc

@thorsten.otto is the TOS guru, I believe. Should we crowdfund him an ST536 so he has a reason to work on a cache-flushing TOS206 patch that could be folded into MAPROM? ;)

BW

[Badwolf]

When I got my Atari running, and it's not that long ago, I was all excited to finally be "smart" enough to use Devpac and do the work on the Atari itself. For me, it was much more about that experience than anything else.
I was a young kid last time I had used the machine and Devpac was some kind of black magic to me back then :)
In hindsight, yeah it would for sure be much more sensible to do differently. Like make it in C and cross compile on the Mac.

Nearly a me too! The primary motivating factor for me building DFB1 was to be able to do software development in vivo, as it were. My MiNT install is perfectly up to it now for C projects, but it's the quality of the text editor I miss when doing it like that.

For somethign like MAPROM, that really needs a reboot to test it out, dev on the test machine is a chore, though.

BTW, idly fiddling with this: to get MAPROM building with vasm, all I needed to do was indent the SECTION commands and remove a .w from an addq. :)

Code: Select all

sed -i "s/^section/    section/"  *.S

Code: Select all

#Makefile
VASM=vasmm68k_mot
TARGET=maprom.prg

all: maprom

clean:
        rm -f *.o $(TARGET)

maprom:
        $(VASM) -Ftos -devpac -tos-flags=0 -monst MAPROM.S -o $(TARGET)

BW

[agranlund]

BTW, idly fiddling with this: to get MAPROM building with vasm, all I needed to do was indent the SECTION commands and remove a .w from an addq. :)

Tag, you're it!
I'm transferring ownership of the Github repo to you :lol:

(no, but seriously, that's great actually! That'll make it less cumbersome than Devpac for sure :))
That asm code is the result of someone starting with 0 knowledge of 68k assembly. Not assembly in general, but a huge lack of knowledge about this specific instruction set. I'm sure it's full of fun stuff, I dare not look at it in too much detail nowadays :)