cc7800, a C compiler dedicated to the Atari 7800

[+bsteux]

On 1/3/2024 at 6:47 PM, bsteux said:

OK. I will add 48ko ROM support to the upcoming version of cc7800 (ASAP).

Happy new year to all Atarians !

I've just committed on github a new version of cc7800 that should support 8KB to 48KB linear ROM. It automatically tries to fit the code in the different sizes until it succeeds... @karri, please test it with your code to check that it's OK. I've tested a few examples on my side already, but as this new feature required a lot of refactoring, I'm afraid of remaining bugs. I'll officially publish the next cc7800 when I'll get your green light.

 

[+karri]

5 hours ago, bsteux said:

I've just committed on github a new version of cc7800 that should support 8KB to 48KB linear ROM. It automatically tries to fit the code in the different sizes until it succeeds... @karri, please test it with your code to check that it's OK. I've tested a few examples on my side already, but as this new feature required a lot of refactoring, I'm afraid of remaining bugs. I'll officially publish the next cc7800 when I'll get your green light.

 

My code works well with the new compiler version

Thank you!

[+karri]

There is one strange thing about when code size exceeds 32k. I can run my 48k code on a7800 and on the new 2600+ console. But on the real Atari 7800 only the 32k version runs. When I try to run the 48k version the screen stays black.

 

I have included my C-code for the good and the bad version. The only difference in these is a little more bytes to exceed the 32k boundary.

 

Looking at the LST files did not reveal the cause for me.

 

rainbow48k.zip

[Trebor]

7 hours ago, karri said:

There is one strange thing about when code size exceeds 32k. I can run my 48k code on a7800 and on the new 2600+ console. But on the real Atari 7800 only the 32k version runs. When I try to run the 48k version the screen stays black.

 

I have included my C-code for the good and the bad version. The only difference in these is a little more bytes to exceed the 32k boundary.

 

Looking at the LST files did not reveal the cause for me.

 

rainbow48k.zip 56.67 kB · 0 downloads

Unsure if this is happening under a PAL or NTSC system, but both A7800 and 2600+ would allow the image to run without being signed properly for an NTSC system.  An original NTSC 7800/BIOS would require the binary to be properly signed.

 

If this is happening under a PAL console, please ignore

[+karri]

17 hours ago, Trebor said:

Unsure if this is happening under a PAL or NTSC system, but both A7800 and 2600+ would allow the image to run without being signed properly for an NTSC system.  An original NTSC 7800/BIOS would require the binary to be properly signed.

 

If this is happening under a PAL console, please ignore

Thank you @Trebor. This is most likely the logical reason. I do have a PAL 7800 so it should not be an issue. Somehow I had commented out the signing process from my Makefile and all my test roms that I compiled myself were without signature. The 32k version worked without signature on my console. But the 48k did not.

 

I also compared the assembler listings between a 32k and a 48k version of the same game and neither game has any data in the area used for the signature. The only strange thing is that the start address is at 4800 when my previous versions had the start at FXXX to keep the signature check shorter. But for a PAL console this should not matter. I have to run some tests tomorrow.

[+karri]

I just tried to sign the rainbow.a78 and just got this error message:

karri@swing:~/rainbow/cc7800$ sign7800 -w rainbow.a78 
Read $C000 bytes of cartridge data.
Cartridge reset vector points outside hashed area!

   9769  fffa                  e8 51                  .word.w   #dli    ; NMI
   9770  fffc                  00 48                  .word.w   #START  ; RESET
   9771  fffe                  61 48                  .word.w   #IRQ    ; IRQ

My guess is that the signature is calculated from the START address to the end of the cart. And the START address cannot be lower than at $8000.

[Trebor]

3 hours ago, karri said:

I just tried to sign the rainbow.a78 and just got this error message:

karri@swing:~/rainbow/cc7800$ sign7800 -w rainbow.a78 
Read $C000 bytes of cartridge data.
Cartridge reset vector points outside hashed area!

   9769  fffa                  e8 51                  .word.w   #dli    ; NMI
   9770  fffc                  00 48                  .word.w   #START  ; RESET
   9771  fffe                  61 48                  .word.w   #IRQ    ; IRQ

