Ko-Window exploration

[spyffe]

Sharing this in case folks are interested in Ko-Window, an X11-like graphical user environment for X68K machines.  I haven't found many docs out there for basic installation, so I'll document as I go along and discover things.

To get Ko-Window basically working, you don't need very much.  It's free software, available from Vector completely above-board.

• Make sure you get kowin14b.lzh and unpack it.
• Put the contents of kowin14b.lzh on their own floppy.  They won't boot so you need Human68k (2.01+, but 3 preferred) to boot.
• From the floppy, type 'kowin' and kowin.bat will launch the window manager.

On initial launch your screen should look like this:


What you're seeing is:

• Console: the shell.  It runs ordinary shell commands, but you need to prefix them with RUN (e.g., RUN SWITCH) if they want to take over the screen.  (RUN invokes a COMMAND.X shell underneath so the paths it uses are the ones you get in Human64k.)
• KF: A sort of file system explorer.  It has lots of functions for manipulating files, and you open them by clicking on the little icon to the left of the file name.
• The doc viewer: NOT an editor.

Right-click menus exist for the vast majority of things, and in particular right-click on the desktop has a list of useful apps:

• SCRMODE opens the resolution selector
• XF which you know from above
• Exit which quits out of Ko-Window

I'm interested in setting up a native development environment so I'll be perusing NaRuHoDo.doc for recommendations on software and let you know what I find out.

[neko68k]

you're gonna have a bad time finding software. the vector archive has been gone for so long even internet archive doesn't have it. I really need to get together the few things I found that are of any note... a web browser, a MCDRV player, a port of vi, a "multitasking" terminal, a wallpaper setting thing, an IRC client. some other stuff. if I remember tomorrow I'll wrap up the folder from my HDD and put it somewhere. <3

(edit)
ah screw it, I'll do it now. Make sure you check the paths and stuff in kowin.bat and the files win\microwm.rc and win\wsrv.rc

my ko-windows install

(edit 2)
I should probably talk about it a little... I set it up to use NeXT style windows so you have to have the mouse cursor over a window to interact with the keyboard. Also you have to click the window title bar to bring the window forward. It won't work if you click somewhere else. You can change that in either wsrv.rc or microwm.rc I don't remember anymore.

To use KoMCP you need to be running PCM8 and MCDRV. You can drag and drop MDX and MDC songs and also MID and probably RCP files from KF on top of it and they'll play as expected.

STEVIE is a port of vi, it works like you'd expect vi would. You can drag text files from KF onto it and it'll fill the whole path in for you. Very handy.

You can drag image files on top of the Ko-Slice window and they'll become your wallpaper. There are some samples in the PIC folder. Probably some not work safe stuff in there. Don't say I didn't warn you

KIRC is an IRC client, setting internet up is detailed on the wiki but it's a little weird in Ko-win and I don't remember the details anymore.

I don't think I put KoNetJoker in there. It's a web browser but it's useless these days. It's available here.

I also don't think I included BGTERM. That lets you run console programs in the background. For instance you can fire up a command prompt in it and still use the rest of the system at the same time. Useful for editing code with STEVIE and running the compiler at the same time. It's available somewhere in the RetroPC library. Oh bgterm.win is in there but you still need the driver in config.sys and that's a whole other thing.

[megatron-uk]

Interesting. It's got a very 'twm' or 'motif lite' look to it. Is there any X11 underpinnings to it, or is it merely a visual similarity?

[neko68k]

It's just visually similar. The UI is drawn on TVRAM so it sorta makes sense to go with that old X11 style widget toolkit look.

[spyffe]

you're gonna have a bad time finding software. the vector archive has been gone for so long even internet archive doesn't have it.

Hi Neko68k!  Thanks for your reply, I really appreciate pointers from the more long-standing forumers, since I'm just getting started.

I haven't yet had a chance to play with Ko-Window more, but I did find two interesting URLs.

• https://www.vector.co.jp/vpack/filearea/x68/
• http://most.bigmoney.biz/g0org/x68tools/

