There’s no doubt about it. Syntax highlighting in code is the cornerstone of readability (in my mind anyway). I was browsing around today and found an assembly language highlighter for visual studio here.
Now my code looks like this (inside of VS).
Well, not really.
Nostalgia got the better of me today in the form of some good old mode 13 demo code. All the hours I’d blown previously developing little tid-bit apps like this and I never saved off any of my code. Thankfully, I have a good memory and whilst my assembly skills aren’t “top shelf”, they’re certainly up to the task of re-creating this sort of effect.
They’re all the same. They work of the same principal.
Easy!
So, I’ll present this little demo in a couple of chunks and explain them as I show them. The code is pretty well documented anyway so that reading it line for line should be very self-explanitory.
.model small
.stack 100h
.code
start:
mov ax, 0013h ; set 320x200x256 mode
int 10h
mov ax, 0a000h ; we can't directly address ES so
mov es, ax ; we do so through AX. ES = A000
call setup_palette ; setup a palette with greyscale
; to support the smoke effect
no_kbhit:
call randomize_lines ; draw some random pixels
call bloom ; average out the video buffer
mov ah, 01h ; test for a key press
int 16h
jz no_kbhit ; continue running if no key was hit
mov ax, 0003h ; set text mode
int 10h
mov ax, 4c00h ; return control back to dos
int 21h
; -- subroutines removed for brevity
end start
endThis is the main program. It needs to drop us into the required video mode, make sure we don’t want to quit (i.e. was there a key hit?), actually perform the effect (the loop of random/average) and then clean up (send us back to text mode, return control to dos).
Setting up the palette in this type of routine really does determine the “type” of routine that it is. As I’d said above:
The idea is to experiment with palette creation to see what comes out best for you. Here’s how I setup a greyscale palette.
setup_palette:
mov cx, 255 ; 256 colour indicies to set
next_colour_idx:
mov al, 255 ; setup al so that we're setting
sub al, cl ; colour indicies from low to high
mov dx, 3c7h ; this port selects the colour index
; that we'll set r,g,b for
out dx, al
mov dx, 3c9h ; this port sets the r,g,b components
; for the selected index
shr al, 2 ; rgb intensities are in range of 0..63
; so, divide by 4 to adjust
out dx, al ; set the red
out dx, al ; set the green
out dx, al ; set the blue
dec cx ; move onto the next colour
jnz next_colour_idx
retSo, just a touch of VGA theory here. Unlike today’s video modes, the 256 colour VGA supported 256 indices that each had an RGB intensity set ranging (0..63) each. Sometime, I don’t know how we ever used this video mode, but we got by – and made some damn cool stuff using it. So, software port 3c7 takes a colour index. 3c8 can be used to read the colour intensities (not used in this program). 3c9 is the port we use to write (r,g,b) intensities. Dividing by 4 allows me to interpolate 0..255 against 0..63 so that 0 is the colour with least intensity up to 255 which has the greatest.
###(not so) Random
Getting psuedo random numbers with nothing in the toolbox is difficult. The method that I’ve used here is to constantly read from software port 40h which is tightly coupled with the timer interrupt but it keeps a fairly steady count. The uniformity of these numbers actually provides a very tame smoke effect, you’re not going to see much chaos.
randomize_lines:
mov cx, 640 ; we're going to set two rows of pixels
; at the bottom of the screen to be
; random colours, so that's 640 pixels
mov di, 63360 ; we're going to start writing these
; pixels on the last two lines so that's
; 64000 - 640
next_rand_pixel:
mov dx, 40h ; we get quasi-random values from port 40h
in al, dx
stosb ; store the pixel on screen
dec cx ; move onto the next pixel
jnz next_rand_pixel
retSo, following along with the effect we only randomize the last two rows of the video array. Simple.
It’s just an averaging effect. We take the average of the current pixel, left, right and top most. We then re-set the pixel back into video memory 1 pixel above our current location. Therefore, we have no interest in trying to process the top-most row of video memory.
The only other part that is a little awkward to look at in this code block will be the ADC instructions. We’re dealing with bytes (values of 0..255). We’re adding 4 of these together so we’re going to quickly overflow a byte sized register. ADC (or add with carry adjustment) allows us to overflow this information into AX’s higher-order byte (AH). When it comes time to divide (or take the arithmetic average) of this pixel’s intensity, we’ll be able to perform this operation on the word sized AX register. Neat. Check it out:
bloom:
mov cx, 63680 ; we average every pixel except the top row
mov di, 320 ; we start at the 2nd row
next_avg:
xor ax, ax ; clear out our accumulator
mov al, es:[di] ; get the current pixel
add al, es:[di-1] ; add the pixel to the left
adc ah, 0 ; adjust for overflow
add al, es:[di+1] ; add the pixel to the right
adc ah, 0 ; adjust for overflow
add al, es:[di-320] ; add the pixel above
adc ah, 0 ; adjust for overflow
shr ax, 2 ; divide by 4 to get the average
cmp al, 0 ; can we dampen?
jz no_damp ; jump over if we can't
dec al ; dampen the colour by 1
no_damp:
mov es:[di-320], al ; put the averaged pixel 1 pixel above
inc di ; next pixel
dec cx ; keep count of how many we've got left
jnz next_avg
retSo, when you put it all together (and run it in DosBox) you’ll get something that looks like this:
Well.. I’m feeling all nostalgic now. Might go and fire up DosBox and play a couple of games of Double Dragon.
For such a long time I have read over these tutorials. They have been a great source of information in doing things the “unix way”.
Beej’s site http://beej.us
Beej’s Guide to Network Programming http://beej.us/guide/bgnet/output/html/singlepage/bgnet.html
Beej’s Guide to Unix IPC http://beej.us/guide/bgipc/output/html/singlepage/bgipc.html
Beej’s Quick Guide to GDB http://beej.us/guide/bggdb/
Haskell is a strange beast at times. I think you can see from the brute-force approach on this implementation of SPR that I was getting clearly frustrated with even some of the simplest of things.
I really could have used “Maybe” I really could have used “Read”
It’s a learning experience:
module Main where
import System.IO
import System.Random
data Move = Scissors | Paper | Rock | Unknown deriving (Eq,Show)
data Outcome = Winner | Draw | Loser | ND deriving (Show)
str2Move :: String -> Move
str2Move s = do
case s of
"s" -> Scissors
"p" -> Paper
"r" -> Rock
_ -> Unknown
getWinner :: Move -> Move
getWinner m = do
case m of
Scissors -> Rock
Rock -> Paper
Paper -> Scissors
Unknown -> Unknown
getOutcome :: Move -> Move -> Outcome
getOutcome player cpu
| player == Unknown || cpu == Unknown = ND
| player == cpu = Draw
| cpu == winner = Loser
| otherwise = Winner
where winner = getWinner player
getCpuMove :: StdGen -> Move
getCpuMove gen = do
let (randNumber, newGen) = randomR(1, 3) gen :: (Int, StdGen)
case randNumber of
1 -> Rock
2 -> Scissors
3 -> Paper
main = do
gen <- getStdGen
putStr "Enter your choice (s, p or r): "
hFlush stdout
line <- getLine
let player = str2Move line
let cpu = getCpuMove gen
let outcome = getOutcome player cpu
putStrLn $ "Player Chose: " ++ (show player)
putStrLn $ "Cpu Chose : " ++ (show cpu)
putStrLn $ "Outcome : " ++ (show outcome)Some who have been nice enough to comment from time to time have suggested that I move forward with this implementation (inclusion of Lizard, Spock).
Anyway, I’ll keep struggling.
This one came across the news wire today. I just wanted to make a note of it so that I don’t loose it.
There’s plenty in here that will allow you to take any site from 0 to hero.
http://ivanzuzak.info/2012/11/18/the-web-engineers-online-toolbox.html