vbcc optimizing C compiler for 6502 now supports bbc

[vbc]

Out of curiosity I did a quick "hello world" test to see how it works.

What I found a little odd is that you're using zero page addresses, but using long address mode
eg

Code: Select all

1904 A9 00    LDA #0
1906 8D 20 00 STA &0020

Instead of "8D 20 00" the sequence "85 20" would save a byte and be quicker.

Oops, good point! Apparently I missed correctly declaring the zero page registers in the bbc startup code. I will have to fix that. Code generated by vbcc (and assembly code written more carefully) will not have this problem.

Also, is the code meant to return back to BASIC, or is it designed to hang after running?

Well, the vbcc documentation (in C Library => 6502/BBC) mentions "With the default configuration, after exiting the C program, the code will wait for pressing return before returning to basic (does not yet work correctly)."

I have never owned a bbc and so far spent barely more than one day creating the bbc target for vbcc (including finding information and setting up an emulator) - which IMHO speaks for the clean design of that machine. So, I could use some feedback on what is typically useful here. Btw. the vbcc6502 archive contains in libsrc/6502-bbc the source for the startup code as well as all the bbc-specific library code.

[sweh]

So, I could use some feedback on what is typically useful here.

So in my mind there's typically two types of program.

The first is those that "take over" the machine and are never expected to return. A typically game, or a spreadsheet. If that's the type of code being written then the return from main() might write out something like "[program ended. exit code 0. press BREAK]" so the user knows to reset the machine.

The other type are "utility" programs which do something and return. So

Code: Select all

LDA #65
JSR &FFEE
RTS

would be a simple "utility" program that writes the letter A. (So useful!)

Now these programs have some constraints. In particular they can't just trample over zero page because the caller might be using that. Language ROMs (eg BASIC) definitely make use of it. If you modify any of those values then you should restore them before returning (eg push them onto the stack at the start). Then you have the problem of _where_ the program should be loaded into memory. &1900 is the typical PAGE value for DFS machines and so would overwrite any BASIC program the user is writing. That'll cause BASIC to return "Bad program" after running code.

You _could_ force BASIC to restart, but that would mean people who ran programs from another language (or wordprocesor like VIEW or...) wouldn't return to their language. Maybe restarting the current language might be a reasonable approach.

I'm sure others may be able to think of other options!

[vbc]

The other type are "utility" programs which do something and return. So

Code: Select all

LDA #65
JSR &FFEE
RTS

would be a simple "utility" program that writes the letter A. (So useful!)

Now these programs have some constraints. In particular they can't just trample over zero page because the caller might be using that. Language ROMs (eg BASIC) definitely make use of it. If you modify any of those values then you should restore them before returning (eg push them onto the stack at the start).

Apart from restoring zero-page, is there anything else to do to reliably return?

Then you have the problem of _where_ the program should be loaded into memory. &1900 is the typical PAGE value for DFS machines and so would overwrite any BASIC program the user is writing. That'll cause BASIC to return "Bad program" after running code.

So I assume this can only be handled by the developer specifying the load address (which is a simple change in the linker command file at the moment) and then hoping that any BASIC program is short enough?

If a C program is supposed to work like a utility, I assume it should be able to be executed multiple times without re-loading it from disc? In that case initialized data has to be duplicated in RAM. This is a configuration option I provided for the C64 target.

Is there a standard way to pass "command line parameters" to the C code?

[sweh]

Apart from restoring zero-page, is there anything else to do to reliably return?

Not really, as long as you don't mess with OS vectors, etc. Running a command (eg with *RUN or */ or *filename in some cases) pretty much just does a "load file at LOAD address; JSR to RUN address" so an RTS is all that's needed.

So I assume this can only be handled by the developer specifying the load address (which is a simple change in the linker command file at the moment) and then hoping that any BASIC program is short enough?

Yeah. For really short code (eg less than 256 bytes) it's not uncommon to have it load over the serial buffer or similar (eg page &A or sometimes page 9) because that's normally "safe".

If a C program is supposed to work like a utility, I assume it should be able to be executed multiple times without re-loading it from disc? In that case initialized data has to be duplicated in RAM. This is a configuration option I provided for the C64 target.

