OSDev.org

Just look back into getting polling to work, since I'm assuming you're wanting to deal with VGA-level hardware rather than more modern stuff.

I've seen the PIT being abused in a different way: there's this Kellog's platformer which uses a raster effect for a water effect, which seems fine at first... until you realize there's no hblank interrupt and CPU speeds were all over the place by then. What that game is doing is calculate how long it would take for the beam to reach the desired scanline then reprogram the PIT at the start of every vblank accordingly. Then the PIT interrupt would effectively act as a "hblank" interrupt.

If we insist on using the PIT for a vblank interrupt (e.g. in case something is taking too long but don't want to interfere with smoother stuff), what you could do is program the PIT to fire a bit before vblank would happen, then in the interrupt poll for vblank, reprogram the PIT (so it'll fire again) and do whatever you need to do. Yes, you're still polling, but you'd only poll for a bit instead of having to wait for the CPU to have nothing else to do.

Sik wrote:Just look back into getting polling to work, since I'm assuming you're wanting to deal with VGA-level hardware rather than more modern stuff.

I've seen the PIT being abused in a different way: there's this Kellog's platformer which uses a raster effect for a water effect, which seems fine at first... until you realize there's no hblank interrupt and CPU speeds were all over the place by then. What that game is doing is calculate how long it would take for the beam to reach the desired scanline then reprogram the PIT at the start of every vblank accordingly. Then the PIT interrupt would effectively act as a "hblank" interrupt.

If we insist on using the PIT for a vblank interrupt (e.g. in case something is taking too long but don't want to interfere with smoother stuff), what you could do is program the PIT to fire a bit before vblank would happen, then in the interrupt poll for vblank, reprogram the PIT (so it'll fire again) and do whatever you need to do. Yes, you're still polling, but you'd only poll for a bit instead of having to wait for the CPU to have nothing else to do.

I wanted an universal solution, but it seems its not possible. I'm still gonna poll for vsync, so it will look nice on old hw while new will have to live with tears ( I decided to not do any fast moving stuff so it wont look that bad )
I've found a website where a guy connects the vsync pin of vga to the irq line of the parallel port. He also wrote a driver for win XP to get access to that interrupt. Check it out, I think it's neato
http://mjsstuf.x10host.com/pages/vsync/vsync.htm

as for your sugestion to use pit with polling. That's a good idea and I saw it mentioned in some other thread whrn I was looking around for answers, but since I don't expect my code to be slower than 70 loops a second (I just wont have that much code to execute ) i think just polling will be fine.

Well, if it drops lower than 70Hz then you can just do frameskip (where you run several logic frames until it catches up before drawing up again), although consider putting a cap on that in case it ends up going too slow (would rather start slowing down than skip too many frames to the point of making it unusable). It won't look pretty but then again you can't avoid that if you end up missing the next refresh.

Just to give you guys some more information, I just finished my own mode 13h code, and I have verified that my VSYNC code (similar to the first post on this thread) works properly on my laptop (an HP Elitebook), and it does not work on VirtualBox and VMWare, even with the VSYNC option turned on...

In any case, I just thought that I'd let you guys know that I actually got VSYNC working on a physical machine.

EDIT: I also tried VSYNC with Bochs debug, and although it was extremely slow to update the screen, it did seem to be attempting to provide a proper VSYNC value, because I only saw one frame obviously tearing while testing for a few seconds. I'll run some more tests when I get some time.

SpyderTL wrote:Just to give you guys some more information, I just finished my own mode 13h code, and I have verified that my VSYNC code (similar to the first post on this thread) works properly on my laptop (an HP Elitebook), and it does not work on VirtualBox and VMWare, even with the VSYNC option turned on...

In any case, I just thought that I'd let you guys know that I actually got VSYNC working on a physical machine.

EDIT: I also tried VSYNC with Bochs debug, and although it was extremely slow to update the screen, it did seem to be attempting to provide a proper VSYNC value, because I only saw one frame obviously tearing while testing for a few seconds. I'll run some more tests when I get some time.

It works on my Pentium 1 laptop, but I was looking for an Universal solution. I think I will just leave the VSYNC code in case it actually works on the target hardware, and if not, just use PIT set at ~70Mhz. Here's my super extra pro "loader" that is supposed to look like the C64

You get an "A" for nostalgia alone. The C64 is actually the inspiration for my OS.

I wanted a system that I could turn on and immediately use to read web pages, watch videos, or listen to music.

