bug65: cc65 simulator + debugger for Visual Studio Code

[barnacle]

vbc wrote:

To run from ROM you can add a memory region "rom", analogous to the "ram" you currently have in vlink.cmd. Then modify the entry for the data section like this

Code: Select all

  data:   {*(data)} >ram AT>rom

Now you can define some more symbols in the linker file:

Code: Select all

  __DS = ADDR(data);
  __DE = ADDR(data) + SIZEOF(data);
  __DC = LOADADDR(data);

The startup code has to be extended to fill the RAM from __DS to __DE with the contents from ROM starting at __DC.

I don't know if you need some additional hardware initializations or interrupt vectors.

Thanks; I'm getting further. But as I understand (quite probably incorrectly) your comment above, the code in rom will be moved to ram to execute? I can't e.g. put a monitor or a bios written in C in the rom and execute directly from there?

Also, I haven't yet found where/how to change the startup code. Section 16.4.1 of the manual suggests:

16.4.1 wrote:

The startup is usually split into two parts. The first part is done by assembly code that produces the object file lib/startup.o. This assembly code is usually provided with vbcc and may have to be adapted to the hardware you are using.

but I haven't yet found it. Probably I'm not yet looking in the right place. Similarly, I'm still looking to see where the IO source code is (I assume at present its precompiled into libvc.a?)

Can I repeat the compliments expressed earlier: in particular, it's hard to see how much more could be chopped of the code generator for

Code: Select all

void cout (char ch)
{
    // output single character to serial port
    while ((* (volatile char *)ACIASTATUS & 2) == 0)
    { /* wait */ }
    * (volatile char *) ACIADATA = ch;
}

which produces

Code: Select all

_cout:
	lda	sp
	bne	l8
	dec	sp+1
l8:
	dec	sp
l3:
l4:
; volatile barrier
	lda	32768
	and	#2
	beq	l3
l5:
; volatile barrier
	lda	r0
	sta	32769
l1:
	inc	sp
	bne	l9
	inc	sp+1
l9:
	rts

Many thanks for your efforts, and apologies for pestering

Thinking about it I have two use cases: Firstly, to write C code compiled to run at a base address in low RAM (i.e. normal user programs) and secondly to replace my experimental FAT32 code, with at least the basic file operations in ROM.

The first is easy, once the text input and output are sorted suitable to my system.

Neil

[barnacle]

Aha! I have found libsys.h hiding in /vbcc6502/libsrc and that has some inline code for character in and out:

Code: Select all

unsigned int __write(int,const char *,unsigned int);
unsigned int __read(int,char *,unsigned int);

__regsused("") void __chrout(__reg("a") unsigned char x)="\tinline\n.1:\n\tbit\t$d012\n\tbmi\t.1\n\tsta\t$d012\n\teinline";
//__regsused("") void __chrout(__reg("a") unsigned char x)="\tjsr\t$ffef";
__regsused("") char __chrin(void) = "\tinline\n.1:\n\tlda\t$d011\n\tbpl\t.1\n\tlda\t$d010\n\tand\t#127\n\teinline";

which look simple to convert to talk to my 68B50, and startup.s in the same place.

My limited knowledge of the Apple 1 and a little sleuthing suggests that this is talking to a 6551 or equivalent, so I'm guessing that it's working at whatever baud rate it's previously been set to. I'll probably need to add a small amount of setup to configure the 68B50, perhaps inserted into startup.s.

Note: I have copied

• /vbcc6502/vbcc6502_linux/vbcc/targets/6502-apple1 to /vbcc6502/vbcc6502_linux/vbcc/targets/6502-dnb
• /vbcc6502/vbcc6502_linux/vbcc/config/apple1 to /vbcc6502/Projects/vc.config (my working directory)
• /vbcc6502/libsrc/6502-apple1 to /vbcc6502/libsrc/6502-dnb

and hopefully all my references are correct.

Neil

[vbc]

barnacle wrote:

Thanks; I'm getting further. But as I understand (quite probably incorrectly) your comment above, the code in rom will be moved to ram to execute? I can't e.g. put a monitor or a bios written in C in the rom and execute directly from there?

No, no, the copying is only necessary for the data section, i.e. initialized data. Consider e.g.

Code: Select all

int glob = 123;

int main()
{
  if(glob == 123) ...
  glob++;
  ...
}

Here, glob has to be located in RAM, but is needs to be initialized to 123 before main() is called. When running from RAM you can simply have the 123 in the image at its target location and glob will be initialized automatically when the image is loaded into RAM. When running from ROM, glob has to be initialized by the startup code. Therefore the init data is put into the ROM image and has to be copied by the startup code to the correct RAM area. The user code will always access the RAM location.

