Pure C (demo) coding

C and PASCAL (or any other high-level languages) in here please

Moderators: exxos, simonsunnyboy, Mug UK, Zorro 2, Moderator Team

User avatar
Nyh
Atari God
Atari God
Posts: 1496
Joined: Tue Oct 12, 2004 2:25 pm
Location: Netherlands

Pure C (demo) coding

Postby Nyh » Fri Nov 10, 2006 9:47 am

Hello,

For all those thinking of using Pure C for (demo) programming on the Atari I will publish here some source code and do some explanation. Main focus will be C coding for demo and games. No to be found over here and not a lot of OS calls. I will use hardware registers a lot.

My intention is to publish some work in progress, like the game engine I will be doing for Sarek ( http://www.atari-forum.com/viewtopic.php?t=9473 ) but I maybe I will show you also some other ideas I. Who knows.

How succesfull this thread will be will depend on the reactions. If I like them I will continue otherwise I will stop.

Hans Wessels

User avatar
christos
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2323
Joined: Tue Apr 13, 2004 8:24 pm
Location: Greece
Contact:

Postby christos » Fri Nov 10, 2006 11:57 am

May I be the first one to look forward to this? Now that I have a proper keyboard..... Some falcon support would be great too.
Felix qui potuit rerum cognoscere causas.
My Atari blog

STOT Email address: stot(NoSPAM)atari(DOT)org

User avatar
Nyh
Atari God
Atari God
Posts: 1496
Joined: Tue Oct 12, 2004 2:25 pm
Location: Netherlands

Moving Background

Postby Nyh » Fri Nov 10, 2006 12:04 pm

Starters.

Maartau wanted something interesting: "I want to do a moving background + Text.
I created the simple program attached to this post.

A medium res DEGAS picture is loaded, preshifted in an assembly function and displayed using a assembly function.

Things to look at:

1 the project file:

Code: Select all

; DEFAULT.PRJ for use with single module programs

bg.prg             ; name of executable program is topmost window
.C [ -Y ]
.L [ -L -Y ]
.S [ -Y ]
=                  ; list of modules follows...

e:\pc\lib\original\PCSTART.s          ; startup code

bg.c               ; compile topmost window
bgs.s

PCBGILIB.LIB       ; BGI library
PCFLTLIB.LIB       ; floating point library
PCSTDLIB.LIB       ; standard library

PCEXTLIB.LIB       ; extended library
PCTOSLIB.LIB       ; TOS library
PCGEMLIB.LIB       ; AES and VDI library

;

As the text says it is the default project file modified a little bit. The project will build bg.prj by compiling and linking the following modules:
e:\pc\lib\original\PCSTART.s ; startup code, I am not sure where this module is on a normal Pure C distribution. In the time I have been coding I have added multiple startup modules so I am not 100% sure if this can be found in a normal Pure C distribution. Please give me feedback on this.
bg.c ; the C source, here is the function main, the first function that will be called after startup
bgs.s ; the assembly, some high speed functions doing the hard work.

PCBGILIB.LIB ; BGI library
PCFLTLIB.LIB ; floating point library
PCSTDLIB.LIB ; standard library
PCEXTLIB.LIB ; extended library
PCTOSLIB.LIB ; TOS library
PCGEMLIB.LIB ; AES and VDI library
All the libraries. Just use the standard bunch. The linker will take the parts it needs.

The C-file.

Code: Select all

#include <stdio>
#include <tos>

Headerfile stdio.h for printf and the file-IO. tos.h for the function Supexec(), to execute a function in supervisor mode.

Code: Select all

#define save_regs movem_save();reglist();
#define restore_regs movem_load();reglist();
void movem_save(void) 0x48e7;     /* movem.l reglist,-(sp) */
void movem_load(void) 0x4cdf;     /* movem.l (sp)+,reglist */
void reglist(void) 0xffff;        /* -1, alle registers */

I think the is Pure C specific. This you insert inline assembly code. By 'calling' movem_save() the compiler will insert the opcode 0x48e7 into the code. The #define creates 'save_regs' and 'restore_regs' to save and restore all registers on the stack.

Code: Select all

void (*init_music)(unsigned long data);
void (*play_music)(void);

Here two pointers to the functions init_music(unsigned long data) and play_music(void) are defined. We will use those pointers later to call the music routines.

Code: Select all

int main(void)
{
  Supexec((long (*)( ))(demo));
  return 0;
}

The main function. Only thing it does is calling the function demo in supervisor mode. The "(long (*)( ))" is a very interesting typecast to cast the pointer to the function into a long. It can be done in a more simple way by using a simple (long) but then you get the nonportable pointer conversion warning.

Code: Select all

char screen[32256UL];
char buf[16*32000UL];
char mus[22000];
int colors[16];

Reserve some memory for screen, buffer for preshifting the background picture, music and colors. For colors I use int (16 bit) because the color registers should be written to as 16 bit words.

Code: Select all

  { /* copy colors */
    long* p=(void*)(buf+32000UL+2);
    long* q=(void*)colors;
    *q++=*p++;
    *q++=*p++;
    p=(void*)(screen+222+2+8);
    *q++=*p++;
    *q++=*p++;
    *q++=*p++;
    *q++=*p++;
    *q++=*p++;
    *q++=*p++;
  }

Dirty and lazy, casting a pointer to char and pointer to int into a pointer to long because with longs you copy 4 bytes at a time. When you cast a pointer to char into a pointer to in or long be sure the pointer is on an even address otherwise bombs will greet you as soon as you dereference the pointer.

Code: Select all

    old_scrp=*(long*)0xFF8200UL;
    scr=(char*)(((long)screen+256)&0xffff00UL);
    scrp=(long)scr;
    scrp+=(scrp&0xff00)>>8;
    *(long*)0xFF8200UL=scrp;
    old_res=*(char*)0xff8260UL;
    *(char*)0xff8260UL=0; /* st low */

Reading and writing to some hardware registers. 0xff8201 and 0xff8203 are the videobase registers. By reading the long at 0xff8200 you get them both in one read. (long*) casts 0xff8200 into a pointer to a long. *(long*) reads (or writes) the long at the given address. First the old screen address is read and stored into old_scrp. The address of the new screen is calculated. Because the screen has to start at a multible of 256 the screenbuffer is cast into a long, 256 is added and by doing a bitwise and with 0xffff00 we are sure the address is at an 256 byte boundary then the address is casted back into a pointer to char. With "scrp=(long)scr; scrp+=(scrp&0xff00)>>8" the address in converted into a long value that can be written to the videobase registers "*(long*)0xFF8200UL=scrp;". With "*(char*)0xff8260UL=0;" the computer is forced into ST LOW (the old resolution is saved on the line before). Note I don't use xbios for doing screen change. This means most of the OS doesn't know the screen adress has been changed, output of printf will go to the 'wrong' screen.

Code: Select all

      for(i=0;i<16>>2), scr);
      save_regs;
      play_music(); /* play music */
      restore_regs;