Not normally, no. If I ran my "printa" program 10 times it'd load 10 times from disk. What I call a "utility" program isn't normally meant to persist data across executions. If it needs to then it might try and steal the odd unused memory byte here or there, or else increase OSHWM ("OS High Water Mark") to allocate a page of memory and use that.

Is there a standard way to pass "command line parameters" to the C code?

You call OSARGS (&FFDA) with A=1 and Y/X pointing to a block of memory. So, for example

Code: Select all

LDA #1
LDX #&70
LDY #0
JSR &FFDA

Now (&70) points to the command line. You'll need to do the parsing to split the string into the argv[] array before calling main()

[dominicbeesley]

If you're calling any OS functions that might cause an error (the BBC MOS uses the BRK instruction to signal errors, followed by an error number and a zero-terminated error string) you might want to capture / restore the BRK vector at startup/exit. I did some work ages ago for cc65 that does some of this and also traps ESCape. https://github.com/dominicbeesley/cc65/ ... bbc/crt0.s - it's pretty crappy and could be done a lot better I'm sure but it might be useful?

I'll try and get a look at vbcc soon.

Is there a version of vbcc that produces 65816 code?

D

[Fabrizio]

I am trying to have vbcc work under Cygwin.

Does the Windows binary expects config files in Windows format?
Maybe a third hybrid format is necessary for Cygwin and for other Posix environments under Windows.

Under Cygwin I am still getting a "no config file!" error.

I have tried to set the VBCC variable to point to
/cygdrive/c/Retro/vbcc6502/vbcc6502_linux/vbcc (Linux version)
and
/cygdrive/c/Retro/vbcc6502/vbcc6502_win/vbcc (Windows version)

So with the Linux version I see:
$ cat $VBCC/config/bbc
-cc=vbcc6502 -I$VBCC/targets/6502-bbc/include -quiet %s -o= %s %s -O=%ld
-ccv=vbcc6502 -I$VBCC/targets/6502-bbc/include %s -o= %s %s -O=%ld
-unsigned-char
-mainargs
-as=vasm6502_oldstyle -quiet -nowarn=62 -opt-branch -ldots -Fvobj %s -o %s
-asv=vasm6502_oldstyle -nowarn=62 -Fvobj -opt-branch -ldots %s -o %s
-rm=rm %s
-rmv=rm %s
-cpr=vcpr6502 -quiet %s %s
-cprv=vcpr6502 %s %s
-ld=vlink -b bbc -Cvbcc -T$VBCC/targets/6502-bbc/vlink.cmd -L$VBCC/targets/6502-bbc/lib $VBCC/targets/6502-bbc/lib/startup.o %s %s -o %s -lvc
-ldv=vlink -b bbc -Cvbcc -T$VBCC/targets/6502-bbc/vlink.cmd -L$VBCC/targets/6502-bbc/lib $VBCC/targets/6502-bbc/lib/startup.o %s %s -o %s -lvc -Mmapfile
-l2=vlink -b bbc -Cvbcc -T$VBCC/targets/6502-bbc/vlink.cmd -L$VBCC/targets/6502-bbc/lib %s %s -o %s
-l2v=vlink -b bbc -Cvbcc -T$VBCC/targets/6502-bbc/vlink.cmd -L$VBCC/targets/6502-bbc/lib %s %s -o %s -Mmapfile



while I have the PATH variable set to point to the windows binary:
$ which vc
/cygdrive/c/Retro/vbcc6502/vbcc6502_win/vbcc/bin/vc

(I have removed the path to other previous vc versions I was using).

Is there a verbose and/or debug mode to run the vc command so that I can figure out what is wrong?

[sweh]

I have tried to set the VBCC variable to point to
/cygdrive/c/Retro/vbcc6502/vbcc6502_linux/vbcc (Linux version)
and
/cygdrive/c/Retro/vbcc6502/vbcc6502_win/vbcc (Windows version)

Did you export VBCC ?

What does

Code: Select all

env | grep VBCC

show ?

[vbc]

