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

_________________
--
Gordon Henderson.
See my Ruby 6502 and 65816 SBC projects here: https://projects.drogon.net/ruby/

Thoughts will be given!



How old?! I've been using Linux nearly exclusively for over 20 years now, and I have yet to have a single 'make' work for me! Massaging make files, fiddling with linkers, wow, I thought I was alright but apparently not. So, in a way, maybe I'm showing you that even adept/journeyman Linux users would still struggle with make files and the like.



Honestly, for TinyBASIC and other things, I would say, "Yes." If you gave me 6502 code with BASIC on it, and made it clear at the top where you have your in's and out's, how it's expected to act under conditions (i.e. ASCII), etc, then golly I think that'd be fairly easy for me to alter some addresses and make a couple sub-routines to get my character I/O to match yours. I'd honestly like to try and see if I could get it to work.

On the flip side, BASIC is far different than Tetris. I can port *my* Tetris to *my* other systems because they all use the same graphics systems. It's trivially easy because it's all my own stuff and I designed it to be copies of previous models with only slight improvements. But port my Tetris to the C64 or the Beeb or something? That'd be a disaster. There are no easy character I/O sub-routines to fix that mess.

If you wanted to run 6502 applications on Linux/Mac/Windows though, a simulator/emulator would be best. I made my own, and that's how I develop my games MUCH faster than going back and forth all the time with ROM chips or SD cards. For that, I use C++ and OpenGL, and I can guarantee it will work on both Windows and Linux, probably Mac also. But I don't think that's the kind of "porting" you were thinking about here.

Thanks for the discussion Gordon!

Chad

Well, some 43 years Unix experience and counting. I first touched Unix in 1980 at uni. a PDP-11/40. Amazing to think it supported 6 terminals a line printer and system console with a 16-bit CPU running in single-digit MHz with 128K of core ... (<Four Yorkshiremen/>)

I've also been involved with bare-metal things on various microcontrollers, and other systems over the years when you need to know stuff like how the linker works and where code and data are expected to be, so ...



Binary patching?

the main issue I have with this TinyBasic is the zero page usage. I thought I'd be OK until I met the W65C134-SXB. In some cases I wish I'd never met it at all. Another issue is other systems I have, love and use - e.g. Apple II as I've looked at getting it going there too. The BBC Micro will be trivial when I get round to it as my RubyOS mimics the Acorn MOS, but the Apple II has quite a creative use of zero page, so fitting something in there is always interesting. I've absolutely no idea about the PET, C64, etc.

The SXB leaves little ZP for user programs - some is taken up by hardware too, so I replaced the on-board ROM with my own which uses no more than 8 bytes. (so 2 for the price of 1...) But to get that into EEPROM I need to boostrap a RAM version which does use the on-board ROM, so I had to work out a way to have a 'core' set of ZP locations (pointers, etc.) and data that can live outside ZP - slower, more code, but workable.

The cc65 suite is quite clever in that respect - I can define segments and place them in different areas as well as specifying the location and size of those areas...

So everyone who has made their own system is different and it's not just as simple as patching the IO calls.

(And I'm in the process of designing/building another 6502 system purely to run TinyBasic and nothing else and that's going to be different again although at least I'll have 100% control over it)



ROM chips and SD cards? Well back in 1982 or so I was developing code for a real-time blood analysis machine - it was 8080 based - the first thing we did was buy a 16KB RAM board for it and then we developed code on a Northstar Horizon and download via serial and ran it from RAM.. Only every now and then would we burn EPROMs for it - just to make sure we were still on the right track. Today I work the same way - I assemble the code on my desktop and download via serial... Even on my Ruby board which I designed to support self development, but I don't currently have a good assembler for it - I'd end up using BBC Basic and I never really got on with that, even though I've used it to write a lot of code with - I always had what seemed like nicer tools on the Apple II (Which I'd use then copy over serial to the target system, ...) Same for Ruby - I'd write an assembler for it, but I'm not sure I can better ca65 ...

