EURO 24 football program disk with added game - a slot machine

[Soloman]

= Edit = Post of June 20th contains the disk.

This summer 24 European countries will fight for the championship football (In the US it's called soccer). 51 games will be played in 10 stadiums in Germany. I started programming a system on the unexpanded VIC for following the tournament. It will be a memory-fight, but that is what I like.

First I set up four tables:
1. The country-table (country, poule);
2. The stadium-table (only the names of the cities);
3. The game-description-table (group, quarterfinals, half finals, final);
4. The matchtable (matchnumber, day, date, time (hour), place, game, poule, team home, team out, score team home, score team out, played (0=will be played, 1=played, 2=extra time, 3=penalties), red cards team home, red cards team out).

De tables will be written to a seqeutial which will the base of the programs.

Programs:
EURO24P0 - Menu
EURO24P1 - Initialize the sequential file EURO24FB
EURO24P2 - Entering the scores of the matchscores
EURO24P3..P7 - Several information consulting (matches, standings) programs
EURO24P8 - What if?-program. For future-analysis.




Part of program that writes the initial sequential file. At top the last part of the countries, the stadium-table, the matchtype-table and the first record of the match-table. I'm still typing. Still 30 matches to go in the matchtable (scores are still zeroes, no need to put them in the DATA-lines), monkish work. 2000 bytes left
When the sequential file is completed, the consulting-programs will read the file in arrays. I pray the memory will be large enough.. If not, I have to puzzle out solutions. My target is to stay unexpanded!

[chysn]

Ambitious, for sure, but I'm looking forward to seeing it develop!

[Soloman]

I know, and that is the interesting part of it. The match-table is what bothers me. Integers take two bytes of space and as you look at the table, most variables fit in a single 8-bit byte. Looking at the date, the tournament takes place from june 14th to july 14th, so I can nibble of the monthnumber and can repair that in programs. Ehmm noo, now the 14th of juni is represented as 614. I make it monthnumber 1 for June (114 for that day) and 2 for july. So that fits in a byte. It's so simple.
I was thinking to reduce the Basic-RAM-part, so I create space for the match-"table", so I can retrieve that table with PEEKs and POKEs.
The table has 10 elements, 51 matches, that's 510 bytes.

Top of VIC-Basic-RAM unexpanded is 1C00, 7168 decimal, so I must reduce the Basic ram to adress 6658 decimal for creating space for the match-table.
For me to find out which adresses I have to modify to do this. (VIC 20 Quick Refence handbook to find out)

Edit
The match-table has 51*11 elements, all integers 1 byte = 561 bytes
I need a standing-table too, that is 24*7 elements (24 countries) all integers 1 byte = 168 bytes
Makes a total of 729 bytes, let's say 730.

The top of the Basic-ram is pointed in address 55 (LSB) and 56 (MSB) decimal. $00 in 55 and $1E in 56. Top of RAM is $1E00, 7680 decimal. Minus 730 bytes, that will be decimal 6950, $1B26. $26 (38) in 55 and $1B (27) in 56.
POKE 55,38
POKE 56,27
The result is 2851 bytes free and protected space for the two tables between locations 6950 and 7680.
Back to normal is POKE 55,0:POKE 56,30

I make a separate program to calculate the standings. I have three sequential files: EURO24FB.SEQ - The basic file with countrynames, places, etc. EURO24FM.SEQ the matchfile and EURO24FS.SEQ the standingsfile. The first field of both the matchfile and the standingsfile is a sequencenumber. It's a counter for every update. When the standings are calculated the sequencenumber in both files are the same. This is for checking bij looking-up-programs.

[Soloman]

Lessons learned: Loading longer programs from another program. I made a menu-program for this system from where I load other programs. I knew this would go wrong, because the VIC doesn't update the pointers to the memory where variables and arrays are stored and this will corrupt the program loaded. After hours studying, this is what to do:

At the beginning of the program the locations 45,46,47,48,49,50 must be set with the correct values. To determine these values, first load the program in the direct mode. Then check out the values of 45 and 46, with PEEK. Than in the beginning of the program POKE these values to 45 and 46. Then the pairs of 47, 48 and 49, 50. These pairs must have the same values of the pair 45, 46.
Then PEEK again in 45 and 46. The values have changed (mostly 46 remains the same), because you added coding. Change the values in the program to the current values.

Code: Select all

10 REM PROGRAM
20 POKE 45,180
30 POKE 46,21
40 POKE 47,180
50 POKE 48,21
60 POKE 49,180
70 POKE 50,21

And then the chaining goes correct wihout unexplainable error messages or a corrupt part of the program. Don't forget to save the program again (scratching first). Every time you edit the program, you must update the lines with these POKEs.

And, about making space in the program-RAM for the tables, I mentioned before: Calculate the space you need, calculate the address where the space must start. These are the memory-locations that must be filled with the address (LSB,MSB-pairs): 51/52, 53/54, 55/56

Ready are now:
The startup-program, the start of the menuprogram, the program that builds the sequential files with countries, matches etc.

Starting screen:


Menu until so far:


The lookup menu is for watching data about groups, matches, kick-out-phase, matches at places etc.
The system-menu is for local-time-correction en restore initial data, that kind of things.
A menu option of What happens when... -analyses will be added.

The whole system will be flexible, so it can be simply adapted for the World championship 2026, which will take place in Canada, USA and Mexico.

[Mike]

Loading longer programs from another program. [...] At the beginning of the program the locations 45,46,47,48,49,50 must be set with the correct values.
[...]
Calculate the space you need, calculate the address where the space must start. These are the memory-locations that must be filled with the address (LSB,MSB-pairs): 51/52, 53/54, 55/56

It is not necessary to do the POKEs to 47..50 and 51..54, provided you follow up the POKEs to 45/46 and 55/60 with a CLR statement. CLR will set the pointers in 47/48 and 49/50 from 45/46 and the pointers in 51/52 and 53/54 from 55/56.

That being said, using constants in the program to set 45/46 is not very robust. After LOAD, the address of the byte following the program is stored in 174/175 - that means POKE45,PEEK(174):POKE46,PEEK(175) with a follow-up CLR will also do the job and won't need to be corrected after edits, see here.

As that procedure will anyhow clear all variables, yet another, established method eliminates the POKEs to 45/46 entirely: printed LOAD messages on screen and simulated key presses in direct mode, like thus:

Code: Select all

xxx PRINT"{CLR}LOAD"CHR$(34)"<name>"CHR$(34)","PEEK(186):POKE631,19:POKE632,131:POKE198,2:END

Replace <name> with the intended name of the file to load. Note the last quote of the PRINT statement needs to be placed before PEEK(186), writing it as ",PEEK(186)" does not work!

This line places a LOAD command in the top-left corner of the cleared screen. The keyboard buffer is filled with {HOME} (code 19) and {RUN} (code 131). The {RUN} code internally expands to LOAD + RETURN + RUN + RETURN, which executes the printed LOAD command and autostarts the loaded program. As this command is executed in direct mode, the pointer in 45/46 is correct, regardless what length the chained-to BASIC program is.

Also, lowering the roof with POKEs to 55/56 should only be done once, in the start/menu/boot program: I'd presume what you store in that buffer needs to be persistent, so all programs in the suite have to work with the altered memory setup anyway. There's no need to replicate the POKEs to 55/56 in the other programs, as that setting is preserved until actively changed by the user (and LOAD won't change it!).

[Soloman]

It is not necessary to do the POKEs to 47..50 and 51..54, provided you follow up the POKEs to 45/46 and 55/60 with a CLR statement. CLR will set the pointers in 47/48 and 49/50 from 45/46 and the pointers in 51/52 and 53/54 from 55/56.

Sorry for my late reply, I had to work this week. Now it's weekend and now I have time to continue.
I did some homework. I already read about the 174 and 175, but I wasn't confinced about the CLR. I tried it out with breaks through the program, I checked it in the monitor, and you're right! CLR sets 47, 48, 49, 50 ($2F..$32).
Thank you!

Now I continue with a simple data consulting program.

[Soloman]

Hello there again! I am still there. But I was/am very busy with my work.
Now, in the long weekend, picking up this project again. The chaining of programs keeps me worrying:

"that means POKE45,PEEK(174):POKE46,PEEK(175) with a follow-up CLR will also do the job and won't need to be corrected after edits"

This doesn't work for large programs. One of the programs is creating a Group-sequential-file and a Game-sequential-file. It's a program filled up with DATA-lines. A small part reads all data per part and writes them to the files. Just a few FOR..NEXTs with READ en PRINT#, just a few lines. No arrays.
Before running there are 900 bytes free. The variables are minimal.

First running line after a REM: POKE45,PEEK(174):POKE46,PEEK(175):CLR
As soon as the first variable is assigned, the terror starts and the end of the program is blurred.

Mike gave me a second option with the keyboard-buffer. That must work. But first I develop the other programs without the pokes.

[Mike]

This doesn't work for large programs.

I already pointed out in the thread "Corrupt end of basic program", that copying 174/175 to 45/46 is problematic. Actually, it only works immediately after the program has been loaded - the KERNAL load procedure places the address behind the last loaded byte into 174/175 -, with a freshly typed-in program or after edits, the value in 174/175 is invalid.

Please refer to that other method I gave in my preceding post in the thread here:

[...] another, established method eliminates the POKEs to 45/46 entirely: printed LOAD messages on screen and simulated key presses in direct mode, like thus:

Code: Select all

xxx PRINT"{CLR}LOAD"CHR$(34)"<name>"CHR$(34)","PEEK(186):POKE631,19:POKE632,131:POKE198,2:END

Replace <name> with the intended name of the file to load. Note the last quote of the PRINT statement needs to be placed before PEEK(186), [...]

There also exist other methods of chaining to another loaded file, without the need to print out the LOAD statement (which - without question - "messes up" any crafted "LOADING ..." screen) and without using buffered keypresses, but these need machine code and are beyond the scope of this thread here.

[Soloman]

This doesn't work for large programs.

I already pointed out in the thread "Corrupt end of basic program", that copying 174/175 to 45/46 is problematic. Actually, it only works immediately after the program has been loaded - the KERNAL load procedure places the address behind the last loaded byte into 174/175 -, with a freshly typed-in program or after edits, the value in 174/175 is invalid.

Please refer to that other method I gave in my preceding post in the thread here:

[...] another, established method eliminates the POKEs to 45/46 entirely: printed LOAD messages on screen and simulated key presses in direct mode, like thus:

Code: Select all

xxx PRINT"{CLR}LOAD"CHR$(34)"<name>"CHR$(34)","PEEK(186):POKE631,19:POKE632,131:POKE198,2:END

Replace <name> with the intended name of the file to load. Note the last quote of the PRINT statement needs to be placed before PEEK(186), [...]

There also exist other methods of chaining to another loaded file, without the need to print out the LOAD statement (which - without question - "messes up" any crafted "LOADING ..." screen) and without using buffered keypresses, but these need machine code and are beyond the scope of this thread here.

Yes, I knew, but I tried, hoping for a good end.
Inbetween I'm writing the programs. The lookup-program for matches is finished.

Now I am writing the group-standing-program and the input-score-program.

As I said I made two sequential files, that are created by a program. EURO24FB.SEQ contains general data like country-names, stadium-places in Germany, weekdaynames, etc. Part of the datalines to be read and written in the file:


EURO24FM is the matchtable (part of the datalines):

Field 1 is the matchnumber, 2 the weekday, 3 the date mdd (m subtracted by 5, so it will fit in a byte in the RAM-memory), 4 the hour mid-Europeantime, 5 the city where the match will be played, 6 group/tournamentphase, 7 hometeam, 8 guestteam, 9 game-indicator (like teams still unkown, 10=not yet played, cancelled, played, played with extension, played with penalties, etc. etc. )
After those four fields for score and cards.

[Soloman]

Working on the program that lets the user input te score of a played game. Still on the unexpanded.
The program first reads the match-file: 51 matches with 13 integer-data:
1. Matchnumber
2. Weekdaynumber
3. Date (from 114 to 214, where 1 is june and 2 is july, to fit in a byte)
4. Hour of day
5. Placenumber (1=Berlin and so on)
6. Tournamentphase
7. Hometeamnumber
8. Guestteamnumber
9. Game-indicator (not played yet, played, cancelled, penalties, etc etc etc)
10. Score hometeam
11. Score guestteam
12. Cards hometeam
13. Cards guestteam

And read the countrynames from a sequential file. I first stored it in arrays. After that I had 872 bytes left for all the programming. Does not work.
Integers take 2 byte a piece. When I use 1 byte I get more bytes left.
So I reserve a piece of memory.
Bottom of BASIC is $1000, top $1DFF (7679 decimal)
The matcharray is 51*13=663 bytes
7679 -/- 663 = 7016. That's the place of the first byte of the matchtable.
So 7015 will be the new top of BASIC, is $1B67
High byte $1B in memory-address 56 decimal
Low byte $67 in 55.
So POKE 56,27 and POKE 55,103.

Around 2000 bytes free with the lines already programmed. Correct. Reading the file, POKE from 7016 to 7679.
Well and now further to program something neat.

[Soloman]

Working on the program that calculates the standings in the groups. I finished the program for inputting the matchscore. Reserving memory for the matchtable helped me a lot. It remains a struggle, those 3500 bytes free.
This week I hope to present a disk with the programs: clear scores, input scores, lookup matches, calculate and lookup groups. After that I have to program the calculation of following matches after the groups.

I know that this is a one-time project, but I learned a lot. The world championships has much more teams. The unexpanded VIC has to less memory for it. Maybe relative files?

I'm thinking about the next project. Startrek for the unexpanded VIC maybe? Or an adventure on the moon?
And I started with machine language. Now I know how I create a machine language with a first Basic SYS-command, that users simply can load with a simple LOAD "PROG",8. The tips of Michael were very useful. But one thing: you save the program from address $1001, not $1000, where you have first the BASIC 1 SYS 4110 and than you can program from $100E to $1DFF. Room enough for a rookie!

[Mike]

[...] unexpanded VIC [...]

You seriously should reconsider that premise before resorting to REL files.

[Soloman]

All programs on the disk for the unexpanded VIC

And hereby the disk with the programs. It's a pity I had to used the normal INPUT-statement. There was no room for my INPUT-routine. Technical description follows later.

The disk has the following programs:
EURO24-MATCHES To lookup the matches from a specific data.
EURO24-GROUPS To lookup group standings
EURO24-INPUT To enter the scores. You need the matchnumber to enter. You find the matchnumbers with the program EURO24-MATCHES
EURO24-ERASE Look out! Running this program creates the sequential files. So everything will be initialized to the start of the tournament
EURO24-CUP Just for fun, a picture of the cup. Does nothing further.
EURO24FB Sequential file with the base-data like countrynames, matchdates etc.
EURO24FM Sequential file with all the matchdata.

De files are updated to today. The scores are entered till yesterday-evening.

A bonus on this disk: BEACH, for the unexpanded VIC, a slot machine I programmed a few years ago. For rolling you must press enter. For putting in a coin press space, for HOLD F1, F2, F3.

[Soloman]

I continue with writing a program that calculates the matches after the group-phase. But I do that for myself. Now, this topic ends with this, because I doubt whether this topic is a contribution to this forum. (In America soccer is not something that reaches the front pages of newspapers, so I understand).

But, it doesn't stop me in this forum to start up the development of two new projects: a calculator for programmers and a game Gold digger.
The first notes are a little on paper, but in the near future I hope to tell you more. And both again for the unexpanded VIC. It's really a joy programming the VIC-20. I love it!

Thanks for the buddies here and especially Mike who thinked along with me with this project. It really helped me a lot! Next step, with the other programs, will be my first machine language program, I think an easy/simple game.
Till later folks!