FPGA FPGA 2D Video Game Console

[Gilberetsu]

Hey,

I am an electronics engineer student and as my final career project I want to create a game console in an FPGA. It is going to be a 2D video game console, the maximun amount of colors is 256 and is going to be developed in a Spartan6. I want to know your thoughts or any question you have. And if you can, please fill in the survey.

[Pixelboy]

Reading your survey, I just had to take a few minutes to write a few custom answers, given that the selection of choices for each question is a little lacking.

 

Do you play video games?

This is the forum section of a web site called AtariAge. You will not find any video gaming enthusiasts here, obviously. When we're not posting messages on these forums, we're all busy playing a friendly game of Go.

 

 

How old are you?

I think Dracula said it best: "What is a man? A miserable little pile of secrets!"

 

 

Do you like or would you like to play on a video game console?

Absolutely not. I find Pac-Man to be a much more satisfying experience when played on an abacus. By the way, if I answer "yes" to the very first question of your survey, but "no" to this question, does that make me a masochist? I'm excluding PC gamers from this equation, of course.

 

 

Would you like to play on a video game console that is running in the FPGA?

a-AH! I see what you did there! The inclusion of the word "on" makes this a trick question! Since an FPGA runs a virtual game console, such a console has no physical presence, and therefore, it's impossible to stand, sit, or "play" on it! Shame on you for pursuing such chicanery!

 

 

How interested would you be?

I find this question rather puzzling. Are we still talking about video games, FPGAs and whatnot? Because that's already been covered by the question just above this one.

 

 

How would you like the games to be inserted on the console?

I'd like to use a single hand, if possible. Doing it with toes is no fun at all, because you need both feet to do it, and you have to take off your shoes every single time and that's always annoying, even if you do it for the purpose of a funny YouTube video.

 

 

How much would you like a console that only supports 2d?

Well, a 1D console is essentially a carnival high striker, and that's only mildly entertaining for a little while. And a true 3D console would actually be the home version of the Star Trek holodeck, which I think is a little beyond the scope of your proposed project. Same goes for 4D, which is actually time travel. So I'm going to go with the probable majority and say 2D should do fine... As long as there's no sprite flicker.

 

 

How much will you be willing to pay?

That's the wrong question to ask. The correct question is "Kickstarter or Indigogo?".

 

 

How many buttons, besides the D pad, would you like the gamepad to have?

This is probably the most profound philosophical question of our time. Two buttons or not two buttons, that is the question. I could recycle Douglas Adams' probable answer, but that would be lame.

 

 

What resolution would you like the console to have?

I've got your resolution right here (feel free to adjust it to your liking): "I, currently unnamed FPGA gaming console, vow to always display a maximum of 256 colors, to disallow purchasable/downloadable extra content in any of the games I run, to only run bug-free software, and to never allow myself to be placed inside a Jaguar console shell, for as long as I shall exist."

 

 

Seriously, if you want some interesting specs to ponder about for your FPGA gaming console, have a look here.

[Keatah]

That was an amusing response to counter the other bad news I read about earlier.

 

I want to add some stuff, but I'm not sure exactly what.

[Gilberetsu]

That is the best response I've seen on the internet Pixelboy, It made me laugh so hard . But it makes sense, I guess XD.

 

 

This is probably the most profound philosophical question of our time. Two buttons or not two buttons, that is the question. I could recycle Douglas Adams' probable answer, but that would be lame.

That was the best part.

 

And thanks for the tip.

[Pixelboy]

I'm glad you liked my response, because I wasn't trying to be snarky. I was just in a silly mood.

[+grips03]

FPGA Intellivision / Tutorvision would be great.

[matthew180]

The questions were too binary or did not offer options that worked for me. It also sounds like you are trying to create a project that will make money, however you also state that you are a student doing this as a final project. Which is it? IMO you should do it because you want to, you think you can pull it off, and you will have fun. As soon as you start making decisions based on requirements to satisfy an imaginary set of "gamers", you can guarantee it will never get done.

 

