Multi-Part Loader - Yes or No

[Vic40]

Hi,

I am in the process of re-writing the first serious game I programmed for my Vic20 in the 1980s. Without the original source and not that much free time at the moment progress is slow. Also the "re-learning" curve is probably a little steeper than I thought it would be. Anyway I have now come to the point where I have rapidly ran out of memory with +3K and I now need to change it to be a +8K game.

I am also considering splitting the program so that it has a separate load program (like the original had). This will save all of the DATA statements for the graphics/machine code and give me another 1K to play with. This approach was very common in the 80s but is it so relevant now as I guess I could just make it a single +16K program if I need to.

Anyone got any views about whether I should make the split ?

Thanks

[nbla000]

Do you think to do a basic or ML game ? btw my opinion is, single file for any drive that you may crunch after with pucrunch, 8/16k expansion is no more a problem for vic users.

[Kweepa]

I think the answer depends on why you are re-writing the game.
Is it for the journey or for the result?

If it's just to have the game again, and YOU don't care how you get there, I suspect no-one else will (except perhaps Jeff ). So just do whatever is easiest.

If you're trying to keep the authoring process authentic, then go with the loader.

If you're trying to make it as efficient as possible, I would try some new techniques, such as placing the data directly in memory rather than using data statements.

Good luck with the game!

[Jeff-20]

These days, I try to make all of my games single-load, unexpanded memory. In the past, I was fond of the multi-loader (made popular by COMPUTE magazine). Load the graphics and get instructions.

But I have to agree with Kweepa, the product is far more important than the procedure. I just went for single load because I think users are much more likely to try it. Multi-load is like Tape games, they require a bit more patience.

[Vic40]

