ArkanDOS

[tienkhoanguyen]

It was easy. Those who made the computer structure were nice enough to put the resource map out there for people to lookup. I did the easy part and turned it into a function in C so that you do not have to type the whole activation of 255 colors all the time haha

[tienkhoanguyen]

Thank you Quadko for being there as a cool person. I do not know you, but you ended up being right about that mode 0x13. However, it took assembly and a register call or something to activate it instead of Borland Turbo C 2.01 without assembly.

I do not know anything. All, I know is that I was able to access 256 colors somehow through some internet resources.

I wish I knew who to give credits to. However, missing the key of who designed it - I have to just Thank you to Jesus Christ and let him take care of taking care of those who takes care of me!!!!!!!!!!!!

[tienkhoanguyen]

There is a C source called "pixel.c" by David Brackeen.

It demonstrates writing to direct video memory and using the interrupt to write to memory.

I used his demonstration of using the system interrupt to write to mode 0x13

Then I wrapped it within my function and so it is based off of this.

[tienkhoanguyen]

My theory is that I let the system interrupt do the memory writing instead of direct video memory access since the system checks for safe measures. For instance making sure it does not crash.

The direct video access would be faster so a game such as Quake would be able to update the entire screen like that. However it might be unstable since it bypasses system checks for proper input.

Normally you would want to check your car before running it after a certain period or else the tires might be worn.

Bypassing this check on a regular basis is unstable.

Just my two cents on the two ways to do it.

[Quadko]

Eh, not much can go wrong writing to video memory other than writing past the end. And even that's safe other than maybe making the computer reboot or getting a write failure trying to write to a ROM address that never can be written to. I wouldn't worry about it, you can't hurt anything writing to memory, certainly not video memory. It's designed to do that all day every day and twice on Sundays. Up to you!

