C7420 ?

The clock frequency of this module is only 3.547 MHz.

I've tried removing the text at the bottom, but that didn't help (in STORE/SCREEN mode).
I think you can make the game faster if you use the LINE command instead of SCREEN: this way only the specified line is being updated instead of the complete screen.

If you double the height or width of a character, you have to print it TWICE, otherwise you'll only see one half of this character. It is possible to have double and single sized characters together on the screen, so it doesn't really affect the display mode of the videochip.

The USR command is used to call a Z80 assembly subroutine. With the help of DATA and POKE commands you'll have to put the Z80 instructions in HEX code in a certain part of the RAM, then you can execute it with USR. So if you're familiar with Z80 assembly programs AND with this specific hardware, you could use it to write faster programs.

The Basic module and the G7400 console are actually two separate computers with their own CPU, ROM and RAM chips, which only exchange video and keyboard data. The G7400 console is nothing more than a dumb terminal for the C7420 Basic computer. You would have to study the disassembly's of the Basic interpreter and the 8048 ROM inside the cartridge of the Basic module to try to make it do anything that's not in the manual. I have dumps of these ROMs on my harddisc, so let me know if you would like to see them. I also have the service manual of the C7420 and the G7400.

I've done a test with the LINE command, and it made the ball move a lot faster.
I've done a few other optimizations, and now the ball takes about 25 steps per second.

Code:

010 INIT6
020 XBALL=10
030 YBALL=1
040 XDIR=1
050 YDIR=1
060 XMAX=39
070 YMAX=19
080 BOUNCE=50
085 STORE:PAGE
090 REM Main loop
100 IF XBALL<=1 THEN GOSUB 340
110 IF YBALL<=0 THEN GOSUB 390
120 IF XBALL>=XMAX THEN GOSUB 250
130 IF YBALL>=YMAX THEN GOSUB 300
140 CURSORX XBALL
150 CURSORY YBALL
160 PRINT " ";:LINE YBALL,YBALL
170 XBALL=XBALL+XDIR
180 YBALL=YBALL+YDIR
190 CURSORX XBALL
200 CURSORY YBALL
210 PRINT "O";:LINE YBALL,YBALL
220 GOTO 100
230 REM X>MAX
250 XDIR=-1
260 SOUND1
270 GOTO 430
280 REM Y>MAX
300 YDIR=-1
310 SOUND2
320 GOTO 430
330 REM X<1
340 XDIR=1
350 SOUND3
360 GOTO 430
370 REM Y<1
390 YDIR=1
400 SOUND4
410 GOTO 430
420 REM DISPLAY STATUS
430 CURSORX 1
440 CURSORY 20
445 BOUNCE=BOUNCE-1
450 PRINT "Bounces left:";BOUNCE;" ";
455 LINE 20,20
460 IF BOUNCE<=0 THEN GOTO 480
470 RETURN
480 DISPLAY:SCROLL
490 END

You have done an exellent job of optimizing the code and adapting to this flavor of Z80 Basic.
Your knowledge of the hardware MORE than compensates for your lack of the software language.

where we are at now:
We can make minor action text display games.