I don't know how extensive the original Vector archive you were talking about was, but both of these have enough freeware to get me started.  (The Vector link has GCC, and "Bigmoney" has a very fat kowin folder.)

[megatron-uk]

If you are interested in GCC development, have a look at my wiki page:

https://www.target-earth.net/wiki/doku.php?id=blog:x68_devtools

I've tried to summarise the different versions of GCC that are available, as well as collect all of the dev documents in one place.

I'm currently using the "lydux" GCC 4.6.2 cross compiler toolchain quite successfully:

https://nfggames.com/forum2/index.php?topic=6764.0

I've also written some examples of how to get started with the toolchain and quick ideas if how to use the graphics hardware:

https://www.target-earth.net/wiki/doku.php?id=blog:x68_devcode

Hope that's useful!

[neko68k]

you're gonna have a bad time finding software. the vector archive has been gone for so long even internet archive doesn't have it.

Hi Neko68k!  Thanks for your reply, I really appreciate pointers from the more long-standing forumers, since I'm just getting started.

I haven't yet had a chance to play with Ko-Window more, but I did find two interesting URLs.

• https://www.vector.co.jp/vpack/filearea/x68/
• http://most.bigmoney.biz/g0org/x68tools/

I don't know how extensive the original Vector archive you were talking about was, but both of these have enough freeware to get me started.  (The Vector link has GCC, and "Bigmoney" has a very fat kowin folder.)

Ah yeah I must have got some of this from Ground Zero Org years ago. The old Ko-win vector archive had basically everything there ever was but yeah its decades gone. Too bad. Of course you're welcome to ask questions. I might even have answers! I'd say the SIG forum is probably more active in general than this one though. At least, I usually don't pay attention to this one

[spyffe]

I got to play with this a very little tonight.  I installed vim (from Vector) by putting vim.win into the WIN¥ directory.  (I put the .hlp file into ETC¥ and the doc files into DOC¥ but I doubt it makes a big difference.)

I was pleasantly surprised to see vim launch into its own window in kowin.  I haven't dug a lot into it yet but it did work on config.sys.



I noticed a few oddities.

• vim complained about not being able to create a backup file when saving config.sys.
• vim doesn't recognize the arrow keys as directional keys, so I was left using the home-row navigation keys.  I would say it felt nostalgic except I've never actually used a vim that didn't recognize the arrow keys.

Incidentally, I have been careful to back up my HDS each time I modify it with editdisk... do I need to worry about it corrupting files?

[megatron-uk]

The only time I used vi or vim and it didn't recognise cursor keys was when accessing a Unix box over a dedicated serial terminal which didn't have an appropriate termcap entry. Yes, very annoying!

[spyffe]

So this may be getting a bit off topic but I got the Sharp C compiler (XC) to build and run a test binary under Ko-Window.

The XC compiler images that Sharp released do not include a functioning installer, so I instead obtained

• C COMPILER PRO-68K ver2.1_システムディスク.D88 (boot disk / install disk 1)
• C COMPILER PRO-68K ver2.1_システムディスク 2.D88 (install disk 2)

from "C COMPILER PRO-68K ver2.1.zip".  With those disks in FDD0 and FDD1 respectively, I booted and got a prompt asking me if I wanted to install the C compiler.  Since I did, I went through the steps, see below

Finally, it set up ¥C.BAT and rebooted.

I haven't yet set up my PATH right, so right now I have to do the following embarrassing contortion to get CC to work in Ko-Window:

C
CD ..
KOWIN

Then I can use the C compiler as shown below.  (I'm fresh off the boat from Linux, forgive me)

I'll follow up when I've done something more substantial.  In particular, I'd like to make sure I can actually use the Ko-Window developer kit with this setup.

[spyffe]

The only time I used vi or vim and it didn't recognise cursor keys was when accessing a Unix box over a dedicated serial terminal which didn't have an appropriate termcap entry. Yes, very annoying!

The attached documentation (VimKoWin.doc) suggests the author was aware of the lack of support for arrow keys (along with function keys) but "since it's vi, it's not a big deal..."

[spyffe]

As discussed above, I've installed XC and verified that it can generate working binaries.  However, Ko-Window's development kit requires GCC, so I'm working now on getting a native GCC toolchain.

I've tried installing gcc130.lzh (Vector) and resolving dependencies as gcc asks for them.  -I/xc/include seemed to get past unhappiness about stdio.h (I assume I may have to revisit this if I switch libc releases but I believe XC's libc should work for now).  However, I got stopped in my tracks by a has.x error.  GCC expects to see has, so I installed has309.lzh (Vector)... but then it passes has a command line it's not expecting, as seen in the attached image.  The command line is:

has.x -e -w -u -i hello.s -o hello.o

According to has's error messages / usage(), several of these are being used incorrectly (-w takes an integer parameter with the desired warning level, and -i should be an include path).  Hand-running has with the errors fixed runs into an undefined symbol for printf, so presumably undefined-symbol handling is also not being set up correctly.

All in all, I'm guessing this gcc expected a different has.  Should I be using a v2 has with GCC, or something else entirely?  Any other recommendations for tools?

[spyffe]

Okay, I'm learning more about Mariko and Charlie and it looks like the package on Vector might be an out of date version of Mariko.

Thankfully there seem to be numerous pack rats in the community so I've been able to scare up a newer Mariko with docs. I'll play with that and report back.

[neko68k]

fwiw I use gcc mariko, libc don, has060 and hlk evolution.

[edit]
also IIRC I had to use a very old version of MAKE to build ko from source. and also iirc I needed XC _and_ gcc to build it. currently it doesn't build for me and I don't know why but I haven't looked at doing that in years and years. I also don't think I ever got all the libraries together for KF. it wants a library for symbolic link handling that I couldn't find. I have ln and libln but it wants liblink or something else that I only found dead links and no IA backups for :/

[edit edit]
heres a screenshot of my autoexec.bat. it might not be appropriate for building ko stuff but it works for everything else I do.

[spyffe]

Thank you for your autoexec.bat and description of your setup!

I've got Mariko GCC producing working binaries.  On top of the base XC installation, I needed

• gcc142.lzh (Retro-PC)
• has309.lzh (Vector)
• gnub1502.tgz (Vector)

I put the contents of gcc142.lzh in ¥soft¥gcc142 and the contents of has309.lzh in ¥soft¥has309.  Then I took just libgcc.a out of gnub1502.tgz, renamed it to gcclib.l, and placed it in ¥xc¥lib.

One other file GCC wanted was doscall.equ, which as near as I can tell are symbolic constants for the published human68k entry points.  The XC installation provides a variant that its compiler supports, but GCC wants a slightly different symbol format.  I went into ¥xc¥include and copied doscall.mac to doscall.equ.  Then with an editor I changed each line that started with _, removing the leading _.  This produced a file GCC could work with.

I finally added the following lines to kowin.bat

path a:\;a:\sys;a:\bin;a:\etc;a:\xc;a:\xc\cc;a:\xc\bin;a;\win;a:\soft\gcc142;a:\soft\has309
set include=A:\XC\INCLUDE
set lib=A:\XC\LIB
set GCC_LIB=.l

There was only one other thing that was irritating: I got errors about missing symbols (__FCVT __ECVT __SRAND).  The only way I found around that (thanks neozeed!) was -lfloateml (using floating-point emulation from XC).  But after that -- a working binary!



Future work:

• Extra configuration required to make Ko-Window software build (I'll be referring to your autoexec.bat and kowin_p2.txt)
• Figure out how to make the floateml part implicit instead of having to specify it on every command line.

[spyffe]

Success!  I took the kowin14d distribution (Vector) and follwed kowin_p2.txt closely.

I put the kowin headers in a:¥xc¥include and its libraries in a:¥xc¥lib.
I also installed hlk301.x from hlk301b (Vector).
Then I updated my kowin.bat to set a bunch of custom variables:

set include=A:\XC\INCLUDE
set lib=A:\XC\LIB
set GCC_AS=a:\soft\has309\has.x
set GCC_LINK=a:\soft\hlk301\hlk301.x
set GCC_LIB=.l
set GCC_OPTION=LFIOAM
set HAS=-u -w
set SILK=-x -l

Now I was able to build the wlib samples, as shown in the attachment.

[spyffe]

Got a Ko-Window program to do something interesting (display a dumb 1-bit pattern).  Window title is a bit more ambitious, I'm not there yet.



I explored Ko-Window's DrawBuf[] format (the data format it uses for queues of draw commands).  I was pleased to find that, like any modern command queue system, it lets you re-use a queue you're happy with.  That saves a bunch of memory manipulation in the hot path.  This will be handy for rendering animations: all I have to do is manipulate my buffers and then dispatch the queue to be rendered again.

There are broadly two ways I see in the documentation to render buffers:

• DrawSetPut (as used below) appears to work specifically with 1bpp patterns in Sheet format.  Not sure what the second plane is for yet.
• DrawSetGraphicPut takes a "short *gbuf" whose internal format I don't know yet.  I tried simple things (is it a packed bitmap with bpp determined by a previous call to WindowSetGraphicMode()?) but so far I can't get it to draw anything at all.

One other thing I noticed is that malloc() returns NULL.  I thought I got a 64K heap by default, so this is puzzling.

Source:

/*wlib pattern output*/

#include <stdlib.h>
#include <wlib.h>

static DrawBuf dbuf[2];

#define SHEET_W 100 
#define SHEET_H 100 
#define SHEET_W_WORDS (((SHEET_W) + 15) >> 4)
#define PLANE_SIZE SHEET_W_WORDS * SHEET_H
static short plane1[PLANE_SIZE];
static short plane2[PLANE_SIZE];
static Sheet sheet = {
    /*.h*/ SHEET_W,
    /*.v*/ SHEET_H,
    /*.hword*/ SHEET_W_WORDS,
    /*.buf1*/ plane1,
    /*.buf2*/ plane2
};

void InitDrawBuf () {
  memset(plane1, 0xaa, sizeof(short[PLANE_SIZE]));
  memset(plane2, 0x00, sizeof(short[PLANE_SIZE]));
  DrawSetClear(&dbuf[0], ColorGray);
  DrawSetPut(&dbuf[1], 0, 0, &sheet);
}

int EventExec(WindowID wp, EventInfo *info) {
  switch (info->option) {
  case EventOpen:
    WindowRedraw(wp);
    return TRUE;
  case EventClose:
    WindowClose(wp);
    return TRUE;
  case EventRedraw:
    WindowDraw(wp, dbuf, sizeof(dbuf)/sizeof(dbuf[0]));
    return TRUE;
  }
  return FALSE;
}

int WindowMain()
{
  InitDrawBuf();
  /*WindowSetGraphicMode(WindowAttrGraphic16);*/
  WindowTitleOpen(
      10, 10, 100, 100, NULL,
      "fract", Close|Push,
      EventExec);
}

[neko68k]

kick ass. you've probably written the first all new ko-win code in 20+ years lol

[spyffe]

Reading through the Ko-Window source, I think DrawSetGraphicPut() writes more or less directly to VRAM (the area starting at $c00000).  I'll play more with that soon.

Meanwhile, I've discovered a fascinating behavior of the second plane in the Sheet passed to DrawSetPut().  It gives access to two more shades, as shown in the attachment: a lighter white and a really bizarre color that means different things depending on where on the screen it is!



If you drag the window around on the screen, the "highlight color" (plane 1 off, plane 2 on) is red on the top half, and black on the bottom half.  In Ko-Window, the only thing that I've found (so far) that uses this odd color is the rectangle that is shown when you drag a window.

[spyffe]

As shown in the screenshot, I'm now able to write to vram!

I have no idea about palettes in 16-bit mode, and obviously my estimate of bits per pixel is off.  That's what comes from focusing on Ko-Window and not reading system docs.

One thing that's not shown: I do a WindowSetAttr() now before drawing.

WindowSetAttr(wp, WindowAttrGraphic16);
WindowDraw(wp, dbuf, sizeof(dbuf)/sizeof(dbuf[0]));

I'm not actually convinced I need this call every time.

[megatron-uk]

Ok, so in 16bpp mode there is no palette lookup, the pixel values corresponding directly to their colour... At least when doing direct writes to gvram anyway.

Pixel format is:

GRB+I

Where each of green red and blue are 5 bits of precision and I (intensity) is a sort of brightness modifier.

Remember that the 16bit value is big endian.

I've written up quite a few examples of gvram use in my wiki: https://www.target-earth.net/wiki/doku.php?id=blog:x68_devcode

I don't know how much will be relevant to ko-windows development, but at least the palette stuff should be similar, as I'm using it in my game launcher/browser I'm writing for the native hardware.

[megatron-uk]

I use this macro for generating grbi pixel colour values from a triplet of RGB values:

Code Select Expand

// Macro taken from https://sourceforge.net/projects/x68000-doom/
// Merge 3x 8bit values to 15bit + intensity in GRB format
// Keep only the 5 msb of each value
#define rgb888_2grb(r, g, b, i) ( ((b&0xF8)>>2) | ((g&0xF8)<<8) | ((r&0xF8)<<3) | i )


[spyffe]

Thank you megatron-uk for your clarification of the 16-bit color format!  That agrees with what I saw in the databook for the GVRAM, although I don't fully understand the role of I.  My first guess is that it might be a way to set a high-order bit in a hypothetical 6-bit version of each component, since the data book (page 9) shows a single bit going from the video controller to all three DACs, augmenting the 5-bit signal.

In any event, my code above is in 16-color, not 16-bit mode.  I'm sorry I wrote the wrong thing.  I do want to try full 16-bit mode, and when I do I'll use your Wiki as a reference.

[megatron-uk]

I'm not sure what Res you're working in, but you might not be able to access 16bit colour mode; it's available at a maximum of 512x512 on all models, or at 768x512 on a selected few later models with an updated ROM (I'm not sure which models this applies to - I guess it may just be the 030?).

