Introduction

This is probably the least exciting chapter in the series. Feel free to skip it, unless you are into random numbers, in which case you can just skip to the final section about random numbers. The first section might be of some relevance as well, where we create a static allocator for RAM, but this tool is not going to be used much in the subsequent chapters. The middle section has almost nothing to do with Megadrive. I just plan for a demo effect and anticipate how many cycles I can spare for its implementation. The effect was never implemented, so feel free to skip this section as well.

I just finished watching these and I feel highly motivated. It’s a good thing to know you’re not the only psycho around:

• Saturn CD cracked after 20 years.
• Bad apple! An awesome Megadrive demo. (Note: Run it on the emulator; it’s got better sync than the video)

Handling RAM and variables

It’s becoming apparent that we will need some variables in the near future. This can be as easy as pointing to an address from FF0000 onward, but I think such an approach will be troublesome later, when we have a lot of variables. Furthermore, we can’t allocate variables in the assembly source, because our binary will be mapped to ROM, so we can only put constants there.

I decided to write yet another tool. Let’s call it ‘stalloc’, for “static allocator”. The tool will parse a simple source file, like the following, and output a file containing assembler symbols assigned to their corresponding addresses:

; Global variables
-global { ; The minus sign means "bypass namespace prefix"
variable1 ; All variables are words
variable2
array[23] ; array elements are words
}

level1 { ; This is a namespace called "level1"
bossPosition[] = {0, 0} ; Variables and arrays can be initialized
bossHP = $100 ; Support for hex
}

level2 {
; ...
; ...
}

bonusLevel {
; ...
; ...
}

#mutex1 { ; This is a mutually exclusive group
bonusLevel ; Namespaces can be listed here
level* ; Why not? :)
}

The idea is that games and demos are usually composed of scenes, or levels where only one of them is active at any given time. So we can put all of them in the same mutually exclusive group, and they will occupy the same block of memory.

Namespaces that do not exist in an exclusion group will occupy their own block.

Also, for our convenience while looking at the memory contents, we’re going to align all blocks to 16 bytes (8 words).

The variables will be initialized from the source file to the value we want. We’ll just pass through the values to the assembler, so all values the assembler can recognize will be valid. The tool will output a macro that will initialize all variables to our desired values.

We’ll call the macro from our systemInit.x68, and then we’ll have variables to put our program state in, without caring where they actually are in memory.

Finally, it will be nice to enforce a minimum stack size, say 512 bytes, which will permit a simple recursion of depth 64. That should be enough.

So, let’s start. I’m doing this one in perl, which is my tool of choice when it comes to string manipulation.

And, here’s the tool’s output:

; ------------------------------------------------
; malloc.x68 - RAM allocation and initialization
; Automatically generated on 24/6/2016 16:41
; ------------------------------------------------
defc RAMStart = $FF0000

; Namespace global
;--------------------------------
defc hScroll = RAMStart + $0

; Variable initialization macro
;--------------------------------
macro initializeVariables
move.l #0, hScroll
endmacro

Now, let’s use the ‘hScroll’ variable to hold our horizontal scroll value, instead of the register d1:

(in app.x68)

; appUpdate is called once per frame, when the active scan starts
; ------------------------------------------------------------------------
appUpdate:
add.w #-2, hScroll

rts

; appRender is called once per frame, when VBlank starts
; ------------------------------------------------------------------------
appRender:
VDPPointToVRAM $F800
VDPWriteToData hScroll
rts

Handle DMA bit not being reset when DMA copy ends

It’s a good thing I didn’t look into this right away, because during the previous day, I happened to catch a warning in the docs. It says that, due to a hardware “feature” (the nerve!), DMA transfers must be initiated from RAM. This means that you either start a transfer from code that is executed from RAM, or that the last write to the VDP control port is copied from a RAM address and not the ROM.

Now the easiest of course would be to try the second alternative. Since I don’t want to allocate a variable for this, I’m going to use the stack. Put the value I want to write to the stack, write it to the control port, and then pop it.

So, here’s how the last instruction ended up:

; The last write that initiates the DMA transfer must be from RAM (go figure)
move.w #(((destinationAddress >> 14) & 3) | $80), -(sp)
VDPWriteToControl (sp)
add.l #2, sp

The DMA bit is not cleared though. This may mean more emulator bugs. I’m just going to reset it manually, and set the machine to our default state:

; Reset #1 to the default value
VDPSetRegister 1, $4C ; R#01 : Display=1, VInterrupt=0, DMA=0, Vertical 30 Cell mode (PAL)

Also, let us wrap the entire DMA copy thing in a macro, as it seems to have matured enough:

; Fill VRAM with our cell data
VDPCopyRAMToVRAM GraphicsData, 0, $5000

Now ain’t this cleaner

Better graphics creation tool

From our previous experience while trying to create some graphics, it became obvious that we won’t get away by using bitmaps. Furthermore, I have checked some tile editors, but they are not exactly what you call “user friendly”. For better or worse, I don’t have artistically what it takes to fill the screen with beautiful graphics, and I certainly don’t think I can convince an artist to work with these tools.

I’m gravitating towards a new tool, which will take a carefully created bitmap (so that it reuses cells), and try to compress it, by identifying repeating cells.

As if this wasn’t hard enough to begin with, the tool must also identify mirrored cells (in both horizontal and vertical axes), and maybe it would also make sense to add some tolerance for one varying pixel or two, so we can trade image quality with compression rates.

I’m not going to make this tool right now, because it’s very complicated and I don’t currently have a use for it. I’m just leaving it as a note, in order to have the specs ready, when (if) I’m going to need a good amount of graphics.

And this takes care of our TO-DO list.

Planning a demo effect

I have been thinking about this for quite a while and it may look fantastic or horrible, but it’s worth a try.

This is a classic fake 3d effect I first saw in the arcades some time in late 80s. Sega’s “After Burner” had it in its intro. Here’s the mega drive version:

They apply 3D math to put the sprites in place, and also sort the sprites, so that the ones closer to the viewer cover the others.

My idea now, is to create a rotating sphere of spheres using this technique. But since that would be extremely lame as a demo effect (even for this hardware), I think I can make it a bit more interesting by adding a depth-of-field effect.

Basically, what we need in order to achieve this, is a series of ball sprites that are progressively blurred. So, the sprites that lie around our “camera” focal plane will be crisp, while the other sprites will be more and more blurred, as they move away from the focal plane.

Of course, this is going to look like shit, with just 1-bit transparency, so we must think of another way. Right now, my idea is to export a separate 8-bit alpha channel for each sprite. The alpha channel will be baked every frame to 1bpp by the cpu like this:

Every frame:
    Every pixel:
        Generate a random 8-bit number
        Compare the random number with the 8-bit alpha value for the pixel.
        If the random number is greater, make the pixel transparent
        Update the cell in VRAM

So, every sprite will appear slightly different in each frame. It will have a different dithering pattern, and the frequency of turning on and off semi-transparent pixels will be proportionate to their transparency.

It will obviously flicker as hell, but I think this is acceptable for this console generation. I remember the “Samurai Shodown” mega drive port used a flickery trick like this for player shadows. In that (awesome) game, the shadow from player 1 was visible in even frames and the shadow from player 2 in odd frames. The overall effect was that the shadows appeared to be semi-transparent, darkening the ground with a light flickering grey, but the region where the shadows overlapped appeared like a deforming pitch black shape, which made my heart skip a bit the first time I noticed it.

So, to make this effect we are going to need:

• Some progressively blurred sprites
• A random number generator
• The best framerate we can get

Since we are extremely limited in terms of calculations per frame, and our plan involves per-pixel operations, I’m going to use extremely small sprites. Let’s start with 2×2.

