Trying to understand PEEK with IntyPak

Brian's Man Cave · June 16, 2021

Hey! New here

I have just started learning intybasic from Oscar's book, and I do have a basic understanding of Basic programming.

In the examples folder for IntyBasic, I was trying to decipher how intyPak works. Just wondering if someone can break down for me what exactly this code is doing?

    IF dir = 0 THEN #c = PEEK($0201+X1/8+Y1/8*20):IF #c <> (BG06+FG_YELLOW) AND #c <> 0 THEN dir = 4
   IF dir = 1 THEN #c = PEEK($01FF+X1/8+Y1/8*20):IF #c <> (BG06+FG_YELLOW) AND #c <> 0 THEN dir = 4
   IF dir = 2 THEN #c = PEEK($01EC+X1/8+Y1/8*20):IF #c <> (BG06+FG_YELLOW) AND #c <> 0 THEN dir = 4
   IF dir = 3 THEN #c = PEEK($0214+X1/8+Y1/8*20):IF #c <> (BG06+FG_YELLOW) AND #c <> 0 THEN dir = 4

Thanks for any help!

Brian

carlsson · June 16, 2021

The BACKTAB starts at $0200. I suppose that X1 and Y1 are sprite coordinates, which both are divided by 8 to get column and row. Row is then multiplied by 20 columns to get an index into the BACKTAB.

dir = 0 checks position $0200 + 1 + column + row*20

dir = 1 checks position $0200 - 1 + column + row*20

dir = 2 checks position $0200 - 20 + column + row*20 ($0200 - decimal 20 = $01EC)

dir = 3 checks position $0200 + 20 + column + row*20

BG06 = $0830 which is GRAM card #6, FG_YELLOW obviously is yellow foreground. I suppose the background is black so all the other bits are zero. Thus it checks if the position that is one row or column to the left/right/up/down of the current position either is blank (0) or contains the character BG06. If it contains neither, dir obviously is set to 4 whatever that means in the context.

Another way to put it probably could have been if you have the offsets in a data table:

offfset: DATA $0201, $01FF, $01EC, $0214

#c = PEEK(offset(dir) + X1/8 + Y1/8*20):IF #c<> ...

but I haven't tested if that goes through the compiler or works like I'd expect it to.

Edited June 16, 2021 by carlsson

Zendocon · June 16, 2021

51 minutes ago, Brian's Man Cave said:

In the examples folder for IntyBasic, I was trying to decipher how intyPak works. Just wondering if someone can break down for me what exactly this code is doing?

    IF dir = 0 THEN #c = PEEK($0201+X1/8+Y1/8*20):IF #c <> (BG06+FG_YELLOW) AND #c <> 0 THEN dir = 4
   IF dir = 1 THEN #c = PEEK($01FF+X1/8+Y1/8*20):IF #c <> (BG06+FG_YELLOW) AND #c <> 0 THEN dir = 4
   IF dir = 2 THEN #c = PEEK($01EC+X1/8+Y1/8*20):IF #c <> (BG06+FG_YELLOW) AND #c <> 0 THEN dir = 4
   IF dir = 3 THEN #c = PEEK($0214+X1/8+Y1/8*20):IF #c <> (BG06+FG_YELLOW) AND #c <> 0 THEN dir = 4

I never went through the IntyBASIC examples myself, but I can make an educated guess what's happening here.

PEEK behaves the same way as on the C=64; it directly returns the value in the specified address.

$200-$2ef points to each of the 240 (20x12) "background cards" on the screen. "X1/8" "Y1/8" and "*20" together implies we're looking at a certain sprite's position on screen, since each background card contains 8x8 pixels.

There's a colon in the middle of each line, so it might be easier to separate each of them into two lines.

My guess, based on "FG_YELLOW", is that this code snippet is looking for yellow pixels in a certain card, and if found, sets "dir=4" which probably prevents an object from moving.

Brian's Man Cave · June 16, 2021

From looking at the game, the pellets that the pakman character eats are yellow squares. I assume that has to do with BG06+FG_YELLOW..

the dir 0-3 is

IF dir = 0 THEN X1 = X1 + 1
   IF dir = 1 THEN X1 = X1 - 1
   IF dir = 2 THEN Y1 = Y1 - 1
   IF dir = 3 THEN Y1 = Y1 + 1

