OSDev.org

6502Rulez wrote:My code is still executed way too fast.

6502Rulez wrote:The first time it's always 0, after the other it's always 9 (4th bit set, isn't that weird ?)

Octocontrabass wrote:

6502Rulez wrote:My code is still executed way too fast.

Are you using a virtual machine? Those tend to be inaccurate when it comes to timing.

6502Rulez wrote:The first time it's always 0, after the other it's always 9 (4th bit set, isn't that weird ?)

According to VGADOC, that is the expected behavior.

Geri wrote:first of all, the timing of your game should not rely on vsync.

~ wrote:You really should get development-only laptops and PCs. You won't get far using only emulators. You should also get peripheral cards that work with those systems, and some newer ones. The "old" cards compatible with Windows 98 and DOS will be key and vital to your OS development success, even if most people around don't like it, because they are specific to the PC platform, relatively modern, and thus they will allow you to get the most of your learning about the PC.

The newest PCI cards with diminished backwards compatibility are probably not even specific to the PC platform. They are probably platform-independent, platform-nonspecific cards for Mac, PC and unknown proprietary non-standard hardware platforms.

The ones I like the most are the ones to which I can install Windows 9x because that also gives me access to DOS.

I also consider that it was an error from my part to switch from Windows 98 to Windows XP in my main machines (actually in all of my machines). The moment I did that is when I lost access to the friendliness of the low-level-oriented Windows 9x and DOS which sustained my main OS development efforts.

Only recently I have reinstalled and reactivated all of my development machines with Windows 9x/98/ME/DOS/FreeDOS, and from there I can boot and test my code in DOS or stand alone.

But you need to start out by getting those machines and fully VGA-compatible video cards, as well as CRT and LCD monitors to really test that the effects of your code are doing something at all.

6502Rulez wrote:Yes i'm using qemu like this :
qemu-system-i386 -fda image.img
Same thing happens on VirtualBox

6502Rulez wrote:(and vsync isn't some exotic thing one would want to do, right ? So I assume that qemu/virtualbox can support it fully)

6502Rulez wrote:Any ideas what is going on ? I'm booting from USB

LtG wrote:Not sure what your issue is, but here's a few notes:
- You don't seem to have ORG anywhere? Maybe it's outside of the code snippet you provided
- Is there a reason you are clearing SP specifically BP? Can't see it affecting your issue though
- Is there a reason you push and pop AX at the bottom of your code? What effect is that supposed to have?
- In your "begin" code you are not initializing BX which I think is used by int 0x10, therefore in VM (Qemu) it might be left at zero while on real hardware it could be anything

Last one being your issue is my guess, or maybe first.. So add to your begin after "xor ax, ax":
mov bx, ax

Vsync in a virtual machine is a rather unusual requirement. Vsync using a virtual machine's VGA compatibility layer instead of the VM's native graphics device is unheard of.

globl CHANGE_VGA_COLOR
.type CHANGE_VGA_COLOR, @function

CHANGE_VGA_COLOR:
	push ebp
	mov ebp, esp
	mov dx, 0x3C8			/* VGA port for color index */
	mov eax, [ebp+8]		/* pop the color index from the stack */
	out dx, ax				/* out it to the port 0x3C8 */
	inc dx					/* now the port is 0x3C9 */
	mov eax, [ebp+12]		/* pop the red */
	out dx, ax		
	mov eax, [ebp+16]		/* pop green */
	out dx, ax
	mov eax, [bp+20]		/* pop blue */
	out dx, ax
	mov esp, ebp
	pop ebp
	ret

.globl CYCLE_COLORS
.type CYCLE_COLORS, @function

CYCLE_COLORS:
    push eax
    push ebx
    push ecx
    push edi
    
    xor eax, eax
    xor ebx, ebx
    xor ecx, ecx
    xor edx, edx

CYCLE_loop:
    cmp ecx, 16
    je CYCLE_end_of_loop

    movzx ebx, byte ptr [colorcounter]
    add ebx, ecx
    and ebx, 15
    
    /*add ebx, colortable			this will add whatever that is at colortable instead of the address of colortable itself*/
    lea edx, colortable
    add ebx, edx
    
    movzx eax, byte ptr [ebx+2]
    push eax
    movzx eax, byte ptr [ebx+1]
    push eax
    movzx eax, byte ptr [ebx]
    push eax
    push ecx
    call CHANGE_VGA_COLOR
    add esp, 16

    inc ecx
    jmp CYCLE_loop

CYCLE_end_of_loop:
    inc byte ptr [colorcounter]
    pop edx
    pop ecx
    pop ebx
    pop eax
    ret

LtG wrote:In case you want to try to fix the "read keyboard, print character" issue, can you provide the code you now use, as well as once compiled and then disassembled.

As for your VSYNC/graphics issue, I'm not as much help.. Though I would expect that any emulator/VM software that is supposed to work with DOS would have to support VSYNC or something similar as presumably some DOS games used it.

Are you sure VSYNC is not working in VM? How fast is "way too fast"? Seems to me that your expectation may or may not be correct, so mentioning how fast would be useful. If it's too fast to visually identify, then slow it down (update graphics only every 10 VSYNC, or 100 VSYNC, etc).

Sorry I can't be of much more help, but running a bit out of time.

SpyderTL wrote:The VirtualBox source code is online, and if I remember correctly, the V-SYNC bit is simply toggled back and forth between on and off every time you read the register. It definitely does not work as you would expect.

You may be able to get V-SYNC information if you write a custom video card driver for VirtualBox, but that would be quite a bit more work, and it would only work in VirtualBox.

Unfortunately, none of the popular virtual machines focus much attention on running games using the old VGA registers. They have all been designed to work with Windows with custom drivers.

You might try using SimNOW as a test VM. It has some of the best simulated hardware behavior that I've seen.

Also, I found this thread on a setting in VMWare that will enable V-SYNC. It may be worth a shot.

https://arstechnica.com/civis/viewtopic ... &t=1212037