Make up a set of realistic set of goals for yourself and implement that. I would also recommend doing an SoC of a system that already exists, that way you will have a code-base of software that you can test with without having to write your own. If you do make a custom system, guaranteed no one will buy it since there will be exactly zero software for it, and no nostalgic attachment to coerce people into spending money on it.

[Gilberetsu]

I agree with you matthew180. But I did the poll just because my final project report requires that I put some sort of "reason" behind my decisions. As you said I wont be able to finish the console if I want to satisfy someone else, I agree with that, but I will try my best to do some of those things, at least in the time I have. But if I see it would take too much time I am going to do it the way I see it can be done.

I told my professor that the console wouldn't sell, and he told me that I have to do a poll anyway, so I did it. I have to do a financial plan too, and thats why I asked how much money you are willing to pay for a console you dont know anything about.

I am just doing the console because it's interesting and fun. I dont have any plans to sell the console, if the university doesnt want anything to do with the console (for some reason they have the right to do something with it), I am going to put the source code on github.

[Andromeda Stardust]

For inserting games, you left out the cart slot.

 

I all seriousness, SD card would be preferable because it future-proofs the system. Look at all the useless hardware out that would still work fine but used parallel / serial ports, USB, ect that drivers are no longer supported.

 

Also will the output be analog or digital? Pretty much all game consoles with analog video output are 240p by default, so the resolution question is somewhat redundant. I chose 640x480p because this scales better to HDMI. 240p 2D consoles should be line-doubled, not scaled. 3D consoles need a fast bilinear scalar though for optimum results.

[Gilberetsu]

Also will the output be analog or digital? Pretty much all game consoles with analog video output are 240p by default, so the resolution question is somewhat redundant. I chose 640x480p because this scales better to HDMI. 240p 2D consoles should be line-doubled, not scaled. 3D consoles need a fast bilinear scalar though for optimum results.

It's going to be digital output, and I am going to scale ir to 1024x768, it's going to have black spaces or some sort of frame, because I dont want to strech the image.

 

And yes, the SD card reader is the best option, and the one that i am going to implement first.

[Andromeda Stardust]

It's going to be digital output, and I am going to scale ir to 1024x768, it's going to have black spaces or some sort of frame, because I dont want to strech the image.

 

And yes, the SD card reader is the best option, and the one that i am going to implement first.

You may want to consider support for 1280x720 as this is better supported by widescreen displays and scales better from 240p.

[Gilberetsu]

Are you sure about that? I think most monitors support 1024x768. yea I could use 240p and scale it to 1280 x 720, so there is no black space.

Edited October 23, 2017 by Gilberetsu

[matthew180]

I manged to vote.

 

I'm unclear how much you have to implement yourself, and how much you can use any existing HDL cores? If you have to implement a CPU yourself, and if you have not done it before, I would suggest you limit the project to only making the CPU work. That is a big enough task all by itself. You also do not mention your skill level in HDL and getting circuit working. If you are learning during this process, everything will take longer. If you can use existing HDL cores, then I would suggest a list like this:

 

CPU: existing Z80 or 6502 core. Reason: Proven cores, tools and software already available. If you go with the Z80 and pick the T80 core, make sure you hunt down the latest mash-up of fixes since the version on opencores has bugs.

 

Audio: existing core, or roll your own. Reason: Audio is pretty simple, so you can do it yourself or find something already proven.

 

Memory: FPGA Block RAM. Reason: the Spartan 6 should have enough BRAM for a basic system, and BRAM is fast and easy to work with. If you feel you have to use SDRAM, use an existing proven core and understand it will be slower than BRAM/SRAM.

 

Video: Roll your own VGA. Reason: VGA is convenient and easy. You can roll your own in a few hours and have graphics on the screen. If you are going to use a digital interface (i.e. HDMI), use an existing core.

 

 