Edited June 16, 2021 by Brian's Man Cave

+cmadruga · June 16, 2021

BG06 means position 6 in GRAM.

Look at the DEFINE instruction and check which bitmap is being loaded in that position.

+nanochess · June 17, 2021

I should modernize that code. It is reading the screen to detect if the path is feasible (only can walk over a yellow dot or an empty space)

   IF dir = 0 THEN #c = #backtab(X1/8+Y1/8*20+1):IF #c <> (BG06+FG_YELLOW) AND #c <> 0 THEN dir = 4
   IF dir = 1 THEN #c = #backtab(X1/8+Y1/8*20-1):IF #c <> (BG06+FG_YELLOW) AND #c <> 0 THEN dir = 4
   IF dir = 2 THEN #c = #backtab(X1/8+Y1/8*20-20):IF #c <> (BG06+FG_YELLOW) AND #c <> 0 THEN dir = 4
   IF dir = 3 THEN #c = #backtab(X1/8+Y1/8*20+20):IF #c <> (BG06+FG_YELLOW) AND #c <> 0 THEN dir = 4

You can see it checks the current direction (each sentence IF dir = ) and then reads the screen (player x1 coordinate divided by 8, and y1 coordinate divided by 8 to get the row/column)

The row is multiplied by 20 to get the offset inside the screen and then it applies an offset to "see" ahead of the current position of the player.

The offset is per the direction, one card to the left is -1, one card to the right is 1, one card upward is -20, one card downward is 20.

If the screen card doesn't contain a yellow dot nor an empty space then it stops the player (by doing dir = 4)

Brian's Man Cave · June 17, 2021

So I am playing around with that code to see if I can have the sprite not pass through an object, but its doing weird things. Am I missing something?

INCLUDE "constants.bas"
x = 50
y = 50
CLS
wait
define 0,2,parts_1
wait

game_loop:

#backtab(120) = $807 + 0 * 8
#backtab(190) = $807 + 0 * 8
#backtab(90) = $807 + 1 * 8

sprite 0, $0300 + x, $0100 + y, $0807 + 1 * 8 'hat
wait

if cont1.up then next_dir = 0
if cont1.down then next_dir = 1
if cont1.left then next_dir = 2
if cont1.right then next_dir = 3

IF next_dir = 0 THEN #c = #backtab(X/8+Y/8*20+1):IF #c <> 0 THEN next_dir = 4
IF next_dir = 1 THEN #c = #backtab(X/8+Y/8*20-1):IF #c <> 0 THEN next_dir = 4
IF next_dir = 2 THEN #c = #backtab(X/8+Y/8*20-20):IF #c <> 0 THEN next_dir = 4
IF next_dir = 3 THEN #c = #backtab(X/8+Y/8*20+20):IF #c <> 0 THEN next_dir = 4

if next_dir = 0 then y = y - 1
if next_dir = 1 then y = y + 1
if next_dir = 2 then x = x - 1
if next_dir = 3 then x = x + 1

next_dir = 4

goto game_loop

parts_1:
BITMAP "........"
BITMAP "XXXXXXXX"
BITMAP "..XXXX.."
BITMAP "..XXXX.."
BITMAP "...XX..."
BITMAP "..XXXX.."
BITMAP "..XXXX.."
BITMAP "XXXXXXXX"

BITMAP "XXXXXXXX"
BITMAP "XXXXXXXX"
BITMAP "XXXXXXXX"
BITMAP "XXXXXXXX"
BITMAP "XXXXXXXX"
BITMAP "XXXXXXXX"
BITMAP "XXXXXXXX"
BITMAP "XXXXXXXX"

carlsson · June 17, 2021

There may be several issues, but one that strikes me right away is that you are crossing directions with each other.

I think your code at the very least should look like this:

IF next_dir = 3 THEN #c = #backtab(X/8+Y/8*20+1):IF #c <> 0 THEN next_dir = 4
IF next_dir = 2 THEN #c = #backtab(X/8+Y/8*20-1):IF #c <> 0 THEN next_dir = 4
IF next_dir = 0 THEN #c = #backtab(X/8+Y/8*20-20):IF #c <> 0 THEN next_dir = 4
IF next_dir = 1 THEN #c = #backtab(X/8+Y/8*20+20):IF #c <> 0 THEN next_dir = 4

