• Please review our updated Terms and Rules here

Vic-20 discussions

C

carlsson

Veteran Member
Joined
Jul 30, 2003
Messages
6,274
Location
Västerås, Sweden
Another PBeM soccer and VIC-20 combination? I used to run the Elite Soccer, but it has been on hiatus since two years. Some day I might start it up again. In the mean time, I'm playing WEFS and has been into EEFL, FEFL and few others until they died out.

Oh well. I included a list of visited forums on my VIC page.
 
You obviously have great taste Anders! :)

I think I have heard of WEFS before, but I am unfamiliar with it. I got introduced to Eli Bendersky's ESMS game engine, and have stuck with it. My league is about a third of its way into season #6. Good core of managers thankfully!

Eli is to be releasing a new version of ESMS in a few months, and there are some very nice modifications he has done. It will be very customizable to suit each league. I am looking forward to it.

I have always wanted to do a soccer management program for the vic 20. One thing that I have poked around now and again, is a beach soccer league for the vic. The premise would be that retired soccer players get together once in a while and play 5 on 5 soccer in the Carribean. I think it would be fun to have managers choose players based on favourite retired players, and picking team names based on beaches and such in the Carribean.

I have this actually running via spreadsheets, and I have to convert it over onto the vic.

I hope you find the time some time to get back into running a league again!

Chris
 
The source code to LEFL is relatively small (compared to the source code to the other games) and is written in portable C. I've actually considered compiling it with cc65 if possible to see how large the binaries will be. If too much is left out, it turns into an abstract resource management game or even simulation.
 
Hm. After compiling 3/11 source files, I'm already at 140+ kB of object code, and the executable seldom is much smaller than the object code - rather the opposite after adding "glue". Without optimizing and cutting, it might run on a REU enhanced C64 or better.

Still, it is quite a lot of fun to use a cross compiler, but it would be even nicer if it did floating point.
 
Thank goodness for memory expansion.

I do not think you could make a very good soccer management game with 3.5k, (well I know I could not). Although cutting up the game into many files and retrieving data from files would lighten the demand on RAM.

Chris
 
I'd be happy with 16K multi-loading. Text based management games tend to become rather large, in particular if a lot of data is required to be kept in memory.
 
I find the vic 20 becomes quite a powerful computer once you pump up the RAM.

I use an expansion bay, so I can use more than one memory expansion cartridge at a time.

I did see a scan of an ad for 64k! expansion for the vic, on someone's website. I had no idea the vic could address that much.

By the way Anders, nice picture ;)

Is this your way of telling us you have a cold?

Chris
 
The 6502 inside the VIC-20 can of course address 64K. However, you already have 20K of ROM (Basic, Kernel and characters) and a few I/O slots (which can be filled with RAM/ROM, but it is very unusual). I think the 64K expansions worked with eight slots of 8K each, or maybe four slots of 16K mapped into the same position all the time. You would do the bank switching manually.

The C64 has a 6510, which is a 6502 + I/O port which allows it to switch out the Basic, Kernel and other stuff. Behind these ROMs, 64K of RAM is hidden and ready to be used (well, in practise about 62K is useful). I'm not aware if there are any hacks to put a 6510 into a VIC, but maybe with a modified Kernel, it could work? Again, you would develop an unique machine potentially incompatible with everyone else.

My cold is one week old, but since I'm in front of a webcam all day, I like to make disturbing gestures once in a while and capture those moments.
 
I know I am naive, but I have often wondered why the vic's memory map is the way it is.
Could they not have put things like the sreen RAM, Character genrator ROM and the BASIC interpreter let's say starting at 1024 (decimal obviously) and go up from there, and then have the rest as one large continuous area for user RAM?

Or at least have moved the internal workings of block 4 down to block 1, allowing the use of blocks 2-5 for user RAM. Much better than having blocks 1-3 and 5 available, with that nasty unusable block 4 in the middle.

Like I said, I don't know much about this.

Chris
 
As the 6502 expects to find a few reset and interrupt vectors at $FFFx, putting the Kernel and Basic as high as possible is probably a good idea. Also, at the other end, the first 256 bytes of memory is the zero-page, followed by the stack.