If you do not use initialized data or if your code initializes all its data itself, then you do not need this mechanism. Parts of the C library do depend on it however. On a similar vein, if you want to have programs that sit in RAM and can be restarted there without being loaded into RAM again, you basically need this mechanism as well (because after the program finishes, glob has a new value and must be reset again).

For the actual code, it does not really make a difference if it is running from ROM. It just has to be placed at the correct locations.

Quote:

Also, I haven't yet found where/how to change the startup code.

The one you found in libsrc is ok. After you made your changes, compile it to object code (vc -c startup.s) and copy the startup.o over the one in your lib directory.

Quote:

Can I repeat the compliments expressed earlier: in particular, it's hard to see how much more could be chopped of the code generator for

Code: Select all

void cout (char ch)
{
    // output single character to serial port
    while ((* (volatile char *)ACIASTATUS & 2) == 0)
    { /* wait */ }
    * (volatile char *) ACIADATA = ch;
}

which produces

Code: Select all

_cout:
	lda	sp
	bne	l8
	dec	sp+1
l8:
	dec	sp
l3:
l4:
; volatile barrier
	lda	32768
	and	#2
	beq	l3
l5:
; volatile barrier
	lda	r0
	sta	32769
l1:
	inc	sp
	bne	l9
	inc	sp+1
l9:
	rts

Actually, the stack-pointer handling can be easily eliminated. Just use -O or higher. For the 6502, I would always use at least -O. On the 6502 the difference between optimized and unoptimized code is usually even higher than on many other targets. This is what you get with -O:

Code: Select all

_cout:
; volatile barrier
        lda     32768
        and     #2
        bne     l7
l6:
; volatile barrier
        lda     32768
        and     #2
        beq     l6
l7:
; volatile barrier
        lda     r0
        sta     32769
        rts

[barnacle]

Thanks again! I hadn't worked out what was going on in that move. But that's for later, I think.

I just realised I can substitute the commented line

Code: Select all

__regsused("") void __chrout(__reg("a") unsigned char x)="\tjsr\t$ffef";

and replace the call with a jsr to my own bios. Handy.

Neil

[WillisBlackburn]

Quote:

I don't like github, but some kind of better curated source distribution is on my todo list. Of course the problem with todo lists ...

It is possible to acquire a license for commercial use.

I think I posted the links to the sources for vasm and vlink in a previous post.

I would be happy to include Mac binaries in the target distributions. The problem with Mac is that last time I looked it seems you have to have a Mac and/or some developer subscription to build binaries suitable for public distribution. Maybe I will include the sources and a compile script with the binary distributions. But I would not be able to test if it works on a Mac.

Ask yourself what you're hoping to accomplish. It sounds like you want people to use your compiler? But cc65 already is a pretty good compiler. It's up there on GitHub, and anyone can use it. It doesn't have a restrictive license. It compiles and runs on the Mac with no problem. You don't like GitHub and don't have a Mac, but so what? If you want people to use your stuff, you need to meet them where they are and remove barriers to use.

[BigEd]

A lot of people are using gitlab these days as a close analogue of github.

If you really want to retain a no-commercial clause, please make it clear which of these you wish to forbid
- the use of the compiler in a commercial setting
- the use of the compiler to produce a commercial product
- the resale of the compiler, or code derived from the compiler

[WillisBlackburn]

GitLab would also be fine. Some people don't like GitHub because Microsoft or AI or whatever, but what's most important is to be where your potential collaborators are.

[greghol]

WillisBlackburn wrote:

GitLab would also be fine. Some people don't like GitHub because Microsoft or AI or whatever, but what's most important is to be where your potential collaborators are.

Some of the people I interact with are moving to Codeberg which is based in Germany. https://codeberg.org/

Greg

[BigDumbDinosaur]

WillisBlackburn wrote:

vbc wrote:

I don't like github...

You don't like GitHub and don't have a Mac, but so what? If you want people to use your stuff, you need to meet them where they are and remove barriers to use.

I too don’t care for GitHub, and also don’t have a Mac.  I can’t say with any certainty how many people there are who don’t use/like GitHub, but I can say Mac users continue to be a minority in the computing universe.  At this time, it appears that Linux-on-x86 users are likely more numerous than Mac users.