For the ROM you can use FPGA resources or SD. If you use SD keep in mind that you will need some sort of CPU core and software stack to read data from the FAT file system. Otherwise you can go the quick-and-dirty way and store binary data raw on the SD card, but you will need to write software on a PC to take the binary files and write them to the raw unformatted SD card.

[Gilberetsu]

I manged to vote.

 

I'm unclear how much you have to implement yourself, and how much you can use any existing HDL cores? If you have to implement a CPU yourself, and if you have not done it before, I would suggest you limit the project to only making the CPU work. That is a big enough task all by itself. You also do not mention your skill level in HDL and getting circuit working. If you are learning during this process, everything will take longer. If you can use existing HDL cores, then I would suggest a list like this:

 

CPU: existing Z80 or 6502 core. Reason: Proven cores, tools and software already available. If you go with the Z80 and pick the T80 core, make sure you hunt down the latest mash-up of fixes since the version on opencores has bugs.

 

Audio: existing core, or roll your own. Reason: Audio is pretty simple, so you can do it yourself or find something already proven.

 

Memory: FPGA Block RAM. Reason: the Spartan 6 should have enough BRAM for a basic system, and BRAM is fast and easy to work with. If you feel you have to use SDRAM, use an existing proven core and understand it will be slower than BRAM/SRAM.

 

Video: Roll your own VGA. Reason: VGA is convenient and easy. You can roll your own in a few hours and have graphics on the screen. If you are going to use a digital interface (i.e. HDMI), use an existing core.

 

 

For the ROM you can use FPGA resources or SD. If you use SD keep in mind that you will need some sort of CPU core and software stack to read data from the FAT file system. Otherwise you can go the quick-and-dirty way and store binary data raw on the SD card, but you will need to write software on a PC to take the binary files and write them to the raw unformatted SD card.

 

I have to use the external memory, I know is slower than the BRAM, but I will think about something like a cache and see if i can manage with that or talk to my professor.

 

I have to create my own CPU, I think that if I can change the memory where the screen data is stored, if I can do arithmetic operations and jump from and instruction tu another I well be fine. But I now creating a good microprocessor is not an easy task, I am learning about it.

 

I have a video system working, so not a big problem. Abou the SD card I am going the quick and dirty way for now.

 

And I am going to work with the audio when I get the microprocessor working.

 

I know VHDL (well, maybe), like 3 months ago a did a video game, but with no processor just a couple of FSMs, a video system and a RS 232 port to connect it to the pc and control it with a keyboard (it was because in the class that i took they told us we had to use the serial port for our final project of that class). I did it in a Spartan 3. Its not finished is just a level and a coin.

 

This is a video showing the game https://drive.google.com/open?id=0B-8jYZQ-zYb3T3Z0Z1IwZW5xU0k

 

Thanks for the suggestions.

Edited October 24, 2017 by Gilberetsu

[matthew180]

I did a 9900 core for my F18A project, and I used dedicated control logic instead of a microcoded control (the real CPU is microcoded). I have since gone back to implement it as a microcoded CPU and found that it is actually much more difficult than dedicated control. I have also started a Z80 and 6502 a few times and found that the control logic on the 8-CPUs is *very* complex compared to the orthogonal 16-bit 9900. I managed to get my first 9900 core working in about 3 weeks. I do *not* recommend trying to do a Z80 or 6502 for this project, you may never finish (or you are a far better HDL programmer than me! )

 

The project you did sounds like the Pong game from Chu's VHDL by Examples book. That is a very good book and was the book that opened the door to HDL for me.

[Gilberetsu]

I did a 9900 core for my F18A project, and I used dedicated control logic instead of a microcoded control (the real CPU is microcoded). I have since gone back to implement it as a microcoded CPU and found that it is actually much more difficult than dedicated control. I have also started a Z80 and 6502 a few times and found that the control logic on the 8-CPUs is *very* complex compared to the orthogonal 16-bit 9900. I managed to get my first 9900 core working in about 3 weeks. I do *not* recommend trying to do a Z80 or 6502 for this project, you may never finish (or you are a far better HDL programmer than me! )

 