Wait for end of screen, display the backgrounddata and play the music.

Code: Select all

    while((*(char*)0xfffc02UL)!=57);

Continue the loop until the space bar is pressed reading the scancode from the keyboard ACIA register.

Code: Select all

  { /* exit */
    init_music(0L); /* stop music */
    vsync();
    {
      int i;
      for(i=0;i<16;i++)
      {
        ((int*)0xff8240UL)[i]=old_colors[i];
      }
    }
    *(char*)0xff8260UL=old_res;
    *(long*)0xFF8200UL=old_scrp;
  }

Restore everything back to normal.

Code: Select all

void vsync(void)
{
  char reg;
  long base;
  base=*(char*)0xffff8201UL;
  base<<=8;
  base+=*(char*)0xffff8203UL;
  base<<8>>16)&0xff;
  while(*(char*)0xffff8205UL!=reg)
  {
    (void)0;
  }
  reg=(base>>8)&0xff;
  while(*(char*)0xffff8207UL!=reg)
  {
    (void)0;
  }
}

Special vsync function. As soons as the end of the screen is reached the function will end it's wait loop. To be exact: the wait is ended as soon as the shifter starts with the last 256 bytes of the screen, that is 1.6 line before the screen is ended but as long as you start updating the screen at the top everything is OK. This way you have a bit more time for updating the whole screen as when you wait for the VBL interrupt which is at the top of a new screen. If you update the screen from top to down fast enough (within 20 ms or 50 Hz) the electron beam will never catch up and there is no need to work with two screens.