[spyffe]

Thank you megatron-uk for the warning!  Ko-Window has a CRTC library that allows resolution-switching.  There's a built-in app that uses the library too, although it provides more resolutions than just 1024x1024 and 512x512, reflecting the flexibility of the hardware CRTC.

I^m not seeing any special support for palette switching in Ko-Window.  My guess is that the UI is rendered using a 4-color palette in TVRAM, which is what I get when I use DrawSetPut with a 2bpp Sheet.  Presumably I could mess with that palette using DOS calls if I wanted, but it would be separate from any palette switching I do for GVRAM (where DrawSetGraphicPut renders to).

I still haven't figured out why one of the UI colors changes depending on where on the screen I draw it.  I've noticed in fact that this color appears to reflect the contents of GVRAM (!) so perhaps it's some kind of "transparent" color.

[spyffe]

Okay, looking through the sources (Vector) I see that TPALET is being used (manager.c) to set TGRAM palette colors.

int Palet1 = (20 << 11) + (20 << 6) + (20 << 1);
int Palet3 = (31 << 11) + (31 << 6) + (31 << 1);
...
TPALET(0, 1);
TPALET(2, 0);
TPALET(1, Palet1);
TPALET(3, Palet3);

These appear to correspond to constants (wlib.h):

#define ColorBlack   0
#define ColorGray    1
#define ColorGraphic 2
#define ColorWhite   3

Note that palette entry 2 (so plane 2 = 1, plane 1 = 0, as seen in my early experiment with Sheet drawing) is ColorGraphic...  I bet the display controller uses the GVRAM color when the TVRAM color is equal to exactly 0, and the TVRAM color otherwise.  That would also explain the "transparency" I observed.  I'll try to find some support for that in the X68000 specs.

[spyffe]