That said, I suspect the reason Dr. Barthelmann (the vb in vbcc) dislikes Github stems from the same things that make others dislike GitHub, the Microsoft aspect being one of them (before Microsoft got their hooks into GitHub, it was okay—now it just plain sucks).  Dr. B has published everything about the vbcc package at an accessible website.  Also, vbcc comes up in numerous search engine results.  Given that, I see no reason for him to maintain a parallel site on GitHub and potentially expose his stuff to surreptitious “borrowing” by Microsoft.

Quote:

But cc65 already is a pretty good compiler.

I beg to differ.  WDC’s C compiler, despite its age, is better, which is not saying a lot.  vbcc is compatible to ISO-1989 and most of ISO-1999—cc65 is a retread of Small C, which is basically a watered-down version of K&R C from 1978.  vbcc is under active development and incorporates contemporary thinking on compiler design—maintenance of cc65 is sporadic, with the most recent release occurring over five years ago.

To date, I have done very little C programming outside of the UNIX/Linux environment—assembly language continues to be my weapon of choice with 65xx hardware.  Also, the eight-bit 65xx MPUs are not good compiler targets.  However, with the development of vbcc, I may start writing some applications for my nascent POC V1.4.1 unit in C, using raw assembly language only where performance matters the most.

greghol wrote:

Some of the people I interact with are moving to Codeberg which is based in Germany.

Membership is not free at Codeberg.  I think I understand why, but I’m not willing to pay someone else to host my work.

[BigEd]

An independent self-built website is a handy thing, but a code repository is also handy, and serves as a backup, in both the short and the long term.

That any particular class of users might be in a minority isn't decisive.

[vbc]

WillisBlackburn wrote:

Ask yourself what you're hoping to accomplish.

I have done that a long time ago and I act accordingly.

Quote:

But cc65 already is a pretty good compiler. It's up there on GitHub, and anyone can use it. It doesn't have a restrictive license. It compiles and runs on the Mac with no problem.

If those are the most important points for you and cc65 satisfies them, then you should be fine. Why would you want another compiler following the same approach?

Quote:

You don't like GitHub and don't have a Mac, but so what? If you want people to use your stuff, you need to meet them where they are and remove barriers to use.

Quote:

The restrictive license would still be an issue, though.

So what you are saying is that I should do stuff that I do not enjoy and perhaps buy hardware that I do not need, in order to make it easier for people who are making money using my tools, but do not want to pay for it? Sorry, that does not really click with me.

[vbc]

BigEd wrote:

A lot of people are using gitlab these days as a close analogue of github.

Thanks for the hints (in other posts as well) regarding hosting sites, but I prefer to keep the version control system for my sources on my own server.

Quote:

If you really want to retain a no-commercial clause, please make it clear which of these you wish to forbid
- the use of the compiler in a commercial setting
- the use of the compiler to produce a commercial product
- the resale of the compiler, or code derived from the compiler

I think most people have a pretty good idea what commercial usage entails, even if there are many edge cases. An exact legal definition that is suitable for all cases (and countries) is likely not possible in my situation (and writing contracts is one of the things I do not enjoy doing). Usually, the terms have to be decided on a case per case basis anyway. Especially in a situation like vbcc where you may a large company with special requests on one hand and some guy planning to develop a game for a retro system where he expects a 50-50 chance of being able to sell a few copies.

Regarding your list, I would say the first two items are classic example of commercial usage. However, I am not sure that wording really makes it much clearer. Resale of the compiler is something else and would require a different license altogether.

[BigDumbDinosaur]

BigEd wrote:

An independent self-built website is a handy thing, but a code repository is also handy, and serves as a backup, in both the short and the long term.

I agree a repository can be handy, especially for someone who doesn’t have the resources and/or desire to self-host his/her work.  However, there is no guarantee that a public repository will be there in the future.  If whomever operating the public repository decides one day that it’s costing too much time and/or money to operate, they can simply “pull the plug” and cut their losses.  If you the repository user don’t have local copies of everything that was on the repository, your work literally vanishes in an eye-blink, and you have no legal recourse whatsoever, unless you have executed a written contract with the repository operator (which will inevitably cost you something) that compels him/her to maintain service.

In the same vein, a repository service can arbitrarily cut off access to one’s work, something that GitHub has done numerous times, mostly for political reasons.  If one is dependent on unimpeded access to a repository to earn an income, that arbitrariness can be disastrous.

There is also a security angle to be considered.  If someone who has no relationship to you, other than acting as a hosting service, is hosting your work, what assurance do you have they are safeguarding it and maintaining site backups should disaster strike at their end?  After all, absent a written and signed contract, the hosting service is under no legal obligation to protect your data.  If a natural disaster destroys their data center and the decision is made to not rebuild, you and others that were using the service will be out of luck—an “act of God” is typically a legally-accepted reason for not honoring the terms of a contract.