The assembly:

Code: Select all

export preshift, copy_2plane

Export these labels to outside the assembly module.

Code: Select all

;void preshift(char* buffer)
; preshift data in buffer
; buffersize =16*32000 bytes
; 2 bitplane data
preshift:
   move.l  d3,-(sp)
   move.w  #8000-1,d0
   move.w  (a0)+,d1
   move.w  (a0)+,d2
.loop0:
   lea     (a0),a1
   swap    d1
   swap    d2
   move.w  (a0)+,d1
   move.w  (a0)+,d2
   swap    d1
   swap    d2
   moveq   #14,d3
.loop1:
   lea     32000-4(a1),a1
   rol.l   #1,d1
   rol.l   #1,d2
   move.w  d1,(a1)+
   move.w  d2,(a1)+
   dbra    d3,.loop1
   rol.l   #1,d1
   rol.l   #1,d2
   dbra    d0,.loop0
   move.l  (sp)+,d3
   rts

Straight forward preshifting. The source address is in A0 as it is a char* according to the C prototype.

Code: Select all

;void copy_2plane(char* src, char* dst)
;copy 2 bitplane data from src to dst (screen)
copy_2plane:
   movem.l d0-d7/a2-a3,-(sp)
   REPT 200
   movem.l (a0)+,d0-d7/a2-a3
   move.l  d0,(a1)
   move.l  d1,1*8(a1)
SNIP
   move.l  a3,19*8(a1)
   lea     160(a1),a1
   lea     80(a0),a0
   ENDM
   movem.l (sp)+,d0-d7/a2-a3
   rts

Simple copy. Source en destination address are in A0 and A1. I am using the REPT macro to generate code for 200 lines (a loop should be fast enough too). Don't forget to save the registers.

Have fun,

Hans Wessels
You do not have the required permissions to view the files attached to this post.

User avatar
bolda
Atari freak
Atari freak
Posts: 50
Joined: Fri Feb 28, 2003 8:34 am
Location: Solihull, UK

Postby bolda » Fri Nov 10, 2006 12:45 pm

Great stuff, thanks Nyh! I'm looking forward to learning a lot from this thread. :D

Will have a tinker with this stuff over the weekend.

Andy
10 HOME
20 SWEET
30 GOTO 10

User avatar
Nyh
Atari God
Atari God
Posts: 1496
Joined: Tue Oct 12, 2004 2:25 pm
Location: Netherlands

Making it more interesting

Postby Nyh » Fri Nov 17, 2006 10:28 am

I hadn't finished and released the previous code as I realized there was something more interesting in the code. With a simple change in the preshift routine and some extra memory you can display the background picture on any position. And as I was making the code more interesting anyway I decided to move the text too.

Working at the code I noticed I was duplicating the file loading code so it was moved in it's own function:

Code: Select all

int load_data(char* path, void* dst, long size)
{
  FILE *f;
  f=fopen(path,"rb");
  if(f==NULL)
  {
    printf("Source file: %s open error!\n", path);
    return -1;
  }
  fread(dst, 1, size, f);
  fclose(f);
  return 0;
}

I decided to let the background picture bounce in y direction while keeping the left right movement in x-position. The let the picture bounce I generate a bounce table. The values in the bounce table can be added to the x-offset without any additional calculations:

Code: Select all

    {
      int i;
      float x;
      for(i=0;i<BOUNCE>=muse)
  {
    p=mus;
  }
  *q=0;
  *r=*p++;
  *q=1;
  *r=*p++;
  *q=2;
  *r=*p++;
  *q=3;
  *r=*p++;
  *q=4;
  *r=*p++;
  *q=5;
  *r=*p++;
  *q=6;
  *r=*p++;
  *q=7;
  *r=*p++;
  *q=8;
  *r=*p++;
  *q=9;
  *r=*p++;
  *q=10;
  *r=*p++;
  *q=11;
  *r=*p++;
  *q=12;
  *r=*p++;
  *q=13;
  *r=*p++;
  musp=p;
}

The next code is the heart of the 'demo'. To see the processor time left I change the border color to red before the vsync() routine and back to the picture background color after the vsync(). The copy_2plane() routine has now three parameters. Position of the background, position of the foreground and the screen address. As these are all pointers and Pure C only passes two pointers by address register (the other pointers will be placed on the stack) I cast the last pointer into a long so it will be passed as a long in D0. Naughty but fast. :-)

Code: Select all

void copy_2plane(char* src1, char* src2, long dst);
...

      *((int*)0xff8240UL)=0x700;
      vsync();
      *((int*)0xff8240UL)=*colors;
      copy_2plane(buf+(i&0xf)*32000+bounce[k]+((i&0xff0)>>2),txt+j*80, (long)scr);
      do_music();

As the copy_2plane() function is moving a lot of data I want to use as many registers as possible. I need 3 address registers for source 1, source 2 and destination address. That leaves 13 registers for data (8 data registers and 5 address registers). A7 is used as stack pointer and cannot be used either, or can it? On the 68000 A7 is used as stack pointer during interrupts, the processors stores the status register and the return address on the stack and the interrupt routines will save registers on the stack. All this is on the supervisor stack. You can use the user stack without problems. So in the copy_2plane() routine I go to user mode and at the end of the routine I go back to supervisor mode using a trap #3 call. Before we can use trap #3 we have to install the trap handler. This is done in C:

Code: Select all

    old_trap3=*(void **)0x8c;
    *(void**)0x8c=trap3_handler;

The trap #3 handler itself is assembley:

Code: Select all

trap3_handler:
   move.l  save_ssp,sp         ; restore stack
   movem.l (sp)+,d3-d7/a2-a6; restore registers
   rts

and works only in close cooperation with the copy_2plane() routine because the trap #3 handler finishes what the copy_2plane() routine starts. Registers and supervisor stack pointer saved in copy_2plane() are restored in the trap #3 handler.

Code: Select all

;void copy_2plane(char* src1, char* src2, long dst)
;copy 2 bitplane data from src1 and src2 to dst (screen)
copy_2plane:
   movem.l d3-d7/a2-a6,-(sp)
   move.l  sp,save_ssp
   and     #$fff,sr         ; go user!
   move.l  sp,save_usp

   move.l  d0,a2
   REPT 200
   movem.l (a0)+,d0/d2/d4/d6/a3/a5/a7
   movem.l (a1)+,d1/d3/d5/d7/a4/a6
   movem.l d0-d7/a3-a7,(a2)
   movem.l (a1)+,d0/d2/d4/d6/a3/a5/a7
   movem.l (a0)+,d1/d3/d5/d7/a4/a6
   movem.l d0-d7/a3-a7,1*52(a2)
   movem.l (a0)+,d0/d2/d4/d6/a3/a5/a7
   movem.l (a1)+,d1/d3/d5/d7/a4/a6
   movem.l d0-d7/a3-a7,2*52(a2)
   lea     160-4(a2),a2
   move.l  (a1)+,(a2)+
   lea     80(a0),a0
   ENDM

   move.l  save_usp,sp   
   trap    #3

trap3_handler:
   move.l  save_ssp,sp         ; restore stack
   movem.l (sp)+,d3-d7/a2-a6; restore registers
   rts