Played with the gvram palette a little today, as seen in the screenshot.  (For the eagle-eyed: yes, I probably don't need that memset() any more.)

IOCSLIB routines worked for palette manipulation, but I had to make a little change to iocslib.h to get it to work with GCC:

struct INQUIRY {
   unsigned char unit;
   unsigned char info;
   unsigned char ver;
   unsigned char reserve;
   unsigned char size;
#ifdef __GNUC__
   unsigned char buff[0];
#else
   unsigned char buff[];
#endif
};

[spyffe]

Confirmed my theory about TVRAM transparency, see the screenshot.
The GVRAM is the same as previously (colored vertical lines), but the TVRAM now has rotating rows of 0x0, 0x1, 0x2, and 0x3.
As expected from the TPALET lines I found earlier, this gives

• 0x0 -- "high-intensity" black which just means opaque black
• 0x1 -- Palet1 which I haven't touched so it's a medium gray
• 0x2 -- transparent black
• 0x3 -- Palet3 which I haven't touched so it's low-intensity white

(Be aware of the window decorations when you try to count along in the image

[spyffe]

I'm getting more comfortable with gvram and palettes.  Here's a quick status report -- I'm going to play a bit with assembly next to see if I can speed up the underlying computation.

[Sugo77]

Hello!
I finally found file for download, whith KO-Window from here:
https://www.dropbox.com/s/buo44nz3mwl2tnv/kowin.zip?dl=1
But, when i try drag files from Disk Explorer to my HDD ( .HDS ), this lost 5 files in folder PIC, i do not know why, in window with errors text said this:
Not found files:

[Shoometsu]

Hello!
I finally found file for download, whith KO-Window from here:
https://www.dropbox.com/s/buo44nz3mwl2tnv/kowin.zip?dl=1
But, when i try drag files from Disk Explorer to my HDD ( .HDS ), this lost 5 files in folder PIC, i do not know why, in window with errors text said this:
Not found files:

Disk Explorer has issues with files and folders with special characters (that's how it decode Japanese text). Copy the zip file inside you hd / hdd image, and in LHES, extract it with F2 key to a folder/floppy disk of your choice.

[Sugo77]

Shoometsu, in first, helo and thanks for your answer!
In second, i not pro in this all... Explain full method - step by step(1, 2, 3,) for get final results of extracting files from folder PIC in archive PIC.zip inside DOS or KO-Window to new folder(\"Directory").

My step by step method was that... What i was already try to do:
1. First, i just ziped all files from folder PIC to archive PIC.zip
2. Second step. I used Disk Explorer,, and just drag PIC.zip to KO-Window main directory.
3. i was try use in DOS in command.x and button f12, and typed command; extract, but in all method nothing happens for me...
If use button F12 in emulator, thsi just back my mouse to my real windows of our modern time...(By pressing button F12 in DOS inside emulator = this will be just gived out mouse from inside emulator to oour modern windows)

P.S.:
I even try was extracted files from this archive(PIC.zip) inside Visual Shell KO-Window, but also fail...
Because i also not sure, how correct extracting files inside KO-Window, and not sure this possible or no? If yes, then how?(All menus on japanese language in which i totally zero!)

[Sugo77]

I even added to KO-Window, to folder BIN 6 drivers-files ( LH.X, LHA.X, LHESVIEW.X, LHVW115.DOC, LINER.X, LZX.X ) from popular in internet HDD X68000_V4SP2.HDS, and other files-drivers...


Shoometsu, explain, please teach me or someone else who know, how extract files inside DOS or visual shells?

[Shoometsu]

- Using XM6 TypeG with X68000_V4SP2.HDS image, ensure that your config.sys has the line "DEVICE = \SYS\WINDRV.SYS" enabled (it must not have the comand "REM" at beginning
- In XM6, go to menu Tools/Options and in WinDRV tab, set a folder in your PC as the shared folder, and reset the emulator. Then copy the zip files you want to extract to this folder
- Now inside LHES press L key to be able to switch between drives. If you have only one HDD image mounted, your shared folder is probably in D:
- Select the file you want to extract from then press F2 key and select extract options accordingly to your needs.

[Sugo77]

Shoometsu, thanks you!
I will check in free time... Now i busy at SX-Window and games for\from Sharp x68000
But, i was fast pre checked this option in emulator XM6 TypeG, and had small question to future, pre begin work with this...
This option Use Recycle BIN in WinDRV need active or no?
Pre begin to work with this...

[Shoometsu]

It's irrelevant. It would only move content you deleted from the folder you set to recycle bin. Mine is off by default.