The project you did sounds like the Pong game from Chu's VHDL by Examples book. That is a very good book and was the book that opened the door to HDL for me.

The book that teach me how to describe hardware in VHDL was Free range VHDL. I am going to check the VHDL by example book.

 

I am not a better HDL programmer than you!, or at least I don't think so. I am going to see the 9900 core architecture to see what I can take from it. I am going to see what seems to be the quickest way and then I am going to add complexity.

 

Thanks for the recomendation

[matthew180]

I have passed on Free Range VHDL a few times, I'll have to go give it another look. As for Chu's books, I can't recommend them enough. The "by Examples" book (he has the same book for both VHDL and Verilog) is very approachable and introduces a lot of working projects without bogging down in a ton of theory. By the end of the book he brings everything together in a dedicated-hardware version of Pong. His other book "RTL Hardware Design Using VHDL" is also really good, but that one a much heavier read and more towards analysis and deeper understanding.

 

I picked the 9900 because it is the CPU in my Classic computer of choice (the TI-99/4A), and because I wanted it as the "GPU" in my video board. It is easy to understand, it is very orthogonal, the opcodes are easy to decode, and it seems to borrow a lot from the PDP-11 line of minicomputers. It has a RAM-based register-file though, which is odd compared to many of the CPUs of the same era. Also, if you have to use external RAM, try to have it be SRAM. SDRAM is a pain in the ass to use, and has horrible performance for random access. And no matter what RAM you use, I'm not sure if a cache would be worth the effort and complexity. I would say to get it working without a cache, then add it later if you have time and a need for it. There are a few simple VHDL controllers out there, Hamster has one, and his work inspired me to write one. Both are available on our respective websites.

FPGA discussions are few and far between, so if you have questions or things you want to discuss, please post (maybe in a different area, since this is a very strange place for this thread). If you have a project website please post the link, it would be fun to watch your progress and decisions.

 

Edit: Ah yes, Free Range VHDL, the free book. I have it, I just have not had time to read it yet.

Edited October 25, 2017 by matthew180

[Gilberetsu]

I think Free Range VHDL is a good book. I was reading about the MIPS architecture that is described in the book Digital Design and Computer Architecture by David Money Harris and Sarah Harris and the Game Boy CPU Manual for ideas.

I am using a development board, the Mimas V2 Spartan 6, and it has an LPDDR memory as the external RAM, so I am stuck with that (for now), to use it I created a Memory Controller core using the MIG of Xilinx, and I can write and read from memory so it's working, the latency depends heavily on the amount of commands I issue and the amount of ports I have, that's why I wanted to create something like a cache, at least for the video controller I am going to use a BRAM to store what is going to be on the screen, I am going to have 2 buffers, 1 is going to be what is currently on the screen and the other is going to be the next frame.

