Sometimes it’s like two steps forward and one step backwards but I already learned a lot of the vic20 inner workings.
The roms with the additional two bytes I mentioned in the previous post are simply autostart cartridge roms “converted” to the .prg format which contains the in memory starting address in the first two bytes.
To upload those roms with the MiST interface would require a continuous block of ram instead of the multi blocks I use currently. But using one big block requires multiplexing of the different signals to the ram (ram and block select).
After I did this the vic20 didn’t work anymore. The screen went mad or – the best case – just blinks with the ready. I didn’t figured out why it behaved like that but using again single blocks for the basic working ram, the screen ram and the screen color ram helped to make it stable again. But cartridge uploads to the big block still won’t work.
I can make an own block for the blk5 memory block again but something is wrong with the multiplexing and it would be nice if I could find and fix it.

Can you spot the difference?

It was pretty easy to add the memory since we still have some internal ram available. Just added 8k ram to the entity when the vic20 is accessing blk1 or blk2.

Found a few minutes today to have a look at the cartridge system. As it was implemented the vic didn’t start the rom when doing a reset. As found in the documentation linked in the previous post the vic expects some magic bytes at a specific address to autostart a cartridge:

It looks like that those dumped roms (.prg) have two extra bytes in the beginning. Shifting the access to those roms two bytes up made it work:

Astroblitz

Choplifter

Solar System

As usual the source code can be found in my github repository.

Update 07.12.2014
Looks like that there’re different dumps available. Found a side with .a0 cartridges which doesn’t need the shift.

Recently I tried to implement the ram expansion for the Apple II+ but failed again. The test suite didn’t recognize the additional ram or the additional memory access interfered with the disc access which lays in the sdram as well.

A little disappointed I was in need of a simple new project for my little free time. The vic20 was the obvious choice as it has low demand on memory and should be easy to port. But I was wrong.
The first difficulty was to find the right sources. Unfortunately there were no sources on the fpgaarcade site where it derives from. An Internet search revealed several places with several different implementations of the same original sources.
I started with the Papilio port but didn’t succeed. I got a screen output but only with a lot of “@”s.
Even though the sources were almost identically I got more success with the de2 sources. I used BRAM instead of SRAM and the vic20 on the MiST was alive:

But there’s still a lot do to to make it usable. The refresh rate is a little odd and needs a little tuning.
An internal test cartridge and one uploaded via the MiST osd didn’t start.
Due to this the sound output isn’t tested. The vic20 is only unexpanded and needs some memory expansions.
And finally the boot time is rather long and I dunno what’s doing there (testing ram?).
Fortunately I found some resources on the net which might help me to got those topics done:

http://paradroid.automac.se/vic20ram/
http://ftp.giga.or.at/pub/c64/library/vic20.doc

The sources can be found here:
https://github.com/wsoltys/mist-cores/tree/master/vic20

Other sources:
http://forum.gadgetfactory.net/index.php?/topic/1284-vic20/
https://fador.be/fpga/vic20/
http://jderogee.tripod.com/projects/minimig_altcores/Minimig_altcores.html