If you're calling any OS functions that might cause an error (the BBC MOS uses the BRK instruction to signal errors, followed by an error number and a zero-terminated error string) you might want to capture / restore the BRK vector at startup/exit. I did some work ages ago for cc65 that does some of this and also traps ESCape. https://github.com/dominicbeesley/cc65/ ... bbc/crt0.s - it's pretty crappy and could be done a lot better I'm sure but it might be useful?

Thanks, I will have to look into that.

Is there a version of vbcc that produces 65816 code?

Currently not.

[vbc]

I am trying to have vbcc work under Cygwin.

Does the Windows binary expects config files in Windows format?

The Windows binary of vc.exe does a call to getenv() to query the environment variable VBCC which is used to find the config file. As vc was compiled for normal Windows (using Mingw that is), it will probably not see any environment variables that you set in a cygwin bash. That is probably your first problem (to find the config file). Try also setting the Windows environment variable VBCC. I think you can also put a config file in the current directory or specify the full path with +<cfg>.

After vc has read the config file it uses the command templates from the config file to call the different translation passes and executes them using the system() library function. How this is executed under cygwin, I do not know.

Is there a verbose and/or debug mode to run the vc command so that I can figure out what is wrong?

-v will display all the command lines that vc is executing using system(). -vv prints some more debug info, but it will probably not help. The question is whether $VBCC or %%VBCC%% has to be used in the config file and what environment variable (Windows or cygwin) is used.

For testing you can try to replace the compiler calls in the config file by echo or something similar. Then you will probably see if it is correctly replaced.

[Fabrizio]

@vbc
By using the Windows setup for %PATH% and %VBCC% I got everything working under Cygwin, which is my dev environment.
I am now using the latest multi-target version as I plan to use it to build binaries for all of its targets.

BBC: OK
I managed to integrate vbcc into Cross-Lib and use to compile one of my games for the bbc (currently in a purely character-based turn-based version). Ant it works.

BBC MASTER: maybe KO ?
On the other hand it seems that the bbcmaster target may be producing broken binaries (even with an hello world example) or I am doing something wrong... The effect is that I see gibberish on the screen when I run the hello world on the emulated BBC Master 128.

I am testing the hello world with BeebEm (Hardware->BBC Master 128).
I create an empty disk and I insert the binary into it (through the emulator).
I use *CAT to verify that the binary is in the disk.
I load and run it with *RUN"<name>".

[lurkio]

I see gibberish on the screen when I run the hello world on the emulated BBC Master 128. I am testing the hello world with BeebEm (Hardware->BBC Master 128). I create an empty disk and I insert the binary into it (through the emulator).

Can you upload the disk-image here so that people can have a look?

[vbc]

On the other hand it seems that the bbcmaster target may be producing broken binaries (even with an hello world example) or I am doing something wrong... The effect is that I see gibberish on the screen when I run the hello world on the emulated BBC

To be honest, I think it has been quite some time since I last tested the bbcmaster config. I usually only tested with +bbc. The only differences between those two targets is the memory layout and use of 65C02 instructions. So it is probably just the memory layout that is wrong.

Maybe some of the bbc experts can help here. What memory area can be used on those machines? The current configurations use:

bbc/micro: 0x1900..0x7C00
bbc/master: 0x0E00..0xAC00

Apparently those are not safe values at least for the bbcmaster target. What would be suitables values?

[BigEd]

Hmm, that's an odd kind of memory range.

As I understand it, in the Master 128, if in a shadow VDU mode, you can use RAM from E00 up to 8000. If you're in control of sideways RAM configuration, you can probably arrange to go up to C000 for many purposes (but not all - you can't easily do file i/o to this area). If you're really taking over the machine, you might be able to go up to E000, by mapping in HAZEL. But it's not crystal clear to me that HAZEL is usable for code and data.

I expect the OS call which returns HIMEM will give you 7C00 in mode 7, or 8000 in mode 7+128.

[Fabrizio]

@lurkio
I have attached the binary file, the .inf file and the .ssd file (created with BeebEm).

[vbc]

Is there a standard way to pass "command line parameters" to the C code?

You call OSARGS (&FFDA) with A=1 and Y/X pointing to a block of memory. So, for example

Code: Select all

