|
|
Post by roberto on Jan 22, 2014 10:40:24 GMT -8
I was able to compile the emulator on Visual Studio but there's a problem that maybe related to the use of raw input on Windows.
Running the emulator on the Windows console produces a strange behavior, for example trying to get the directory list produces this:
A:\>←[?25hdir
←[?25h Volume in drive A is FREEDOS1
Volume Serial Number is 4559-120D
Directory of A:\
KERNEL SYS 45,450 04-07-2012 8:13a
COMMAND COM 66,090 12-10-2003 7:49a
CONFIG SYS 721 01-19-2014 2:05a
AUTOEXEC BAT 894 01-19-2014 2:04a
←[0mDOS <DIR> 10-07-2006 10:56a
←[0mNFO TGZ 11,021 10-11-2006 3:00p
←[0mEMU COM 5 06-19-2013 4:35p
←[0m 6 file(s) 124,181 bytes
←[0m 1 dir(s) 17,408 bytes free
←[0m
A:\>←[?25h
|
|
rai
New Member
Posts: 6 
|
Post by rai on Jan 22, 2014 16:14:20 GMT -8
Those are ANSI codes, right? I know they were used back in the old days for formatting purposes. I looked up a few things and came across something called ANSICON, which I'm guessing allows ANSI codes to be used in the Windows console. |
|
|
|
Post by Adrian Cable on Jan 22, 2014 17:31:15 GMT -8
As rai said correctly, it's because the FreeDOS console outputs ANSI codes formatting, which the default Windows terminal does not support.
Two ideas: I/you look into whether there is an option to make it avoid ANSI codes. Or, you can find an MS-DOS (e.g. 6.22) boot disk image and try that. MS-DOS does not use ANSI codes in the terminal for sure.
-Adrian
|
|
|
|
Post by roberto on Jan 22, 2014 18:59:42 GMT -8
Thanks for the help guys, it was indead escape sequences that FreeDOS was sending to the Windows console and it was only displayed as plain text by it, but the right behavior should be this:
[?25h -> show cursor
[0m -> restore default color (and intesity)
It seems that ANSICON utility is really helpful, thanks Rai
|
|
|
|
Post by Roy on Jan 26, 2014 2:40:19 GMT -8
the hercules emulation seems funny.  |
|
|
|
Post by roytam1 on Jan 26, 2014 2:55:06 GMT -8
In PCem the chinese-enabled shell looks normal:  |
|
|
|
Post by roytam1 on Jan 26, 2014 4:55:19 GMT -8
alright I finished half of it, video_mem_update() now really depends on GRAPHICS_X but not magic values.  #ifndef NO_GRAPHICS
void video_mem_update()
{
for (scratch_int = GRAPHICS_X * GRAPHICS_Y; scratch_int--;)
((unsigned*)sdl_screen->pixels)[scratch_int] = -!!(1 << (7 - scratch_int % 8) & mem[scratch_int / (GRAPHICS_X*4) * (GRAPHICS_X/8) + scratch_int % GRAPHICS_X / 8 + ((88 + io_ports[0x3B8] / 128 * 4 + scratch_int / GRAPHICS_X % 4) << 13)]);
SDL_Flip(sdl_screen);
}
#endif
But it needs dynamic changing resolution instead of compile time hard-coding. |
|
|
|
Post by Adrian Cable on Jan 26, 2014 8:50:14 GMT -8
roytam1,
I agree that Hercules CRTC should be implemented in the base code sufficiently to enable dynamic resolution changing. I now have a new version that I would like to test internally - check your PMs. Thanks!
-Adrian
|
|
|
|
Post by Adrian Cable on Jan 26, 2014 9:55:45 GMT -8
All,
I have now released 8086tiny 1.03, which supports Hercules resolution reprogramming. ETEN Chinese System should work. Please try and let me know your feedback.
Thanks!
-Adrian
|
|
|
|
Post by roytam1 on Jan 26, 2014 16:22:23 GMT -8
All, I have now released 8086tiny 1.03, which supports Hercules resolution reprogramming. ETEN Chinese System should work. Please try and let me know your feedback. Thanks! -Adrian yeah it is working now, thanks.  |
|
|
|
Post by roytam1 on Jan 26, 2014 18:38:59 GMT -8
BTW it will be nice to name the SDL window:
#ifndef NO_GRAPHICS
if (io_ports[0x3B8] & 2)
{
// Hercules card is in graphics mode. If we don't already have an SDL window open, set it up
SDL_PumpEvents();
if (!sdl_screen)
{
sdl_screen = SDL_SetVideoMode(GRAPHICS_X, GRAPHICS_Y, 32, 0);
SDL_WM_SetCaption("8086tiny graphics output","8086tiny");
}
// Update the display from video RAM
video_mem_update();
}
else if (sdl_screen) // Application has gone back to text mode, so close the SDL window
{
SDL_Quit();
sdl_screen = 0;
}
#endif
|
|
