Jump to content

Photo

ATASCII -> screen code in MODE1

ATASCII screen code 20x24 text mode mode 1

9 replies to this topic

#1 Fabrizio Caruso OFFLINE  

Fabrizio Caruso

    Star Raider

  • 77 posts

Posted Fri Sep 29, 2017 4:16 PM

Hi everyone!

 

How can I transform ALL ATASCII codes including 128-255 into screen codes in mode 1 (20x24 5 color text mode)?

 

I am having a hard time with the ones above 127. Subtracting 128 and applying the same rules as 0-127 does not work.

 

For the ones below 128 I have used:

if(screen_code<128)
{
    if(image->_imageData<32)
    {
        screen_code+=32;
    }
else if(image->_imageData<96)
    {
        screen_code-=32;
    }
}

but doing the same (after subtracting 128) does not work.

I need to get the write screen code with the RIGHT COLOR.

  Fabrizio

 

Edited by Fabrizio Caruso, Fri Sep 29, 2017 4:24 PM.


#2 Stephen ONLINE  

Stephen

    Quadrunner

  • 7,263 posts
  • A8 Gear Head
  • Location:No longer in Crakron, Ohio

Posted Fri Sep 29, 2017 5:12 PM

When in mode 1 & 2 (BASIC modes 1 & 2), you can only display 64 characters at a time, not all 128.  I believe this was done because certain high bits determined character colour?



#3 Wrathchild ONLINE  

Wrathchild

    River Patroller

  • 2,123 posts
  • Location:Reading, UK.

Posted Fri Sep 29, 2017 5:16 PM

You've only 64 characters to play with?

So you simply have a char value of 0-63 and the top two high bits control the colour of 0-3.

 

A test app shows this:

 

10 GRAPHICS 1+16
15 POKE 708,3*16+4
20 POKE 709,0*16+14
25 POKE 710,8*16+8
30 POKE 711,12*16+10
35 POKE 559,33
40 A=PEEK(88)+256*PEEK(89)
45 FOR I=0 TO 255
50 POKE A+I,I
55 NEXT I
60 GOTO 60

gr1_test.png

 

So if you want a RED_O then its $2F, WHITE_O is $2F+$40, BLUE_O is $2F + $80 and GREEN_O is $2F + $C0


Edited by Wrathchild, Fri Sep 29, 2017 5:20 PM.


#4 sanny ONLINE  

sanny

    Moonsweeper

  • 337 posts
  • Location:Bavaria

Posted Fri Sep 29, 2017 5:32 PM

Yes. In this mode you only have 64 chars available. But more colors....

 

The font generator (memory, default $E000) in this mode, is just 512 bytes (and can start at any 512-byte boundary), while the "regular" font generator (BASIC mode 0, 128 chars) must be at a 1024-byte boundary.


Edited by sanny, Fri Sep 29, 2017 5:36 PM.


#5 Wrathchild ONLINE  

Wrathchild

    River Patroller

  • 2,123 posts
  • Location:Reading, UK.

Posted Fri Sep 29, 2017 5:44 PM

Looking at your current sources here you should:

 

1) fixup the color assignments

// 128 -> YELLOW; 32 -> RED; 160-> BLUE; 0 -> WHITE
#define _ATARI_MODE1_WHITE 0
#define _ATARI_MODE1_WHITE2 64
#define _ATARI_MODE1_RED 32
#define _ATARI_MODE1_YELLOW 128
#define _ATARI_MODE1_BLUE 160

to

// 0 -> RED; 64 -> WHITE; 128 -> BLUE; 192-> YELLOW
#define _ATARI_MODE1_RED 0
#define _ATARI_MODE1_WHITE 64
#define _ATARI_MODE1_BLUE 128
#define _ATARI_MODE1_YELLOW 192

2) at the start of INIT_IMAGES use these defines as values assigned to your _color properties.

 

3) don't add the colour to the _imageData properties.

 

4) Then '_draw' method only needs to contain:

POKE(PEEK(88)+PEEK(89)*256+(x+X_OFFSET)+(y+Y_OFFSET)*20,image->_imageData + image->_color);

Though I'd recommend assigning the PEEK(88)+PEEK(89)*256 to a variable after the _graphics call in INIT_GRAPHICS and then use that in _draw (and in _delete) instead to save some time.


Edited by Wrathchild, Fri Sep 29, 2017 5:46 PM.


#6 dmsc OFFLINE  