I am going to create a post on WordPress (so I don't waste too much time creating a website), I don't have one right now because I didn't think someone would be interested in the project or helping me, so thanks for offering your help. When I get it ready I am going to post the link here.

Thanks!

[matthew180]

I would recommend making the video system tile-based and generate the image on-the-fly using a single line buffer. This method was used by many coin-op games from the early 80's (the golden era), as well as many home computers and consoles.

If you go with a 100% pixel-addressable display, then you will need a lot of memory bandwidth, and a CPU that can update the off-screen buffer in less than 16.6ms. At 640x480 the pixel scan-out is 40ns per-pixel, and you will need to multiplex CPU access that can write just as fast. This is where SDRAM sucks, since writing to a frame-buffer by the CPU is random, but pixel scan-out can be very linear (depending on how the pixel data is laid out).

Using a MIG-generated memory controller you can probably use a burst-mode for reads and writes. In that case, you can probably get something like 8-bytes in 100ns or so, which is the same as 1-byte about every 12.5ns. With a pixel-rate of 40ns (assuming 640x480), 8 pixels is 320ns worth of time, which will give you 220ns (320ns - 100ns to read 8-pixel) before you need another 8-bytes. That should give you enough time to allow full-speed CPU access. A 640x480 display is 307,200 pixels, and if you run your CPU at 100MHz and can update a pixel every cycle (10ns), you could update the whole display in about 3ms. But, your CPU instructions will not execute every 10ns for sure (that would be a very efficient CPU!), and you have to clear the buffer too (a dedicated hardware loop could clear the back buffer in about 3ms though).

For all those reasons, a tile-based solution with hardware sprites makes a nice system that is easy to program and gives good results. Or reduce the resolution. There is a reason DOOM on a 486 was only 320x200 pixels.

There are lots of options, but don't fall into the trap of doing what modern computers do just because, well, modern computers can do it. Modern computers are running at GHz speeds with graphic cards that have extreme memory bandwidth and really wide (128-bit or more) data paths. The classic consoles and computers (mid 80's) are good examples of systems that would be a good fit, IMO.

... I don't have one right now because I didn't think someone would be interested in the project or helping me, so thanks for offering your help. ...

It is always interesting to see a project when the person doing the work is serious and actually producing something. However, most of the time people are just talking and nothing comes of it, thus the conversation gets exhausting. I'm always glad to talk about concepts, ideas, implementation specifics, etc. but you are the one who will have to figure out the details and do the work.

 

If you don't know about Hamster's wiki, you should do a search (you will know when you find it). Also, Radical Brad's Vulcan-74 project on the 6502.org forum is unbelievable and a must-read:

 

http://forum.6502.org/viewtopic.php?f=4&t=3329

[Gilberetsu]

 

 

But, your CPU instructions will not execute every 10ns for sure (that would be a very efficient CPU!), and you have to clear the buffer too (a dedicated hardware loop could clear the back buffer in about 3ms though).

Yes, I know, just with the read and write latency of the memory controller I get way over that number. I was thinking about doind a dedicated hardware to do that.

 

 

 

I would recommend making the video system tile-based and generate the image on-the-fly using a single line buffer.

Well if I have a dedicated video system I could do a frame buffer, not just a single line. If i could update every pixel on the screen in 3ms I thinkg is posible, becase using a 640x480 it is going to take the VGA system 12.3 ms to put every pixel on the screen (without considering the Vsync and Hsync zones), so I have a lot of time left, so the system cold.

 

 

 

For all those reasons, a tile-based solution with hardware sprites makes a nice system that is easy to program and gives good results. Or reduce the resolution. There is a reason DOOM on a 486 was only 320x200 pixels.

Yes, I could do that too.

 

 

 

There are lots of options, but don't fall into the trap of doing what modern computers do just because, well, modern computers can do it. Modern computers are running at GHz speeds with graphic cards that have extreme memory bandwidth and really wide (128-bit or more) data paths. The classic consoles and computers (mid 80's) are good examples of systems that would be a good fit, IMO.

Yeah, thats why I was reading the GBA CPU manual and the snes one too, so I at least get an Idea of what I should do.

 

 

 

It is always interesting to see a project when the person doing the work is serious and actually producing something. However, most of the time people are just talking and nothing comes of it, thus the conversation gets exhausting. I'm always glad to talk about concepts, ideas, implementation specifics, etc. but you are the one who will have to figure out the details and do the work.

At least in my case, it is not an option, not to do it.

 

 

 

If you don't know about Hamster's wiki, you should do a search (you will know when you find it). Also, Radical Brad's Vulcan-74 project on the 6502.org forum is unbelievable and a must-read

yep, I think I found it. Radical Brad does magic with a breadboard WOW

 

Thanks!

[Andromeda Stardust]

Bump. How did the final result of your projdct turn out? A followup would be nice.

[+HatNJ]