Edited June 17, 2021 by carlsson

mmarrero · June 18, 2021

One issue is that Y needs to be adjusted by 1. I fixed the code, made it more readable, used constants, and shows a sprite aligned to grid/backtab.

To allow sprite closer to the obstacle, I'd use hardware collision, or, do an extra test where x\4 and y\4 (or x\8,y\8) are zero. I remember programming a maze game when I was young, the approach I used (which might have been wrong): grid-based (8x8) x,y coordinates, and a separate xoffset,yoffset (I think it was -4 to +4) to transition from one grid to another.

Spoiler

OPTION EXPLICIT
INCLUDE "constants.bas"
DIM x,y,next_dir,#c
x = 50:y = 50
CLS:wait:define 0,3,parts_1:wait
CONST DIR_NONE=0:CONST DIR_U=1:CONST DIR_D=2:CONST DIR_L=3:CONST DIR_R=4
'---
#backtab(120) = BG00 + CS_YELLOW:#backtab(190) = BG01 + CS_GREEN:#backtab(90) = BG01 + CS_TAN
PRINT AT 0 COLOR CS_BLUE,"x,y:":PRINT AT 20,"grid:"
game_loop:
    sprite 0, x + VISIBLE + HIT + 4, y + ZOOMY2 + 4, SPR00 + SPR_LIGHTBLUE 'hat
    sprite 1, (x/8)*8 + VISIBLE + HIT + 8, ((y-1)/8)*8 + ZOOMY2 + 8, SPR02 + SPR_BLUE 'cursor
    wait
    PRINT AT 05, <3>x,",",<3>y '--x,y
    PRINT AT 25, <3>(x/8),",",<3>((y-1)/8) '--x,y grid
    PRINT AT 14, <5>#c
    '--controller---- no diagonals
    IF cont1.left then
        next_dir = DIR_L
    ELSEif cont1.right then
        next_dir = DIR_R
    ELSEIF cont1.up then
        next_dir = DIR_U
    ELSEif cont1.down then
        next_dir = DIR_D
    ELSE
        next_dir = DIR_NONE
    END IF
    '--slow it down
    IF CONT1.BUTTON THEN WAIT:WAIT
    '--verify direction----
    IF next_dir = DIR_L THEN
         #c = #backtab((X/8) + (((Y-1)/8)*20) -1):IF #c = 0 then x=x-1
    ELSEIF next_dir = DIR_R THEN
        #c = #backtab((X/8) + (((Y-1)/8)*20) +1):IF #c = 0 then x=x+1
    ELSEIF next_dir = DIR_U THEN
        #c = #backtab((X/8) + (((Y-1)/8)*20) -20):IF #c = 0 then y=y-1
    ELSEIF next_dir = DIR_D THEN
        #c = #backtab((X/8) + (((Y-1)/8)*20) +20):IF #c = 0 then y=y+1
    END IF
goto game_loop
parts_1:
BITMAP "XXXXXXXX"
BITMAP "..XXXX.."
BITMAP "..XXXX.."
BITMAP "...XX..."
BITMAP "...XX..."
BITMAP "..XXXX.."
BITMAP "..XXXX.."
BITMAP "XXXXXXXX"
'---
BITMAP "XXXXXXXX":BITMAP "XXXXXXXX":BITMAP "XXXXXXXX":BITMAP "XXXXXXXX"
BITMAP "XXXXXXXX":BITMAP "XXXXXXXX":BITMAP "XXXXXXXX":BITMAP "XXXXXXXX"
'---
BITMAP "XXXXXXXX"
BITMAP "X      X":BITMAP "X      X":BITMAP "X      X"
BITMAP "X      X":BITMAP "X      X":BITMAP "X      X"
BITMAP "XXXXXXXX"

Brian's Man Cave · June 18, 2021

Thanks! I will play around with that.

My first attempt was to use the collision to detect a background pixel, but the sprite would stop when collision was made and then be stuck there.

I then made it move back a few spaces when a collision was made and that worked, but it looked like the sprite was bouncing off of it... not the effect I wanted.

