MII: New IIe open source emulator, mine this time!

Sounds nice!  I will check it out soon!

I git cloned the project and then did a make and ran with mii_emu -def  A couple of weird things I've noticed...  PR#6 appears to run the //e self test.  And when I select "Amber" on the left side menu the text comes out blue.  If I'm in Green or Amber and the self test runs it goes to color when running the test then "System OK" comes out in mono.  Weird.  I haven't dug in deeper than that yet.

I don't see an "install" target in the Makefile.  I'm assuming that disk images need to go in the disks folder, but not sure how to specify a different location for that.  Also not sure how to pick what disk image is in the "drive".

Another weird thing I just noticed...  If I do this:

GR

COLOR=1

HLIN 0,39 at 0

HGR

The lowres plot looks fine but the hgr doesn't show the hires graphics screen.  The lowres is still there.

HGR2

HCOLOR=1

HPLOT 0,0 to 279,0

That clears the 2nd hires page and draws a green line like expected.  But if I do this:

HGR

Now I get the lowres screen again...

Very strange.

Awesome!

mmphosis wrote:

Awesome!

grep -rn 'hires = 0' *

mii_emu-main/src/mii_video.c:167: //hires = 0;

That seems to have fixed the problem.  Should I create a pull request?

More stuff I wouldn't expect on an actual Apple //e...  If I do this:

CALL -151

then do <Ctrl>-C <return>

I don't get back to Applesoft.

Ctrl-B doesn't work either.

Neither does:

3D0G

or 

9DBFG

Not surprised by the later since DOS doesn't appear to be loaded.

I finally got it to boot from a disk image:

build-x86_64-linux-gnu/bin/mii_emu -s 6:disk2 -d 6:1 /home/leeh/src/mii_emU/disks/prodos242.dsk

It would be super useful to provide left menu items to select drives and mount disks.  Doing it from the command line is awkward and I am not sure how to change disks after starting.

I'm probahly being super stupid and not getting it though.  It took me a lot longer to figure out the command line than it probably should have.

Yeah, I finally figured out the command line options to make it work.  I don't mean to be picky about the UI.  I understand it is a project in progress.  It has a ton of potential. I'm looking forward to seeing how it develops.

A lot of .dsk images don't seem to boot it seems kind of hit or miss which ones work or don't.  Some seem to take a long time before they start to boot.  .do and .po files seem to work better.

In some games it seems like the orange color in hires is way more yellow than I would expect.  I guess I should start looking in the code to see if I can figure it out myself rather than just posting. 

I'm looking at the video code and the RGB values in the emum seem to be what I'd expect.  The weird thing now that I think about it is that the yellowish color that I'm seeing in hires where things should be orange is the color amber I'd expect everthing to be in the Amber mode which shows up as blue for me...

Weird.

I got the Ctrl keys working.

I went a bit "nuklear" and removed some stuff: cut/copy/paste etc.

With some code added to handle the control key, control keys work and the Tab key works like a Ctrl+I keypress.

#    patch mii_emu-main/nuklear/mii_nuklear.c      mii_nuklear.c.patch

#    patch mii_emu-main/nuklear/nuklear_xlib_gl3.h nuklear_xlib_gl3.h.patch

# cat mii_nuklear.c.patch

262a263,264

> static int control_key_down = 0;

>

272c274,281

<             mii_keypress(mii, in->keyboard.text[0]);

---

>             char c;

>

>             c = in->keyboard.text[0];

>             if (c > 63) { // is alpha?

>                 if (c > 95) c -= 32; // convert to upper case

>                 c -= control_key_down; // convert to control character

>             }

>             mii_keypress(mii, c);

351a361,367

>         else if (nk_input_is_key_pressed(in, NK_KEY_TAB))

>             sig.data = 'I' - 'A' + 1;

>         else if (nk_input_is_key_released(in, NK_KEY_CTRL))

>             control_key_down = 0;

>         else if (nk_input_is_key_down(in, NK_KEY_CTRL)) {

>             if (!control_key_down) control_key_down = 64;

>         }

# cat nuklear_xlib_gl3.h.patch

644,667d643

<             if (*code == 'c' && (evt->xkey.state & ControlMask))

<                 nk_input_key(ctx, NK_KEY_COPY, down);

<             else if (*code == 'v' && (evt->xkey.state & ControlMask))

<                 nk_input_key(ctx, NK_KEY_PASTE, down);

<             else if (*code == 'x' && (evt->xkey.state & ControlMask))

<                 nk_input_key(ctx, NK_KEY_CUT, down);