We may or may never see a follow he has not signed on since Dec 4th

[Gilberetsu]

Hey, sorry for not updating I thought you all lost interest, I had to focus and I had to stop the development a month ago because of another project. The console turned out fine, its functional. I am going to write a post with more information but for now I am going to show you some images of what I manged to achieve.

 

This is the console and its controller

 

This 2 are images in a simple program that show images on the screen

 

This is an image created by the console

This is a video in the console

This is a program that moves an image layer in the screen

This is a simple "game" running on the system

 

 

 

Edited March 16, 2018 by Gilberetsu

[Gilberetsu]

Polybios

 

Hey, I took a little bit more than I expected to write this post, sorry, I am a little bit busy with something now. I am not sure if this post is going to be enough, but if you have any questions, comments or ideas on what I could have done differently, please write a post response.

To make this console I used VHDL because is the HDL that I am most comfortable working with. To make this project I used 2 Xilinx cores: the memory block and the memory controller, everything else was written by me in VHDL.

 

I created a Micro SD card reader for low capacity cards version 1, I used the SPI mode for communications, at the moment the system reads the first 64 MB of the Micro SD card and puts it on the memory card. I don't use any file system, the reader just receives any information the sd card may have.

When the system is turned on the sd card waits for the memory controller to be calibrated then it sends the initialization messages then the message to read a block of data from the micro SD card and when it reads 64 MB the system enables the Video Card and The Processor, and the Micro SD card reader stays in IDLE state. In the future, I am going to add the possibility to read and write from memory in runtime from the processor. It takes the system around 1 minute and 35 seconds to load. The reader and the card have a clock speed of 20MHz because of the limits of the SD card.

The processor and the video card have a clock speed of 130 MHz because that's double the clock speed of the VGA connector controller that is 65MHz because that's the speed needed for the output resolution.

 

The Video System

 

The video system has an output resolution of 1024x768, but the image that is displayed has a resolution of 256x192, the images are scaled up so black lines don't appear at the side of the screen or on the bottom or top. The video system uses 2 layers to show the images on the screen, the layers are 272 x 208, as you can imagine the system doesn't show the entire image on the screen and the pixels that don't show on the screen I intend to use them as buffers. One of the layers is on top of the other and to make the two of them visible at the same time the top layer has a transparent color that can be changed via the processor, and when the system is "rendering" the image it takes that into account to make the final image. The Layers can be moved to any direction, and its like you had the layer as a texture of a sphere and when you move the layer is like you rotated the sphere in the X axis, Y axis or both at the same time. This can be changed via the processor too.

The entire layer is stored in the memory, the system has 2 line buffers, one for the line of pixels that is been put in the screen and the other is the next line that is going to be shown, it has 2 line buffers for each layer, and the lines that are loaded in the line buffer depends on the positions of the layers and the actual line of pixels that the screen needs. So the system knows where to look for the images there is 1 signal in the video card that says the address for the first pixel of the layer.

 

The Processor

 

After the micro sd card reader finishes reading from the memory card and writing to the RAM, the processor starts reading the first address in memory. The processor can read and write 32 bits of memory at any given time. The processor reads from memory, executes the action, and changes the program counter (if the operation changed the program counter this step is skipped) then repeats. The processor has 31 general purpose registers and 1 register that is always 0 that is in total 32 internal registers. The processor also has a memory block that stores a sprite, that can be 8x8, 8x16, 16x8 and 16x16 pixels this is used to copy sprites from one location in memory to a video layer, it is specific to a video layer because in a video layer the pixels of a sprite arent contiguous unless they are in the same line. Apart from that, the processor can do a lot of things the instruction set is this.

 

The Game

 

The code of the game I showed in the other post (before passing through the compiler). You can see it has labels and a weird operation "IMG" these are not seen by the processor, the compiler gets rid of them before it gets stored on the sd card.

