vbcc optimizing C compiler for 6502 now supports Atari

[vbc]

On 8/6/2020 at 11:59 AM, thorfdbg said:

The way how I do that is to first load a small loader into a "known to be available" space, e.g. page 6, and then the loader figures out where the binary would need to go (e.g. above MemLo), pull in the data from the file, and then relocate through data also in the file.

Technically, such a binary consists of a regular "binary load file" in the sense of the regular Atari DOS syntax, whose first chunk sets an init vector, that is, fills the vector at 2E2,2E3. Then, after finding the init vector filled, the Dos loader will jump through the init vector, thus to your program, and from there, you can continue loading. Relocation information is in the simplest case just a bitmask, one bit for each byte in the file, whether it needs to be relocated. In such a simple layout, one would need to round up to entire pages as only the high-bytes would need relocation. In more complicated setups, one would need a table.

 

Do you continue loading from the same file or do you have separate files for the loader and the actual code? If it is the former, are there any conflicts with the DOS loader?

 

Is there example code available?

 

On 8/6/2020 at 3:49 PM, David_P said:

If you are programming for a current version of SpartaDOS X, there are tools for system memory allocation (including expanded memory, but not 65816 memory) and native relocatable programs.

 

http://sdx.atari8.info/index.php?show=en_docs

 

I would hope for the programs to be usable on a wide variety of machines. Is this DOS widely used?

 

Also, I had a quick look at the manual and it seems to suggest that only 16bit relocations are available. This would imply that code like this

 lda #<addr
 sta lo
 lda #>addr
 sta hi

would not work. Is this correct?

[flashjazzcat]

9 minutes ago, vbc said:

I had a quick look at the manual and it seems to suggest that only 16bit relocations are available. This would imply that code like this

 lda #<addr
 sta lo
 lda #>addr
 sta hi

would not work. Is this correct?

Correct. You need to store the address as data and do lda word/lda word+1.

[thorfdbg]

2 hours ago, vbc said:

Do you continue loading from the same file or do you have separate files for the loader and the actual code? If it is the former, are there any conflicts with the DOS loader?

 

Is there example code available?

 

I would hope for the programs to be usable on a wide variety of machines. Is this DOS widely used?

I continue loading from the same file. everything else would be quite inconvenient. You find example code here:

 

http://www.xl-project.com/download/os++.tar.gz

 

There, look into menuloader.asm which does exactly that. The sources also include a makefile (for ca65 and gcc) and sources to create the relocation information. The relocatable file then consists of "menu.asm" and the "menuloader.asm", plus relocation information. The "reloc.c" file creates the relocation information from two assembled versions of the menu.asm.

 

I would not state that Sparta is universally used. I would rather say that the most widely used DOS is Atari's DOS 2.5. For my taste, the memory footprint of Sparta is too steep. Dos 2.5 does not provide such services.

 

[vbc]

On 8/7/2020 at 5:17 PM, flashjazzcat said:

Correct. You need to store the address as data and do lda word/lda word+1.

This is not really an option then.

 

On 8/7/2020 at 7:32 PM, thorfdbg said:

I continue loading from the same file. everything else would be quite inconvenient. You find example code here:

 

http://www.xl-project.com/download/os++.tar.gz

 

There, look into menuloader.asm which does exactly that. The sources also include a makefile (for ca65 and gcc) and sources to create the relocation information. The relocatable file then consists of "menu.asm" and the "menuloader.asm", plus relocation information. The "reloc.c" file creates the relocation information from two assembled versions of the menu.asm.

Interesting, thanks. However implementing this in a nice user-friendly and general way seems too much work at the moment. Maybe if there is much demand in the future.

 

Quote

I would not state that Sparta is universally used. I would rather say that the most widely used DOS is Atari's DOS 2.5. For my taste, the memory footprint of Sparta is too steep. Dos 2.5 does not provide such services.

The missing 8bit relocations are a deal-breaker anyway.

 

I have attached an updated version of the 6502-atari target directory for testing. I did the following changes:

• Used memory starts at $2000 by default with the stack at the beginning (MEMSTART and STACKLEN can be adjusted in vlink.cmd).
• The heap starts at APPMEMHI and can grow up to MEMTOP, adjusting APPMEMHI.
• The program returns rather than entering an endless loop (it seems to be necessary to clear the carry-flag before returning, is there a return code or something?).
• When stdio is used, <return> has to be pressed before control is returned in order to be able to see the output.
• clock() has been fixed.

The attachment contains the 6502-atari target directory to replace the one in the vbcc6502-distribution.

 

I would be interested to hear if this works better or if more changes are necessary.

 

 

6502-atari.zip

[thorfdbg]

18 hours ago, vbc said:

Interesting, thanks. However implementing this in a nice user-friendly and general way seems too much work at the moment. Maybe if there is much demand in the future.

Thanks for the update. Of course, I do not understand enough how your compiler works. In a typical setup, it would be the linker that would create the necessary relocation information, from the object code created by the compiler. It looks in my case a bit complicated because I do neither know enough about the ca65 object code, it is hence a bit kludgy.

[vbc]

On 8/11/2020 at 8:17 PM, thorfdbg said:

Thanks for the update. Of course, I do not understand enough how your compiler works. In a typical setup, it would be the linker that would create the necessary relocation information, from the object code created by the compiler. It looks in my case a bit complicated because I do neither know enough about the ca65 object code, it is hence a bit kludgy.

Yes, in my case, I would have the linker create the relocation information (although I used an approach similar to yours in creating a relocatable version of the ieee-library from two absolute binaries). However, it still is necessary to define a kind of file format, extend the linker, write the relocating loader, etc. Nothing impossible, but also not done in an hour or so.

[vbc]

I have uploaded a new version: http://www.compilers.de/vbcc.html

Not too much new for Atari. Mainly accumulated fixes from the last patches.

Major changes since last update:

- first version of a BBC Micro/Master target
- support for 65C02
- C99 mode is now the default, -c89 selects C89
- several bug fixes
- small code improvements
- updated/improved documentation

[vbc]

I have uploaded a new version: http://www.compilers.de/vbcc.html

Major changes since last update:

- new target: MEGA65 (native mode, some banking support)
- new target: Commander X16 (thanks András Péteri)
- new options -prefer-statics/-force-statics (allocate local variables in static memory rather than on the stack)
- new option -range-opt (first implementation of some range-based optimizations changing induction variables to smaller types)
- added support for o65 object file format
- added support for Oric target format
- better use of x register
- improved cross-module function-inlining
- IEEE math library works with 65c02
- several code generation improvements
- fixed several bugs
- slightly reworked examples

 

[vbc]

I have uploaded version 3 of the vbcc distribution for 6502 targets at http://www.compilers.de/vbcc.html

Major changes since last update:

• - several bug fixes
• - improved code generation
• - linker mask optimizations to reduce overhead of some library functions (still much room for improvement)
• - improved attribute checks for banking
• - C64 new features:
  •   - stdio functions allow file access on 1541 compatible drives
• - MEGA65 new features:
  •   - free license for commercial usage
  •   - code generator uses 32bit extensions
  •   - code generator uses HW multiplier
  •   - full automated banking support
  •   - ROM-less library enabling full use of the entire RAM
  •   - stdio functions allow reading of files on SD card
• - BBC new features:
  •   - stdio functions allow file access
  •   - full automated banking support for systems with sideways RAM
  •   - support for command line arguments
  •   - configuration for clean return after exit
• - CBM PET new features:
  •   - added as new target

We are happy to announce that the Museum of Electronic Games & Art e.V. (http://www.m-e-g-a.org) has decided to sponsor the MEGA65 version of vbcc.
This does not only help us to continue supporting and improving this port but it also allows us to relax the terms of use for the MEGA65 community. Everyone may now freely use vbcc to develop MEGA65 code for commercial as well as non-commercial usage (for details please refer to the license in the documentation).

We thank MEGA e.V. for the confidence in vbcc and hope that this step will help in the creation of new software for the MEGA65.