<             else if (*code == 'z' && (evt->xkey.state & ControlMask))

<                 nk_input_key(ctx, NK_KEY_TEXT_UNDO, down);

<             else if (*code == 'r' && (evt->xkey.state & ControlMask))

<                 nk_input_key(ctx, NK_KEY_TEXT_REDO, down);

<             else if (*code == XK_Left && (evt->xkey.state & ControlMask))

<                 nk_input_key(ctx, NK_KEY_TEXT_WORD_LEFT, down);

<             else if (*code == XK_Right && (evt->xkey.state & ControlMask))

<                 nk_input_key(ctx, NK_KEY_TEXT_WORD_RIGHT, down);

<             else if (*code == 'b' && (evt->xkey.state & ControlMask))

<                 nk_input_key(ctx, NK_KEY_TEXT_LINE_START, down);

<             else if (*code == 'e' && (evt->xkey.state & ControlMask))

<                 nk_input_key(ctx, NK_KEY_TEXT_LINE_END, down);

<             else {

<                 if (*code == 'i')

<                     nk_input_key(ctx, NK_KEY_TEXT_INSERT_MODE, down);

<                 else if (*code == 'r')

<                     nk_input_key(ctx, NK_KEY_TEXT_REPLACE_MODE, down);

<

681d656

<             }

Anyone else see the Amber mode as blue and the orange in hires coming out amber or is that just me?

softwarejanitor wrote:

Anyone else see the Amber mode as blue and the orange in hires coming out amber or is that just me?

 

OK...  maybe something is messed up for me, but it seems like the HI_RGB in mii_video.c the code was not quite right...  I changed it like this and now things look better to me...

#define HI_RGB(r,g,b)   (0xff000000 | ((b) << 16) | ((g) << 8) | (r))

I also find that changing the mono const like this looks more pleasing for the amber mode:

static const uint32_t mono[3][2] = {

        { 0xff000000, C_WHITE },

        { 0xff000000, C_GREEN },

        //{ 0xff000000, C_ORANGE },

        { 0xff000000, HI_RGB(0xfd, 0xcf, 0x14) },

};

I saw the post on the FB group.  Not sure about the colors thing yet, other than someone else questioned it there.  The butterfly pic in an earlier post here definitely looks like the color palate is backwards compared to the one posted on the FB group.

I will be interested to hear if I'm totally crazy or if the color pallate was off.

Here are the changes that I'm currently running, all in mii_video.c

diff --git a/src/mii_video.c b/src/mii_video.c

index 6c633b0..574a212 100644

--- a/src/mii_video.c

+++ b/src/mii_video.c