Thanks for the advice. The game will be mainly Basic with some MC as per the original. The next game I tried to write in the 80s was 100% MC but I never finished it (mainly due to the fact that I didn't have an assembler and was trying to write all the MC by hand). Perhaps that may be my next project if I ever get to the end of this one.

On thinking about it the end result is more important than the journey - I want to produce something that my kids may want to play (at least for a day or two) - however it will be hard competing with their Nintendo Wii. So I will keep it as a single program and use upto 16K if I need to.

Maybe in the future if I become more proficient I could try and write something for the unexpanded Vic but I would rather not have the memory constraint at the moment

[nbla000]

Today is really easy to write an ML program, just use a text file in windows/linux, compile with DASM and debug with VICE if required.

Which kind of game wants your kids ? Nintendo Wii Sports ?

[carlsson]

I believe PEEK(186) holds the value of last used device, so if you write a multi-part loading program, it could be written in such way it loads equally well from both tape and disk. Other forms of storage (i.e. flash cartridges if any) may be another story.

[nbla000]

I believe PEEK(186) holds the value of last used device

Yes this is true, i've used this technique to fix multi part games for disks before to single-file them.

[Vic40]

Think it is going to have to be a multi-load after all. This topic from a few years ago seems to describe the next problem I have run into making the switch from +3K to +8K

http://sleepingelephant.com/v-web/bulle ... .php?t=827

In it Anders provided a neat piece of code to move the program and the start of Basic 512 bytes forward to accomodate space for custom graphics. I needed more space so I modified this to instead move the start of Basic forward 2048 bytes as shown below (Custom Graphics 4096-6143, Screen 6144, Start of Basic 6652). This works fine as a standalone test program but didn't work for a much larger Basic program. Basically Line 15 went into an infinte loop. On breaking out the loop counter "I" had the strange value of 8094.00034. Anyway this copy is too slow for a large program so I think splitting into two parts is the way to go.

Code: Select all

5 IF PEEK(44)=26 THEN 30
10 A=PEEK(44)*256+PEEK(43):B=PEEK(46)*256+PEEK(45)
15 FOR I=BTOASTEP-1:POKEI+2048,PEEK(I):NEXT:POKEI,0
20 POKE 44,PEEK(44)+8:POKE46,PEEK(46)+8:SYS50483:CLR:POKE123,PEEK(123)+8
25 FORI=0TO2047:A=PEEK(32768+I):POKE4096+I,AOR(A*2):NEXT
30 POKE36866,22:POKE36869,224:POKE648,24
35 PRINT"[CLR]DONE"

In answer to the following

Which kind of game wants your kids ? Nintendo Wii Sports

It would be great to do something like that on the Vic but it might be pushing it just a little . Though having said that the graphics on Wii Sports aren't that great it is the gameplay that is spot on which is something you can at least try to emulate on the Vic

[Mike]

This works fine as a standalone test program but didn't work for a much larger Basic program. Basically Line 15 went into an infinte loop. On breaking out the loop counter "I" had the strange value of 8094.00034.

Most probably the copied program overwrites the variable space here. You'd need to move the start of variables (45/46) first, before moving the program itself.

For a multipart loader I often use this construction:

Code: Select all

100 PRINT"{CLR}LOAD"CHR$(34)"PART 2"CHR$(34)","PEEK(186)
105 POKE631,19:POKE632,131:POKE198,2

The code 131 will place "LOAD{RETURN}RUN{RETURN}" in the keyboard buffer. You aren't required to place a RUN statement correctly on the screen, and this method only needs a prefacing {HOME} in the keyboard buffer.

Michael

[carlsson]

With risk of going off-topic, I'd like to revisit the original question of multi loading games. A few weeks ago I bought Lode Runner for the MSX computers. It was available both as cartridge and on 3.5" floppy disk - I got the disk version.

For some unknown reason, the game not only loads new levels from disk as you advance, but also reloads the level from disk when you lose a life! Anyone who has played Lode Runner knows how complex the levels are. The VIC-20 version fits on a 16K cartridge. I suppose the C64 version is not much larger. The BBC version seems to fit in 32K. The MSX1 computers came with 16-64K to start with. My computer is a MSX2 with 128K, but if the game is written to load very small chunks at a time, perhaps it doesn't matter how much memory the computer actually has.

What I'm trying to say is you should not be afraid of dividing your work into many parts if it is logical or you can't fit it all in memory, but watch out so you don't fall into the Lode Runner trap. It is a bit annoying really.

[Vic40]

For a multipart loader I often use this construction:

Code: Select all

100 PRINT"{CLR}LOAD"CHR$(34)"PART 2"CHR$(34)","PEEK(186)
105 POKE631,19:POKE632,131:POKE198,2

The code 131 will place "LOAD{RETURN}RUN{RETURN}" in the keyboard buffer. You aren't required to place a RUN statement correctly on the screen, and this method only needs a prefacing {HOME} in the keyboard buffer.

Thanks Mike this works great - though somewhere before the load of the second part I need to issue a NEW so that it is loaded correctly. Is there anyway of modifying the above so that it places "NEW{RETURN}LOAD{RETURN}RUN{RETURN} in the keyboard buffer ?

[Mike]

In that case you'd use:

Code: Select all

100 PRINT"{CLR}NEW"
105 PRINT"{2 DOWN}LOAD"CHR$(34)"PART 2"CHR$(34)","PEEK(186) 
110 POKE631,19:POKE632,13:POKE633,131:POKE198,3

If you possibly want to move the BASIC start, these POKE's go between {CLR}, and NEW; for example you move the BASIC start to 8192 as follows:

Code: Select all

100 PRINT"{CLR}POKE43,0:POKE44,32:POKE8192,0:NEW"
105 PRINT"{2 DOWN}LOAD"CHR$(34)"PART 2"CHR$(34)","PEEK(186) 
110 POKE631,19:POKE632,13:POKE633,131:POKE198,3

POKE 43,0 is inserted just to be sure.

The 2nd part now can place user-defined graphics, and ML data into the RAM below 8192, and perhaps then chain to a 3rd part, which contains the main program.

Greetings,

Michael

[Vic40]

Thanks Mike this worked a treat. The only problem is that the NEW seems to revert the value in location 186(last used device) back to 1(at least in Vice anyway haven't tested yet on my Vic20). I ended up with the following code which "remembers" the value in location 186 in a convenient place in my case location 824 (the start of the cassete buffer). I also only need to move Basic to start at location 6656 (hence POKEing 28 rather than 32)

Code: Select all

10 POKE824,PEEK(186)
20 PRINT"{CLR}POKE43,0:POKE44,28:NEW" 
30 PRINT"{2 DOWN}LOAD"CHR$(34)"PART 2"CHR$(34)","PEEK(824) 
40 POKE631,19:POKE632,13:POKE633,131:POKE198,3

I didn't have the POKE 6656,0 and it seems to be fine. Do I need to add it or will the NEW do this for me anyway?

[Mike]

Both the NEW, and RUN command will not work, if the byte at the BASIC start doesn't contain a 0.

I checked the behaviour of address 186 you observed in VICE, but I couldn't reproduce your problem.