Apart from the VIC-I graphics chip can address 16K of RAM, there also is a 4K character ROM which is mapped in so the 6502 can access it. There also is control registers and I/O blocks which to a great deal seem to be unmapped (the Rabbit fast loader and possibly some speech cartridge are the only ones I can think of using this space). To which extent things interfer which eachother, I can't tell without looking deep into technical documents.

Maybe we could've had a map similar to this?

$0000-$03FF : Zeropage + stack + vectors/pointers/work memory
$0400-$1FFF : 7K RAM standard (usually 4K)
$2000-$3FFF : 8K RAM/ROM expansion block 1
$4000-$5FFF : 8K RAM/ROM expansion block 2
$6000-$7FFF : 8K RAM/ROM expansion block 3
$8000-$9FFF : 8K RAM/ROM expansion block 4
$A000-$A3FF : 1K VIC-I and VIA control registers
$A400-$A7FF : 1K Colour RAM nybbles
$A800-$AFFF : 2K EEPROM user space (replaces I/O blocks 2 and 3)
$B000-$BFFF : 4K Character ROM
$C000-$DFFF : 8K Basic ROM
$E000-$FFFF : 8K Kernel ROM

Imagine 39K of continuous memory, compared to 28K (31K) otherwise. The VIC might have been a little more expensive if it was equipped with 3K more, but also more usable from the beginning. Of course, the EEPROM socket should be inside the VIC and not on a cartridge.
 
wow, i wonder what effect on sales and development, that extra little bit of RAM would have been on the vic 20?

A more expensive computer (how much I wonder?), would have affected sales.

The increased RAM would have helped people make some more robust programs for the vic right off the bat.

I also remember reading that if the vic 20 would have had more RAM, that this would have been a great help to ML programmers.
I guess about having a nice machine language monitor in RAM and enough space to still prorgram?

Chris
 
I've read that there was a shortage of (static?) RAM chips about when the VIC was introduced, so it might not only have been a cost issue that limited the onboard memory. Compare with the price for the +3K expansion cartridge and maybe cut it in half as the circuitry would not have been required.

With 7K RAM, full-screen bitmapping (4K) would have been a piece of cake on an unexpanded machine, although Albert of Pu-239 among others have shown it is perfectly possible with the smaller machine too - just use the lowest 1K in a creative way.

Yes, a ML monitor into that 2K EEPROM block might have been a good improvement. Theoretically it can be done today by locating it at $9800, but I'm not sure how a such cartridge can be mapped in (although the Rabbit fastloader does).
 
carlsson said:
Still, it is quite a lot of fun to use a cross compiler, but it would be even nicer if it did floating point.
Click to expand...
I downloaded a demo version of the ADC compiler, which comes with code generation for 6502, Z80, 8051, 68HC11 etc. The demo version only outputs Intel Hex and does not have any system-dependent startup glue. I haven't been able to perform any intelligent tests to see how good the code generation is. It outputs list files, so one can read (and copy/paste) the assembly code.
 
Hi Anders;

With this compiler you downloaded, are you able to code and then send it over a cable or wahtever back to a vic?

Chris
 
No. Just like every other compiler or assembler, it would generate an object or executable file on your hard drive, which you in some way have to transfer to your VIC. Potentially you can modify the makefile to have it automatically transfer an executable after finishing compiling, but it is not included in the environment.

The same goes for cc65, which is a free and working compiler. The reason I wanted to check out the other, commercial one was it says it supports floating point etc and I'd like to see how much better (if at all) code it generates compared to a free product.
 
It outputs list files, so one can read (and copy/paste) the assembly code.
Click to expand...

Ok, I think I am understanding a bit more.

I thought that perhaps you could take the list code and send it over a cable to your vic, and then use it there before you compiled.

Chris
 
It is a disassembly listing, i.e. one which will need to pass through an assembler to generate executable code. While it might be possible to send this text file to the VIC and paste it into an assembler, I'd prefer to use a cross-assembler and only transfer the runnable results.

Maybe there is a converter from Intel Hex to pure object code, so it could be used anyway. After finding out the demo didn't allow me to easily evaluate it (not that I'd consider buying it anyway), it is not as urgent to play with compared to all the other things I do. Maybe I'll have another go some day, but until then I can live with integers and code optimization line-by-line instead of larger blocks.
 
You must log in or register to reply here.
Back
Top