What's new

Simple Visual Basic Programming Question

sammyboy

Certified SuperHero
I have tried numeros times to create an emulator (chip-8, gameboy) on Visual Basic but a few problems always hit me.


When emulating - where on earth do I start.

Loading - How do I implement out the loading opcodes

Loading - What else do I need to do when programming the loading part

Testing - How do I test to make sure the loading workd even though I havn't started the running game part.

Running - I dont have a clue about this.

The best way someone could help me is to give me a tutorial but not one that is boring with loads of long words but one that has funny bits and jokes kind of like they are talking to someone and not a computer. Otherwise I loose interest in the tutorial and walk away from it none the wiser.
 

MasterPhW

Master of the Emulation Flame
sammyboy said:
I have tried numeros times to create an emulator (chip-8, gameboy) on Visual Basic but a few problems always hit me.


When emulating - where on earth do I start.

Loading - How do I implement out the loading opcodes

Loading - What else do I need to do when programming the loading part

Testing - How do I test to make sure the loading workd even though I havn't started the running game part.

Running - I dont have a clue about this.

The best way someone could help me is to give me a tutorial but not one that is boring with loads of long words but one that has funny bits and jokes kind of like they are talking to someone and not a computer. Otherwise I loose interest in the tutorial and walk away from it none the wiser.
Don't think there's a tut like these out there, but if there's one, I would like to see a link to it or something like this... if nobody has a link than probably is google ypur friend, but I don't think you will find a funny one.
 

glVertex3f

Crap Cracker
You need to make sure you know the basics of the language.

The process of emulation is like so.

1.) Load a rom into a "buffer" so you can access it
2.) You can make a variable called "opcode" or what ever and assign it with the current location in the buffer.
3.) Do this in a loop so after you have assigned the opcode you can see what the opcode's value is and do the associatd action.

quick example

Lets say the contents of a "rom" is like so

12 45 DA 54 36 24 65 57

Now you load that in to a buffer so you can have constant access to it.

So you would now assign the opcode variable to 12.. check docs to see what the 12 instruction is and "do" it. then increse your location... now opcode is 45, etc..

This is a rough idea on how it works, but you should get the idea ;)
 
Last edited:

refraction

PCSX2 Coder
also you will find that many of the opcodes are shown as hex format, if im not mistaken VB doesnt actually support hex, so you will need to convert all the values into decimal :)
 

glVertex3f

Crap Cracker
I myself had actually thought about trying to make a Chip8 emu in a few different languages just for the heck of it, but I couldnt find a decen (free) IDE for any knid of BASIC language
 

BGNG

New member
Hex can also be done in VB with "&H" before the number, such as &HFF. Be warned that certain numbers will be considered negative. If it becomes a problem, then just use decimal math. No biggie.

A good place to start emulating is the ROM binary specification. All parts of a ROM mean something, and all ROMs of the same type are arranged the same way. Knowing the specification will let you tear apart its header and initialize anything it needs to use.

The boot instructions of any program simply set parts of memory. This will be emulated in an almost-identical manner to the rest of the ROM. Probably the simplest way to see if the loading completed successfully is to step through every boot instruction yourself, then compare it to the state of the memory in your emulator.

As was mentioned earlier, load the entire ROM into memory. Don't keep reading from hard disk. Visual Basic allows things like this to do that:
Code:
Dim Buffer() As Byte
Open "C:\File.rom" For Binary Access Read As #1
ReDim Buffer(0 To LoF(1) - 1) As Byte
Get #1, 1, Buffer()
Close #1
Also, a handy thing to do is set aside exactly the number of bytes for "memory memory" as the emulated machine has total. So if you're emulating a 64K machine, set aside 64K bytes of memory in a RAM() array or something to that effect.

Basically, an emulator just boots and runs. Running, as was also mentioned before, simply jumps around in the Buffer reading instructions and manipulating memory. Some instructions will be for normal memory, some for audio, and some for video. Look up documentation of your opcodes to find out what does what.
 
OP
sammyboy

sammyboy

Certified SuperHero
Look hang on lets get this striaght, first of all how would I set up a buffer.
 
OP
sammyboy

sammyboy

Certified SuperHero
BGNG said:
*Points up, as the previous two posts were posted mere seconds apart*

Sorry, you posted at an identical time to me,