My guess is that the signature is calculated from the START address to the end of the cart. And the START address cannot be lower than at $8000.

This thread may be useful regarding the above:

Also, from the 7800 Software Guide Memory Map:

[+bsteux]

18 hours ago, Trebor said:

This thread may be useful regarding the above:

Also, from the 7800 Software Guide Memory Map:

Thank you for this precious information. I had completely missed these points.

I've just committed a change to cc7800. I've moved the startup code to the end of the memory and reserved some ROM for the signature. @karri, could you check please that everything is OK on your side now ?

 

[+karri]

Still problems with signing the cart.

 

karri@swing:~/rainbow/cc7800$ sign7800 -w rainbow.a78 
Read $C000 bytes of cartridge data.
Cartridge reset vector points outside hashed area!

   9674  fffa                  8e 4f                  .word.w   #dli    ; NMI
   9675  fffc                  13 d7                  .word.w   #START  ; RESET
   9676  fffe                  74 d7                  .word.w   #IRQ    ; IRQ
 

[+bsteux]

7 hours ago, karri said:

Still problems with signing the cart.

 

karri@swing:~/rainbow/cc7800$ sign7800 -w rainbow.a78 
Read $C000 bytes of cartridge data.
Cartridge reset vector points outside hashed area!

   9674  fffa                  8e 4f                  .word.w   #dli    ; NMI
   9675  fffc                  13 d7                  .word.w   #START  ; RESET
   9676  fffe                  74 d7                  .word.w   #IRQ    ; IRQ
 

OK. I see. I put the startup code at the end of the code, not at the end of the memory... d713 is not in the last 4KB in your case... My mistake. @karri, can you try again with my last commit ?

[+karri]

20 minutes ago, bsteux said:

OK. I see. I put the startup code at the end of the code, not at the end of the memory... d713 is not in the last 4KB in your case... My mistake. @karri, can you try again with my last commit ?

Thank you! I can now sign the cart and my silly little text adventure strolls along on a real Atari 7800. It may not be any "game of the year". But I plan to finish my childish adventure. Still three missing minigames, sound effects and some nice background sound track.

[+bsteux]

On 1/22/2024 at 8:07 PM, karri said:

Thank you! I can now sign the cart and my silly little text adventure strolls along on a real Atari 7800. It may not be any "game of the year". But I plan to finish my childish adventure. Still three missing minigames, sound effects and some nice background sound track.

Here is the windows installer for the latest cc7800 v0.2.21, and the Changelog :

v0.2.21 (01/17/2024) :
    - Added support for 8KB, 16KB, 32KB and 48KB ROMs  
    - Added support for 52KB ROMs
    - Moved startup code to the end of the first bank (just before interrupt vectors)
    - Reserved ROM for cart encryption signature
    - Always hash the last 4KB
     
v0.2.20 (01/08/2024) :
    - Added support for constant address in array of pointers
     

I've just finished a first version of multisprite for cc2600. Back soon on cc7800...

cc7800-0.2.21-x86_64.msi

[+bsteux]