Furthermore, we will take advantage of the cell mirroring the VDP does for free, so that we can update just one quarter of each sprite per frame. I think I can blur a 2×2 cell in GIMP and maintain the symmetry, by first blurring horizontally and then vertically. This way, the top-left cell will be symmetrical to the other 3 even after the blur.

We won’t need to do any pixel operations for the “focused”, crisp sprite. We can start with one blurred version and see how much of our frame time it consumes. Then we can add more blurred versions.

Some early estimations

Every blurred version will cost us 8×8 = 64 repetitions of the above pseudocode. If I remember correctly, we have about 20K “empty loop” repetitions during the active scan, so if we estimate this repetition to be 10x the duration of the empty loop (it’s a random number generation and a comparison versus an addition), we get to perform pixel operations on about 30 cells per frame.

Here is how 2×2 cell particles would appear on screen:

Which is ok-ish, but I’m not thrilled with the amount of pixels I can play with:

Since we estimate to have enough processing power, let’s try a larger sprite size. Say 4×4 cells. This is 32×32 pixels, and we only need to update the top-left 16×16 region because of the symmetry. Using the same estimation, we can afford about 8 such sprites per frame. I think we can get away with fewer, say 4 blurred versions, and save the rest of the cpu time for 3D rotation and sorting, which is not at all trivial.

And here is how the 4×4 sprites are supposed to look, in terms of size (blue blobs):

So, let’s hope our projections are correct (I think 10x is safe enough), and let’s create a symmetrical 4×4 sprite:

Aren’t I quite the artist! I added a hole in the center, which I think will make for a better depth-of-field effect.

Now that I look at it, maybe we should also update some transparent pixels on the “crisp” version of the sprite, just to add some antialiasing around the edges. That should make our render loop simpler as well.

Also let’s keep it as a note to add some palette rotation. The radial gradient just begs for it!

Luckily enough, our image came out to be symmetrical and divisible by 2 without any effort on our part. Now, we want to create the progressively blurred versions.

Since we are currently happy with the gradient (we don’t need any defined shapes in the sprite), I think I’ll skip blurring the color channels and just blur the alpha channel. For the gradient, the effect should look exactly the same.

And, after some tedious work of blurring and cropping, here are our bitmaps:

And now, for some random numbers…

Found this fast 8bit random number generator.

• 3 additions
• 3 xors
• 1 shift

I ran some tests on the rng:

It spreads the random values uniformly, and it produces good noise, with no detectable patterns. The author states that it’s not good for cryptography, but it’s more than enough for our purpose.

So, here is the algorithm we need to implement:

// initialize (s1,s2,s3 are 3 seed bytes)
x = 0;
a = s1;
b = s2;
c = s3;

// calculate next random
x++;
a = (a^c^x);
b = (b+a);
c = (c+(b>>1)^a);

I’ll have to check again the C operator precedence (I’m not sure what comes first, addition or XOR), but before that, I realize this is a routine we’ll be calling too frequently.

Furthermore, the generator state is just 4 bytes, so we can fit it in our registers. I’m going to use 4 registers for now, even though we could fit the entire state in 1 32 bit register. Thankfully though, the 68K has plenty of registers and we are more interested in speed right now.

Another thing I want to achieve is make this a routine and not a macro, so it doesn’t get copied around multiple times, but, I don’t want to pay for pushing/popping the return address to/from the stack. The algorithm fits nicely in our registers and it would be a shame to spend 2 memory accesses for merely calling it!

Since the routine will not call any other routines, it’s safe to just put the return address to an address register (again, we’ve got plenty of them!). I think this is called a “pseudoroutine”. I may be wrong, but I like the name.

And because I may be creating more routines of this kind, I think I’m going to make a couple of macros, for calling/returning from “pseudoroutines”:

macro pseudoCall, addr
move.l #pseudoCall\@ , a6 ; a6 will hold the return address. We use '#' to take the label as a number and not what it points to in memory
jmp \addr
pseudoCall\@: ; \@ will create a unique id "_nnnnnn" (n=number), unique for every instance of the macro
endmacro

macro pseudoRet
jmp a6 ; a6 better not have changed!
endMacro

I’ve checked the C precedence. So, addition comes first and then XORing follows.

We are now almost ready to implement our random number generator in 68K assembly. If only we knew how to XOR two values…

http://mrjester.hapisan.com/04_MC68/Sect03Part04/Index.html

… of course they had to name it EOR (Exlusive OR) …

Let’s start by assigning register names to the C variables. Following our “put stuff at the bottom” tradition, we’ll use d4, d5, d6 and d7. Also, we’re going to spread the calculations so that we have one operation per line:

; Seed random number generator, using a 32 bit seed stored in d0
; This needn't be a pseudoroutine, but just for symmetry with the other routine, we'll make it one
rngSeed:
d4 = 0;
d5 = s1;
d6 = s2;
d7 = s3;
pseudoRet

; Calculate next random number, it will be stored in d7
rngNext:
d4++;
d5 ^= d7;
d5 ^= d4;
d6 += d5;

d4 <<= 9; ; Hack - shift d4 to the left, so we can use its 8 LSB for storing the intermediate value move.b d6, d4 ; - Tmp store d6 d4 >>= 1; ; - This will produce d6>>1 in the LSB

d7 +=.b d4; ; I wonder if I will be able to remember the symbolism later :)

d4 >>= 8; ; Hack - Revert d4 to what it was before

d7 ^= d5;
pseudoRet

And… if we count bitwise operations to take as many cycles as additions, we are already past the 10x estimate. The compact C syntax can be misleading.

We could have made it a bit faster by using another register, say s3, to hold the intermediate value, but I’m already occupying half our data registers for the RNG and I don’t feel comfortable about it. For now I’m going to tell myself that the XORs cost less than the additions, and we’ll see later if that’s the case.

So, let’s convert that nonsense to 68K assembly. Bit shifts are restricted to a maximum of 8 bit positions per instruction, so I used another trick in place of the >>9. I shifted left 8 bits with instruction size of ‘w’ (word), so that our byte rests safely in the second least significant byte of the register. Then to calculate the >>1, I shift with instruction size of ‘b’ (byte), so that our stored byte remains intact. Good stuff.

; Seed random number generator, using a 32 bit seed stored in d0 (s0s1s2s3 high to low bytes)
; This needn't be a pseudoroutine, but just for symmetry with the following routine, we'll make it one
rngSeed:
move.b d0, d4
lsr.l #8, d0
move.b d0, d5
lsr.l #8, d0
move.b d0, d6
lsr.l #8, d0
move.b d0, d7
pseudoRet

; Calculate next random number, it will be stored in the low byte of d7
rngNext:
add.l #1, d4
eor.b d7, d5
eor.b d4, d5
add.b d5, d6

lsl.w #8, d4 ; Hack - shift d4 to the left, so we can use its 8 LSB for storing the intermediate value
move.b d6, d4 ; - Tmp store d6
lsr.b #1, d4 ; - This will produce d6>>1 in the LSB

add.b d4, d7 ; Yup! I remebered it!

lsr.w #8, d4 ; Hack - Revert d4 to what it was before

eor.b d5, d7
pseudoRet

To test it, I produced 10 random numbers in both 68K assembly and the C implementation, using the same seed (all zeroes).

It may not seem like much, but this is actually the first algorithm I have ever implemented in an alien assembly, and I’m extremely happy my quick transcript from C worked right away!

Dawn is breaking.

Need… to… sleep…

Afterword

Lost you just yet? I hope not. Keep on reading because the real action is about to start!

• Got a list of English words, sorted by popularity.
• Kept only 3 to 10 letter words.
• Removed similar words. All words of equal size differ by at least 2 letters.
• Removed plurals.
• Removed verbs.
• Kept the top 1024 remaining words. So each word can represent 10 bits.

Here it is:

able about above absolutely accept access accident according
account across act acting action actually adam address
admit advice afford afraid after afternoon again against
agent ago agree agreed ahead alarm alex alive
all allow allowed almost alone already alright also
although always amazing america among ancient and angel
angry animal anna another answer anybody anymore anyone
anything anyway anywhere apart apartment apologize apparently applause
appreciate area army around arrest arrested arrived ask
asleep attack attention audience aunt aware away awesome
awful baby back bar base based bathroom battle
beautiful beauty because become bed before begin beginning
behind being believe belonging besides best better between
beyond big bigger biggest bird birth birthday bitch
bite black blame blessed blind blood blow blue
board boat bobby body bomb both bottom boy
boyfriend boys brave break breakfast breaking breath breathing
brian bridge bright brilliant british bro broken brother
brown buddy building bullet buried business busy but
call calling camera camp can captain card career
careful cash castle cause center certain certainly chair
challenge change changed character charles charlie check checked
cheering cheers chef chest chicken chief child children
chinese choice chris christ christmas chuckles church city
class classic clear clearly client close closed clothes
club coach coffee college colonel color coming command
commander common company complete completely computer concerned condition
consider contact contest continue control cool cop corner
correct country couple course court cousin cover covered
crazy created credit crew crime criminal cross crowd
cute daddy damage dance danger dangerous daniel danny
dark darling daughter david day dead death decide
decided decision definitely department desk destroy destroyed detective
devil difference different difficult dinner director dirty discovered
discussion distance division doctor dog dollar done door
double doubt down draw dream dress dressed drink
drive driver drop dropped drug dude due dumb
during duty each earlier early earth easier easily
easy eddie either else emergency empty ended ending
enemy energy engine england english enough entire eric
escape especially even evening every everybody everyone everything
everywhere evidence evil exactly example excellent except excited
excuse exercise exist expected experience extra eyes face
faith family famous fans fantastic faster father fault
fbi feel feeling felt female field fighting figure
film final finally finding finger finish fire first
fish fix flat flight floor flowers fly focus
folks followed foot football for force forced forever
forgotten form forward france frank free freedom french
fresh friday friend from front full funeral funny
further future garden general gentlemen george german ghost
gift girl girlfriend given glad god good goodbye
government grace grand grandma great greatest green group
grow grunts guard guess guilty guy hair half
hand handle handsome happening happiness happy harder hardly
health heaven heavy hello help henry her here
herself high him himself history holy honest honestly
honor hope hoping horrible hospital hotel hour house
how however huge human hundred hungry hurt husband
ice idea idiot important impossible incredible indeed influence
innocent insane inside inspector instead interest interested interview
into invited involved island issue itself jail james
jane japanese jealous jeff jerry jesus jimmy job
john johnny joke judge just justice kenny kept
kevin key kill killed kinda king kitchen knife
knock ladies lady language large last late lately
later laugh law lawyer leader least left leg
less level lie light like little living local
london long longer look loose lord love lovely
luck lucky lunch machine madam magic majesty major
mama manager many market marriage married martin matter
max maybe mean meaning medical medicine meet meeting
member memory men mention message michael middle mile
military million minister minute miss missed missing mission
mistake model mom moment mommy money monster month
more morning most mother mountain movie moving much
murder murdered music myself name named narrator national
natural nature nearly necessary neck need needed neither
nephew nervous network never new next nice nobody
noise nonsense normal nose not nothing notice noticed
nowhere number obviously off offer office officer often
oil okay old once one only open opened
opening operation opinion order ordered original other otherwise
our ourselves outside over own pain pal papa
paper pardon parents paris part partner party pass
path patient paul people perfect perfectly perhaps person
personal pete peter phone photo pick picture piece
place plan planet playing please pleasure plenty plus
point police position possible power powerful prefer pregnant
prepared present president pressure pretty price prince princess
printer prison private probably problem process professor program
promise proof property protector proud public pudding purpose
purse queen question quick quickly quiet quit quite
radio raise ready real reality really reason recently
record relaxation release remember report research respect restaurant
return rich richard ridiculous risk river road robert
rock roger roll room ruined rule run running
russian ryan safe said sarah saturday sauce saved
saying scared scene school science scott scream screw
sea search seat second secret security sense serious
seriously server service seven several shallow share sheep
sheriff ship shirt shoe shoot shooting side signal
signed silence silly simon simple single sir sister
sitting situation skin slept slowly smell smile smoke
social society soldier somebody somehow someone something sometimes
somewhere soon sorry sort soul sound space spanish
special speech spirit split spot spread stand standard
start state station stayed steel steve stick still
stole stolen stomach stop stopped story straight strange
street strength strike strong student study stuff stupid
success sudden sugar suicide summer sunday super support
supposed sure surely surgery surprise surprised suspect sweet
sweetheart sweetie sword system table taken talk target
taste teacher team teeth terrible thanks that the
their themselves there they things third this thomas
those though thought thousand three throat through ticket
time tired today together tomorrow tonight tony too
total totally towards train training travel trial trip
trouble truck true truly trust truth try tunnel
turn turning twice type ugly uncle under understood
unit united universe unless until upon upset upstairs
used usual usually very victim video view village
visit voice vote waiting wanted warm watch weapon
weather wedding week weekend weight weird welcome well
whatever when whenever whether which while who whoever
whom wife wild window with within without witness
woman wonder wonderful work working worried worse worth
written wrong yeah yes yesterday you young yourself

Introduction

In this chapter we’re going to handle timing and have our code run periodically. This will enable us to do such cool things as a scrolling background.
We’re also going to ingest the super mushroom! We’ll start looking at what other people have done. Figuring out stuff by myself has been fun but it gets old real soon.

So, let’s dig in!

Creating a main loop

There are different kinds of things we can do during the active scan and the vertical retrace periods. During the active scan, VDP is really busy, so we’d better not mess with it too much. While the VDP is putting pixels on screen, the CPU has “limited access” to it. This means that the writes we do to data and control ports of the VDP will be consumed less frequently by the VDP, so the corresponding FIFO will become full quickly. I think I saw somewhere in the manual that the FIFO has enough space for 4 writes.

It is both a good and bad thing that, after the FIFO becomes full, the CPU must wait before it can write again. Thank God for this, because otherwise we’d have to check if the FIFO is full before writing. This would complicate things a lot. The bad thing is that we get a performance penalty. Fortunately this is small (about 5-6 microseconds), but nevertheless we don’t want to perform frequent writes to the VDP during active scan. These small delays could stack up pretty easily.

During the vertical retrace, we have unlimited access to the VDP.

Given the above, the simplest way to organize our main loop would be:

	Update (perform game logic etc)
	Wait for VBlank
	Render (push cells/indices/palettes to VDP)
	Wait for active scan
	Repeat

Probably, this is the only way we can do it. There’s this VBlank interrupt that bugs me. I’m trying to figure out what its purpose is, and if we could somehow make use of it. For example, we could set a flag in the interrupt, so that our update routine terminates, but this requires that our update routine is periodically checking for that flag. And if we do that, we don’t even need to use the interrupt. The flag is already available to us in the VDP “status” register:

The other thing that’s bugging me is that we have absolutely no way of controlling when a frame is displayed. Actually, the frame is controlling us. So, in case our update routine takes much time, we will end up waiting for the VBlank of a next frame. I guess the only way around this is to make sure that our update routine is short enough.

Since there’s no practical way of enforcing this, the next best thing is to somehow display a warning if update exceeds its time limit. Let’s push that to our TO-DO stack and carry on with our main loop. We need two routines to implement it:

	VDPWaitForVBlank
	VPDWaitForActiveScan

Both routines will loop until a condition is met. They’re going to be similar to what we did for waiting for DMA completion:

VDPWaitForDMA:
	VDPReadStatus d0
	btst #3, d0
	bne VDPWaitForDMA
	rts