I will have to try again

Lillapojkenpåön · June 28, 2021

I'm looking at this example and wondering how you make a new level? Start with garbage tables and slowly enter new numbers?

It would take a long time to build levels by entering numbers and not seeing how the level is gonna look, but maybe you get used to it?

carlsson · June 28, 2021

If you refer to the SCREEN command, the DATA can be constants instead of absolute numbers. It means GW could be a green wall, perhaps $0800 + 5 and WE could be a white exit, i.e. $0808 + 7. In that way, you can kind of get a human readable display if you have 20 DATA statements per row, it could look something like this:

  DATA GW,GW,GW,GW,GW,GW,GW,GW,GW,GW,GW,GW,GW,GW,GW,GW,GW,GW,GW,GW
  DATA GW,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,WE
  DATA GW,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,GW
  DATA GW,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,GW
  DATA GW,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,GW
  DATA GW,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,GW
  DATA GW,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,GW
  DATA GW,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,GW
  DATA GW,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,GW
  DATA GW,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,WE
  DATA GW,GW,GW,GW,GW,GW,GW,GW,GW,GW,GW,GW,GW,GW,GW,GW,GW,GW,GW,GW

Of course you could algorithmically draw levels too, using start and ending coordinates etc, depending on how detailed the levels are. The above example would almost be easier (but a little slower) to draw through FOR loops than using SCREEN to paste an entire screen.

Edited June 28, 2021 by carlsson

Lillapojkenpåön · June 28, 2021

Thanks! I like that alot better.

2 hours ago, carlsson said:

Of course you could algorithmically draw levels too, using start and ending coordinates etc, depending on how detailed the levels are. The above example would almost be easier (but a little slower) to draw through FOR loops than using SCREEN to paste an entire screen.

I would prefer FOR loops since that's what I'm used to, but have'nt found an example of that yet, just started experimenting and still very confused.

I'm guessing this

CLS

DEFINE DEF00,16,bitmaps

WAIT

copies the tiles to GRAM starting at $0800, says it's for Background GRAM cards, does cards mean 8x8 tiles basically?

I define my sprite in the same way so it also end up there, guess it counts as background?

tile indexes get stored to $0000 and forward.

So I'm a little confused what the for loops would do if all the graphics are where they are suppose to be?

Color them and make them visible? Or do they need to be copied to somewhere else?

Now that I wrote it down it seems pretty reasonable that the define just store the indexes and I have to copy the tiles to GRAM?

But I don't have to do that for the sprite??

Edited June 28, 2021 by Lillapojkenpåön

carlsson · June 29, 2021

GRAM is used for both BACKTAB (20x12 cards) and sprites (MOB) at the same time. The $0800 is not a memory address but an offset for setting the GRAM bit when putting cards onto the BACKTAB or using those as sprites. Each card on the BACKTAB is 8x8 pixels, while sprites can be either 8x8 or 8x16 (using two consecutive GRAM starting on an even index). Sprites also can be expanded horizontally and vertically, but retain the same resolution as before expansion.

Both FOR loops and the SCREEN command then places GRAM (or GROM) onto the BACKTAB. You can obviously put the same GRAM into many positions of the BACKTAB. Also as you note, the combination of foreground and background colours is defined within each BACKTAB card or sprite.

I think some of the samples like game2.bas or game3.bas would give you some ideas, if you can't find any other code. Actually those two have alternative ways to define simple levels, though in the example limited to one character backgrounds. Then again those samples are more than 7 years old and IntyBASIC has advanced a lot since then so perhaps those should not be taken as de facto examples how to do things.

Lillapojkenpåön · June 29, 2021

Thanks! I've drawn the character backgrounds allready, I can't find a game3 tho?

Other than the unnecessary nested loops, what am I doing wrong here?

RESTORE level1

FOR y = 0 TO 11

FOR x = 0 TO 19

READ #line

POKE BACKTAB_ADDR+x*y,#line

NEXT x

NEXT y

WAIT

