I have to disagree to some extent. Assembly is generally done a source file at a time. In some environments, assembly just to accommodate a change in a kernel jump table would become very tedious if a lot of software is involved. I've been there and done that multiple times over the years.

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

I once scanned through an Apple ProDos programming manual. They had a slightly different approach to a single-entry point BIOS. Their calls looked something like this, IIRC:


The idea being that from the address the JSR pushed on the stack it was possible to create a pointer to the arguments immediately following. Those could be either constants or a pointer to something (a variable, a block of variables, an i/o location, whatever).

The BIOS would take care of reading the arguments and updating the return address to point past them. No need for the programmer to worry about saving or restoring registers.

Although it still seems easier to load the accumulator with a value you went sent to output, rather than put that value somewhere and point an API call at it. I never programmed ProDos, so I don't know ultimately how easy it was to work with.

Did anyone see the post about SourceForge? XD

Seriously though, should I put up a Git repo for the community to contribute to?

_________________
It may look hard, but it won't take long if you take it one byte at a time.

Yes.

I use INCLude statements which bring the other needed source-code files in, then only mention the main source-code file when calling the assembler. I have a friend who, until he retired recently, managed software projects so huge and involving so many programmers that they took around 24 hours to re-compile. What we do with our 65xx efforts will assemble the whole thing in a few seconds.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

That procedure is analogous to Commodore's PRIMM (PRint IMMediate) kernel subroutine in the C-128, in which the null-terminated character string to be printed follows the JSR PRIMM. That's good for API calls where the data location is known at assembly time, but becomes a programming headache if the data location has to be computed at run-time.

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

As do I. However, the main source file for each program has to be submitted to the assembler. Currently I have 13 separate programs that I have written for POC, each of which would have to be reassembled if I changed the BIOS jump table. It would take some time, since the actual assembly processing time is only part of the total time needed.


I have had experiences like that, although not involving multiple programmers. Back when I wrote a truck leasing and billing system for the Commodore 128 running on a Lt. Kernal hard drive subsystem I was working with around 100,000 lines of code. Assembly of the entire mess took about 8 hours. Needless to say, I did my best to avoid making any changes that would have required full reassembly. Once it was all working changes could often be made to a few source files and only those would require reassembly, reducing the development cycle time quite a bit.

I just ran POC's BIOS through the assembler to see how long it would take to assemble it. It took about 5 seconds to run through 12,218 source lines. The program that I am working on that generates an S51K filesystem analog takes about 8 seconds to assemble, and runs to nearly 20,000 lines spread out through a bunch of INCLUDE files. And I'm not even finished with it!

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

I've used ca65 for assembly. It can assemble into object files that can be linked at a later time, so you can split up a project into different files. You can also use include files to combine several sources into a single program. Having lots of different programs doesn't have to be a problem either. You can have a makefile that automatically rebuilds any number of programs, just add a rule for each program. You can even set up rules to combine all the binaries into a disk/eprom image and actually program the system (as long as all your tools are command line, and don't require mouse interaction). Most of my projects have a 'make prog' target, that will build the project, and upon success, burn it into the flash, so that's all I need to type to test out any code changes.

I don't know if anybody wants to contribute actual code, but just having the option to read all the code can be useful. I don't know sourceforge, but I know several people here that use github, myself included: https://github.com/Arlet

The problem is that these are utility calls, not "transparent" interrupts. Some of them need to return values, and the best place for that would be in registers.

Sure, you could shove return values into the stack space that will be popped, but that's a lot fiddlier than it needs to be. However, I do agree that the BIOS should preserve registers that are not directly used as input or output.

_________________
WFDis Interactive 6502 Disassembler
AcheronVM: A Reconfigurable 16-bit Virtual CPU for the 6502 Microprocessor

Good point.


The nice thing about using the stack is that you don't need variables space. The "variables" are on the stack, and when they're no longer needed, they cease taking any memory. Having a separate data stack in ZP makes it a lot less fiddly.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

It's always best to do your development in the open - I'd recommend github rather than sourceforge, as sourceforge seems to be dying, and google code is also dead. There are other places, but github seems presently to be the popular choice.

Github it is then

_________________
It may look hard, but it won't take long if you take it one byte at a time.

No question that overwriting stack copies of registers is fiddly with the 65C02. It's a very simple process with the 65C816, involving use of the ,S addressing mode to replace the pushed register value with a new one. I use that procedure all the time.

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

That will work as long as the function being called doesn't have to be recursive/reentrant.

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