LITERALR1 layerA
MOV 1 10
SVR 10 0
SSP 10
MOV 10 11
ADDI 11 221 0
SVR 11 1
LITERALR1 stackPointer
MOV 1 25
SSP 25
LITERALR1 redraw
MOV 1 30
RVALUP 12 0 0
RVALDOWN 12 0 253
RVALUP 13 0 0
RVALDOWN 13 0 62
RVALUP 24 0 0
RVALDOWN 24 0 5
MOV 0 9
MOV 0 8
MOV 0 5
LITERALR1 0 0 10
MOV 1 18
MOV 1 15
LITERALR1 0 0 128
MOV 1 16
MOV 1 19
MOV 0 17
LITERALR1 worldArray
MOV 1 6
forLoopBody:
ADD 5 6 7
LOAD 7 4
LS 4 10 3 9 8
ADDI 9 0 4
ADDI 5 0 1
GREATER 9 13 0
JUMPI elseA
MOV 0 9
ADDI 8 0 16
GREATER 5 12 0
JUMPI forLoopBody
GVR 22 9
CALL 30 31 0
JUMPI mainProgram
elseA:
JUMPI forLoopBody
mainProgram:
GCA 14
BTF 14 8 0
JUMPI elseBtn1
BSF 17 0
MOV 15 18
ADDI 15 0 1
GVR 22 9
CALL 30 31 0
JUMPI loopRedraw
elseBtn1:
BTF 14 7 0
JUMPI mainProgram
BCF 17 0
MOV 15 18
SUBI 15 0 1
GVR 22 9
CALL 30 31 0
JUMPI loopRedraw
loopRedraw:
GVR 23 9
SUB 23 22 21
GREATER 21 24 0
JUMPI loopRedraw
JUMPI mainProgram



redraw:
LITERALR1 eraser
MOV 1 4
LS 4 11 3 18 19
MOV 19 20
ADDI 20 0 16
LS 4 11 3 18 20
BTF 17 0 0
JUMPI elseredrawA
LITERALR1 charUpSideA
MOV 1 4
LS 4 11 3 15 16
LITERALR1 charDownSideA
MOV 1 4
MOV 16 20
ADDI 20 0 16
LS 4 11 3 15 20
RETURN
elseredrawA:
LITERALR1 charUpSideB
MOV 1 4
LS 4 11 3 15 16
LITERALR1 charDownSideB
MOV 1 4
MOV 16 20
ADDI 20 0 16
LS 4 11 3 15 20
RETURN