LDA #1
LDX #&70
LDY #0
JSR &FFDA

Now (&70) points to the command line. You'll need to do the parsing to split the string into the argv[] array before calling main()

Thanks! I did a short test and the results look good. I will try to support it for the next release.

[tricky]

As has already been suggested, you could have a utility mode where the target can be *run and an application mode where it loads into sideways ram as a language and can use all the language work space including zero page.

[vbc]

As I understand it, in the Master 128, if in a shadow VDU mode, you can use RAM from E00 up to 8000. If you're in control of sideways RAM configuration, you can probably arrange to go up to C000 for many purposes (but not all - you can't easily do file i/o to this area). If you're really taking over the machine, you might be able to go up to E000, by mapping in HAZEL. But it's not crystal clear to me that HAZEL is usable for code and data.

So, by default, there is no RAM mapped above 0x8000? Does that mean the mapping has to be changed before upper RAM can be used? Is it possible to load code/data into the upper RAM with a standard command or would an extra loader be needed?

Is there a nice specification of the banking mechanism?

[vbc]

As has already been suggested, you could have a utility mode where the target can be *run and an application mode where it loads into sideways ram as a language and can use all the language work space including zero page.

How do you load into the sideways RAM? Are there separate requirements/restrictions?

[BigEd]

There are the two Acorn references for the Master, and also one by Watford: see the splendid recently-remastered versions linked here.

For the sideways area, from 8000 to BFFF, you can think of the Master and the Beeb as very similar, at least if you imagine a Beeb with sideways RAM fitted. There are 16 banks, and usually one is Basic and another is the DFS or other filing system. And then in the Master four of them are RAM banks - in the Beeb, zero of them as-shipped but often two of them are RAM.

Yes, the application code needs to decide which sideways bank is mapped in at any time, and yes, loading into this area is tricky because the DFS already lives here. In the Master there's an SRLOAD command.

[tricky]

Selecting banks for reading is just a case of writing a single register, writing is different depending on the machine and ram expansion fitted.
The most common ones are:
Master, select the bank with a similar register to the read bank.
DIY, select bank to write with the read select.
Solidisk, select the write bank by writing to the user port low bits - this will confuse any "MMC" device living there.
Watford 12 ROM/RAM board, any ROM on the board writing to the RAM range will write to bank 14 if fitted with RAM, the RAM cannot be written from main memory, but can be read.
I'm fairly sure I have posted my discovery and loading code several times, but maybe I should start a dedicated thread if there isn't one already.

[BigEd]

A dedicated thread would be great!

[dominicbeesley]

Using the sideways ram for mixed code/rodata/bss has its problems - there are a number of OS calls provided by other ROMs that won't work. I've done some experiments on larger cc65 c programs and have come up with two methods which work but I've not had the time to get to a state where I'd be happy to release them.

1) Shared C library ROM
Move the code for C library and commonly used code snippets into a ROM and page that ROM in*3 the entire time the C program is running*1. The bit I've not done here is to make a system whereby there is a vector of routine addresses that would allow the same library rom to work over multiple C versions.

2) Code/Read only data in SWRAM
A more simple and flexible approach which seems to work well is to have the code/read only data relocate itself to SWRAM at startup leaving all the regular RAM free for data which can be used with regular OS calls*2

*1 - Finding the ROM, selecting it and fixing up calls in the code would have to be done by the startup code?
*2 - Caveat: OS calls serviced by other ROMs would still not work with static data pointed to in the SWRAM area and would need to be copied into normal RAM. some way of marking ro data to not be copied high (code pragma/attribute and separate linker section?)
*3 - When paging in a ROM you must write $F4 first then $FE30 next to actually select the ROM, otherwise an interrupt routine could come along and page your ROM out (FE30 is read-only so F4 is used to flag which ROM is in use).

Shadow mode
-----------------
It's nice to use the Master/B+ shadow mode to get more memory but larger programs that want to access the screen directly (games, demos, graphics) will be a bit hamstrung. It would be nice to have configurations for each screen mode - it's a PITA but that's kind of how the BBC/MOS is

[vbc]