dmsc

    Moonsweeper

  • 443 posts
  • Location:Viņa del Mar, Chile

Posted Fri Sep 29, 2017 9:12 PM

Hi!,
 

4) Then '_draw' method only needs to contain:

POKE(PEEK(88)+PEEK(89)*256+(x+X_OFFSET)+(y+Y_OFFSET)*20,image->_imageData + image->_color);
Though I'd recommend assigning the PEEK(88)+PEEK(89)*256 to a variable after the _graphics call in INIT_GRAPHICS and then use that in _draw (and in _delete) instead to save some time.


Also, you can use "PEEKW" instead of your two PEEK, this should be the same as asigning to a variable:
 
POKE( PEEKW(88) + (x+X_OFFSET) + (y+Y_OFFSET)*20, image->_imageData + image->_color);
Or better yet, you can define a macro like:
 
#define SCREEN(x,y) ((unsigned char *)*(unsigned *)88)[x + y * 20]
And use it like:
 
 SCREEN(x + X_OFFSET,y + Y_OFFSET) = image->_imageData + image->_color;


#7 Fabrizio Caruso OFFLINE  

Fabrizio Caruso

    Star Raider

  • Topic Starter
  • 77 posts

Posted Sat Sep 30, 2017 12:45 AM

Thanks guys! This solves my problem for the display of the characters through POKEs!


It does not answer my question about the ATASCII conversion, though. The question is not so important now because I could always use POKEs.
I am also printing them through cputc() or cprintf() or printf() and I would like to know how to convert them to the corresponding ATASCII that I can use with conio.h or stdio.h in the few places where I still use conio.h or stdio.h.



#8 Wrathchild ONLINE  

Wrathchild

    River Patroller

  • 2,123 posts
  • Location:Reading, UK.

Posted Sat Sep 30, 2017 4:26 AM

Come on... your OP doesn't reference using the conio routines so we aren't psychic, its been your choice to mix direct access and use of functions in your porting. Your approach seems quite random (and I appreciate you have said that this is one of a multitude of ports) and you give an impression of not experimenting otherwise you'd be saying "this is what I've done, this is what I expected, this is what happened".

Conio functions are not going to factor for the graphics mode you are in. Additionally, the cc65 suite will code the strings in your source code in a certain way. So what I'd recommend is to create your own function that takes a string (unsigned char * ) and a colour (0-3) and then loops through and takes the char value, ands it with 63 and then ors it with colour*64.
Try that and if the Ascii conversion is needed, e.g. A as colour 0 doesn't show as an 'A', then the solution will probable be just to subtract 32.

#9 Irgendwer OFFLINE  

Irgendwer

    Stargunner

  • 1,410 posts
  • Location:Germany

Posted Sat Sep 30, 2017 12:29 PM

It does not answer my question about the ATASCII conversion, though.

 

I have provided mappings for the two different Atari character types a while ago.

 

See

https://github.com/c...i/charmapping.c

 

for an example.


Edited by Irgendwer, Sat Sep 30, 2017 1:32 PM.


#10 Fabrizio Caruso OFFLINE  

Fabrizio Caruso

    Star Raider

  • Topic Starter
  • 77 posts

Posted Sat Sep 30, 2017 2:45 PM

@Wrathchild, indeed mixing conio and direct access is not a good thing!

I have been experiment quite a lot with conio.h on both CC65 and Z88DK (and even on CMOC for 6809-based computers) and I am opening issues on both projects.
My initial idea was to use conio as much as possible because it makes my code more portable. I am writing a sort of "universal" game for a multitude of 8-bit computers and consoles (currently about 40) and I want to use the same code as much as possible.

My code for the ATARI port was using ONLY conio.h until I realized conio.h is bugged on some targets (ATARI, ATMOS at least) in that 

it flips th 7th bit of the character at the position pointed by the latest gotoxy (as if the cursor were visible), as well as the character to the right of the latest printed character.

Then I started moving from conio.h to direct writes into video memory. I have kept conio only for the score but I may get rid of it. 
The reason why I have kept conio for the score is that it is common code used in 40 targets and I am trying to reduce avoidable target-specific code.
Thanks a lot for your suggestion on how to implement a good print function on mode 1!


Edited by Fabrizio Caruso, Sat Sep 30, 2017 2:54 PM.






Also tagged with one or more of these keywords: ATASCII, screen code, 20x24, text mode, mode 1

0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users