Starting VIC-20 unexpanded-project UEFA European football championship 2024

[Soloman]

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.