This time we’re looking at bit #2. Let’s start with waiting for the active scan, which will be nearly identical to waiting for DMA completion. We’re looking for a bit to be cleared:

VDPWaitForActiveScan:
	VDPReadStatus d0
	btst #2, d0
	bne VDPWaitForActiveScan
	rts

And then, we flip the condition to wait for VBlank (the things I’m capable of, to avoid understanding again what “bne” means):

VDPWaitForVBlank:
	VDPReadStatus d0
	btst #2, d0
	beq VDPWaitForVBlank
	rts

Ready to roll

We are now ready to make our main loop. But I’d really like to make it do something. Would scrolling our background be too much to ask? Let’s see what the manual has to say…

I had to ask, hadn’t I?

So, to scroll horizontally, essentially you fill this table with the same offset value. Even slots of the table will affect scroll A and odd will affect scroll B. We can also specify a different offset per scanline, which would enable us to do some nice effects. I never liked a game that didn’t have a fake perspective floor.

But I’m not going to do it right now. Alternatively, you can only set the first table position for the entire scrool A and the second for B. I’m not in the mood right now to push 480 words to VRAM, during the VBlank, which, as we saw earlier, is severely limited. In order to do that, you set register #11 to be zero, which we already did during initialization.

Like the sprite table, this table will be more or less permanent in VRAM. So, let’s put it right above the sprite table.

We’re putting the HScroll table to F800, which is right above the sprite table, as tightly packed as the resolution permits (1KB increments – 6 most significant bits of the 16 bit address). We set those bits to register #13.

By the way, here is the main program logic:

	jsr appStart					; app initialization routine
	jsr VDPWaitForActiveScan		; wait for the next active scan
	
mainLoop:
	jsr appUpdate					; app update - during active scan
	jsr VDPWaitForVBlank
	jsr appRender					; app render - during VBlanking
	jsr VDPWaitForActiveScan
	jmp mainLoop

I put the start/update/render routines in a separate file called “app.x68”. Now our previous test’s code is in appStart. We now have a cleaner main file. Actually let me rename it from “test.x68” to “entryPoint.x68”, to be more descriptive.

Now, let’s actually do something in our update routine. I’m just going to increase d1 by one:

appUpdate:
	add.l #1, d1	
	rts

It’s going way too fast. I’ve put code in the wait functions as well, to increase other registers every time they loop. I then divided these registers with d1 to find out that we can do 6 iterations of adding and branching back per frame. I know the Mega Drive is a bit limited, but this is just ridiculous! Furthermore, my frame counter goes up really fast. In the order of thousands of frames per second.

This can only mean one thing: we are not actually waiting for VSync.

Maybe we’re not testing the right bit? Nope, I double-checked the docs.

– Enough is enough. –

This is a major turning point in this series. From now on, I’m going to utilise every single bit of information I can get my hands on. Because otherwise we’re getting nowhere. I’ll find another way to add some adventure to it.

There are far too many errors in the sega2 document. Look at this for example:

WaitVBlankStart:
	move.w  vdp_control, d0	; Move VDP status word to d0
	andi.w  #0x0008, d0     ; AND with bit 4 (vblank), result in status register
	bne     WaitVBlankStart ; Branch if not equal (to zero)
	rts

WaitVBlankEnd:
	move.w  vdp_control, d0	; Move VDP status word to d0
	andi.w  #0x0008, d0     ; AND with bit 4 (vblank), result in status register
	beq     WaitVBlankEnd   ; Branch if equal (to zero)
	rts

This is written by Matt, from BIG EVIL CORPORATION.

Again, I’m not going to try and trace where this info came from, but I’d really like to recursively thank everyone who helped solve this ridiculous mystery.

Also, the BIG EVIL CORPORATION blog has a very nice wordpress theme. I’m stealing that as well.

So, after all, we need to check for byte #3. Fine by me, but then, what on earth were we doing when we were waiting for DMA completion? We were actually waiting for the next frame…

So, where is the DMA bit then? Aha:

I’m keeping this txt by Charles MacDonald.

So we correct all 3 of our waiting routines. Now, frame counts are more believable.

Some stats

Again, I let it run for a while and did the divisions in windows calculator. Seems like we can do about 2658 repetitions of “add, read status, check bit, branch” in our update routine, and about 242 in our render routine. Which totally sucks.

So, VBlanking will take about 8% of our time. That’s an easier number to keep in mind.

Back to scrolling

The only thing left to do now, is write the value of d1 to VRAM location F800. A macro would be handy for writing VRAM:

	macro VDPPointToVRAM, addr
		VDPWriteToControl #(( \addr & $3FFF) | $4000)
		VDPWriteToControl #(( \addr >> 14) & 3)
	endmacro

And then, here is how we scroll:

	VDPPointToVRAM $F800
	VDPWriteToData d1

And yes! It slides!

I’m only scrolling plane A. It seems to be enough, as plane A is of higher priority than plane B, there are no transparent pixels in our image, so we can’t see plane B anyway.

Now, I’d like it to scroll a bit faster and from right to left:

	add.l #-4, d1

Initializing the rest of the VDP (CRAM, VSRAM)

I’m adding a similar macro to point to CRAM, so we can easily change colors:

	macro VDPPointToCRAM, addr
		VDPWriteToControl #(( \addr & $3FFF) | $C000)
		VDPWriteToControl #(( \addr >> 14) & 3)
	endmacro

And one more for VSRAM (Vertical Scrolling RAM):

	macro VDPPointToVSRAM, addr
		VDPWriteToControl #(( \addr & $3FFF) | $4000)
		VDPWriteToControl #((( \addr >> 14) & 3) | $1000)
	endmacro

And here is how we clear both the CRAM and VSRAM to zero in our initialization routine:

	VDPPointToCRAM 0
	repeat 64
		VDPWriteToData #0
	endrepeat
	
	VDPPointToVSRAM 0
	repeat 40
		VDPWriteToData #0
	endrepeat

A little more housekeeping

Sprite table and Hscroll table will be constants, so let’s make some assembler symbols for them:

	defc VDPSpriteTable = $FE00
	defc VDPHScrollTable = $F800

Next item in my list is: “Optimize double writes to control with a long write”. I don’t know if this is going to save some cycles, but let’s do it anyway.

I’m creating two more macros VDPWrite*L, with the ‘L’ suffix:

	macro VDPWriteToControlL, value
		move.l \value, $C00004
	endmacro
	
	macro VDPWriteToDataL, value
		move.l \value, $C00000
	endmacro

And replacing my writes with packed long word writes throughout the code, like this:

	VDPWriteToControlL #$40000080		; Destination address (0)

Afterword

Having taken care of a lot of items in our list, it’s time to move to somewhat higher level programs. Stay tuned for next chapter where we’ll create a primitive memory manager that will let us refer to memory locations using variable names instead of numbers.

There are many situations where it could be useful. In this particular instance, we are making a rotoscoping application with Nuclear, where we draw polygons over a video, to create animations for a game we’re making.

The polygons have uniform fill, so it would be very useful to get a representative color automatically, based on the video pixels that lie underneath each polygon.

The first thing that comes to mind is to just get the average color. This is a simple method, but it can lead to weird results.

For instance, if we have an image that contains mostly blue, but a significant portion of the pixels is red, we’ll end up with a purple average, which is not at all representative of the picture.

The next thing I tried was to select the pixel that is closest to average. This works better, but still, in most images you’ll find edge pixels that vary smoothly between the colors the edge separates. So, in the blue-red example above, it is possible that a purple pixel is found in the boundary between blue and red. In which case we’ll end up with purple, again.

So, here is what I came up with:

• Get the average of all pixels.
• Sort all pixels; from closest to more distant from average.
• Discard the second half (the most distant pixels from average).
• Repeat, until you end up with just 1 pixel.

This works because it progressively gets rid of “impurities”.

