• Please review our updated Terms and Rules here

Video on 5150

i've run across that before. the guy who made is says the actual video file is about 10 MB and includes mono sound. i downloaded his software and saved it for when i finally get an old 8-bit disk controller, then i'll be able to test it on my 4.77 MHz 8088 :)
 
To get it running smoothly you need an IDE drive, MFM drive isn't fast enough and you just get rebuffering every 15 seconds.
 
The author wrote it on a machine with an MFM drive. Basically it was a stock XT, with the exception of the sound card.

You could have a slower hard drive, or your interleave factor might be set wrong. Also, it might not be perfect code .. in a private conversation he mentioned that there are some bugs that he's hunting.
 
Erik said:
If I were to guess, I'd say that the scenes were rendered elsewhere and the PC just slams data into the video card memory space (B800) and uses page flipping (the CGA supported 8 pages of 80x25x16 color text mode video) to get the effects.

Assuming 30 frames a second that's about 60K a second and probably a total of about 1MB or so for the full video. All well within the PCs capabilities.

Very impressive, though! :)
Click to expand...

yup, i've exchanged a few emails with the guy. that's exactly how he did it. and yeah, its well within an 8088's capabilities w/ CGA. you might even be able to manage the full 30 FPS writing a player even in a language like qb45 if you use some tricks.
 
Mike Chambers said:
yup, i've exchanged a few emails with the guy. that's exactly how he did it. and yeah, its well within an 8088's capabilities w/ CGA. you might even be able to manage the full 30 FPS writing a player even in a language like qb45 if you use some tricks.
Click to expand...

Not likely. Jim is a master of assembly language programming on the 8088. I don't think that QB gives you tight enough code to match the hand coded assembler that he has done.
 
mbbrutman said:
Not likely. Jim is a master of assembly language programming on the 8088. I don't think that QB gives you tight enough code to match the hand coded assembler that he has done.
Click to expand...

well, by "tricks" i meant load a frame at a time from the "video" file (in the file format he made, each video frame is 4000 raw bytes) and store it in a 4000 byte string variable.. then put in a string simple "hand-compiled" ASM that copies the 4000 bytes from qb's variable location directly to the CGA memory page followed by a return opcode. you can do a call absolute to the pointer of the string you put the raw binary code into.

the only thing is that it would basically be mostly ASM... qb wouldnt have much to do with it except load file data so maybe my point is moot. :)
 
Let's explore that a little further.

Using QB to load a full page of data (4000 bytes) would mean copying it once from the file to your buffer. And then you have to move it from your buffer to the video buffer.

That makes you already 2x slower than the optimal solution, which is to have the results of the file read dumped straight into the video buffer, thus eliminating the second 4000 byte memory copy.

C and other languages can do this for you. QB puts you at a disadvantage because by not letting you make mistakes, it also ties your hands.
 
true... maybe it could pull off... 15-20 FPS? dunno...

oh well, all i do know is i need to freakin' learn some C. it can't be THAT hard, i am expert in BASIC i think.. i should be able to transition.
 
I've told other people this, but they are skeptical.

C is all you need. If you master C, C++ is trivial. Java is easy as well. Even assembler isn't too far out of reach, as many people refer to C as glorified assembler.

Languages like Perl and Python have lots of flash, but you can't write an operating system with them.
 
Ok, quite a bit off-topic, but *cough* on that C++ is trivial for anyone who knows where to put his both feet into the C pasture. Dunno about real Java, I never seriously tried to get into that language.

However, I agree that when it comes to squeezing the most out of your vintage computer, nothing beats hand-coded assembler. Perhaps with modern computers the situation is a bit different, but in this context I'm quite convinced that what one just manages to accomplish from optimized assembly code, is close to impossible to get from C or even less QB, no matter how effective compiler it offers.
 
C is pretty good on hardware. Never as good as assembler, but you'd never get your projects done if you had to start with assembler each time.

Even something as primitive as Turbo C++ 3.0 for DOS (which is my weapon of choice) lets you do the following:

- Declare pointers into arbitrary regions of memory.
- Access by byte, word, or double word, signed or unsigned
- Hint to the compiler that a variable should be in a register.
- Bit shift and other logical operations

Where C falls down is when you need to expose primitives that the hardware provides that the compiler doesn't know to take advantage of. For example, on x86 hardware the LOOP instruction can be used to construct a for loop, but the compiler doesn't like to generate that instruction for some reason. Or the XCHG instruction is great for byte swapping, but there is no construct in C that maps to that.

And for those cases, Turbo C++ 3.0 lets you use inline assembler. :)

Most OS work involves maintaining data structures. C is very adept at that. Which is why most OSes are in C, with a sprinkling of assembler.
 
You must log in or register to reply here.
Back
Top