Another question: if your repository is private, what are your assurances that the hosting service will not let third parties gain access to your work without your authorization?  This last question in this day and age is of utmost importance, as data theft has become a serious issue.

On the topic of data theft, GitHub is owned and controlled by Microsoft, one of the least-scrupulous of companies involved in the computing industry.  Microsoft has had a long history of misappropriating others’ work, with the goal of profiting from it.  A user of Github has absolutely no guarantee that his/her work is safe from that sort of theft.

Quote:

That any particular class of users might be in a minority isn't decisive.

I agree on that—minority status is but one factor to consider in software design.  That said, if the intent is to create something for gain of some sort, supporting the minority has to be weighed against the possibility that the time and money expended to do so will be all out of proportion to the expected gain.

[BigEd]

Hmm, if one puts one code in a repo as a backup, one isn't demanding that backup lasts forever or even outlasts the original. It's a backup. If it vanishes, try again. Only if both copies are lost is there a problem.

Also noteworthy that sharing one's work in a public repo such as at gitlab does not preclude keeping a local copy also under source control. Which need not be git.

If, on the other hand, a person has decided not to do a thing, there's no need to justify that. I merely wish to point out some tactics which a lot of people find advantageous.

[BigDumbDinosaur]

BigEd wrote:

Hmm,  if one puts one code in a repo as a backup, one isn’t demanding that backup lasts forever or even outlasts the original.  It’s a backup.  If it vanishes, try again.  Only if both copies are lost is there a problem.

Indeed, and such a calamity can occur even with locally-hosted systems.  I strongly urge my clients to religiously back up their systems to tape or RDX cartridge each business night.  Generally, I have them use a double set of tapes or cartridges to maximize redundancy.  LTO tape failures are very rare—mostly caused by mishandling, and the same is true for current-generation RDX cartridges (DDS is somewhat-less reliable—a case in which you only get what you pay for).  Nevertheless, I insist on the double tape/cartridge set, and highly recommend that one of the sets be off-site when the other set is in use.

Aside from being a protection from hardware failure, multiple redundant backups can help with the situation in which a file or directory is deleted or corrupted, and a few days pass before the problem is discovered.  With multiple redundant backups, one may be able to go to an older backup to restore the file or directory.

My main quibble with using a “cloud” service as the primary (or only) archiving strategy is that doing so cheerfully assumes the service will always be available.  Trouble is, if your backup files have to be restored right now and your Internet service, or the “cloud” service, is on the fritz, you’ve got a serious problem.  About six years ago, one of my insurance agency clients, who was using a “cloud” backup service instead of local backups, had that happen to them.

One of their employees accidentally wiped out a directory containing insurance quote work-in-progress files, causing an immediate calamity.  By sheer happenstance, their Internet service provider was experiencing an area-wide outage at that time and my client could not get access to their backups.  Yours truly had to get access to their “cloud” service from my office, download the backup files to one of my servers and copy the files over to an RDX cartridge.

Taking that cartridge and a spare RDX carrier chassis to their office, I was able to restore most of the blitzed files—some were not in the most recent backup, so they were completely lost.  By the time the dust had settled, they had wasted five hours of productivity, as almost everyone in the office was idled until the missing files could be restored.

Since then, this client discontinued the “cloud” backup service and has relied on backups to LTO tape.  Also, I left the RDX carrier installed in their server so a middle-of-the-workday incremental backup could be done to an RDX cartridge during lunch hour.  Doing so further increases the likelihood that an accidentally-deleted file or directory will be immediately recoverable.

Quote:

Also noteworthy that sharing one’s work in a public repo such as at gitlab does not preclude keeping a local copy also under source control. Which need not be git.

True that, although if I were inclined to take that route, I would consider the gitlab repo as the copy, not the original.

Quote:

If, on the other hand, a person has decided not to do a thing, there’s no need to justify that.  I merely wish to point out some tactics which a lot of people find advantageous.

As the old saying goes, whatever floats your boat.    It all comes down to how essential redundancy is to the user.

In my little, dinosaurish brain, one should know the pros and cons associated with any given method of archiving one’s work.  I tend to view this from the perspective of a business case, in which data loss is not acceptable.  A hobbyist may not have that perspective, of course, but presumably will/should understand the implications of relying on a remote service operated by a faceless entity to protect his/her work.