skul:
IMG ./images/PPP.jpg 8
cloud1:
IMG ./images/cloud1.jpg 16
cloud2:
IMG ./images/cloud2.jpg 16
cloud3:
IMG ./images/cloud3.jpg 16
cloud4:
IMG ./images/cloud4.jpg 16
ground:
IMG ./images/ground.jpg 16
underground:
IMG ./images/underground.jpg 16
sky:
IMG ./images/sky.jpg 16
eraser:
IMG ./images/eraser.jpg 16
charUpSideA:
IMG ./images/charUpSideA.jpg 16
charDownSideA:
IMG ./images/charDownSideA.jpg 16
charUpSideB:
IMG ./images/charUpSideB.jpg 16
charDownSideB:
IMG ./images/charDownSideB.jpg 16
stackPointer:
IMG ./images/eraser.jpg 16
IMG ./images/eraser.jpg 16
IMG ./images/eraser.jpg 16
IMG ./images/eraser.jpg 16
IMG ./images/eraser.jpg 16
IMG ./images/eraser.jpg 16
IMG ./images/eraser.jpg 16
IMG ./images/eraser.jpg 16
IMG ./images/eraser.jpg 16
IMG ./images/eraser.jpg 16
IMG ./images/eraser.jpg 16
IMG ./images/eraser.jpg 16
IMG ./images/eraser.jpg 16
worldArray:
DB 0 sky
DB 0 sky
DB 0 sky
DB 0 sky
DB 0 sky
DB 0 sky
DB 0 sky
DB 0 sky
DB 0 sky
DB 0 sky
DB 0 sky
DB 0 sky
DB 0 sky
DB 0 sky
DB 0 sky
DB 0 sky
DB 0 sky
DB 0 sky
DB 0 cloud3
DB 0 cloud4
DB 0 sky
DB 0 sky
DB 0 sky
DB 0 sky
DB 0 sky
DB 0 sky
DB 0 sky
DB 0 sky
DB 0 sky
DB 0 sky
DB 0 sky
DB 0 sky
DB 0 sky
DB 0 sky
DB 0 cloud1
DB 0 cloud2
DB 0 sky
DB 0 sky
DB 0 sky
DB 0 sky
DB 0 cloud3
DB 0 cloud4
DB 0 sky
DB 0 sky
DB 0 sky
DB 0 sky
DB 0 sky
DB 0 sky
DB 0 sky
DB 0 sky
DB 0 sky
DB 0 sky
DB 0 sky
DB 0 sky
DB 0 sky
DB 0 sky
DB 0 cloud1
DB 0 cloud2
DB 0 sky
DB 0 sky
DB 0 sky
DB 0 sky
DB 0 sky
DB 0 sky
DB 0 sky
DB 0 sky
DB 0 sky
DB 0 sky
DB 0 sky
DB 0 sky
DB 0 sky
DB 0 sky
DB 0 sky
DB 0 sky
DB 0 sky
DB 0 sky
DB 0 sky
DB 0 sky
DB 0 sky
DB 0 sky
DB 0 sky
DB 0 sky
DB 0 sky
DB 0 sky
DB 0 sky
DB 0 sky
DB 0 sky
DB 0 sky
DB 0 sky
DB 0 sky
DB 0 sky
DB 0 sky
DB 0 sky
DB 0 sky
DB 0 cloud3
DB 0 cloud4
DB 0 sky
DB 0 sky
DB 0 sky
DB 0 sky
DB 0 sky
DB 0 sky
DB 0 sky
DB 0 sky
DB 0 sky
DB 0 sky
DB 0 sky
DB 0 sky
DB 0 sky
DB 0 sky
DB 0 cloud1
DB 0 cloud2
DB 0 sky
DB 0 sky
DB 0 sky
DB 0 sky
DB 0 cloud3
DB 0 cloud4
DB 0 sky
DB 0 sky
DB 0 sky
DB 0 sky
DB 0 sky
DB 0 sky
DB 0 sky
DB 0 sky
DB 0 sky
DB 0 sky
DB 0 sky
DB 0 sky
DB 0 sky
DB 0 sky
DB 0 cloud1
DB 0 cloud2
DB 0 sky
DB 0 sky
DB 0 sky
DB 0 sky
DB 0 sky
DB 0 sky
DB 0 sky
DB 0 sky
DB 0 sky
DB 0 sky
DB 0 sky
DB 0 sky
DB 0 sky
DB 0 sky
DB 0 sky
DB 0 sky
DB 0 sky
DB 0 sky
DB 0 sky
DB 0 sky
DB 0 sky
DB 0 sky
DB 0 sky
DB 0 sky
DB 0 sky
DB 0 sky
DB 0 ground
DB 0 ground
DB 0 ground
DB 0 ground
DB 0 ground
DB 0 ground
DB 0 ground
DB 0 ground
DB 0 ground
DB 0 ground
DB 0 ground
DB 0 ground
DB 0 ground
DB 0 ground
DB 0 ground
DB 0 ground
DB 0 underground
DB 0 underground
DB 0 underground
DB 0 underground
DB 0 underground
DB 0 underground
DB 0 underground
DB 0 underground
DB 0 underground
DB 0 underground
DB 0 underground
DB 0 underground
DB 0 underground
DB 0 underground
DB 0 underground
DB 0 underground
layerA:

As I said earlier if you have any questions, comments or ideas on what I could have done differently, please write a post response.