The news for today is the added cc7800 support for TIATracker (for those who can't afford a Pokey). I've made a fork on github with a new option in the menu to generate C code : https://github.com/steux/tiatracker/. You will find in attachment an archive with the win32 executable.

The C code generated is split into 2 headers (song_tiatracker.h and song_trackdata.h, where song is the song name). The first one contains the variables definition and the player code, the second one the song data itself. Note that these functions and data can be put into another bank just by enclosing their definition by a "bankn {}" bracket. 2 functions are defined in the header : tia_tracker_init() and tia_tracker_play(), the first to be called once, the second to be called every frame (50Hz or 60Hz depending on the song definition).

Here is an example of song player (examples/example_tiatracker.c) - Note that the volume is directed to 2 variables XAUDV0 & XAUDV1 through the TIA_TRACKER_INDIRECT_REGISTERS option. This is done in order to display the volume graphically. It could be used also to change the volume on the fly.

 

#include "prosystem.h"
#define TIA_TRACKER_INDIRECT_REGISTERS
unsigned char * const XAUDC0    = 0x15;     // Audio Control Channel   0                    write-only
unsigned char * const XAUDC1    = 0x16;     // Audio Control Channel   1                    write-only
unsigned char * const XAUDF0    = 0x17;     // Audio Frequency Channel 0                    write-only
unsigned char * const XAUDF1    = 0x18;     // Audio Frequency Channel 1                    write-only
unsigned char XAUDV0, XAUDV1;

#include "miniblast_tiatracker.h"
#include "miniblast_trackdata.h"
#include "conio.h"

char i, j, k, l;

void main()
{
    tia_tracker_init();

    clrscr();
    gotoxy(12, 0);
    textcolor(2);
    cputs("TIA Tracker Player");

    for (i = 0; i != 2; i++) {
        gotoxy(18 + (i << 2), 19);
        putch('1' + i);
    }

    textcolor(1);

    i = 0;

    do {
        // Display the volume for each channel
        k = 18 + (i << 2);
        l = 17 - (((i == 0)?XAUDV0:XAUDV1) & 0x0f);
        for (j = 2; j < l; j++) {
            gotoxy(k, j);
            putch(' ');
        }
        for (; j < 18; j++) {
            gotoxy(k, j);
            putch(127);
        }
        i++;
        if (i == 2) i = 0;

        *BACKGRND = 0x00;
        while (*MSTAT & 0x80); // Wait for end of VBLANK
        while (!(*MSTAT & 0x80)); // Wait for VBLANK
        *BACKGRND = 0x0f;
        
        tia_tracker_play();
        *AUDV0 = XAUDV0;
        *AUDV1 = XAUDV1;
    } while(1);
}

 

Not that bad for a TIA chip no ?

See you soon for paddles support !

tiatracker_cc_v1.1.zip example_tiatracker.a78

Edited February 8 by bsteux
typo

[+karri]

The Tiatracker is really easy to use. It is very practical for small games.

 

2 hours ago, bsteux said:

See you soon for paddles support !

A shoot them up for 4 players?

 

Medieval Mayhem with 4 paddles for the 2600 was a nice game at retro events. Something similar for the 7800 would be great!

[+bsteux]

47 minutes ago, karri said:

The Tiatracker is really easy to use. It is very practical for small games.

 

A shoot them up for 4 players?

 

Medieval Mayhem with 4 paddles for the 2600 was a nice game at retro events. Something similar for the 7800 would be great!

Indeed, I was thinking of a 4 players racing game, in the Indy 500 style, and writing it for the 2600 AND the 7800, sharing most of the logic. Could be fun on the 2600+, no? (the new paddles are soooo inexpensive that it's tempting to make 4 players games...). But yes, Medieval Mayhem on the 7800 would be great.

[+bsteux]

Hi,

Here is an example of using paddles with cc7800 and the Atari 7800 : a simple breakout game.

It's called Donald T.'s Breakout. Donald T., a fictional character, has been sentenced to 150 years in jail for bankruptcy, forgery, conspiracy, corruption, tax evasion and sexual harassment. He MUST get out of jail to save America. His weapons : a suitcase full of dollars (good damping), a tennis ball and a ton of carrots to get a nice tan. Will Donald T. succeed in escaping the prison ?

 

This game is 16KB only, with just 1 level, but demonstrates that the Atari 7800 is very capable at handling paddles.

Basically, I'm using a simple DLI to get paddle measurement (note that it can take up to 200 lines of CPU time).

void interrupt dli()
{
    if (!dli_done) {
#ifdef DEBUG
        *BACKGRND = 0x05;
#endif
        *VBLANK = 0x00; // Let paddle capacitors charging 
        Y = 200;
        do {
            strobe(WSYNC); // 3 cycles
            if (*INPT0 & 0x80) break; // 7 cycles
            Y--;
        } while (Y); // Looping 5 cycles
        // This takes 15 cycles out of 113.5. Maria should have enough cycles left... 
        X = paddle_pos_idx;
        X++;
        if (X == PPADDLE_BUFSIZE) {
            X = 0;
        }
        paddle_pos_idx = X;
        paddle_pos[X] = Y;
        *VBLANK = 0x80; // Dump paddles to ground
#ifdef DEBUG
        *BACKGRND = 0x00;
#endif
        dli_done = ++Y; // To tell the main prog how much lines the DLI took
    }
}

which stores the paddle position in a small ring buffer for low pass filtering. The result is very precise and quite reactive.

 

4 other things to note in this demo :

- it's a 320A/C game. 320C mode is nice : 8 colors + background + high res.

- the use of a new "multisprite_8lines.h" header. "multisprite.h" only proposed 16 lines double buffered processing. You now have the option to use 8 lines sprites, which is necessary for a breakout. As it takes more memory, double buffering was removed.

- the use of two different sprites for the ball and the suitcase, since Maria is not able to to display sprites at 320 pixels resolution (it's limited to 160 pixels horizontally). With a different sprite for odd and even positions, we can use the full 320 pixels resolution for sprite positioning.

- I'm using a new feature of cc6502 v1.0.20 for filtering the positions of the paddle : 16-bits right shift operation. I've provided a new installer for cc7800 v0.2.22 which was compiled against cc6502 v1.0.20.

 

Have fun. It's indeed quite playable (tested by my son Maxime in the video).

breakout.a78 example_breakout.c breakout.yaml cc7800-0.2.22-x86_64.msi

[+bsteux]

Hi,

Here is an anniversary update for cc7800 (a little late since cc7800's birthday was on the 4th of April).

Among the news are the added support for 12 lines scattered data, and many bug fixes both in the memory mapping of cc7800 and in the underlying cc6502 library. A bug in the joysitck header has also been corrected (joystick2 wasn't working correctly).

I've started a new tool "Bitmap7800" to support bitmap display. I'll be back soon with some examples.

I'd like to add support for furnace tracker and SN sound. Would there be some examples for the Atari 7800 around ?

cc7800-0.2.24-x86_64.msi

[ZippyOasys]

5 minutes ago, bsteux said:

Hi,

Here is an anniversary update for cc7800 (a little late since cc7800's birthday was on the 4th of April).

Among the news are the added support for 12 lines scattered data, and many bug fixes both in the memory mapping of cc7800 and in the underlying cc6502 library. A bug in the joysitck header has also been corrected (joystick2 wasn't working correctly).

I've started a new tool "Bitmap7800" to support bitmap display. I'll be back soon with some examples.

I'd like to add support for furnace tracker and SN sound. Would there be some examples for the Atari 7800 around ?

cc7800-0.2.24-x86_64.msi 1.64 MB · 0 downloads

Seek no further, I just so happen to have some furnace files

 

atarispeedcore.furtinymod3 - atari tia.fur

[+bsteux]

19 minutes ago, ZippyOasys said:

Seek no further, I just so happen to have some furnace files

 

atarispeedcore.fur 3.27 kB · 0 downloads tinymod3 - atari tia.fur 1.45 kB · 0 downloads

Thank you. Would you have some code (asm?) that plays this ?

[+karri]

I have a tiaplayer that works on music tunes that are small enough and hopefully limited to 60Hz update rates. These example tunes are much faster.

 

I did try to compile the tinymod3 but it failed.

tiaplayer.zip

 

For  a reference I have a working tune in
SpanishFlea.zip

 

The tiaplayer code is wip by @Dave C

 

Btw... I actually happen to have a working Furnace Tracker player for the SN chip on the 7800. But if is fairly complicated. Currently I need to output the music as a vgm file from Furnace Tracker. Then I have a python script converting it to a vgc player format. The idea is to run-length encode every SN register separately and then use Huffmunch to extract a byte at a time during VBL interrupts.

 

To further complicate things the asm is a bit self modifying code and is run in RAM. Wizzy tried to use one 16k ram bank for graphics and one 16k ram bank for sounds so they are never active at the same time.

 

If you want I can give you access to my repo.

The tiaplayer approach works as a direct romout export from Furnace Tracker. So you save a lot of space as the structure of the song is not lost.

 

I do have a github fork of furnace at my karrika account. There is a branch named Mikey-rom-export that handles romout for the tia as well. But I hope that the original author makes a pull request at some point in time.
karrika/furnace at Mikey-rom-export (github.com)

 

The way to export the rom from a command line is:

./furnace -romout tiaplayer song.fur

 

The folder tiaplayer must exist for the export.

[+bsteux]

1 hour ago, karri said:

I have a tiaplayer that works on music tunes that are small enough and hopefully limited to 60Hz update rates. These example tunes are much faster.

 

 

I did try to compile the tinymod3 but it failed.

tiaplayer.zip 99.48 kB · 0 downloads

 

For  a reference I have a working tune in
SpanishFlea.zip

 

The tiaplayer code is wip by @Dave C

 

Btw... I actually happen to have a working Furnace Tracker player for the SN chip on the 7800. But if is fairly complicated. Currently I need to output the music as a vgm file from Furnace Tracker. Then I have a python script converting it to a vgc player format. The idea is to run-length encode every SN register separately and then use Huffmunch to extract a byte at a time during VBL interrupts.

 

To further complicate things the asm is a bit self modifying code and is run in RAM. Wizzy tried to use one 16k ram bank for graphics and one 16k ram bank for sounds so they are never active at the same time.

 

If you want I can give you access to my repo.

 

The tiaplayer approach works as a direct romout export from Furnace Tracker. So you save a lot of space as the structure of the song is not lost.

 

I do have a github fork of furnace at my karrika account. There is a branch named Mikey-rom-export that handles romout for the tia as well. But I hope that the original author makes a pull request at some point in time.
karrika/furnace at Mikey-rom-export (github.com)

 

The way to export the rom from a command line is:

./furnace -romout tiaplayer song.fur

 

The folder tiaplayer must exist for the export.

Thanks. All this info should be a good starting point for integrating a tia player in cc7800 compatible with furnace tracker. The TI SN chip seems to be a good alternative to Pokey, though it's not supported by the 2600+. I've seen that the Yamaha sound chip is supported by the 2600+. I'll have a look at this one. Could be a good target for making music through furnace.

 

[+bsteux]

Hi,

Does anyone know how the Atari 2600+ is detecting the presence of a YM2151 ? Does it probe some specific address on the bus or does it look into the dumped ROM code for some access to a specific address (like 0x460 as suggested by the http://7800.8bitdev.org/index.php/YM2151_Detection detection code by @RevEng ? By the way, same questions for the Pokey chip...

[RevEng]

2 hours ago, bsteux said:

Does anyone know how the Atari 2600+ is detecting the presence of a YM2151 ? Does it probe some specific address on the bus or does it look into the dumped ROM code for some access to a specific address (like 0x460 as suggested by the http://7800.8bitdev.org/index.php/YM2151_Detection detection code by @RevEng ? By the way, same questions for the Pokey chip...

I have to be a bit careful here, as I'm not able to disclose closed technical details. I will just point out that it's been publicly reported that the 2600+ YM/Pokey emulation works with games that have code to drive these chips but don't physically have them on the PCB.

[+bsteux]

2 hours ago, RevEng said:

I have to be a bit careful here, as I'm not able to disclose closed technical details. I will just point out that it's been publicly reported that the 2600+ YM/Pokey emulation works with games that have code to drive these chips but don't physically have them on the PCB.

Thanks. This is exactly what I needed to know.

[+karri]

On 4/11/2024 at 5:29 PM, bsteux said:

Thanks. All this info should be a good starting point for integrating a tia player in cc7800 compatible with furnace tracker. The TI SN chip seems to be a good alternative to Pokey, though it's not supported by the 2600+. I've seen that the Yamaha sound chip is supported by the 2600+. I'll have a look at this one. Could be a good target for making music through furnace.

 

I would say that Furnace Tracker is the way to go. TIA has very nice percussion instruments in Furnace Tracker. The melody instruments are a bit out of tune. The Yamaha YM2151 is in tune. So it is a good match. You may even write the music in a way where you have a nice stand alone percussion track if the YM2151 chip is missing. All the sound effects could be taken from the sfx library for the TIA.

 

I did also use this driver in my Easter (Klondike) game using the cc65 compiler.

 

The Furnace Tracker is faster to work with than any other tracker I have tried. So I would love to re-use my tunes for the 7800 and the Lynx.