At the end of the C code we restore everything to normal. The trap #3 handler is removed and the music is stopped by setting the volume of all three channels to 0.

Code: Select all

  { /* exit */
    { /* kill mus */
      char *p=(char*)0xffff8800UL;
      *p=8;
      p[2]=0;
      *p=9;
      p[2]=0;
      *p=10;
      p[2]=0;
    }
    vsync();
    {
      int i;
      for(i=0;i<16;i++)
      {
        ((int*)0xff8240UL)[i]=old_colors[i];
      }
    }
    *(void **)0x8c=old_trap3;
    *(char*)0xff8260UL=old_res;
    *(long*)0xFF8200UL=old_scrp;
  }


Of course the possibilities of this little demo haven't ended here. By using some more memory and preshifting the foreground picture too both fore and background can be placed on arbitrary positions. It won't cost much processor time, only some extra memory. That last modification is left as an exercise to the reader.

Next week I think we will make a small detour into picture conversion.

Have fun,

Hans Wessels
You do not have the required permissions to view the files attached to this post.

User avatar
karlm
Atari Super Hero
Atari Super Hero
Posts: 713
Joined: Thu Nov 13, 2003 4:09 am
Location: Top of the World - Australia

Postby karlm » Tue Nov 21, 2006 11:14 pm

Nice work Nyh.

Am looking forward to part 2.

Cheers

karlm.

User avatar
Nyh
Atari God
Atari God
Posts: 1496
Joined: Tue Oct 12, 2004 2:25 pm
Location: Netherlands

Work in progress

Postby Nyh » Fri Nov 24, 2006 1:40 pm