I forget the upper bound, but I think you have all memory from 0xA0000 to 0xC0000 (minus one) for video. Lets see: 320 x 200 x 1 byte per pixel (256 color) is 64000 bytes, in hex is 0xFA00, so maybe just from 0xA0000 to 0xB0000 with a little left right before the end? Maybe 0xB0000 memory is for video rom, that rings a bell. But text screen memory is at 0xB8000 as I recall (and am using in my joystick program this week so I know it's true), so best to look the video memory range up to double check. Again, you can't hurt anything writing to the memory, it'll either work or not.

However, you do have to be more careful if you ever do an "out port" assembly call. That's how you tell hardware to do stuff, so you want to be sure you get the right command to the right device. It's fine if you are careful or just talking to the video card with normal commands, of course! But unless you are doing HICOLOR/TRUCOLOR video modes, you shouldn't have to write to the video ports unless you want to, and even then it's probably easier to figure out the VESA driver calls rather than write directly to the port. Just lots of little facts, nothing important in all this.

[tienkhoanguyen]

haha - well, I am new so I am building on a solid empty foundation. I am using interrupt calls so I better get the right interrupts or else I end up writing to disk instead of video memory haha - that would be a bummer to find out one day all my files have been corrupted because I used the wrong interrupt address call haha

Anyways, I just hate writing directly to video memory. It just looks so improper and besides I think it would be less compatible with future versions. The interrupt should be stable on the other hand. Just my two cents.

I am not an expert or else I would be able to do everything by now. However, I just like learning. For instance, I just enjoy learning about Borland Turbo C 2.01 just for learning sake. It is like a fun hobby of mine. I just wish I could do everything before I pass away at 100 years old - if I am fortunate hehe

[tienkhoanguyen]

Thanks for your feedback for what it is worth. I really appreciate it, and glad to see your joystick routine is going good. I am happy for you too. Sounds like you are also do a lot of stuffs now a days and that is cool!

[MrFlibble]

However, I am still trying to figure out how engines like QuakeOne redraws an entire screen so fast.

Have you looked at the source code? BTW, I didn't know/realise until now that the Quake engine was written in C.

[tienkhoanguyen]

Well, for this new exciting day, I have made an honest attempt to test out as safely as I can direct video access. Unfortunately it is unstable. The addresses stored in as video memory is not continuous and is erratic. The direct video memory access has proven to be unreliable on my computer.

However, using the official system call to place the pixels such as with interrupts always has so far proven reliable.

O-well, so much for fast 1 second updates at this point in time. I guess I have to wait 12 seconds per page haha

[tienkhoanguyen]

Thank you for the interesting read. Just noticed one main thing is Quake uses assembly for the rendering of scenes. If my memory serves me correctly there is a protected mode access that has to be changed so that it allows direct video access. In this case I can see it is possible to draw the entire Quake scenes at 1 second per page.

However, assembly is way over my head at this point in time as I have chosen to specialize in pure C. O-well, better the tortoise than the hare. haha

Thank you again for the nice article.

[Quadko]

...The addresses stored in as video memory is not continuous and is erratic. The direct video memory access has proven to be unreliable on my computer.

However, using the official system call to place the pixels such as with interrupts always has so far proven reliable.

Interesting results. "Not continuous" is also interesting, though I have a faint memory that each video line might be aligned on something like a 16 byte boundary, so maybe there are some padding bytes between. I was recently reminded that bitmap files have something similar - an image might be 5 pixels wide, but each line might have 8 bytes rather than 5 bytes on it, 3 bytes of padding to align it to an even power of two boundary.

I'm glad you have at least some stable method! I think the only concern is if it's fast enough for you.

Last night my first joystick project is a completed success! Then I woke up with one more idea to implement, but that and some cleanup and I'll play show and tell here shortly. I'm very happy to have this as a building block, and maybe get that project out of my brain. Honestly, the joystick code was easy, it was the formatting of data into strings for display in assembly and some math that was the biggest challenge. And of course, I already have ideas for my second joystick project...

[tienkhoanguyen]

Cool. Be glad to see it. However no pressure. I know working on my ArkanDOS official release for paid version is maybe put on hold indefinitely haha

Maybe it will be abandon ware

[Quadko]

Here's the demo image, and I'll get a zip package up for download soon.

It's a text mode program to show two working joystick axis and 4 buttons. Move the sticks, the knobs and axis sliders move around, and the numbers across the bottom show Joystick 1 values and which of the four buttons are pressed.

Of course, if you only have a one axis joystick/gamepad, that works just fine!

With this I can take over the world! Muhahaha! Well, hopefully, at least I can do the next steps of turning a little interactive demo into a game. Two paths from here - convert the demo to graphics, or make a text mode game from this. Both have temptations, but perhaps it's time to cycle through other projects first.

And tienkhoanguyen, if you've wrapped some assembly into a C function, reading the joystick is equally trivial, at least in dosbox! It works great in dosbox because Windows calibrates the joysticks and they "just work". In dos the game has to calibrate the joysticks; otherwise they "work" but probably don't have the right range of motion. Code still works, though, just a matter of scaling the numbers you get back - much easier in C than in ASM! I'll show off the joystick code once I get the zip uploaded and linked, just in case you or anyone is interested sometime in the future.

Thanks for the encouragement and infectious enthusiasm!

[tienkhoanguyen]

I know how rewarding it is to have even a small demo out. So even your joystick demo is worth seeing. I enjoy looking at the pictures even though I do not have a gamepad myself. Keep going - it looks promising. Remember, if you do end up making a game - I would add an easy keyboard alternative just in case the people do not have one of those. I will see what I can do about getting one of those Sabrent USB gamepads. It looks cool.

Hey - at least one person might be testing it out. I might have to hold off until Christmas time to get the funds though. I am pretty sure I can get $20 bucks for Christmas haha That is what my 100-packs of blank DVDs usually costs when it is on sale haha

[Quadko]

Thanks! Yes, a joystick only game is limiting enough; a dual-stick gamepad game for dos is limited even further.

I really like the Sabrent; I got it because it looked cool, was cheap, and showed promise. It was a risk that paid off. It's definitely cheaper and not just less expensive than an XBox360 gamepad, that's still my favorite for playing on windows. But DosBox doesn't recognize the 360's second stick correctly, something to do with mapping an an extra analog "axis" on the trigger buttons and DOSBox just using the first 4 no matter what, so I can't use it for a dual stick game in Dos! Not that there are many/any other than what I'm writing. But the 360 controller works great in windows and dosbox as a left-joystick and right-buttons, so really no complaints. Hopefully a future DosBox release will fix that minor issue.

Here's the asm for joysticks values in Dos/Dosbox that I talked about. Basically just call an interrupt twice, once for analog axes, once for buttons. You can treat it like two joysticks, or a dual-stick gamepad setup. The trick is INT 0x15, function 0x84, subfunctions 1 & 0. It's the fastest way to get values in DOSBox, and the slowest way in dos. And again, DOSBox joysticks are autocalibrated and return a number from 0x01 to 0xFE with 0x7F/0x80 being centered. For Dos you really have to do the "put joystick in upper left" ... "now in lower right" ... "now in center" to find out what the real joystick's ranges are, and every joystick is different.

Code: Select all

	; Get joystick Axes into ax,bx and cx,dx for two joysticks
	mov ah, 84h
	mov dx, 1
	int 15h

       ; Now do something with the values in ax,bx (X,Y #1) and cx,dx (X,Y #2)
	
	; Get joystick buttons into ax - 4 buttons, two on each joystick
	mov ah, 84h
	mov dx, 0
	int 15h

        ; Now do something with the values in ax, bits 4-7 are "button on/off" flags

I looked up how to do inline assember in C, and this is what I came up with. It might be wrong or I might have typos, but maybe it saves someone time

Code: Select all

void GetJoystickValues(void)
{
    int x, y, x2, y2, buttons;

    asm mov ah, 84h
    asm mov dx, 1
    asm int 15h

    asm mov [x], ax
    asm mov [y], bx
    asm mov [x2], cx
    asm mov [y2], dx

    asm mov ah, 84h
    asm mov dx, 0
    asm int 15h

    asm mov [buttons], ax
}

or it looks like instead of the asm keyword on every line, mabye use an asm block?

Code: Select all

void GetJoystickValues(void)
{
    int x, y, x2, y2, buttons;

    /* some sites say the { must be on the same line as __asm keyword */ 
    __asm {

        mov ah, 84h
        mov dx, 1
        int 15h

        mov [x], ax
        mov [y], bx
        mov [x2], cx
        mov [y2], dx

        mov ah, 84h
        mov dx, 0
        int 15h

        mov [buttons], ax
    }
}

Of course, then you do something with the values, or maybe you make the variables global rather than local or store them somehow. There's also probably a way to do buttons = ax or x = ax without using asm (I see things like "buttons = regs.x.ax;" in sample code, but I don't know if that's correct or works for your Turbo C version.) Ultimately it doesn't matter as long as it gets the right values to the right memory location for use as the variable!

[tienkhoanguyen]

That's quite a bit of work you seem to have done. Well, reading it makes me tired haha However, it is interesting. I will see if I can put it into Borland Turbo C 2.01 format and do an alternative second gamepad input for ArkanDOS. Just for you to try out if you like it. Something for fun.

I just try to do things for fun now a days since I have just learned that I really do not care about being paid for something. I know money is important for getting food, rent, and stuffs like that paid. However, I just let my mom handle that. I was never good with money. That is why I had so many jobs. Each job tries to get you to "sell" and I always end up talking to the people instead haha

[tienkhoanguyen]

Well, I just entered it in Borland Turbo C 2.01 and it would not allow inline assembly like you have it. However, for your purposes as long as you are able to get it to work on your end that is what we are looking for. I do not need it at the time. I am pretty sure I can get it working however I just need time to compare how one of the vga sample does their assembly. Maybe the assembly program that gives me 255 colors can give me pointers on how to do assembly.

[tienkhoanguyen]

/*
Here is the working proper working assembly version. However you may need to edit it to your needs.
*/
void GetJoystickValues3(void)
{
int x, y, x2, y2, buttons;
union REGS regs;
regs.h.ah = 0x84;
regs.x.dx = 1;
int86(0x15,&regs,&regs);
x = regs.x.ax;
y = regs.x.bx;
x2= regs.x.cx;
y2= regs.x.dx;

regs.h.ah = 0x84;
regs.x.dx = 0;
int86(0x15,&regs,&regs);
buttons = regs.x.ax;
}
/* I am not sure if it works 100% - however it compiled all the way in Borland Turbo C 2.01 */

[tienkhoanguyen]

Also I just found out I am not able to test the code out on my own ArkanDOS game at this point in time since I do not have a gamepad yet.

[Quadko]

Cool work, though. Thanks for the more official compilable code, I'm glad to learn. int86() - great function to know. ASM is fun but a pain, for larger projects I'll likely try to get a C compiler working, and you speak so highly of yours...