So, for our blue-red example, in the first iteration, a purplish average will be calculated. This average will be more similar to blue though. So, we’ll discard all the red pixels in the first iteration.

The next iterations will progressively refine the blue average, until we end up with the most representative blue that can be found in the image.

Because this can be a bit slow, here is an optimization: calculate the representative color of each scanline first, then find the representative of the representatives.

Example output:

Doesn’t it seem like a person picked those colors?

Meanwhile, I couldn’t resist posting this shot:

Introduction

I’m starting to get some mixed feelings about this project.

First of all, I find it unacceptable to have spent so much time for a blank screen.

On the other hand, I know I’m so close to displaying something that I simply must do it today.

And then, I see this:

How on earth did they do it? I have my theories about most of the effects, but what about the giant rotating sprite?

I ran it on the emulator (they provide separate binaries for each emulator cause they also have found bugs in them). I opened the VDP debugger to see how they organize their sprites. In the most interesting parts I see no sprites at all. Maybe they swap them in and out quickly so they don’t appear in the debugger.

But enough thinking about the complex stuff. Back to today. Let’s put something on the screen!

A world made of tiles

All graphics entities of the VDP (sprites and backgrounds) are much like textures. They have a programmable size, in powers of two cells.

A “cell” is a 8×8 pixel region where each pixel is 4 bits – a palette entry. Each cell must choose one of the 4 palettes, so we are restricted to 16 colors per cell. Or 15 colors if you don’t count the transparency (color 0 of every palette is transparent).

VRAM contains cell information. You can organize the VRAM however you like. For every sprite and background, you write all the cells that compose it in VRAM one after another.

Then you assign the graphical entity its starting VRAM address. The entity holds the information for its size (you have specific sizes to choose from for backgrounds and sprites), which implies how many cells it will occupy in VRAM.

The sprite table

VRAM also holds the “sprite table”. This table has a fixed size (64 sprite records if I remember correctly) and it is actually a linked list. It starts with sprite 0, which is a record that contains sprite size, cell data offset in VRAM and a ‘link’ field that will enable the next sprite. I’m guessing they did this so that the programmer could insert and delete sprites fast.

You can put the sprite table wherever you like in VRAM and you tell the VDP where it is by setting register #5.

A first approach

The first thing we could try here is to somehow create a file with our intended VRAM contents, embed that file in the ROM and then copy from ROM to VRAM using a DMA transfer.

So, first of all, we need some 16-color paletted images. BMP files have a 4bpp mode so let’s try to make such a file with GIMP. In order to fill the screen, we need a 32×32 cell background, or a 256×256 bitmap. I like this one:

In GIMP, I changed the mode to indexed, using an optimized palette of 15 colors. Then I added one more color for transparency (purple is commonly used for masks), which is not used in the image, and I put it at index 0, so the useful colors will be from 1 on. Manipulating the palette in GIMP is not that easy. Maybe there are better tools for the job, but right now, we have something to work with.

I exported the image as a 4bpp bmp. I then wrote a tool in C (bmp2cell) that reads the file and spits out a .cell file containing what I think is the correct layout of bytes to fill the VRAM with.

I then embedded the .cell file in my assemby source, using the “binary” directive. There’s also the “even” directive that will make sure what follows is at an even address, so as to avoid odd addressing issues:

	even
VRAMData:
	binary "test.cell"

DMA transfer

And now, to copy the data to VRAM. Here’s how you do a DMA memory to VRAM transfer, according to the manual:

An image is missing (probably register #22), but I have all the information I need from the register descriptions above. It took some experiments, but I think this is it:

	
	VDPSetRegister  1, $5C		; Turn on "DMA" bit (M1)
	VDPSetRegister 15, $02		; R#15 : Auto-increment by 2 bytes
	VDPSetRegister 20, $40		; Copy length: 3FFF will copy 4000 words - NOT!
	VDPSetRegister 19, $00
	
	; bits 8-1 of source address (bit 0 ignored)
	VDPSetRegister 21, ((VRAMData >> 1) & $FF)
	VDPSetRegister 22, ((VRAMData >> 9) & $FF)	; bits 16-9
	; Rest of the bits (MSB must be 0 for memory->VRAM transfer)
	VDPSetRegister 23, ((VRAMData >> 17) & $7F)
	; 2 Writes to control, with splattered destination address
	defc destinationAddress = 0
	VDPWriteToControl #((((destinationAddress >> 8) & $3F) | $40) << 8) 	VDPWriteToControl #(((destinationAddress >> 14) & 3) | $80)

There are a million things to worry about here. First of all, after the transfer is complete, the “DMA” bit of register #1 is not automatically turned off as promised. The transfer did not work like in VRAM fill, where we put one increment less than we need. Now it seems to just copy the exact amount of words we specify. Finally, the word’s byte order is reversed (again). This might be normal.

I stoically reversed the byte order in my C program.

Also, before exporting the palette from the .bmp, I just wanted to test the DMA transfer, so I just made a grayscale palette by repeating the same set of instructions 16 times:

	VDPWriteToControl #$C000	; Give the command to write to palette entry 0
	VDPWriteToControl #$0000
	VDPWriteToData #$0000		; Write color to the data port

I really expected to see something recognizable on screen after running this. We had everything initialized to zero, so the backgrounds must already point to VRAM location 0. Here’s what I saw:

Also, there was a cool flickering effect, I’m guessing that some frames pass while I change the palette.

Moving the sprite table out of the way

I think what we’re seeing here is the sprites. We set everything to zero indeed, so the sprite table must also be at VRAM 0, where we also put our bitmap data. So the sprites are just garbage. Let’s try putting the sprite table elsewhere. The best place I can think of right now is the bottom of VRAM.

The sprite table seems to occupy 512 bytes. So the sprite record must be 8 bytes, for 64 sprites. We must set the 7 most significant bits of the sprite table address to register #5, like this:

	0XXXXXXX (X = A15-A9)

So, to put the table at the bottom, we need to:

	VDPSetRegister 5, $7F

Let’s put that in our initialization routine.

Nothing happens, except the sprites have been cleared. Not all sprites. The emulator shows more than 64 sprite records. The manual mentions more sprites in case we use the “40 cell mode”, which I don’t remember what is at the moment. So let’s try to clear bit 9 of the sprite table address, effectively putting the table a little above the bottom so that more sprites will be cleared.

Again, no visible changes, but the sprite table has been fully cleared. I shouldn’t have expected more though. Clearing everything to zero will not set up the backgrounds to our liking.

So let’s keep on reading the damn manual…

Cell indices

It should have dawned on me sooner. We’ve already filled half our VRAM with the contents of just one background. There’s no room left for the second background, let alone sprites. So we can’t possibly define a background by laying out one cell after the other in VRAM. There’s simply not enough space.

The cells that we write in VRAM are reusable and you create backgrounds by laying out indices to cells.

To complicate things a tiny bit more, the indices are packed with other kinds of stuff, like priority, flipping and color palette selection. So we are constrained to 16 colors per referenced cell (and not per background) after all:

So we must somehow reuse our cells. Too bad I’ve spent time on this tool that exports unique cells from a bmp. We’re going to have to search for another tool for graphics, but right now I will display what I have.

The situation is like this:

• We have occupied the top half of our VRAM with our wonderful texture.
• Therefore we need to fill backgrounds A and B with indices to those cells, in order from 0 to 1023 (32×32 cells for each background)
• So every background occupies 2 KB in VRAM

The quickest thing I can think of right now is to have my bmp2cell tool output this index buffer along with the cell data and then point both backgrounds to the start of the index buffer. That should do the trick.

	/* This tool is going to die soon - add some dumb cell indices for my viewing pleasure */
	for (i = 0; i<1024; i++) {
 		dst[0] = i & 0xFF;
 		dst[1] = (i >> 8) & 7;
		dst += 2;
	}

Note: We point the backgrounds to look for indices in the upper half of the VRAM by setting VDP registers #2, #3 and #4

Now, can I find it in my heart to call this “progress”? I wish I could… Putting aside the urge to give up, let’s mess around with stuff a little bit more…

I seriously have no clue how I reached to that point. I kept flipping things around, but I’m almost certain, the current situation is exactly the same as before. Spooky.

Now, the only thing remaining is to flip high and low bytes in the image data and we’re done. Maybe I was being stoic for no good reason earlier:

From heaven to hell and back!

Also, we get to discover that the scrolling backgrounds wrap around. And what a happy coincidence that I chose a tilable texture for my first test!

The ROM header

Now that I’m satisfied to see my pixels on-screen, I think it’s time to revisit stuff I’ve been neglecting. And first of all, let’s make a proper header instead of copying Sonic’s:

http://www.zophar.net/fileuploads/2/10614uauyw/Genesis_ROM_Format.txt

Here’s a visual representation of the header:

I’ll assume the top half part of the ROM header is given to the programmer to use it however he likes. For instance, check out the funny header TITAN put in their “Overdrive” demo.
Then there’s a series of strings (the green region) that are more or less self-explanatory.

Then we have the product type. We’ll use GM for “game”.

Then follows product code and version number. I’ll set them to ascii ‘0’.

After that, we have the checksum we already calculated in the romtool, in yellow.

Then we have a large string that will start with ‘J’, for “joypad support”, and the rest of it will be ascii spaces as we’re not going to use other peripherals.

Then, there’s the ROM capacity we already handle, in green (start address – always zero) and red (end address).

For the following two long-words, I’ll just copy the values from sonic. I don’t know what they do.

From then on, we have a large string of ascii spaces, with ‘JUE’ near the end, which means the game can be played in Japan, USA, Europe. I’m going to go with that as well.

So, let’s create a separate assembly file, where we’ll put the header data. How do we put ascii and binary data in vasm?

We do both with the same directive: “byte”. It takes any number of arguments that can be either integers or strings.

So let’s do that:

	; Think of something clever to say here
	ORG $0
	byte "IGNORED IGNORED IGNORED IGNORED "
	byte "IGNORED IGNORED IGNORED IGNORED "
	byte "IGNORED IGNORED IGNORED IGNORED "
	byte "IGNORED IGNORED IGNORED IGNORED "
	byte "IGNORED IGNORED IGNORED IGNORED "
	byte "IGNORED IGNORED IGNORED IGNORED "
	byte "IGNORED IGNORED IGNORED IGNORED "
	byte "IGNORED IGNORED IGNORED IGNORED "
	
	ORG $100
	byte "SEGA MEGA DRIVE "
	
	ORG $110
	byte "PSYFLEX 2016.JUL"
	
	ORG $120
	byte "GAME NAME                             (DOMESTIC)"
	
	ORG $150
	byte "GAME NAME                             (OVERSEAS)"

	; "GM" for "game", "AI" for "educational"
	ORG $180
	byte "GM"
	
	; Product ID and version
	ORG $182
	byte " 0000000-00"
	
	; Checksum
	ORG $18E
	byte 0, 0
	
	; I/O Support - 'J' = joypad
	ORG $190
	byte "J               "	
	
	; ROM capacity - this is handled by the romtool
	ORG $1A0
	byte $00, $00, $00, $00, $FF, $FF, $FF, $FF
	
	; RAM - No idea what this is - I'm putting the values from sonic
	ORG $1A8
	byte $00, $FF, $00, $00, $00, $FF, $FF, $FF
	
	; MODEM, MEMO and Country - Mostly spaces
	byte "                                "
	byte "                                "
	byte "JUE             "

I’m including the file ROMHeader.x68 on top of my main program.

Now let’s see how we tell vasm to produce a flat binary. You do that with the -Fbin argument.

Let’s try to create a binary first.

The header looks ok, but regen shuts down (crashes?) when I load the binary. Maybe it’s the broken checksum/rom capacity. Let’s fix that with a new tool. I’m going to call this romtool2 and put it in its own folder, because I want to leave romtool intact so that previous chapter setups will work too.

I’m considering creating a git repository for the whole project, but it’s going to be troublesome when (if) I post the series online. I will then have to go to specific revisions to grab the version of the tool that will work with a specific day’s test.

Wait a minute… That’s not troublesome at all!

So, now that we have a git repository, we can just modify the romtool to only calculate the checksum and rom capacity.

And so we did. But regen still crashes.

I’m starting to believe that the first 256 bytes contain something important. Not so funny after all. Also I think I remember the first bytes in the address space are used for interrupt vectors. Yup, they are.

Interrupts

And now it’s time for our first cheat. I’m going to copy this guy’s code for the first 256 bytes:

Credit for this goes to Marc Haisenko. There are other people involved in figuring this out, whose names are listed in the link above. A recursive “thank you” to you all!

I’m adding a new file called “interrupts.x68”. Our handlers for now will be empty subroutines.

This also takes care of another item in our TO-DO list: “Assumption that nop-nop-bra is mandatory”. It isn’t. I know now because the second long word of the ROM is the code starting address. Sonic actually starts at $206, which means we can now safely remove the nop-nop-bra nonsense.

Unfortunately, vasm does not seem to have a “long” directive, so our version of the first 256 bytes is going to be as ugly as:

	word   ((genericInterrupt >> 16) & $FFFF), (genericInterrupt & $FFFF)		; Bus error

And now, let us pause for a moment to reflect upon our monumental luck, that the random addresses we copied from sonic’s ROM just HAPPENED to be somewhere safe.
Unbelievable. It’s a good thing we put that out of the way.

Trying other emulators

Next item in our list is to make sure we haven’t based our code on false assumptions, based on our reference “hardware”, which is actually an emulator. I tried the binary in 3 emulators just in case:

Afterword

It might not be much, but this little demo brings us closer to our goal… which is kind of undefined… but definitely closer! Stay tuned as we are now almost ready to do some basic animation!

Apparently he runs at 360 Mbps, which means that one bit is being transmitted for the duration of 1/360th of a microsecond.

On the other hand, light travels in fibre optics at 200 m / microsecond.

That’s all we need to know to calculate the length of a bit, ie: how much of the cable a single bit occupies if we freeze time and examine the beginning and end of the signal that represents the bit. Its width is propagation velocity times signal duration.

So it is 200/360 = 0.56 m. A bit is about as wide as one of the chairs below:

This is far from what I’ve expected. I thought bits were tiny. A few mm at most. I was visualizing them as tiny little spots traveling through the wire extremely fast.

Now that I’ve done the math, I find it fascinating because I’m developing a new appreciation of the speed of light.

Everyone has some intuition about how fast a megabyte travels. Now imagine some 8 millions of the above chairs traveling from Brazil to Japan, as fast as a selfie does, and you get a taste of the speed of light. Well 2/3rds of it, but you get the idea…

Now the only thing remaining is to somehow develop intuition about what a “million” means, which I’m not going to say I possess. Nevertheless, I’m still tempted to do some calculations:

Check out the Monsters website and facebook page for more news, release dates etc.

The question is: what happens first? Render queue sorting or Sorting layer sorting?

So, I put 3 sprites at the exact same z:

• A is in render queue 3000
• B is 3100
• C is 3200

So far, so good. Then, we move sprite ‘A’ to “order in layer” = 1:

‘A’ goes on top, which means that sorting layer sorting takes place first, and then render queue sorting is performed among objects of the same sorting layer.

Edit: The beginning of chapter 03 was written in past tense, because the corresponding notes were just summarizing how I found an assembler. There were lots of back and forth most of which I deemed too useless to take notes about.

Introduction

I had no idea that finding a decent 68k assembler for windows would have been that difficult (at least if you are not a cygwin fan). I encountered so many dead-ends that I seriously considered making my own.

Among the assemblers I found, the most promising was “vasm”, a multi-cpu, multi-syntax, multi-host, multi-output assembler that clearly stated it supported m68k and motorola S-REC files. The only problem being that despite its multi-host capabilities, it didn’t support windows.

As a last resort before writing my own assembler, I decided to try and compile it myself. After all it was written in C, so there was a chance it would compile on windows.

Migrating to vasm

So, I used mingw/msys and tried to compile with the following options:

make CPU=m68k SYNTAX=mot

This failed because msys has no ‘CC’ variable defined, so I corrected this as follows:

make CPU=m68k SYNTAX=mot CC=gcc

Which worked like a charm.

I now had a standalone assembler executable. But that didn’t assemble my test files. Maybe the “mot” (motorola) syntax was not the correct one. I’ve tried them all and finally the “oldstyle” seemed to somehow work:

make CPU=m68k SYNTAX=oldstyle CC=gcc

That is, excluding the ‘*’ comments which it didn’t recognize and the END directive that worked somehow differently (the END START line produced an error that said the “START” was garbage, so I removed it and it worked).

Now the only thing left was to make the assembler produce an S-REC file, instead of the “a.out” weird listing it produced by default. Here are the command line options to do that:

vasmm68k_oldstyle.exe -Fsrec -s19 -o test.s68 test.x68

I compiled my previous blue-screen test, and a red-screen variant just for fun and they seem to work fine.

Now I’d like to find out how can we include files using this assembler. Taking a look at the docs.

It simply is:

    include file

Let’s try that. I’m going to make a separate assembly file that sets the background to green this time and include it right after setting to blue:

I needed to indent the “include” directive, otherwise it produced an error, and the filename must have been in quotes, but otherwise, it worked.

Also I found out something useful: if you just write to VDP’s data port a second color, it’s not going to replace the first one, but it will increment the target color by 1 (2 bytes) so you can write multiple entries in the palette with one command to the control port and multiple writes to the data port. Useful.

Automatic build

Now, to somehow automate the building process. We now have a command line assembler, but it doesn’t help if we invoke it by hand. To summarize, the current situation looks like this:

• We have a .x68 file, containing our assembly code, plus as many include files as we want, in the same directory.
• The assembler searches for include files in the current directory, so we must run it from there.
• The assembler produces a .s68 S-REC file with our program, in machine code
• Our “romtool” reads the .s68, plus a “header” binary located in its own directory (so it must be run from there) and produces the final ROM binary.
• Regen (emulator) can load games from the command line!

The only problematic thing here is the “header” binary the romtool reads, which prevents it from working in any path other than its own. Maybe its time to ditch the external dependency. After all, it’s just 512 bytes, so why not embed them directly in the source?

I swear I’ve made this bin2c program a thousand times, but it’s nowhere to be found. I’m just going to modify the existing romtool to spit out the bytes in hex…

Done. We got rid of the dependency and romtool can now be called from anywhere. Now let’s create a bat file to automate the process…

I made a quick bat for now, that just calls the 3 programs (assembler, romtool, emulator) one after another. Maybe I’ll somehow make it stop if anything fails in this sequence, but for now, I’m just happy to be able to test my code instantly.

..\..\tools\vasm\vasmm68k_oldstyle.exe -Fsrec -s19 -o test.s68 test.x68
..\..\tools\romtool\romtool.exe test.s68 test.bin
..\..\tools\regen\regen.exe %~dp0test.bin

I promised this chapter would have been boring, didn’t I?

Now what?

I’m a bit unsure about how to proceed.

Now that we have an acceptable development system, the next thing I was planning to do was to fully initialize the VDP. I’m pretty sure this is going to involve a ton of repeating code, for initializing the various registers and memory locations of the VDP, using the same two (data + control) ports.

So we could surely use some structure in our code. Maybe create some subroutines to perform frequent tasks and see if the assembler provides macros. That could help too.

Subroutines

Back to the 68K tutorial:
http://mrjester.hapisan.com/04_MC68/Sect05Part04/Index.html
http://mrjester.hapisan.com/04_MC68/Sect05Part05/Index.html

So CALL and RET in 68k are JSR (jump to subroutine) and RTS (return from subroutine). Before we can use them, we must initialize the stack first.

My decision to allocate a7 for the VDP was unfortunate, as the 68K treats it as the stack pointer. Identifiers ‘sp’ and ‘a7’ refer to the exact same register, so we’ll need to put the VDP’s port elsewhere, maybe a5. But first we need to decide where to put the stack. Let’s review the memory map in sega2 document again…

Am I stupid for not understanding this? The text above the image says this image displays the difference between the two modes: 16-bit mode and master system compatibility mode. I’m going to guess that the right hand side is for the 16-bit mode because it has a mapped area for the z80. So our work RAM must be in the range FF0000-FFFFFF, which gives us 64K to play with.

So let’s put our stack pointer to FFFFFF:

    move.l #$FFFFFF, sp

And let’s create a separate assembly file for system initialization. I’ll approach this by creating a subroutine there that will perform the initialization, then include the file at the bottom of our program and call the subroutine from our main program, so that the interesting stuff remains on top of the binary.

Silly me, you cannot initialize the stack pointer in a subroutine! This must be the first thing we must do in our program. Let’s just do that.

And… all hell broke loose.

Remember what we said about odd addressing? FFFFFF is odd, isn’t it? So maybe, just maybe we shouldn’t have put the stack pointer there! I put it at $1000000 and the subroutine works just fine. a7 is decremented by 4 bytes first and then the return address is copied on top of stack:

This is also the last memory location that regen allows me to see, which means our assumption was correct: Mega Drive’s working memory is from FF0000 to FFFFFF. The emulator shows only the last 4 hex digits of the address though. Strange, but then again those are the important ones.

Macros

Because I’m extremely lazy, I checked the vasm documentation hoping to find some macro mechanism that will facilitate certain tasks (like packing a word to set a VDP register).

I wrote the following as a joke, but I’m truly amazed the assembler could actually parse it:

    macro VDPSetRegister, register, value
        move.w #((( $80 | \register) << 8 ) | \value), (a5)
    endmacro

So now, we can easily set a VDP register by writing the following, and all the packing required happens during assembly time:

    VDPSetRegister registerIndex, value

Now, since we have the luxury of macros, we needn’t allocate our precious address registers to point to the VDP ports. We can simply hard-code the port addresses in the macro:

    macro VDPSetRegister, register, value
        move.w #((( $80 | \register) << 8 ) | \value), $C00004
    endmacro

Not sure which method is optimal. I guess using an address register will generate a more compact instruction, but I wont let myself worry about that.

Even better, we can use a nested macro for writing a register:

    macro VDPWriteToControl, value
        move.w \value, $C00004
    endmacro

    macro VDPSetRegister, register, value
        VDPWriteToControl #((( $80 | \register) << 8 ) | \value)
    endmacro

A little voice in my head says this is not at all how they programmed the console back in the 90s, and it goes on to say that if that’s the way it’s gonna be, I’d be better off using a C compiler or something.

I’m ignoring the voice.

After adding one more macro to write to the data port, here is how our previous “blue screen” test looks like:

    VDPWriteToControl #$C000    ; Give the command to write to palette entry 0
    VDPWriteToControl #$0000
    VDPWriteToData #$0E00        ; Write BLUE to the data port
    
    VDPSetRegister 7, 0         ; Set VDP register #07 (BGColor) to 0
    
    VDPSetRegister 0, $04        ; Set r#00 as the manual says
    VDPSetRegister 1, $44        ; Set bit 7 of VDP r#01, to enable display

Initializing the VDP

After spending about half an hour making sure there’s absolutely nothing left to do to make my life easier, it’s time to do this full VDP initialization we talked about in Chapter 2.

OR, I can take a break and go for a walk! After all, it’s better to do this kind of thing with a clear head, isn’t it?

Ok, I’m back! I’m so bored to do the following that I took one of my long walks today.

The “long walk” protocol is simple: I choose a random direction and walk as far away from home as possible, taking random turns as I go, until I get lost. Then I use my (often perfect) sense of direction to guide me home.

This randomness makes the walk a bit more adventurous. You never know what lies after the next corner (mostly houses though). It also is an interesting way to burn some calories… At least more interesting than the treadmill.

Let us first set all the VDP’s registers, since we already have the relevant macros. I’m going to do this by looking at the docs, see what a specific register does, and then de-activate all features that I don’t understand or that I’m not going to use.

Here is a first draft:

systemInitVDP:
    VDPSetRegister  0, $04        ; R#00 : HInterrupt=0
    VDPSetRegister  1, $4C        ; R#01 : Display=1, VInterrupt=0, DMA=0, Vertical 30 Cell mode (PAL)
    VDPSetRegister  2, $00        ; R#02 : Pattern name for SCROLL A
    VDPSetRegister  3, $00        ; R#03 : Pattern name for WINDOW
    VDPSetRegister  4, $00        ; R#04 : Pattern name for SCROLL B
    VDPSetRegister  5, $00        ; R#05 : Sprite Attribute Table
    VDPSetRegister  6, $00        ; R#06 : Should be zero
    VDPSetRegister  7, $00        ; R#07 : Background Color: 00PP CCCC
    VDPSetRegister  8, $00        ; R#08 : Should be zero
    VDPSetRegister  9, $00        ; R#09 : Should be zero
    VDPSetRegister 10, $01        ; R#10 : HInterrupt timing - probably '1' means "every scanline"
    VDPSetRegister 11, $00        ; R#11 : ExternalInterrupt=0, Vscroll=Hscroll="full"
    VDPSetRegister 12, $81        ; R#12 : Horizontal 40 cell mode, no interlace, no shadow/highlight
    VDPSetRegister 13, $00        ; R#13 : HScroll data table
    VDPSetRegister 14, $00        ; R#14 : Should be zero
    VDPSetRegister 15, $02        ; R#15 : Auto-increment by 2 bytes each RAM access
    VDPSetRegister 16, $00        ; R#16 : Scroll size: H32, V32 cell
    VDPSetRegister 17, $00        ; R#17 : WINDOW 0 cells from left
    VDPSetRegister 18, $00        ; R#18 : WINDOW 0 cells from bottom
    VDPSetRegister 19, $00        ; R#19 : DMA Length counter low
    VDPSetRegister 20, $00        ; R#20 : DMA Length counter high
    VDPSetRegister 21, $00        ; R#21 : DMA Source Address Low
    VDPSetRegister 22, $00        ; R#22 : DMA Source Address Medium
    VDPSetRegister 23, $00        ; R#23 : DMA Source Address High
    rts

DMA

Then, it would make sense to zero the VDP’s memory. What would be the best way to do this? We can access VRAM through the VDP ports, or we can use a “DMA Fill”, which sounds better. Here is the procedure to perform a DMA Fill:

We first need to turn on the DMA bit (M1) of register #1. After the DMA operation is complete, it will be reset to 0 automatically. Let’s first make a few more macros to read back VDP registers and automate toggling specific bits.

Nope, the registers are write-only, except from the “status” register which is read-only. For now, we’re just going to refill r#01:

    VDPSetRegister  1, $5C

Next, we need to specify the fill length in registers 19 and 20. The VDP has 64K of VRAM, so I’m a bit unsure of what to put in there. I can’t fit a value greater than FFFF, so maybe a value of 0 will fill the entire thing.

This will be my second experiment, but for now, let’s just fill FFFE bytes:

    VDPSetRegister 20, $FF
    VDPSetRegister 19, $FE

Then, we need to fill register #23 with the pattern MMSS SSSS. First two bits is “DMA mode”, which in our case is ’10’ (VRAM fill) and rest of the bits are for source address (in case of DMA copy), which we’ll set to zero:

    VDPSetRegister 23, $80

Next, we have two writes to the control port, containing the destination address, scattered. Fortunately, our destination is zero, so:

    VDPWriteToControl #$4000
    VDPWriteToControl #$0080

Finally (omg!) we must write the fill pattern to the data port (let’s try ABCD as a test fill):

    VDPWriteToData #$ABCD

Note that this ain’t the whole story. Register #15 contains the “increment” value. We set that to ‘2’ previously while initializing, so this is going to be a 16 bit fill. Let’s leave it at that and do the test…

Hehehehe ….

Something was accomplished here. Probably not what we wanted though. The blue stripes are of color 0, so we might have filled zeroes every other byte or so. Let’s take a look at the contents of VRAM:

It’s filled allright, but only with “AB”. What happened to “CD”? Also, why is it filled all the way to the end (FFFF)? Maybe the fill length is in “increments” and not in bytes. Let’s try to fill fewer bytes, say the first 256:

    VDPSetRegister 20, $01
    VDPSetRegister 19, $00

Fuck…

Now we know the length is in ‘increments’. It fills about 512 bytes. 514 to be exact, and only the first two bytes contain my data. Inverted.

…

Ok. The inversion is normal. The filler starts with the lower byte. Also the “increments+1” is normal-ish. That is if you interpret the “DMA starts at after (E)” to mean that. I’m buying it and say I want to fill 255 bytes instead.

Also, for my psychological well-being, I’m going to assume that the zeroes are just a silent emulator bug. Maybe there aren’t any games that try to fill VRAM with words (you normally fill with zeroes anyway). I’ll set the auto-increment (register 15) to be 1 by default and both high and low bytes to be the same ‘AA” and it better work.

Respect my authorita:

Ok. Now we have some sense of control over the VRAM fill thingy. Also, this “increments + 1” allows us to fill the entire VRAM. Let’s now fill it with zeroes and forget about it.

Not so fast! Literally. Before we’re through with this, we must first wait for the operation to finish. I don’t feel that comfortable issuing more commands to the VDP while it’s filling its memory.

To do that, we must first read the VDP “status” register.

To do this, we just read the “control port” address (C00004). Bit 3 is the DMA bit. DMA is active while this bit is ‘1’.

Let’s first create a macro to read the register:

    macro VDPReadStatus, value
        move.w $C00004, \value
    endmacro

The macro takes a register as its argument, and copies the status byte to that register.

Now, how do we loop with a specific bit as a break condition? The 68K has a handy BTST instruction that checks bits, and another one that branches based on the zero flag:

systemInitVDP_loop0:
    VDPReadStatus d0
    btst #3, d0
    bne systemInitVDP_loop0        ; wait until bit 3 (DMA) of status register is cleared

Here is how the condition works:

• btst will test bit #3 (DMA)
• If bit 3 is set, the zero flag will be zero
• This means “not equal” (because when doing comparisons, you subtract, and if the result is zero, this sets the zero flag, which in turn means equal)
• We branch back on “not equal” with bne

I would really prefer the instruction to be jnz. This extra step of “equality” took the best of me.

Since we may do some more DMA in the future, let’s make a subroutine to wait for DMA:

VDPWaitForDMA:
    VDPReadStatus d0
    btst #3, d0
    bne VDPWaitForDMA
    rts

I put that in a separate file called “VDP.x68”, which will be the place to put all VDP related routines.

Afterword

In this chapter we achieved significant progress. We learned about subroutines and macros, we performed a DMA operation and we more or less put the VDP in a defined state.

That’s not the kind of progress that I like. I very much prefer the visual stimulation of new stuff appearing on the screen, but nevertheless we covered a lot of ground towards that.

Next time, I want a sprite on the screen!