As promised now something for reading and converting pictures. Work in progress. As you might have read on this forum I am developing a plug-in for the windows picture viewer IrfanView (http://www.irfanview.com to read Atari ST picture formats. The plug-in generates from the Atari ST input files a windows .BMP file.

This project has two parts:
1 the atarist.c and the atarist.h files
These files will become the plug-in for IrfanView.

2 the tst2bmp.c and winbase.h files
These files are to test the routines. As I am developing on the Atari I do not have windows include files. The tst2bmp.c file is the test environment. It takes files to be converted from the commandline, calls the conversion routine and saves the resulting .BMP file.

What makes the project interesting is endianity problems. The 68000 is a Big endian processor. Windows is running on a little endian processor. (http://en.wikipedia.org/wiki/Endian)
Also the size of the 'int' type differs on the two systems. Some clean C-programming is needed.

The main function reads the names of the files to be converted from the commandline, passes the name to the converion routine, prints the results and saves the resulting .BMP file. While calculating the filesize from the info in the .BMP file you can see a typical endian clean conversion from bytes to a long:

Code: Select all

int main(int argc, const char *argv[])
{
  char error[256];
  char comp[256];
  unsigned char *p;
  while(--argc>0)
  {
    *error=0;
    *comp=0;
    p=ReadAtariST((char *)argv[argc], error, comp);
    printf("File: %s\nError: %s\nCompression: %s\n", argv[argc], error, comp);
    if(p!=NULL)
    {
      char naam[256];
      unsigned long size;
      size_t len;
      FILE *f;
      strcpy(naam, argv[argc]);
      len=strlen(naam);
      strcpy(naam+len-3,"bmp");
      size=p[5];
      size<<=8;
      size+=p[4];
      size<<=8;
      size+=p[3];
      size<<=8;
      size+=p[2];
      f=fopen(naam, "wb");
      if(f==NULL)
      {
        printf("File open error: %s\n", naam);
      }
      else
      {
        fwrite(p, 1, size, f);
        fclose(f);
      }
      free(p);
    }
  }
  return 0;
}


tst2bmp.c provides also the windows GlobalAlloc() function. It is simply replaced b a malloc(). The (void)uFlags; is to suppress the warning that a variable is never used.

Code: Select all

void* GlobalAlloc(int uFlags, long dwBytes)
{
  (void)uFlags;
  return malloc(dwBytes);
}


In atarist.c the most important function is: ReadAtariST(). This function will be called from IrfanView.

Code: Select all

HANDLE ReadAtariST(char *fileName, char *errorText, char *compressionText)
char *fileName: pointer to file name of the file to be converted
char *errorText: poiter to (by caller provided) error text space (size MAX_PATH)
char *compressionText: pointer to (by caller provided) compression text space (size MAX_PATH)

The function determines the picture type from the file extension and calls the right function to convert the file to a .BMP file. Up till now the following formats are supported: PI1, PI2, PI3, PC1, PC2, PC3, TN1, TN2, TN3, TNY, PAC, DOO, NEO, SPU, SPC and SPS. I still want to add the .SPX format. If you have a format I want to be supported too please drop me a note.

The functions for reading a specific format open and read the file and convert it to the standard Atari ST screen format including an array with the colors. The spectrum function convert the picture in the standard SPU format. Now I have the following functions:

Code: Select all

HANDLE degas(char *fileName,char *errorText,char *compressionText);
HANDLE degas_elite(char *fileName,char *errorText,char *compressionText);
HANDLE neochrome(char *fileName,char *errorText,char *compressionText);
HANDLE stad(char *fileName,char *errorText,char *compressionText);
HANDLE tiny(char *fileName,char *errorText,char *compressionText);
HANDLE doo(char *fileName,char *errorText,char *compressionText);
HANDLE spectrum(char *fileName,char *errorText,char *compressionText, int type);


After the picture is converted in the standard format this standard format is converted to the .BMP format by one of these functions:

Code: Select all

HANDLE convert_mono(unsigned char* screen, unsigned int* colors);
HANDLE convert_med(unsigned char* screen, unsigned int* colors);
HANDLE convert_low(unsigned char* screen, unsigned int* colors);
HANDLE convert_spectrum(unsigned char* screen);

All these functions call a function to generate a standard .BMP header and this function also allocates the memory:

Code: Select all

unsigned char* create_bmp(unsigned char **start_data, unsigned long int x_size, unsigned long int y_size,
                          unsigned int bits, unsigned int used_colors,  unsigned int* atari_colors);


The code compiles fine with Atari Pure C and gcc under Linux using the commandline:
"-o tst2bmp atarist.c tst2bmp.c".

I am not quite finished yet this project. A least one format will be added and maybe I will make the function somewhat more fault tolerant (like correctly decoding a misnamed PI3 picture into a PI1 picture). But as most file formats except for their extension do not include man clues about the file type don't expect too much from it.

Basically these functions can become the core off a picture load library.

The reverse process, conversion of a .BMP file into one of these picture formats is left as an exercise to the reader.

Have fun,

Hans Wessels
You do not have the required permissions to view the files attached to this post.

Lautreamont
Obsessive compulsive Atari behavior
Obsessive compulsive Atari behavior
Posts: 103
Joined: Fri Jan 27, 2006 9:11 pm
Location: Friceland

Postby Lautreamont » Wed Nov 29, 2006 9:38 pm

At last I've tried Pure C. I'm still a bit lost with the editor.
Your thread can be very valuable because the doc is in German. Many thanks.

Nyh wrote:

Code: Select all

e:\pc\lib\original\PCSTART.s          ; startup code

I am not sure where this module is on a normal Pure C distribution. In the time I have been coding I have added multiple startup modules so I am not 100% sure if this can be found in a normal Pure C distribution. Please give me feedback on this.

It's there on the Pure C I downloaded from Reservoir Gods, and it seems they have customized it. Compiler flags were also set to generate 68040 code.
I got a linker error though. Fixed by typing "pcstart.o" instead.

Nyh wrote:When you cast a pointer to char into a pointer to int or long be sure the pointer is on an even address otherwise bombs will greet you as soon as you dereference the pointer.

That makes me wonder about structs. Do I have to pad them to an even size ?

User avatar
Nyh
Atari God
Atari God
Posts: 1496
Joined: Tue Oct 12, 2004 2:25 pm
Location: Netherlands

Postby Nyh » Wed Nov 29, 2006 11:09 pm

Lautreamont wrote:
Nyh wrote:When you cast a pointer to char into a pointer to int or long be sure the pointer is on an even address otherwise bombs will greet you as soon as you dereference the pointer.

That makes me wonder about structs. Do I have to pad them to an even size ?

No, the compiler will add padding when needed in structs.

Hans Wessels

User avatar
karlm
Atari Super Hero
Atari Super Hero
Posts: 713
Joined: Thu Nov 13, 2003 4:09 am
Location: Top of the World - Australia

Postby karlm » Wed Mar 21, 2007 2:08 am

Nyh - have you got some more stuff for us!? (please, please!?)

cheers

karlm

User avatar
Nyh
Atari God
Atari God
Posts: 1496
Joined: Tue Oct 12, 2004 2:25 pm
Location: Netherlands

Postby Nyh » Wed Mar 21, 2007 9:56 am

karlm wrote:Nyh - have you got some more stuff for us!? (please, please!?)

Like what?

Don't ask for the world but if can can do something with it in a few lost moments I will.

Hans Wessels

User avatar
karlm
Atari Super Hero
Atari Super Hero
Posts: 713
Joined: Thu Nov 13, 2003 4:09 am
Location: Top of the World - Australia

Postby karlm » Thu Mar 22, 2007 9:41 pm

Not expecing the world, don't worry :)

Would like to see if we could do rasters or vu meters in Pure C. Rasters, similar to the old LSD/Was Not Was menus.

Very simple (I hope!) stuff.

Just an extention of what you've been doing.

One question: would PureC be fast enough to cope with turning off borders, etc? Obvioulsy if we're using inline asm it should be ok, but just wondering because all the examples I've ever seen have been assembler, and PureC being a higher level language doesn't have as 'tidy' routines once it compiles (compared to assembler...)

(I'm thinking of the later Medway menus where the scoller and vu meters were in the bottom border, doing this though would use up more cycles though?)

Many questions, hope they are not too dumb though :(

Thanks heaps Nyh!

karlm.

User avatar
Nyh
Atari God
Atari God
Posts: 1496
Joined: Tue Oct 12, 2004 2:25 pm
Location: Netherlands

Postby Nyh » Fri Mar 23, 2007 9:46 am

karlm wrote:Would like to see if we could do rasters or vu meters in Pure C. Rasters, similar to the old LSD/Was Not Was menus.

VU-meters are very simple to do. For rasters there are multiple ways: using interrupts or synchro coding. I always liked synchro coding but I am afraid most people won't like it at all.

[/quote]One question: would PureC be fast enough to cope with turning off borders, etc? Obvioulsy if we're using inline asm it should be ok, but just wondering because all the examples I've ever seen have been assembler, and PureC being a higher level language doesn't have as 'tidy' routines once it compiles (compared to assembler...)[/quote]
Opening upper and lower border shouldn't be any problem with Pure C. For the left and right border I first have to check the accepted timing and then to see whether one it can be done in C.

[/quote](I'm thinking of the later Medway menus where the scoller and vu meters were in the bottom border, doing this though would use up more cycles though?)[/quote]
Hardly. Opening the lower border doesn't take much time. Especially if you use it as a 'V-sync'. It does't matter much where you do things like scrollers and VU-meters.

I will see if I can write some border opening routines the coming time.

Hans Wessels

User avatar
karlm
Atari Super Hero
Atari Super Hero
Posts: 713
Joined: Thu Nov 13, 2003 4:09 am
Location: Top of the World - Australia

Postby karlm » Sun Mar 25, 2007 11:56 pm

Thanks in advance Nyh :)

cheers

karlm


Social Media

     

Return to “C / PASCAL etc.”

Who is online

Users browsing this forum: No registered users and 2 guests