level1
  DATA GW,GW,GW,GW,GW,GW,GW,GW,GW,GW,GW,GW,GW,GW,GW,GW,GW,GW,GW,GW
  DATA GW,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,WE
  DATA GW,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,GW
  DATA GW,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,GW
  DATA GW,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,GW
  DATA GW,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,GW
  DATA GW,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,GW
  DATA GW,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,GW
  DATA GW,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,GW
  DATA GW,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,WE
  DATA GW,GW,GW,GW,GW,GW,GW,GW,GW,GW,GW,GW,GW,GW,GW,GW,GW,GW,GW,GW

+DZ-Jay · June 29, 2021

11 hours ago, Lillapojkenpåön said:

Thanks! I like that alot better.

I would prefer FOR loops since that's what I'm used to, but have'nt found an example of that yet, just started experimenting and still very confused.

I'm guessing this

    CLS

    DEFINE DEF00,16,bitmaps

    WAIT

copies the tiles to GRAM starting at $0800, says it's for Background GRAM cards, does cards mean 8x8 tiles basically?

I define my sprite in the same way so it also end up there, guess it counts as background?

tile indexes get stored to $0000 and forward.

So I'm a little confused what the for loops would do if all the graphics are where they are suppose to be?

Color them and make them visible? Or do they need to be copied to somewhere else?

Now that I wrote it down it seems pretty reasonable that the define just store the indexes and I have to copy the tiles to GRAM?

But I don't have to do that for the sprite??

There are three different concepts here: The screen, the graphics memory, and the background table.

What you think of as the screen is not really a traditional bitmap in which you plot individual pixels. Instead, it is a matrix of 8x8 pixel tiles, which we call cards. These cards, in turn, exist in graphics memory.

Graphics memory is itself subdivided into two types: Graphics ROM (GROM) and Graphics RAM (GRAM). The GROM is a set of 256 pre-defined 8x8 pixel pictures, which includes the built-in character set, as well as some simple geometric shapes and lines.

The GRAM is a special memory section that allows you to define your own 8x8 pixel pictures. It can hold up to 64 pictures.

Both GROM and GRAM can be used to "paint" the screen, by writing to the BACKTAB.

The BACKTAB is a 20 column x 12 row matrix of cards that correspond to the visual display and tell the video controller how to compose the screen.

Essentially, you write on each BACKTAB location which card number to use, whether it comes from GROM or GRAM, and what foreground and background colors to use, and the video controller will draw it for you.

To paint a background scene for a game, you typically need two things: a set of custom pictures to use, and the data describing which pictures go on which cards, and what colors to use for them.

Those are just the building blocks for your scene. The next step is to load your custom cards into GRAM, and then copy your scene description data into the BACKTAB.

In IntyBASIC, the DEFINE statement does the former, by loading any number of contiguous picture data into GRAM, starting at a specific index; and the SCREEN statement does the latter, by copying directly your scene data onto the BACKTAB.

I hope this offers some context on the code you are trying to understand.

dZ.

carlsson · June 29, 2021

2 hours ago, Lillapojkenpåön said:

POKE BACKTAB_ADDR+x*y,#line

You most probably want POKE BACKTAB_ADDR+y*20+x,#line

Or you could set #BACKTAB(y*20+x)=#line which is synthetic sugar for POKE into the screen matrix. I think it would generate the same code?

Of course if you use the SCREEN command instead, you'd paste it even faster and since your loops run across the entire display without modifying the data, it would be more obvious.

+DZ-Jay · June 29, 2021

19 minutes ago, carlsson said:

You most probably want POKE BACKTAB_ADDR+y*20+x,#line

Or you could set #BACKTAB(y*20+x)=#line which is synthetic sugar for POKE into the screen matrix. I think it would generate the same code?

And in case it is not obvious, what it means is described by the following formula:

BACKTAB_address = (base_address + (row * 20) + column)

In other words, “starting at the beginning of the BACKTAB, compute the position by counting 20 columns per row, and adding the position of the column for that row.”

Even though you can think of the BACKTAB as a matrix, in reality it is an array — a contiguous block or memory elements in a single list.

Like @carlsson says, you can either POKE a value into that location, or treat the BACKTAB as an array and assigning the value to a specific element in it.

dZ.

Edited June 29, 2021 by DZ-Jay

Lillapojkenpåön · June 29, 2021

Thanks for answering everything I was wondering comrades!!!!

Is 8 sprites, 228 8-bit variables and 47 16-bit variables an intyBASIC thing or an intellivision thing?

