Richard Smith smithbone@gmail.com writes:
Thinking about ADLO and the shadow enable/disable got some wheels turning.
I've been spending lots of time in V2 and I was wondering if the same type of methodology can't work for ADLO.
In V2 there are specifc .c files that do thing in a chipset specific way and the auto.c includes them as necesary. Those get compiled and then stuck in the startup assembly.
What if we created a shadow.c file that was in the northbridge directory with a simple API type setup that enabled and disabled the various shadow ranges.
That is a fairly sane way to get code sharing, if we need it. The code is small enough and simple enough cut-and-paste code sharing is probably just as good. All you need to do is look at which chipset you are running on. We only need to drop out support if it becomes too much code having support for all of the chipsets and cpus.
But I actually think that is overkill. v2 by default and design enables all of the shadow ranges as memory. So we just need to use those ranges. That should be much easier having to patch ADLO each time. It is fairly unlikely a writable ROM segment is going to break anything.
Once we find the application a writable rom segment breaks I will be happy to reconsider, solutions.
I suppose that that FILO and the emulator render most of ADLO un-needed but if you are going to try and use FreeDOS or Windoze as an OS then you will need ADLO.
ADLO has a use case and for those
Eric