But I am a slow learner so say I was to start a new project on a basic compiler (I have VB.Net 2003, but if you dont I will change it seeing as the BASIC language on .NET is practically a different language all together) what would I do first. Would I work on the GUI and logo and ICON. Or should I work on getting coding done and where exactly should I start emulating, I have no idea. So help me in a step to step basis and dont start using difficult words.
 

BGNG

New member
For starters, you need to go out and learn how the machine interperates and executes the ROMs you want to emulate. It's logically feeble to try making an emulator if you can't make it emulate. But if by chance you do know all the intricacies of the machine you'll be emulating, the best place to start is setting up a software environment that will act as the hardware of the machine. Basically, program the chipsets into your emulator so they integrate with other software functions instead of the machine's real hardware.

VB.NET, huh? As much of an enthusiast as I am about Visual Basic, Microsoft royally biffed with that one. "VBNET" is an acronym that stands for "Big Pile Of Dirt," but they used the wrong letters. (-:

Honestly, though, I don't like it and haven't bothered to learn it. I can't help you with VB.NET
 

refraction

PCSX2 Coder
BGNG said:
VB.NET, huh? As much of an enthusiast as I am about Visual Basic, Microsoft royally biffed with that one. "VBNET" is an acronym that stands for "Big Pile Of Dirt," but they used the wrong letters. (-:

im with you there, i really would suggest using VC++ or something where you have more control over your programming, altho its not as easy to make a window as in VB, its faster and more in depth when it comes to Emulation.
 

BGNG

New member
I'm not going to say you're wrong, refraction........ but consider it highly implied. Most Visual Basic developers are under the illusion that they can make programs by adding controls to the form. That's not true. And because of their mistaken interperatation of what programming is, C++ developers tend to think that Visual Basic is somewhat incapable when it comes to making low-level programs.

I'm personally developing an audio technology for music composition where in essence its files have sounds and notes and the notes are rendered by altering the sounds for volume, pitch, etc. I'm doing this in Visual Basic. I've written all the audio device handlers and procedures, read binary file data from the byte-sizedly-optimized files, render all of 255 sound channels, mix them together, the works. And it does all this full-speed at 22050hz on my 500MHz, Win98 test machine.

I'm as well making a Uniracers remake (3D, but side-scroller) in VB with OpenGL. There's no lag to speak of.

VB also gives complete access to DLLs, TLBs, OCXs, EXEs, etc. There's very little a C++ program (for Windows) can do that Visual Basic can't. The only real restriction is the way Microsoft likes to limit the memory access from VB processes only to the memory allocated for them, but they provided conveniently "undocumented" ways to work around that.

Visual Basic does have more overhang, however, making it somewhat slower than C++. However, VB developers are spared the hassle of exception handling, memory deallocation, overflow checking, etc., so it evens out.
__________

In the case of an emulator, there is no better pick. VB and C++ can both get the job done with tons of cycle time left over. It all boils down to if you would rather say "If X <> Y Then" or "if (x != y) {"
 

NeTo

Emu_64 HiP Coder
Actually, Visual Basic should present some problems while coding, especially if you use the code from other emus as a base. In design, there is the fact that visual is not fully object oriented (class polyphormism and inheritance work in a very limited way), there is a minimal support for pointers, and certain low level memory operations need to be done via API. The way other object oriented languages are designed (not just C++) allows the programmer to follow a more natural design when coding.

Performance wise, there isn't a real multithreading support (altought this problem seems somewhat fixed in .NET). Even if you use activex, all vb code is executed line by line. All the program's code runs in a single thread, and timing several components would be a hard task. Also, simple tasks like casting or making hex to dec convertion take more time in visual basic, as some data type functions will not be replaced with machine code at compiling, but with references to the runtimedlls.

Visual Basic is more than capable for tasks like working in a audio processing application, or a Chip8 emulator (or to say the least with OpenGL and DirectX, as their respective libraries aren't compiled in VB). But when it comes to emulate more complicated systems, other languages show their stronge points.
 
OP
sammyboy

sammyboy

Certified SuperHero
Well I have VB.Net 2003 Enterprise Edition. And everything is object oriented now so that problem has been solved.

So if I open up VB (To Create a CHIP8 emulator) where would I start. I have studied CHIP8 thoroughly and could probably write my own docs on it now, but that would be boring.
 

smcd

Active member
You have the enterprise edition of software that you (apparently) don't even know how to use? :happy: *coughcoughpiratecough*
 

Top