18th of March 2018 Vectorblade IV

(see also: Vectrex Project)

I decided two blogs on one subject (all things Vectrex) might be to much and confusing. For the time being I will update the Vide blog also with the progress on Vectorblade. If you “missed” the first entries – head over to above given link :-).

So. What’s new from the last time?

Looking at above picture one thing captures the eye – the “bigbug” (or so its called internally).

Since I wanted to have different kind of levels:

• normal levels (done)
• bonus levels (aka challenging stages) (not done, but internally I expect them to be quite similar to kamikaze)
• kamikaze levels (done)
• boss fights (not done)
• and the above “normal” level with additional “big enemies” (done)

I have progressed to the “big” enemies. As of now (but configurable) one such a bigbug has 50 hitpoints. Instead of shooting straight down (as the “normal” ones always do) this enemy is able to fire shots directly at the player.

Under the hood changes:

– I split many routines to bank0 and others to bank1 (did I mention it, Vectorblade will be my first 64kb rom)

– I did all configuration to save options and progress to a DS2431 eEprom

– I also made changes that VecFever saving is supported (also there is one open question for Thomas to answer).
FYI: VecFever uses a “header” (starting at $0030 of your cartridge). If you do a 64kb rom the default bank vectrex uses is always bank 1.
The VecFever header must also reside in bank 1 (so to say at $8030).

– started a title screen – although I am not really impressed by it yet.

– I added counting routines for scores, cash, hitpoints and such

– juggled a lot of RAM, as of now I have 4 bytes left. Seems a bit convoluted RAM wise at the moment :-(.

I keep wondering how much ROM space I might have for “free” usage. I am at the moment quite lavish in the use. The enemies/bonus as of now (rotating etc) use a lot of ROM. And I only have two different enemies right now – there should (at some stage) be loads more.

Next things to consider:
– Boss fight + “homing missiles”
– bonus level
– shop
– new weapons (laser)
– additional bonus items (shield, armor, autofire, sucker)
– lots of level editing, pattern editing, enemy drawing
– thinking about explosions
– doing some sound design and adding music to titlescreen, highscore, shop
– doing highscore stuff in general and introduction screen and option screen

Although I am not sure I will make the final version “free” as my other titles.

Something at least a little bit Vide related:

Bankswitching some things to consider

It seemed there was a bug in Vide which I corrected (from next version on) regarding bankswitching,

The “classic” bankswitching (as first done by John Dondzila) uses the cartridge line 35, which is directly connected to the VIA. More exactly to VIA port B bit 6 (hence PB6 line).

The state of PB6 is “calculated” quite easy as:

– if pb6 is in input mode (corresponding bit 6 of ddrb is 0) – than pb6 is always 1
(well – if someone on the cartridge side “writes a 0” than not – but usually the cartridges do NOT write to pb6)

– if pb6 is in output mode – pb6 is always that which is written to pb6

Knowing the above and also knowing that the BIOS never writes anything other than “0” (zero) zo PB6 – bankswitching is done very easily by just switching pb6 from input mode to output mode or vice versa to change the state of the line (and thus do bankswitching).
(also remember – the BIOS quite often writes to port B, so if you do NOT use the input/output method, you better make sure, that bit 6 is always correct!)

VIA is “clever” enough to remember the last value that was set to PB6. So if you set PB6 to 0, switch to bank one (by switching to input mode) PB6 READS 1 (but still remembers 0 as last WRITTEN value). If you switch back to bank 0 (by switching to output mode), PB6 will READ 0 (zero) again – clever.

Now the trap.

Anyway – since I often do my own output routines I ran into following trap:

clr <VIA_port_b
inc <VIA_port_b

That instruction sequence is not really uncommon. The first line enables the mux and sets the mux to y-integrators.
The second line disables the mux (and usually after that you set a value to portA and than have set xy coordinates of some sort).

The thing is – if you do above sequence while in bank 0 (pb6 = 0) the value in port B is (binary): % 0000 0001
– pretty much what you suspect.

If you do the same sequence while in bank 1 (pb6 in input mode – always reads 1) the value in port B is (binary): % 0100 0001

The “inc” instruction does a READ from pb6. And that read is always 1. The inc instruction internally READS the value, increases the value by one and WRITES the value back. And thus VIA does not remember the last zero we set anymore – since the last value that was set was a ONE (by the inc instruction).

If you try to switch back to bank 0 using the above input/output method you will NOT switch, since PB6 is not set to zero anymore.

Malban