Performance quality:
you're estimating 1 character = 25 steps per second.
by following a static curve (which won't be the end result but is good for the planing stages)
you can assume the folowing:
2 animated text characters = 12 steps per second (1/2)
4 characters = 6 steps per second.
6 characters = 3 or 4 steps per second.

a PAP clone on your computer would require a maximum of 8 characters
(provided only one door is animated per step and an alternate End Stage animation is used.)
1 - pete
1 - pic OR key
5 - boulders
1 - door (1 door AT A TIME)

There are some other tricks, however.
a door does not require to be animated every step to get the point across smootly because it has a static location. you may animate a door every other step.
for example - pong.
a paddle and a ball would require 2 charcters (we'll let the paddle be only 1 character long for the sake of the example to avoid the moving platform example that i'll describe below.)
if you animate both of them ever frame then they would both move at the same speed. 50% each of the allowed speed would be used on each one.
but if you animate the ball every OTHER step, then the paddel would move 2x as fast as the ball.

in 2 steps the paddle can move 2 spaces and the ball can move 1. that is 33% to the ball and 66% speed to the paddle.

Observing this method you can alternate animating the boulders in a PAP clone.
supposeing no pick or key is on the screen, no door is animated, and all 5 boulers on the screen we would have the following animation sequence steps:

step 1:
pete
boulder 1
step 2:
pete
boulder 2
ect...
There are costs, however.
in the above example the end result would be pete moving about 5x faster than boulders.
and - to maintain the same speed regardless of wether all 5 boulders are displayed - you would still have to print something (such as a space) in a reserved area of the screen.
this will prevent pete from flying around super fast when there are no boulders on the screen and walking normal when all 5 are on the screen. (it equalizes the processor's speed)

certain larger animations are different.
for example: displaying a horizontal moving platform composed of the text "XXXXXXXXXX" = 2 characters per step.
the reason is because when the platform moves to the right you only place 1 character on the left most X (to erase it) and 1 character to the right of the right most text.

	Code:
	XXXXXXXX <- is here _XXXXXXXX <-- remove first x, add a new X at the end __XXXXXXXX <--- repeat

The center X's would remain the same until they are to represent the end of the platform.

The same is true for verticale moving lines provided they are only 1 space wide.

if a horizontal platform is 2 "X" 's high then double this because it would take 2 spaces for one end and 2 X's for the other end. it would be better to have two seperate moving platforms for for the expense this causes.

This limitation can make scrolling screens difficult; however, walking with static screens (exit screen 1 on the right, appear on screen 2 on the left) still within reach. (see the original ZELDA)

Now -
i beleive there is more to the line command.
for example:
LINE BALLY, BALLY
a basic language's syntax would not be built that way.
i am wondering why they would force the user to repeat something twice each and every time.
It is possiable that it's
LINE TopLine, BottomLine
so
LINE 5,8
(i'm guessing the lesser line goes first)
would actually display lines 5,6,7, and 8.

if this is the case then suppose we are using 2 balls. BallA and BallB.

when Ball A and Ball B are on different horizontal lines then you would have to
LINE BALLA, BALLA
LINE BALLB, BALLB

if they are on the same line then LINE BALLA,BALLA would show both of them.
if they are in neighboring lines such, as say 5 and 6,
then
LINE BALLA, BALLB

with multiple characters on the screen this could actualy speed up animations quite a bit.
the reason is because (in most interactive assmeblers i've delt with) the IF THEN statement takes up much less processor speed than a PRINT command. Perhaps they also would take less time then a LINE command..

now consider a horizontal platform with a width of six characters.
Even though you PRINT twice, you only have to LINE once.
but with a verticle line, Although you would still have to print only twice, you would also have to LINE twice because each end of the verticle platform is on a different line.

Consider all of these things combined and you see there are quite a few options for how to make action games and still optimize the display for faster graphics.

Have you actualy tried the FOR NEXT loop for character display?
defaulting to the Assembly languages 1/2 character for a double width does not sound right to me.
they could simply say in the bios:
IF CURRENT DISPLAY IS DOUBLE WITH THEN PRINT CHARACTER TWICE, ADVANCE CURSOR TWICE.
likewise with the verticle.

if, indeed, it only prints 1/2 a character when you set the display mode to double width or double height, then the programmers of the roms sound a bit lazy.

Would you like to collaberate on something?
Would you like to experiment more?

Let me know. I am at your disposal and enjoying this immensely.

_________________
.

Cluck!

Yes, with the LINE command you can display a range of lines, so: LINE TopLine,BottomLine is correct.

What do you mean by: "Have you actualy tried the FOR NEXT loop for character display?" I think I have, what do you want to know about it?

You have complete control over the Plus graphics videochip, so if you want to print half of a double sized character, you can do that, the BASIC interpreter doesn't automatically print the character twice (or four times for double height and width).

Yes, I would like to do more experiments.

I'm thinking that for the next step we alter this code for a simple PONG game.
(alter the code to save you typing on that keyboard.)
I already understand the joystick commands.
However there are 2 routes we can go with the collisions.
Route 1 : If > Paddel Left edge and < Paddle Right edge and on the line above the paddle then...
Route 2 : If the ball hits an "X" on the screen (more like a true collision) then....

There is a piece of info (command/statement) that is not listed does not appear in this flavor of the BASIC. This command would be much more efficient with programing action games. With this command we can unlock greater speed with action games (due to collision processing).

let me give you an example then explain:
code:
X = SCREEN 3,8
result:
if at the location 3 characters across and 8 lines down there is a "B" on the screen then X would now equal the ASCII value of the letter "B"

do you know how to accomplish this in ASM?
Could you write the code that may do it in ASM?

for example:
MOV R1,3
MOV R2,8
CALL #nnnnh (this function might not exisit in 8048)
MOV A,R5
A now equals the number value of "B" found at screen location 3, 8

or

MOV R1,3
MOV A,8
AND A,R1
MOV R3,A
MOV A,@R3 (go to the ram that stores vid display and see if anything is there for that specific location on the screen.)

if you cannot then we will be stuck with the Route1 with the collisions. It will work, but it will be inadiquate when, for example, there are 200 boxes on the screen that a walking man can bump into- like with maze walls. (That would require 200 IF THEN statments useing route 1 but only one IF THEN if we can use route 2.)

if you can do this hard work in ASL then i can incorporate it into the BASIC to compensate for the command we don't have.

i have to get into work tonight. When it's slow at work I'll be sitting down and doing a pong example to post up later. If you decide there is a different example you would like then do a shout out and i'll see what i can work up. but i figure pong will help us get down the ACTION and STICK commands for joystick movement and display them in action.

_________________
.

Cluck!

This is a scratch-pad post for me to find info later.
you can just ignore it, but it may come in handy to others later on should they be working with the G7420.

Within basic, two commands are available to redefine your characters: SETEG and SETET.
(I have been able to confirm the SETET command in the c7420 but not the SETEG command)

SETEG A,"BBCCDDEEFFGGHHIIKK"

Defines a special user graphic character. A parameter sets the charcter code (between 32 and 127), and double-quoted parameter defines the new character matrix, each line given by 2 hexadecimal characters.

SETET A,"BBCCDDEEFFGGHHIIJJKK"
Same command as SETEG, but deines special user text character.
Ex: A character matrix
00000000 soit 00 en hexadécimal
00111000 soit 38 en hexadécimal
01000100 soit 44 en hexadécimal
01000100 soit 44 en hexadécimal
01000100 soit 44 en hexadécimal
01111100 soit 7C en hexadécimal
01000100 soit 44 en hexadécimal
01000100 soit 44 en hexadécimal
00000000 soit 00 en hexadécimal
00000000 soit 00 en hexadécimal

You can define A character by:
SETEG 65, "00384444447C44440000".

SETET A,"BBCCDDEEFFGGHHIIJJKK"
Same command as SETEG, but deines special user text character.

Diffrences between TX, EG and GR
TX A,B,C Initialises the normal text mode.A, B and C parameters are defined like in ET.
GR A,B,C Initialises the semi-graphic mode. A, B and C parameters have the same characteristics as in EG.
................A parameter gives the ink color
................B parameter the background color.
................C parameter defines the blinking state (0 = not blinking, 1 = blinking).

Ex: type in the following program
10 CURSORX 10 : CURSORY 10
20 EG 3,4,1
This programes defines the zone beginning at (10x10) to be a user graphic zone, blinking, yellow on blue...

Character attributes:
0 normal
1 double height
2 double width
3 double height and double width
4 video inversion
5 video inversion and double height
6 video inversion and double width
7 video inversion, double height and double width

DELIM A,B,C
Highlight a message by changing the delimiter color (A parameter), the background color (B parameter) and to underline this message (C parameter).
A and B parameters are set according to the color code table, C should be odd to underline, and even if you don't want to underline the text.

Addational info G7420 page:
PHILIPS Videopac G7400+C7420 Videopac G7400 + C7420(google translation framed)

_________________
.

Cluck!

Here you go.
i tried modifying the other code but it was getting very bloated so i started fresh.
it's a whopping 112 lines and i know that's alot for the old keyboard and i am sorry.

I've tried to observe the 39 character maximum and think i've succeeded. it's made some commands require 2 lines and the coding a bit more complicated.
The game uses Route1 collision detection that i've mentioned 2 posts earlier.

it LOOKS error free, but i don't have a way to test it.
Odds are that with 100 lines, there will be atleast 1 error or typo.
good luck and let me know if we need any debugging.

If anything in the code doesn't make sense then just speek up and i'll be more than happy to go over it with you.

Code:

010 INIT 6
020 GOSUB 690
030 REM START MAIN LOOP
040 IF CYCLE<>0 OR ACT=0 THEN GOTO 180

050 REM BALL CYCLE
060 CURSORX BALLX
070 CURSORY BALLY
080 PRINT " "; LINE YBALL,YBALL
090 BALLX=BALLX+DIRX
100 BALLY=BALLY+DIRY
110 IF BALLX<3 THEN DIRX=1:SOUND 1
120 IF BALLX>38 THEN DIRX=-1:SOUND 1
130 IF BALLY<3 THEN DIRY=1:SOUND 1
140 IF BALLY>18 AND ACT THEN GOSUB 380
150 CURSORX BALLX
160 CURSORY BALLY
170 PRINT "O"; LINE YBALL,YBALL

180 REM PADDLECYCLE
190 X=STICKX(0)
200 IF X=1 AND PADX+PSIZE<38 GOSUB 610
210 IF X=-1 AND PADX>1 GOSUB 530
220 GOSUB 440
230 X = ACTION(0)
240 IF ACT=0 AND X<>0 THEN GOSUB 300
260 CYCLE = CYCLE + 1
270 IF CYCLE > 1 THEN CYCLE=0
280 IF ACT = 0 AND BALLS = 0 GOTO 1060
290 GOTO MAINLOOP

300 REM ACTIVATE BALL
310 SOUND 2
320 BALLS = BALLS - 1
330 CURSORX 1
340 CURSORY 1
350 PRINT "REMAINING BALLS:";BALLS
360 LINE 1,1
370 RETURN

380 REM DEACTIVATE BALL
390 SOUND 6
400 BALLX = 20
410 BALLY = 5
420 ACT = 0
430 RETURN

440 REM CHECK PADDLE BOUNCE
450 IF BALLY<PADY-1 THEN RETURN
460 IF BALLY>PADY+1 THEN RETURN
470 IF BALLX<PADX THEN RETURN
480 IF BALLX>PADX+SIZE THEN RETURN
490 SOUND 3
500 IF BALLY=PADY-1 THEN DIRY=-1
510 IF BALLY=PADY+1 THEN DIRY=+1
520 RETURN

530 REM MOVE PADDLE LEFT
540 PADX=PADX-1
550 CURSORX PADX
560 CURSORY PADY
570 PRINT "=";
580 CURSORX PADX + PSIZE
590 PRINT " "; : LINE PADY,PADY
600 RETURN

610 REM MOVE PADDLE RIGHT
620 CURSORX PADX
630 CURSORY PADY
640 PRINT " ";
650 PADX = PADX + 1
660 CURSORY PADY + PSIZE
670 PRINT "="; :LINE PADY,PADY
680 RETURN

690 REM INITILIZE VARABLES AND PRINT SCREEN
700 STORE:PAGE
710 BALLX=20
720 BALLY=5
730 DIRX=1
740 DIRY=1
750 PADX=17
760 PADY=19
770 PSIZE=5
780 BALLS=3
790 CYCLE=0

800 REM DRAW SCREEN
810 STORE:PAGE
820 CURSORX 0
830 CURSORY 0
840 FOR i = 1 TO 40
850 PRINT "X";
860 NEXT i
870 FOR i = 1 TO 20
880 CURSORY i
890 CURSORX 0
900 PRINT "X";
910 CURSORX 39
920 PRINT "X";
930 NEXT i
940 CURSORX PADX
950 CURSORY PADY
960 FOR i = 1 to PSIZE
970 PRINT "=";
980 NEXT
990 CURSORX 1
1000 CURSORY 1
1010 PRINT "REMAINING BALLS:";BALLS
1020 LINE 1,1
1030 DISPLAY
1040 STORE
1050 RETURN

1060 REM GAME OVER
1070 DISPLAY
1080 SCROLL
1090 CURSORX 1
1100 CURSORY 10
1110 PRINT "GAME OVER."
1120 END

PS: don't forget to save before you run it.
Mr. Green

_________________
.

Cluck!

BTW, if we could get a working method of Route2 collision detection then the above program would of been 12 lines shorter due to the folowing changes:
(in this example, i call the command SCREEN because of it's name in other basics.
screen X,Y returns what character is stored in video ram at location X,Y on the screen)

so if you are able to show the ASL code for this command (yes, i would be able to incoperate it into basic 80% sure) then it would save alot of typing with big games such as PAP, KC, or others.

lines 90,100,110,120 would of been different.
XXX lines would not of been needed.

Code:

080 PRINT " "; LINE YBALL,YBALL

090 IF SCREEN(BALLX + DIRX,BALLY) <> ASC(" ") THEN DIRX = -DIRX : SOUND 1
(" " = SPACE)
100 IF SCREEN(BALLX,BALLY+DIRY) <>32 THEN DIRY = -DIRY : SOUND 1
(OR use the decimal # that is a space on the c7420 charater chart.)

110 BALLX=BALLX+DIRX
120 BALLY=BALLY+DIRY
XXX IF BALLX<3 THEN DIRX=1:SOUND 1
XXX IF BALLX>38 THEN DIRX=-1:SOUND 1
XXX IF BALLY<3 THEN DIRY=1:SOUND 1
140 IF BALLY>18 AND ACT THEN GOSUB 380

.
.
.
210 IF X=-1 AND PADX>1 GOSUB 530
XXX GOSUB 440
230 X = ACTION(0)
.
.
.
(THIS ENTIRE SUB COULD BE DELETED.)
XXX 440 REM CHECK PADDLE BOUNCE
XXX IF BALLY<PADY-1 THEN RETURN
XXX IF BALLY>PADY+1 THEN RETURN
XXX IF BALLX<PADX THEN RETURN
XXX IF BALLX>PADX+SIZE THEN RETURN
XXX SOUND 3
XXX IF BALLY=PADY-1 THEN DIRY=-1
XXX IF BALLY=PADY+1 THEN DIRY=+1
XXX 520 RETURN
.
.
.

_________________
.

Cluck!

I know part of the RAM is used to store the video data. I also know at which location it is, but not yet how it is stored. I have a program to dump a part of the memory on screen, so I should be able to find out. If a certain location on the screen would correspond to a certain location in RAM, we could use a PEEK command.

I haven't been able to check your other posts, because I've been working on a program to convert the signal of the recorder output of the Basic module to a text file on my PC. I've only done one test so far, but it does work! So I can now record the audio signal on my PC, convert the wave file to a binary file (which is equal to how the Basic program is stored in RAM), and convert it to a text file.

Of course the goal is to do it the other way around too (convert text to an audio signal). But I need to find out first how the CRC check works.

My God Rene, you have such a beautiful mind!
You've actually accomplished the first steps of this?
I bow to you my master

Yes, peeking and poking would be how the ASL(ASM) code would be used in basic.
The screen data would be stored in a leiner fassion. most likely one horizontal line at a time, each 40 bytes long.

Poking is for sending values to RAM. or to the address of registers.
so instead of
MOV R1, #012h
CALL #0FFH
in basic you can do
POKE 255, 18

SCREEN 3,8

RamOffset = 1231343 (the decimal representation of where the vid display is in hex ram.)
X = 3
Y = 8
Char = PEEK ((X * 40) + 8 ) + MemoryOffset)

this can be combined with the DEFFN function which means "Define Function"(though this version of Z basic will require some experimentation to use it.)

	Code:
	10 DEF FNgetchar( A,B ) = ( Peek ( (A * 40 ) + B ) + MemoryOffset)) so 20 BALLX = 5 30 BALLY = 5 40 DIRX = 1 50 DIRY = -1 60 IF getchar(BALLX + DIRX, BALLY+DIRY) = ASC("X") PRINT "THE BALL HIT AN 'X' "

Take your time when it comes to my coding because i am extreemly facinated by what you are doing. and if some day i get a C7420 module then you know i will be hitting you up for that proggy/formula. Very Happy

besides, i'm back at work full time again. so my hours of fun programming are limited. Crying or Very sad

-------------------------
by the way, sience this has become a programming toppic and this board is pretty dead, should we move this discussion to the .nl board?

_________________
.

Cluck!

Yes, please. I like reading, though it is beyond me at this time. I would like this on the .nl board.

The lurker...

Mr. Green

Yes, it's fine by me to move this to the other forum.