Cheers,

-Gordon

_________________
--
Gordon Henderson.
See my Ruby 6502 and 65816 SBC projects here: https://projects.drogon.net/ruby/

When I ported VTL-2 from the 6800, I had a main goal, and that was to make the binary footprint as small as possible. I found that in doing this I was going to need to occupy half each of pages zero, one, and two, and a bit less than four pages of executable. The emulated Apple 1 was my initial host, and it is nearly wide-open, with WOZMON only needing a handful of ZP locations and the same page 2 usage as VTL. The emulated Apple ][ was a friendlier debugging environment, and as long as I stayed away from either ROM BASIC I had no problems with keeping the allocations the same.

So ... where does that leave an adventurer who wants to try my code on his or her hardware? I tried to liberally comment the source with this in mind, but my skills in this area are amateurish, since I have coded only as a hobby, never for a paycheck. I have helped Ed fiddle with it enough to get it running on the Beeb, and several other above-average minds have done similarly, with little or no help from me. For ZP usage, the following section describes the situation to the best of my abilities, and in spite of that it was exactly where Ed needed a bit of help:
I should mention the simple: code in the comments above the ZP equates. I have already changed the "PEEK" and "POKE" comments for better visibilty, after Dave Hassler went and wrote his own add-ons because he didn't realize that mine were built-in and patiently waiting to be used.

_________________
Got a kilobyte lying fallow in your 65xx's memory map? Sprinkle some VTL02C on it and see how it grows on you!

Mike B. (about me) (learning how to github)

When developing PLASMA, I knew I wanted it to run on at least three platforms: Apples 1, II, and ///. In the last iteration, I wanted to to be ported to potentially any 6502 based platform. To this end, I made two decisions to accommodate portability:

1. All zero page usage in a single include file. As a VM, only the VM proper and assembly code modules would need to be aware of the ZP usage. Of course, depending on the platform, ZP is a minefield. My initial Apple targets were easy because I targeted ProDOS/SOS which have a minimal ZP footprint. If I were to include Apple DOS, there would be more shucking and jiving to work around its seemingly random choice of ZP usage (mostly working around the random choice of BASIC usage).

2. Relocatable modules. The Apple II forced me to consider a memory layout that could be drastically different if a given graphics mode was activated. Woz's genius in 1977 was to provide a hires graphics mode even if there was only 16K of memory. Unfortunately, this also placed the hires graphics in the middle of the memory map. Relocatable modules and special flags that can reserve certain areas in the memory map relieve the pressure of hard-coded addresses in the binaries. Another benefit is the ability to place bytecode in auxiliary/extended memory, freeing up main memory for data and native code. The 128K apple //e and Apple /// both load bytecode into memory that is usually hard to access from 6502 code.

The platforms that PLASMA has been successfully ported to include the Apples mentioned above and the Beeb. I did start a port to the C64, but has languished due to my disdain for its slow and rudimentary disk subsystem. PLASMA does better with a more sophisticated and faster DOS. PLASMA does have the ability to build a single binary blob including the VM and bytecode, but this is pretty platform specific.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

I'll post my rambling thoughts too! I've been thinking a lot lately on how to make my program as noob-friendly as possible to install.

Between 'porting code' and 'writing code to be ported', I want to take a two-prong approach for my BBC BASIC project:

1. Port it to the most popular breadboard - For this I chose the Ben Eater 6502.
2. Make a stripped-down minimal version of the port - This would be designed for those who want to use the code as a foundation to write their own extensions. They could freely look at my Ben Eater version code for guidance.

I had a think about CC65 and LLVM-MOS, but those seem like huge cans of worms for those who may not be familiar with C or C++.

I just had an idea: What if there was a web-based tool that would generate a binary based on your chosen preferences (e.g. memory ranges, ACIA/VIA locations)? I think that would be the ultimate noob-friendly way to install a 6502 program.

_________________
----------------------

BeebEater - BBC BASIC for the Ben Eater 6502: https://github.com/chelsea6502/BeebEater

"noob-friendly" is the Arduino IDE (which now targets many things like ARMs/Pi Pico and many others) and that's written in Java. The upgrade from that is drag and drop from your desktop to the 6502 - that's what the Pico / 6502 people are looking at from what I can tell.

Web based makes it harder to access your local filing system, but it's used by MS for the BBC Micro:Bit thing (and others). Might be browser specific though.

My dislike of things like that is that I lose my nice editor and my 40+ years of making modular code and using Makefiles. That may not be an issue for younger folks though.

But what I'm realising (should have known/guessed really) is that the 6502 eco-system is hugely diverse and varied. There is, and never will be a one size fits all solution - I like the ca65 assembler because it works the way I do - allows me to write small modular files and link them together - just what I've been doing for the past 40+ years... (Including other CPUs at the bring-up/assembler level, not just big C projects).

So I think we just need to make it as easy as possible for others to adapt the code to their systems as required - not be too fixed about ZP locations and make it easy for others to adapt as needs...

-Gordon

_________________
--
Gordon Henderson.
See my Ruby 6502 and 65816 SBC projects here: https://projects.drogon.net/ruby/

Sorry, I meant to reply in this thread earlier, just to say thanks for making the improvements. My main problems initially porting GIBL were having to modify quite a few different places in the code, it not being completely clear how flexible the memory map was (or wasn't) - and my lack of understanding about how ca65 works at all, never having used it. The last one is 100% on me - sure it's a bit different in a few ways to most assemblers, and yes it tripped me up (mostly, the stack being in the way), but at least getting GIBL to work made me want to take the time to learn ca65 properly, as it seems very useful, especially things like automatic allocation of non-conflicting zero page addresses, I see a lot of potential there. However, I still haven't found the time!

The other points could be (and have been) improved with changes to GIBL and the documentation, but it's 100% reasonable especially in early stages not to have done that - early adopters do need to be willing to do some legwork! To some extent as an author you find out what needs to change or be documented based on user feedback, and after that it depends on your degree of appetite to actually improve things - and many things never see any significant interest from others, so putting a lot of effort into making them reusable is wasteful, unless you enjoy that process in itself.

And in general, given that most 6502 work being discussed and shared is hobbyist work not done for financial gain, I can't see a world where there's any real standardization over it. As with most open source communities, there are many different styles, I wouldn't say any is categorically the best. There's also no one-size-fits-all ABI partly due to the limited nature of the platform. So for most of my work I am happy to share it, but if you want to use it you'll probably need to read, understand, and adapt it to your needs.

Certainly though, random use of hardcoded zero page addresses should be discouraged, and as a matter of course I try to declare them with obvious variable names (prefixed with "zp"), and where I intend library code to be reused between projects, I either require the caller to provide the variable definition, or I allow the caller to determine where in memory it's going to go (e.g. my FAT32 driver needs some zero page workspace and some general workspace, and the caller has to provide the base addresses for each of these). ca65's approach seems a much better way to manage this.

I think that's more important than many realise - once upon a time I was very into open source and published lots of code on github, and my own GIT platform, etc. which was used by millions of people. However unlike the clever ones I gave users of my code support in the early days and chatted on forums, social media, etc. accepted hardware to port my code to, etc., but latterly when companies stole my code (it was mostly GPLv3) then expected me to support them without pay, it became such a burden that I had no choice but to turn my back on it all. I even asked for help but got nothing back, so the whole episode left me feeling very bitter towards open source and the so-called "community", so it's somewhere I'll not go again.

So now I have to be careful - I'll do what I can but it's mostly for me and my own satisfaction (I've ported GIBL to 3 platforms now with a 4th soon)

So don't feel bad if you try to get in-touch with me about GIBL, or indeed any others who support openly published code - they may not have the time or inclination to reply - especially the ones doing the social media thing at the same time.

-Gordon

_________________
--
Gordon Henderson.
See my Ruby 6502 and 65816 SBC projects here: https://projects.drogon.net/ruby/