Thanks everybody for the hints. I read a bit more about the sideways RAM and did a few tests in an emulator. At first glance, bank switching seems to work as expected. Probably I will start using only the 16K sideways RAM (with optional banking) first.

Using SRLOAD to load into sideways RAM seems to work. Am I assuming correct that I can create a BASIC "script" that will load a program that is comprised of several images, i.e.

10 *SRLOAD bank4 8000 4
20 *SRLOAD bank5 8000 5
30 *SRLOAD bank6 8000 6
40 *SRLOAD bank7 8000 7
50 *RUN mainprg

Will this work? Is SRLOAD supported on all/most BBC systems with sideways RAM?

Apparently there are machines with different configurations of sideways RAM (amount of slots as well as slot numbers used for RAM). Is there a way to detect which RAM slots are available (within a startup code as well as from within a BASIC loader)?

[BigEd]

Oh wow, you're not just looking for a chunk of addressable memory, you're OK with multiple banks?! I'd've thought that was much more involved. But if it can be done, great!

[Fabrizio]

Has anyone used VBCC to code a game?
I am new to the BBC and I am a very lame Assembly developer. I primarily retro-code in C (https://github.com/Fabrizio-Caruso/CROSS-LIB).
I have tried to use putchar with escape sequences to have the same effect as VDU. I probably need to set the correct mode (e.g. MODE 4).

Has anyone managed to hook some BASIC/ROM routines to do graphics and poll the keyboard/joystick?

[tricky]

Srload is not on all beebs, but some rooms do at it.
I'm sure I have published my code, as have others for detecting and loading into sideways ram. One issue is that testing for early solidisk SWRAM upsets user port devices like most mmcs.
Btw, your basic program could be put in a text file without the line numbers and *EXECed.

[RobC]

I have tried to use putchar with escape sequences to have the same effect as VDU. I probably need to set the correct mode (e.g. MODE 4).

VDU 22,4 will do the equivalent of MODE 4.

Has anyone managed to hook some BASIC/ROM routines to do graphics and poll the keyboard/joystick?

Not with vbcc but I have done this sort of thing in C with the native ARM co-pro by hooking into OSWRCH, OSBYTE and OSWORD.

[Coeus]

Has anyone managed to hook some BASIC/ROM routines to do graphics and poll the keyboard/joystick?

The routines in the BASIC ROM are there for BASIC to use so if you want to re-use any of those you would need to work out which version of BASIC is installed and also make sure it is the currently paged in ROM - when called from *RUN it si the filing system that is the current ROM. But, unless you need floating point or trig functions you probably won't need to.

The OS ROM is designed to provide various useful services. All of the graphics available from BASIC are done by sending the right sequence of bytes to OSWRCH (&FFEE). There are a series of calls (OSFILE, OSFIND, OSBGET, OSBPUT, OSGBPB, OSARGS) for working with files and almost everything else is done by either calling OSBYTE or OSWORD with the appropriate register values. These are all documented at: https://beebwiki.mdfs.net/Category:MOS_API as well as in the Advanced User Guide.

BASIC generally has keywords for the most commonly used of the OS functions but most high level languages have the ability to call assembler in the manner of a function/procedure call and you can obviously wrap that to create a function with a more meaningful name. For example, a PLOT sends six bytes to OSWRCH: the code to start a PLOT, the type of things to plot, and the X and Y co-ordinates each as pairs of bytes LSB first. So in C, assuming putchar is directed to the screen, you could write:

Code: Select all

void plot(int code, int x, int y)
{
    putchar(25);     // start a PLOT sequence.
    putchar(code);
    putchar(x);      // sends the LSB.
    putchar(x >> 8); // X MSB
    putchar(y);      // sends the LSB
    putchar(y >> 8); // Y MSB.
}

[vbc]

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

Apart from general improvements, there are several new features for BBC targets. For example, stdio now works with files, sideways RAM is supported for banking, including automated bank-switching, and command line arguments are supported.

As I only could do some tests on emulators, I would be interested to hear how it works on real hardware.

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.

[Fabrizio]

Is the new version of the BBC target included in the universal vbcc compiler?
I am compiling for all targets and I am not sure I can do it if I install the 6502 version on top of the universal one.