Just some rambling thoughts...
(And the next paragraph is not a criticism of VTL, just using it as an example)
For those who build our own systems, we often see code we fancy running, so set about porting it. not always easy - e.g. VTL2C fixes the ZP usage to $80 through $8F... Well, $90 through $FF is used in my own system, so I thought it might be easy to relocate it from $00 through $7F, but no.... Elsewhere in the code the start address in hard-coded into it as $80. After I found that it still didn't appear to do the right thing, so gave up.
Then there are systems which map hardware into Zero Page, depriving you of those precious locations... (W65C134-SXB I'm glaring directly at you, here!) not sure how/if VTL might work there when locations $00 through $2F are taken up by the hardware... (And after the existing monitor ROM wastes some 90% of the rest, I suspect VTL would never run on it)
By contrast, making the 2.22p5C02 version of EhBASIC run was relatively easy - one define for the start of all ZP variables and a couple of specific external calls to patch in and off it went. Same for the pagetable.org portings of other Microsoft Basics. BBC Basic is harder because it demands an operating system (not your rinky dinky little
monitor here, oh no ...)
Some folks also write new code and in doing so, it's easy to get caught in the trap of making it very system specific - which is fine if it's just for you in your own specific system with it's unique hardware, etc. but sometimes it's good to share...
Recently I wrote/ported/re-wrote a TinyBasic to the 6502 and I initially thought it might be easy to port to other systems - put the system specific stuff in one file and off you go...
Turns out it's not that easy as I've recently found out when trying to port it to another system (W65C134-SXB). Slightly less easy in that I decided I was after two different versions to run at different addresses (one in RAM using the existing monitors IO routines) the other in ROM using it's own IO routines. Each version had different amounts of zero page available to it too (the existing monitor ROM uses a lot of ZP, my monitor just 6 bytes) so I was able to select which data to move out of ZP (obviously not pointers, but the aim was to pack as much data into ZP as possible as ZP = speed and fractionally smaller code)
And so I've spent some time thinking about it and making the project easier to port - at least I hope I have. The trouble is, I'm an old Unix hack, so massaging Makefiles and copying template files to platform specific files, fiddling with linkers configurations is utterly trivial to me, but what about newbs who only have MS Win or Mac experience?
It all starts to get a bit hard... And right now to port my TinyBasic to a new platform requires:
- Linker config file: Create a new one (copy existing, change) Has parameters for load address, size of ZP and location of secondary "overflow" data and (optionally) start of Basic program text location.
- Platform specific data.s file: Create a new one (copy existing, change) to define ZP and "overflow" variables.
- Platform specific data.h file: Because I can't work out a better way to do it with ca65.
- Platform specific startup file: Defines the main calls needed like character IO and so on.
- Finally edit the Makefile.
It seems to have gone from something seemingly trivial to somewhat complex and what about the people who are using MS windows? Or even those who want to use a different assembler?
Have I over thought it?
Right now I don't have easy answers to this ... In years gone by I've been involved in projects that were designed to be cross-platform (we're really talking different Unixes and big C programs here) and even today this isn't a properly "solved" problem. (Fritzing I'd pay you money and keep on using you, but
your Linux software no-longer works on
my Linux system, so ...) We while we have autoconf, make, cmake, and so-on, there are still unsolved issues.
Do we go back to the bad old days of distributing binaries that you can then load into your own system and "patch" to change the addresses of the IO ports, subroutines and so on? (And what about relocation?) I'm not sure which is easier now...
Thoughts welcome.
-Gordon