@@ -37,7 +37,7 @@ enum {

  * Colors were lifted from

  * https://comp.sys.apple2.narkive.com/lTSrj2ZI/apple-ii-colour-rgb

  */

-#define HI_RGB(r,g,b)  (0xff000000 | ((r) << 16) | ((g) << 8) | (b))

+#define HI_RGB(r,g,b)  (0xff000000 | ((b) << 16) | ((g) << 8) | (r))

 static const uint32_t lores_colors[] = {

        [0x0] = HI_RGB(0x00, 0x00, 0x00),       // black

        [0x1] = HI_RGB(0xe3, 0x1e, 0x60),       // magenta

@@ -66,7 +66,7 @@ enum {

        C_WHITE         = HI_RGB(0xff, 0xff, 0xff),     // white

 };

 -static const uint32_t hires_colors[] = {

+/*static const uint32_t hires_colors[] = {

        C_BLACK,

        C_PURPLE,

        C_GREEN,

@@ -77,6 +77,18 @@ static const uint32_t hires_colors[] = {

        C_BLUE,

        C_ORANGE,

        C_WHITE,

+};*/

+static const uint32_t hires_colors[] = {

+       C_BLACK,

+       C_PURPLE,

+       C_GREEN,

+       C_GREEN,

+       C_PURPLE,

+       C_BLUE,

+       C_ORANGE,

+       C_ORANGE,

+       C_BLUE,

+       C_WHITE,

 };

  static const uint32_t dhires_colors[] = {

@@ -101,7 +113,8 @@ static const uint32_t dhires_colors[] = {

 static const uint32_t mono[3][2] = {

        { 0xff000000, C_WHITE },

        { 0xff000000, C_GREEN },

-       { 0xff000000, C_ORANGE },

+       //{ 0xff000000, C_ORANGE },

+       { 0xff000000, HI_RGB(0xfd, 0xcf, 0x14) },

 };

  @@ -164,7 +177,7 @@ mii_video_run(

                mii_bank_poke(main, SWVBL, 0x80);

                if (mixed && !text) {

                        text = mii->video.line >= 192 - (4 * 8);

-                       hires = 0;

+                       //hires = 0;

                }

                // http://www.1000bit.it/support/manuali/apple/technotes/aiie/tn.aiie.03.html

                if (hires && !text && col80 && dhires) {

BusError wrote:

I pushed quite a few fixes in the last couple of days, mostly fixes for pretty much everything I've seen here, as well as adding Joystick support!

 

I just pulled and built from github and the colors still don't look right to me.  I re-did a few of my changes and with these it looks correct to me.

diff --git a/src/mii_video.c b/src/mii_video.c

index 1e59b10..252c983 100644

--- a/src/mii_video.c

+++ b/src/mii_video.c

@@ -37,7 +37,7 @@ enum {

  * Colors were lifted from

  * https://comp.sys.apple2.narkive.com/lTSrj2ZI/apple-ii-colour-rgb

  */

-#define HI_RGB(r,g,b)  (0xff000000 | ((r) << 16) | ((g) << 8) | (b))

+#define HI_RGB(r,g,b)  (0xff000000 | ((b) << 16) | ((g) << 8) | (r))

 static const uint32_t lores_colors[] = {

        [0x0] = HI_RGB(0x00, 0x00, 0x00),       // black

        [0x1] = HI_RGB(0xe3, 0x1e, 0x60),       // magenta

@@ -72,10 +72,10 @@ static const uint32_t hires_colors[] = {

        C_GREEN,

        C_GREEN,

        C_PURPLE,

-       C_ORANGE,

-       C_BLUE,

        C_BLUE,

        C_ORANGE,

+       C_ORANGE,

+       C_BLUE,

        C_WHITE,

 };

@@ -101,7 +101,7 @@ static const uint32_t dhires_colors[] = {

 static const uint32_t mono[3][2] = {

        { 0xff000000, C_WHITE },

        { 0xff000000, C_GREEN },

-       { 0xff000000, HI_RGB(0x14, 0xcf, 0xfd) },

+       { 0xff000000, HI_RGB(0xfd, 0xcf, 0x14) },

 }; 

The first change fixes RGB order, the second swaps orange and blue to be correct and the 3rd one makes the amber correct instead of blue.

mii_lowres.png

low res colors 0-15

mii_hires.png

hires colors 0,7

mii_total_replay.png

Total Replay in color

mii_amber.png

Total Replay in amber

Those match my real //e pretty close.

I created a pull request on github with those changes.

When I did a fresh pull I didn't see any changes at all in mii_video.c related to the colors.  I did see changes for the soft switches  Did you look at the diff I posted above or the pull request?  You can see what I did.

The orange in what you just posted really doesn't look right though.  It's way too yellow.

Here is a better illustration of what the colors look like after my changes:

mii_hcolors.png

Note that the blue is a light blue and the orange is very redish

hcolors_source.png

hirescolors2e.jpeg

Bad pic due to backlighting, but you can see the colors on my real //e.  Not a 100% perfect match to what I'm seeing in the emulator, but it is pretty close.  My //e is outputting through a Briel Apple VGA card though, so its color may not be exacly what you'd see on a composite color monitor or TV with RF modulator either.

BusError wrote:

I don't see a pull request either... https://github.com/buserror/mii_emu/pulls

I so see differences, but tnothing to explain the channel swap for amber, for example!

 

The color difference might be explained by the Briel card -- I use the A2 VGA card too here, and the blue is a lot washed out than many of the screenshots (real shots of screens) I've seen. I picked up

For some reason github isn't letting me create a pull request from my fork to your original repo.  It is supposed to have a "yellow banner" but I am not seeing it.  Looking at the history it appears some of the changes may have been made in your repo, but they are not showing on the main branch so if people clone it and build they may not be getting the latest correct code.

I just did a fresh clone from github and made it and for whatever reason it isn't working for me.  I was trying to use disk images I'd used with older versions and they just "spin" forever and nothing happens.  How do you get the menus to come up?  I see nothing, just a blank window.

Like this: 

build-x86_64-linux-gnu/bin/mii_emu_gl -s 6:disk2 -d 6:1 disks/prodos242.dsk

I get nothing but a black window.

BusError wrote:

Hmm what distro/graphic card are you using? I made an asumption in this version that the non-power-of-two texture were now available in OpenGL everywhere, but I might have been a bit too optimistic!

Ubuntu and a i7 10th gen with the Intel HD graphics.

It has been a while since I played with mii_emu...  I don't even remember what keys were ctrl-reset or brought up the menus or anything.

BusError wrote:

It should be fixed now. Works on my laptop anyway (also old i7 with Intel GPU).

 

You don't /really/ have to specify a command line anymore -- when you launch, it has a 'Machine' menu where you can configure the disks etc... and reboot from there

Yes, it is working now!  Looks nice so far.  I am running XPS Diagnostics //e on it just for grins.

Color bar test still looks whacked.

Screenshot from 2024-01-22 11-52-38.png

Looks like exactly the same issue I've seen all along.

Here is after I re-applied the changes I posted above to mii_video.c

Screenshot from 2024-01-22 12-01-17.png

leeh@leeh-ZBOX-MI622-MI642-MI662NANO:~/src/mii_emu$ git diff

diff --git a/src/mii_video.c b/src/mii_video.c

index 7b7c223..6d33719 100644

--- a/src/mii_video.c

+++ b/src/mii_video.c

@@ -39,7 +39,7 @@ enum {

  * and

  * https://www.mrob.com/pub/xapple2/colors.html

  */

-#define HI_RGB(r,g,b)  (0xff000000 | ((r) << 16) | ((g) << 8) | (b))

+#define HI_RGB(r,g,b)  (0xff000000 | ((b) << 16) | ((g) << 8) | (r))

 static const uint32_t lores_colors[] = {

        [0x0] = HI_RGB(0x00, 0x00, 0x00),       // black

        [0x1] = HI_RGB(0xe3, 0x1e, 0x60),       // magenta

@@ -103,7 +103,7 @@ static const uint32_t dhires_colors[] = {

 static const uint32_t mono[3][2] = {

        { 0xff000000, C_WHITE },

        { 0xff000000, C_GREEN },

-       { 0xff000000, HI_RGB(0x14, 0xcf, 0xfd) },

+       { 0xff000000, HI_RGB(0xfd, 0xcf, 0x14) },

 };

  @@ -428,4 +428,4 @@ mii_video_init(

 {

        mii->video.timer_id = mii_timer_register(mii,

                                mii_video_timer_cb, NULL, MII_VIDEO_H_CYCLES, __func__);

-}

\ No newline at end of file

+}

I've had a few weirdnesses with the menu and a couple crashes so far.  I will try to see if I can reproduce them.

BusError wrote:

I'm fairly sure I've nowe got a proper fix for that problem you have (and I don't see here!) seems the OpenGL implementation vs little-endian pixels are a problem. I've also already fixed some problem with the lowres (and double low-res colors) so it's being worked on!

I worked a lot to get 1.5 out with the new UI, and I've got a bit of a backlog of things to do in the emulation proper --

Weird that you don't see that color issue, are you running it on an x86-64 machine or something with an ARM?  Endianes should be the same on all Intel/AMD based Linux boxes.  The little Zotac Z-Box Nano I have is about as plain vanilla and ordinary hardware as you can get and I'm running a recent updated and standard install of Ubuntu.  I don't see color werdness in any other apps including LinApple.

There is a whole directory of diagnostic software on Asimov.

https://mirrors.apple2.org.za/ftp.apple.asimov.net/images/disk_utils/diagnostics/

"COLOR DEMOSOFT" from the DOS 3.3 SYSTEM MASTER is also a good low-res color bar test.  Or COLOR DEMO for IntBASIC.

Looks nice, but don't have a Linux native box so would have to run a VM ot run a VM... doesn't sounds great.Do you know of anyone working on getting a windows build? Looks like some of the tools will be available with windows, so easy right? =) 

BusError wrote:

Ah well, I very rarely used windows unless forced to, so I have no plan of starting now :-) -- I'm sure someone will port it, or, pehaps I'll port it to WASM to run it in the browser at some point...

Yeah, I think I'd rather have a root canal than use Windows let alone develop for it.  Every time I'm forced to deal with it I get reminded just how awful it is and how clunky the user interface is compared to MacOS, let alone Ubuntu.  It's even worse for development, all the tools for Windows are either stupidly expensive or a real pain in the ass to install.  MacOS at least has Brew, although it isn't nearly as good as apt and doesn't have nearly the amount of stuff available.  Windows everything just $$$ in their app store and not much there.

BusError wrote:

Ah well, I very rarely used windows unless forced to, so I have no plan of starting now :-) -- I'm sure someone will port it, or, pehaps I'll port it to WASM to run it in the browser at some point...

Yah, me too but I gotta use it. =(

I never got beyond dos app development, so hopefully somone with that skillset will see the value in doing the work. Can't be too hard, right? lol