I also am trying to find a way to run a single application on a PC and a C64 without recompiling, which I've yet to accomplish, but I think that I may be able to pull off at some point.

SpyderTL wrote: I also am trying to find a way to run a single application on a PC and a C64 without recompiling, which I've yet to accomplish, but I think that I may be able to pull off at some point.

You mean you want one binary which is x86 and 6502 at the same time ?

Can't speak for binary compatibility, but this talk https://www.youtube.com/watch?v=zBkNBP00wJE goes through the process of programming a C64 game in C++ targeted towards x86 which is then converted to native C64 assembly.

A video about x86 to 6502 is found here: https://www.youtube.com/watch?v=CdJOSfK1ja0

And a WIP converter is found here: https://github.com/lefticus/x86-to-6502

goku420 wrote:Can't speak for binary compatibility, but this talk https://www.youtube.com/watch?v=zBkNBP00wJE goes through the process of programming a C64 game in C++ targeted towards x86 which is then converted to native C64 assembly.

A video about x86 to 6502 is found here: https://www.youtube.com/watch?v=CdJOSfK1ja0

And a WIP converter is found here: https://github.com/lefticus/x86-to-6502

I saw that talk some time ago and I was thinking if you refer to that or to a compiled binary (since you said you don't want to recompile) . Making a binary that would work for both systems would be very hard, if not impossible, but I'd love to see it.

6502Rulez wrote:I was thinking if you refer to that or to a compiled binary (since you said you don't want to recompile) . Making a binary that would work for both systems would be very hard, if not impossible, but I'd love to see it.

I wouldn't think it's that hard, though I don't know the C64 all that much.. of course it might turn out to be impossible, but assuming it's not, then it shouldn't really be all that hard. You just need to find some opcode that does branch on one and is mostly harmless on the other.

Though I don't know on what "level" this binary would be run, so is it supposed to be the bootloader that has binary compatibility or an "app" that is loaded by something else? If the bootloader then on what media could you insert it to both a PC and C64? And on PC the MBR/bootsector is used, what about the C64?

Not sure if I understood this correctly http://www.unusedino.de/ec64/technical/aay/c64/bbcc.htm, but it seems to say that 0x90 is a branch (if carry = 0) on C64, and would be NOP on x86, then what is the state of "carry" on C64 after boot (or after whatever event the binary compatibility is needed)?

LtG wrote:

6502Rulez wrote:I was thinking if you refer to that or to a compiled binary (since you said you don't want to recompile) . Making a binary that would work for both systems would be very hard, if not impossible, but I'd love to see it.

I wouldn't think it's that hard, though I don't know the C64 all that much.. of course it might turn out to be impossible, but assuming it's not, then it shouldn't really be all that hard. You just need to find some opcode that does branch on one and is mostly harmless on the other.

Though I don't know on what "level" this binary would be run, so is it supposed to be the bootloader that has binary compatibility or an "app" that is loaded by something else? If the bootloader then on what media could you insert it to both a PC and C64? And on PC the MBR/bootsector is used, what about the C64?

Not sure if I understood this correctly http://www.unusedino.de/ec64/technical/aay/c64/bbcc.htm, but it seems to say that 0x90 is a branch (if carry = 0) on C64, and would be NOP on x86, then what is the state of "carry" on C64 after boot (or after whatever event the binary compatibility is needed)?

The carry might be different on each boot, since the KERNAL (yes, the C64 called it KERNAL for some reason) and BASIC would affect it and you need to use BASIC to load your program. If you want to code your own stuff on C64, especially on this level, first thing you do is turn off all the ROM, so you have all the RAM and nothing else meddling with your code (C64 has 64kb of ram, but the 6502 can only address 64kb of memory, so the ROM is on top of the ram and you can turn it off. That's why you get the 38911 basic bytes free). You can even mask the NMIs with a trick. Visit http://codebase64.org/doku.php for more information. They have a lot of coding tutorials, including many demo tricks such as screen scrolling or sprite multiplexing.

btw, a bit more progress, I think I'm done with the "loader", the only thing I could add is more randomness on the border colors and a blinking cursor. Time to code first game


ps1. Semi related. This guy made a x86 compilator which outputs the binary using only the bytes that match the printable characters of the ASCII table.

Well, I didn't necessarily mean binary compatible on both systems.

For instance, Java running on both platforms would qualify for me. It just turns out that Java is a little too resource intensive for 64k of RAM. The closest I found, or someone on here may have pointed me to, can't remember, is something called Java Grinder, which takes compiled Java code and recompiles it to different platforms. So it would be simiar to the x86-to-6502 converter mentioned above. Java Grinder just happens to be very "early" in development and I had a pretty hard time getting it to work for a simple hello world application.

When I'm not working on x86 stuff, I've got a c64 project going that boots up from a cartridge image, disables all ROM banks, and runs a simple command line interface, similar to my x86 OS. My plan is to implement the same commands and features on both platforms to the point that the same script (i.e. Batch file) will produce roughly the same results on both machines.

If I could pull this off, I would consider it a success.

EDIT: That video is pretty awesome. It reminds me of the SUBLEQ processor stuff that I played around with a few weeks ago. If all else fails, I can always just write a tight SUBLEQ loop on both systems and have it run the exact same code...

SpyderTL wrote:Well, I didn't necessarily mean binary compatible on both systems.

For instance, Java running on both platforms would qualify for me. It just turns out that Java is a little too resource intensive for 64k of RAM. The closest I found, or someone on here may have pointed me to, can't remember, is something called Java Grinder, which takes compiled Java code and recompiles it to different platforms. So it would be simiar to the x86-to-6502 converter mentioned above. Java Grinder just happens to be very "early" in development and I had a pretty hard time getting it to work for a simple hello world application.

When I'm not working on x86 stuff, I've got a c64 project going that boots up from a cartridge image, disables all ROM banks, and runs a simple command line interface, similar to my x86 OS. My plan is to implement the same commands and features on both platforms to the point that the same script (i.e. Batch file) will produce roughly the same results on both machines.

If I could pull this off, I would consider it a success.

EDIT: That video is pretty awesome. It reminds me of the SUBLEQ processor stuff that I played around with a few weeks ago. If all else fails, I can always just write a tight SUBLEQ loop on both systems and have it run the exact same code...

Cartridge is max 16KB, unless you do some bank switching scheme. I guess you'd have to do your own language and compilator, to make the same source output both 6502 (C64 uses 6510, but that doesn't matter ) and x86. I like the idea a lot. If you want to talk more about it, send me a private message I'll give you my contact. This thread went highly offtopic.

Brendan wrote:
VBE doesn't support any kind of vertical sync (no IRQ, and no polling). There was a second specification called VBE/AF ("VESA BIOS Extensions, Accelerator Functions") that added a whole pile of things (hardware bit blits, hardware mouse pointer, hardware line drawing, etc) which included support for multiple buffers in display memory and a "wait for vertical sync then switch the visible buffer" function that could've been used for ensuring vertical sync (via. internal polling done by VBE/AF, and not with a modern "page flip on vertical sync IRQ" approach). However, as far as I know, VBE/AF was never supported by any video card for multiple reasons - games were already using video card specific code because VBE/AF was "too little, too late", video cards were struggling to fit everything in the 64 KiB legacy video ROM area already and didn't have space to add new functionality to their ROMs, and VBE/AF was released in 1996 when everyone was abandoning DOS (and BIOS) and switching to Windows (with native video drivers) so nobody had a reason to care about VBE/AF anyway.

I’ll just raise this thread from the dead...

It’s not clear from the thread exactly what the VBL solution is for VBE graphics.

It appears that there is absolutely no VBlank interrupt, and no VBL hardware flag accessible once grub has set a VBE mode...

It seems the only solution is to run updates every 16ms (~60Hz), which won’t allow display syncing, but will at least offer the regularity required for GFX display tasks.

bloodline wrote:It appears that there is absolutely no VBlank interrupt,

Correct. Most hardware has the capability, but VBE doesn't expose it.

bloodline wrote:and no VBL hardware flag accessible once grub has set a VBE mode...

It depends on the hardware. GRUB can report VBE information, which will tell you if the current mode has register-level compatibility with VGA (including vblank), but it won't help you when the current mode lacks VGA register compatibility, and it won't help you when the "compatibility" isn't actually attached to vblank.

bloodline wrote:It seems the only solution is to run updates every 16ms (~60Hz), which won’t allow display syncing, but will at least offer the regularity required for GFX display tasks.

VBE offers double-buffering functions that are supposed to wait for vblank before switching buffers. Whether or not they work is a mystery, and it doesn't help you on modern PCs without VBE.

If you're not limited to VBE, though, a native driver solves this problem easily. (For certain definitions of "easily".)