It is currently Mon May 22, 2017 12:31 pm

All times are UTC - 7 hours





Post new topic Reply to topic  [ 36 posts ]  Go to page Previous  1, 2, 3  Next
Author Message
PostPosted: Mon Aug 22, 2016 2:35 am 
Online
User avatar

Joined: Fri Nov 12, 2004 2:49 pm
Posts: 7033
Location: Jongny, VD, Switzerland
So what is the best, using direct communication with VGA card, or using the ncurses library ?

If the latter, how do we to reprogram character set with the ncurses library so set your own tiles ?

If the former, how do I access the VGA card (or it's simulation) with the C language ?

Quote:
Characters can be anywhere from 1 to 64 scanlines tall. There is a register that controls that, too. (port 3C4h function 9)

The idea of 1 line characters is interesting, that way we get tiles horizontally and bitmap vertically. However with monochrome 8-piexl wide characters it doesn't make much sense since you can get basically bitmap using 256 characters.

The idea of super-tall characters is interesting as well, although I can't think of any usage right now.


Top
 Profile  
 
PostPosted: Mon Aug 22, 2016 6:10 am 
Offline

Joined: Mon Apr 01, 2013 11:17 pm
Posts: 429
Bregalad wrote:
So what is the best, using direct communication with VGA card, or using the ncurses library ?

What is your target system? Modern operating systems don't allow direct hardware access, and even if they did they probably wouldn't be using the video card's VGA compatibility mode.

Bregalad wrote:
If the latter, how do we to reprogram character set with the ncurses library so set your own tiles ?

I don't think ncurses has any function to set custom glyphs.

Bregalad wrote:
If the former, how do I access the VGA card (or it's simulation) with the C language ?

This depends on the API of your target operating system.


Top
 Profile  
 
PostPosted: Mon Aug 22, 2016 6:16 am 
Online
User avatar

Joined: Fri Nov 12, 2004 2:49 pm
Posts: 7033
Location: Jongny, VD, Switzerland
Joe wrote:
What is your target system?

Ideally, both old and modern PCs runnign both Windows and any Linux.

Quote:
Modern operating systems don't allow direct hardware access

Does they allow indirect access through BIOS calls ? How to do those with C language ?

Quote:
I don't think ncurses has any function to set custom glyphs.

Oh that sucks. This library looked like it was the best to do a progam dealing with PC compatible text mode.

Quote:
This depends on the API of your target operating system.

Therefore it's impractical not using any API.


Top
 Profile  
 
PostPosted: Mon Aug 22, 2016 6:39 am 
Offline

Joined: Mon Apr 01, 2013 11:17 pm
Posts: 429
Bregalad wrote:
Ideally, both old and modern PCs runnign both Windows and any Linux.

In that case, you shouldn't bother with VGA text modes.

Bregalad wrote:
Does they allow indirect access through BIOS calls ?

No.

Bregalad wrote:
How to do those with C language ?

That depends on the OS API, but there's no such API for Windows or Linux since they don't allow BIOS access.


Top
 Profile  
 
PostPosted: Mon Aug 22, 2016 7:16 am 
Online
User avatar

Joined: Fri Nov 12, 2004 2:49 pm
Posts: 7033
Location: Jongny, VD, Switzerland
Quote:
That depends on the OS API, but there's no such API for Windows or Linux since they don't allow BIOS access.

So basically, everything is forbidden. Seriously, where's the fun ? This sucks.


Top
 Profile  
 
PostPosted: Mon Aug 22, 2016 7:37 am 
Offline
User avatar

Joined: Sun Sep 19, 2004 9:28 pm
Posts: 3192
Location: Mountain View, CA, USA
What exactly is trying to be accomplished here?

Are you trying to make a Win32 console application that looks like a "classic MS-DOS app" in the sense of an 80x25 (or other size) "text window" that contains what we old bastards would colloquially refer to as "ANSI text/graphics"?

If so, that is actually possible (I know because I had a roommate who wrote a music player (MOD/IT/XM/etc.) that used Win32's console window as its main interface for everything, so it used colour and so on). Screenshot is attached. Windows actually provides a way to do this, if I remember right, by basically giving you a piece of memory that represents the console screen/buffer and you're forced to do all the rest yourself.

So is this thread about understanding old PC graphics and text modes, or is it about trying to implement them or use them on present-day PCs (really not feasible) while in Windows? (I went back and re-read the entire thread to see if I missed something -- I haven't)


Attachments:
screenshot.png
screenshot.png [ 38.08 KiB | Viewed 510 times ]
Top
 Profile  
 
PostPosted: Mon Aug 22, 2016 7:39 am 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 18332
Location: NE Indiana, USA (NTSC)
Messing with other applications running on the same machine, possibly run by other users of the machine in the background or through a network connection, is forbidden.

And the classic text mode is such an edge case that modern APIs assume drawing a proportional, usually antialiased font to an all-points-addressable display plane.


Top
 Profile  
 
PostPosted: Mon Aug 22, 2016 7:53 am 
Online
User avatar

Joined: Fri Nov 12, 2004 2:49 pm
Posts: 7033
Location: Jongny, VD, Switzerland
koitsu wrote:
What exactly is trying to be accomplished here?

Are you trying to make a Win32 console application that looks like a "classic MS-DOS app" in the sense of an 80x25 (or other size) "text window" that contains what we old bastards would colloquially refer to as "ANSI text/graphics"?

Indeed, that's exactly what I have in mind.

Quote:
If so, that is actually possible

It is certainly possible using ncurses, I just tried it works fine even on Windows. However, I don't think it allows to create your own characters, which is quite limiting.

Quote:
So is this thread about understanding old PC graphics and text modes, or is it about trying to implement them or use them on present-day PCs

Both ? I tought the whole point of "PC compatibles" is that older stuff is still supported - at least most PC will boot in text-mode until the OS is actually loaded and some linuxes will stay in text mode by default (now it is not uncommon to have framebuffer mode by default, which is a text mode emulated with a hardware bitmap mode).


Top
 Profile  
 
PostPosted: Mon Aug 22, 2016 8:23 am 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 18332
Location: NE Indiana, USA (NTSC)
Bregalad wrote:
koitsu wrote:
What exactly is trying to be accomplished here?

Are you trying to make a Win32 console application that looks like a "classic MS-DOS app" in the sense of an 80x25 (or other size) "text window" that contains what we old bastards would colloquially refer to as "ANSI text/graphics"?

Indeed, that's exactly what I have in mind.

Then some sort of terminal emulator written in SDL or Allegro and built into your application might be better. The hard part might be blitting glyphs from your font sheet to the output buffer with palette-swapping.

Quote:
Quote:
If so, that is actually possible

It is certainly possible using ncurses, I just tried it works fine even on Windows. However, I don't think it allows to create your own characters, which is quite limiting.

Have you tried making your own monospaced TrueType font in FontForge and using regedit to add the font to Windows Command Prompt?

Quote:
Quote:
So is this thread about understanding old PC graphics and text modes, or is it about trying to implement them or use them on present-day PCs

Both ? I tought the whole point of "PC compatibles" is that older stuff is still supported

Just because the older stuff is supported through the boot process doesn't mean it's supported once the multitasking, multiuser operating system has taken over. Most people demand a web browser and 3D graphics, not hardware text mode.


Top
 Profile  
 
PostPosted: Mon Aug 22, 2016 8:53 am 
Offline
User avatar

Joined: Tue Jun 24, 2008 8:38 pm
Posts: 1500
Location: Fukuoka, Japan
@Bregalad

If your goal is to program the "old way" as a learning experience then I guess most text based mode should work without issue under dosbox either in windows or linux.

You can do it then either in C under turbo C/DJGPP or maybe there must be other free alternative. If you want a bigger challenge then just do it in x86 assembler! Basic x86 is not so bad, just the segmented memory can be a pain at the beginning. You can even write some assembler code inside turbo C 3.0 if you want (and some version of turbo pascal allowed too my memory is good).


Top
 Profile  
 
PostPosted: Mon Aug 22, 2016 9:37 am 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 9635
Location: Rio de Janeiro - Brazil
Bregalad wrote:
The idea of super-tall characters is interesting as well, although I can't think of any usage right now.

Blazing fast coarse horizontal scrolling?


Top
 Profile  
 
PostPosted: Mon Aug 22, 2016 10:07 am 
Online
User avatar

Joined: Fri Nov 12, 2004 2:49 pm
Posts: 7033
Location: Jongny, VD, Switzerland
So this explains why all fullscreen applications stopped to work in Windows 7. I consider this a serious deffect of the OS and I am seriously considering rolling back to XP just to be able to use fullscreen applications natively again. Since I'll be using an OS considered extremely outdated and obsolete anyway, I might as well using one which offers me the features I need. Any Windows more recent than 7 is out of the question because their GUI is retarded and that's another topic.

Developing new applications which requires DOSBox do not sound like a great idea to me. It'd feel like programming a NES game intended to be run in Nesticle.

I guess I'm stuck using ncurses and the default character set, and use it to create my graphics.

Quote:
Have you tried making your own monospaced TrueType font in FontForge and using regedit to add the font to Windows Command Prompt?

I of course cannot ask users to take all those step themselves before using my program, and this is a Windows-only solution.

Quote:
Just because the older stuff is supported through the boot process doesn't mean it's supported once the multitasking, multiuser operating system has taken over.

But it'd be extremely impractical to write a program which is designed to be booted into. Users would have to reserve a partition on a USB key or CF card or whathever storage device just for this program, and they'd have to reboot every time they want to use it. Also, I'd have to embeed a lot of libraries to read all file systems into my program, and it'd be though to debug. This is probably even worse than relying on DOSBox.

Quote:
Most people demand a web browser and 3D graphics, not hardware text mode.

So do I, but Windows 95 up to Windows XP supported web browsers, 3D graphics and full-screen programs.


Top
 Profile  
 
PostPosted: Mon Aug 22, 2016 10:48 am 
Offline
User avatar

Joined: Sun Sep 19, 2004 9:28 pm
Posts: 3192
Location: Mountain View, CA, USA
Bregalad wrote:
It is certainly possible using ncurses, I just tried it works fine even on Windows. However, I don't think it allows to create your own characters, which is quite limiting.

Program I posted a screenshot of does not use ncurses (that's just a convenience library on *IX platforms for terminal manipulation and some framework bits that make generating escape sequences for different terminal types applicable; on Windows there is no concept of a terminal (pedantic replies will be ignored)). Said application was pure Win32 in C or C++ and maybe a bit of assembly.

The Win32 functionality you want is documented: https://msdn.microsoft.com/en-us/library/windows/desktop/ms682073(v=vs.85).aspx

Changing of font/glyphs is supported through the SetCurrentConsoleFontEx() function which utilises the CONSOLE_FONT_INFOEX struct. You'll need to make your own font for this though (I think this can be installed/uninstalled or utilised somehow during runtime vs. the user having to install it manually).

If what you're wanting is "real-time character/glyph changing", like the ability on classic PCs in MS-DOS to manipulate the BIOS font used, I don't think that's possible. In that situation, you'd need to resort to using something like DirectX and doing everything yourself; yeah, not fun. Maybe SDL or Allegro has support to make this kind of thing a lot easier (but the app will no longer be a Win32 console app and won't use the Win32 console).

Quote:
Both ? I tought the whole point of "PC compatibles" is that older stuff is still supported - at least most PC will boot in text-mode until the OS is actually loaded and some linuxes will stay in text mode by default (now it is not uncommon to have framebuffer mode by default, which is a text mode emulated with a hardware bitmap mode).

Respectfully, I don't see how any of this has to do with Win32 console programs. I'm trying to stay very very focused here on what's trying to be accomplished. :\ I could talk for days on the latter subject, but as said, trying to stay focused.


Top
 Profile  
 
PostPosted: Mon Aug 22, 2016 10:59 am 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 5164
Location: Canada
Bregalad wrote:
Does they allow indirect access through BIOS calls ? How to do those with C language ?

With DJGPP (GCC for DOS), BIOS calls in C looked something like:
Code:
#include <dos.h>
void mode_13h()
{
   union REGS regs;
   regs.h.ah = 0x00; // AH = task parameter for BIOS call (00h sets video mode)
   regs.h.al = 0x13; // AL = mode to use (13h is VGA 320x200 8-bit bitmapped)
   
   // call BIOS interrupt 10h
   int86(0x10,&regs,&regs);
}

It's not that different from how you'd do it in assembly, you just have a wrapper function that copies a C structure into the real registers, runs the interrupt instruction, then copies the registers back into your C structure (in case it had a return value).

Bregalad wrote:
I tought the whole point of "PC compatibles" is that older stuff is still supported...

I think it's a bit of a Ship of Theseus, or a ring species situation. Each generation has been backwards compatible with a few generations prior, but eventually the old ones get dropped off.

Though in the case of PCs, the graphics hardware is still VGA compatible. The critical difference is just that direct access to hardware is now restricted by the operating system (with help from the modern CPU) to only be available to device drivers.

You could switch operating systems though. ;) There's one called FreeDOS which is meant for this purpose. (Modern, open source variation of DOS, intended to run new and old DOS software.) You can dual-boot with it, of course. (Running it in a VM or just using DOSBox might be a lot more convenient?)

Bregalad wrote:
But it'd be extremely impractical to write a program which is designed to be booted into. Users would have to reserve a partition on a USB key or CF card or whathever storage device just for this program, and they'd have to reboot every time they want to use it

Ha ha ha, but making a "boot disk" just to run one game that's already installed on your hard drive was definitely part of the authentic DOS experience. ;)

There were many games that I needed special boot settings for (e.g. not loading device drivers you don't need for that game to conserve memory). Of course, it used to boot in under 10 seconds too, and extra floppy disks to use for this were cheap.

Bregalad wrote:
Developing new applications which requires DOSBox do not sound like a great idea to me. It'd feel like programming a NES game intended to be run in Nesticle.

Just becomes it would run in DOSBox in Windows doesn't mean it can't run natively in an appropriate environment, though? I mean... most people here are used to this from NES already. I don't really see what's so different about this case...


Top
 Profile  
 
PostPosted: Mon Aug 22, 2016 11:43 am 
Online
User avatar

Joined: Fri Nov 12, 2004 2:49 pm
Posts: 7033
Location: Jongny, VD, Switzerland
Quote:
I'm trying to stay very very focused here on what's trying to be accomplished. :\ I could talk for days on the latter subject, but as said, trying to stay focused.

For now I just have a vague idea. Basically it'd be a music player/editor using semi-graphical things in a terminal, just exactly like what you screenshoted. So far I have only written pure command line programs (takes text and files as input, text and files as output, nothing semi-graphical), and graphical program on dedicated platform like the NES and other video game consoles. I know squat about how a graphical program for a computer works internally and I don't really care now. However it sounds like both Microsoft and Linux forces people interested in writing semi-graphical programs in going fully graphical and do not promote hybrid programs using an interactive command line and/or graphics in a terminal (or whatever the equivalent is named in windows - since Koitsu claims cmd.exe is not a terminal and adds a nasty ominous statement that this should not be discussed).

Quote:
Ha ha ha, but making a "boot disk" just to run one game that's already installed on your hard drive was definitely part of the authentic DOS experience. ;)

I completely forgot about it until you mentioned it, but I think one of my favourite games when I was about 10 required me to boot on floopy #1 and then to insert floppy #2 to run the game. I'm not entirely sure how it worked, but it was something like that.

Quote:
If what you're wanting is "real-time character/glyph changing", like the ability on classic PCs in MS-DOS to manipulate the BIOS font used, I don't think that's possible. In that situation, you'd need to resort to using something like DirectX and doing everything yourself; yeah, not fun. Maybe SDL or Allegro has support to make this kind of thing a lot easier (but the app will no longer be a Win32 console app and won't use the Win32 console).

Well, the best would be full real time character changing like CHR-RAM on the NES, the second best would be to come up with any custom character set I like and not be able to change it during the execution of the program, and the worst would be to be forced to use the default character set. But any case is acceptable since I don't know exactly what I want to do, but it changes what is possible.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 36 posts ]  Go to page Previous  1, 2, 3  Next

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 3 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group