If $0800 turns on the GRAM bit could I use some number in the table to turn on a GROM bit to copy GROM numbers

to BACKTAB and use the same code, or do you have to use PRINT for those?

What's up with the rightmost pixels not being drawn?

+DZ-Jay · June 29, 2021

4 minutes ago, Lillapojkenpåön said:

Thanks for answering everything I was wondering comrades!!!!

Is 8 sprites, 228 8-bit variables and 47 16-bit variables an intyBASIC thing or an intellivision thing?

8 sprites is a hardware limitation.

There are also 16-bit and 8-bit RAM limitations, but the numbers you quote are specifically for IntyBASIC, since it reserves some RAM — albeit a small quantity — for its internal processes.

4 minutes ago, Lillapojkenpåön said:

If $0800 turns on the GRAM bit could I use some number in the table to turn on a GROM bit to copy GROM numbers

to BACKTAB and use the same code, or do you have to use PRINT for those?

Just do not use $0800, that is all. The graphics card index applies to GROM by default, and you need to set the special bit with $0800 to specify GRAM.

Just be aware that the different video modes have some limitations. For instance, the common Foreground/Background mode, Mode #2, only supports the first 64 pictures of GROM, which includes the character set, but not the geometric shapes.

Check out the IntyBASIC books for more details on the video modes, or ask here any specific questions you may have.

4 minutes ago, Lillapojkenpåön said:

What's up with the rightmost pixels not being drawn?

You mean, the right-most pixel of the right-most column of the BACKTAB cards?

That’s a limitation of the video hardware: it only displays 159 pixels across a raster line. *shrug*

dZ.

carlsson · June 29, 2021

8 sprites is a hardware feature of the STIC chip, just like the actual resolution is 159x96 pixels as you observed. It just happens to be that way on real hardware too.

The variable space is grafted out of various bits of system RAM in the system, which consists of both 8-bit and 16-bit RAM chips. If you use certain elements of the language like the music player or scrolling, some of the variable space will be consumed by those routines. If you were to program it on the bare metal, CP1610 machine code, you could choose freely what to store where but also you would have to know which memory addresses the system uses.

Offset $0000 would take symbols from GROM, like DZ-Jay indicates in his post right before mine.

Zendocon · June 29, 2021

10 minutes ago, Lillapojkenpåön said:

Is 8 sprites, 228 8-bit variables and 47 16-bit variables an intyBASIC thing or an intellivision thing?

That's an Intellivision thing. Depending on which functions of IntyBASIC you're using, you might have even fewer variables left over for use.

11 minutes ago, Lillapojkenpåön said:

What's up with the rightmost pixels not being drawn?

I'm pretty sure it has to do with the horizontal scrolling capability, but that's only a guess.

carlsson · June 29, 2021

Perhaps it is a good time to already now introduce JLP memory expansion which is available through emulation and for programs running on the LTO! Flash + possible standalone carts that has this circuitry. It gives you another 8,000 decles (16-bit variables) if your program is very variable intensive. Note though that other emulators that doesn't support this extension or possibly simpler forms of cartridges would not be able to run the program if it depends on the memory expansion. Usually you should be very conservative with space, but since I know you have previous experience from programming the Atari 2600, that should go without saying.

Lillapojkenpåön · June 29, 2021

1 hour ago, DZ-Jay said:

Check out the IntyBASIC books for more details on the video modes, or ask here any specific questions you may have.

Thanks!!

I tried

MODE SCREEN_FOREGROUND_BACKGROUND ' Set foreground/background mode

and added a bg color to a card

CONST GW = $0800 + 0 + FG_BLUE + BG_TAN

but that was apparently not how you use it

I also tried not using $0800 but it just uses my GRAM card no matter what number I use?

1 hour ago, carlsson said:

Perhaps it is a good time to already now introduce JLP memory expansion

NO! Not good time but good to know about in the future!

Lillapojkenpåön · June 29, 2021

Lol, my builds have been failing for a while and my batch script ran the last working bin, so that explains the GRAM card,

still don't know how to use the mode tho.

Trying to understand PEEK with IntyPak

Recommended Posts

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Join the conversation

Recently Browsing 0 members